►
From YouTube: IETF102-SECEVENT-20180720-0930
Description
SECEVENT meeting session at IETF102
2018/07/20 0930
https://datatracker.ietf.org/meeting/102/proceedings/
B
D
E
C
F
H
G
A
I
I
I
think
I
kind
of
like
that
Mike
my
notes
here
a
little
redundant,
so
it's
it's
already
being
referenced
in
two
places.
One
of
those
is
open.
Id
connect
back
channel
logout,
where
it's
a
message
being
sent
back
channel
I,
don't
know
if
you
want
to
add
anything
to
that
Mike.
You
are
much
more
familiar
with
that.
J
I
Thank
you
Mike
and
then
the
other
place
its
references
in
risk,
which
is
another
open,
ID
foundation.
Standard
risk
is
standard
for
providers
to
share
signals
about
mutual
customers
for
them
to
talk
about
what's
happening.
In
account,
transitions
are
in
each
of
their
sites
to
help
the
sites
together
by
sharing
information,
better
protect
their
common
customers
and
the
set
is
effectively
the
core
message.
It's
going
back
and
forth
between
providers.
I
G
A
G
L
Well,
that's
much
better:
okay,
Wow,
okay
cool,
so
the
consensus
we
arrived
at
in
London
was,
since
there
is
general
agreement.
Neither
one
of
these
could
be
MTI
for
everyone
that
we
should
split
the
single
delivery
draft
into
two
different
drafts,
one
for
each
in
a
variant
of
the
protocol.
So
that's
what
this
is
for
the
push
side.
This
document
was
basically
directly
copied
from
the
combined
delivery
draft
and
then
had
all
of
the
pull
parts
pruned
out
of
it.
L
So
it's
pretty
straightforward
when
a
event
transmitter
wants
to
send
a
set
to
an
event
receiver.
They
make
an
HTTP
POST
to
the
receivers
events
endpoint
with
the
set
in
the
request
body.
Next
success
response
is
simple
and
obvious:
202
accepted
we're
using
accepted
because
we're
not
actually
processing
the
set,
necessarily
we're
just
recording
it
to
be
processed
asynchronously
out-of-band.
This
is
basically
just
informing
the
the
transmitter
that
this
set
has
been
received
and
the
receiver
is
taking
responsibility
for
handling
it
from
their
next
error.
L
L
So,
where
we're
at
we,
the
kind
of
initial
cut
of
this
push
only
draft
in
April.
It
needs
to
be
edited
and
pared
down.
So
it's
not
just
a
heavy
copy
from
the
original
draft
mm-hmm.
As
far
as
implementations
go
Google
has
a
transmitter
up
and
running.
They
are
working
on
a
receiver.
I
believe.
Is
there
anyone
from
Google
who
can
confirm
that
maybe
not
yeah
Amazon
working
on
receiver
and
transmitter
and
we're
working
with
Google
to
get
those
interoperable
I
think
that's
the
last
slide
all
right.
So
that's
it
short
and
sweet.
M
If
I
can
make
a
quick
observation
as
somebody
who
deals
with
HTTP-
and
it's
not
very
familiar
with
this
draft,
when
you
started
talking
about
HD
per
MP
push,
this
is
not
what
I
expected
that's
kind
of
an
overloaded
term,
so
we
might
be
one
of
the
maybe
hadn't
find
a
different
word
for
this.
Okay,
okay,
I.
L
L
I
J
That
makes
it
less
likely
to
work
Mike,
Jones,
Microsoft
I'll,
be
talking
about
the
other
transport
draft,
the
Paul
based
draft
and,
as
I
said
on
the
list,
I'll
give
you
the
caveat.
I
had
not
read
the
predecessor
draft
in
quite
some
time
and
so
for
good
or
for
bad.
What
you're,
seeing
on
my
slides
to
come
and
what
you
already
saw
on
the
list.
J
If
you
were
reading
it
was
my
reactions
to
what
the
state
of
the
Paul
draft
is
and
some
of
the
comments,
as
all
say,
as
we
go
through
apply
to
both
because
there's
a
lot
of
text
shared
between
both
it
did
work.
What
do
you
know?
So?
What
is
this
it
is?
It
defines
a
polling
based
delivery
mechanism
for
sets,
as
Annabelle
said,
both
of
these
drafts
are
essentially
just
a
copy
of
the
draft
that
used
to
have
two
mechanisms
in
it,
while
rejecting
the
one
that
doesn't
apply.
J
The
first
normative
thing
that
bothered
me
about
the
poles
draft
is
that
there's
duplication
of
information,
which
is
nearly
always
a
bad
thing
in
a
protocol.
It
puts
the
jot
ID
both
in
a
object
member
tag
and
in
the
value
of
the
object
by
copying
it
out
of
the
set
and
putting
it
in
a
second
place.
I
think
we
should
drop
the
second
value
and
just
send
the
set.
I
will
note
that
that
would
make
it
more
parallel
with
the
other
transmission
spec,
which
is
just
sending
the
set
and
is
not
duplicating
that
value.
L
And
Backman
Amazon
just
to
provide
context
for
the
design
as
it
currently
as
I
believe.
The
rationale
for
that
and
I'm
acting
as
a
secondhand
messenger
here,
was
that
by
putting
the
jti
in
as
a
proper
as
a
key
in
the
JSON
object,
it
would
allow
a
processor
of
that
to
filter
out
and
skip
sets
that
it
had
already
processed
just
based
on
jti.
We
can
argue
whether
or
not
that
kind
of
efficiency
optimization
is
worth
it
I'm,
not
100%
convinced
it
is
myself,
but
that's
I,
believe
that
was
the
rationale
for
that
decision.
J
One
of
the
generic
problems
with
doing
this
sort
of
thing
is
you
introduce
error
cases
that
otherwise
could
not
occur.
You
all
of
a
sudden
have
to
check
that
the
jti
in
one
place
is
the
same
as
the
jti
in
the
other,
and
so
in
fact
you
can't
just
ever
use
the
first
jti.
You
still
have
to
check
so
I
would
propose
that
we
delete
the
first
one.
K
L
And
about
back
when
Amazon
said
in
order
to
acknowledge
the
set
as
received
I,
think
you
at
least
need
to
make
sure
you
can
parse
the
set,
so
you'd
still
need
to
kind
of
crack
it
open
and
do
your
signature,
validation
and
all
of
that
anyway.
So
if
that's
the
use
case,
I,
don't
really
think
it
applies.
L
J
J
L
And
about
Backman
Amazon,
given
that
the
hums
are
going
to
be
taken
to
the
list
anyways
generally
as
convention,
does
it
is?
Is
there
a
need
for
us
to
delay
decision
until
that
point,
or
can
we
at
least
get
a
sense
of
where
we
are
at
those
of
us
who
are
actually
here
in
the
room
where
we're
at
the
best.
A
C
O
J
L
And
back-nine
Amazon
I'm
going
to
provide
context
for
this,
especially
for
people
who
may
not
be
as
familiar
with
it.
The
scenario
we're
talking
about
here
is
when
max
events
is
zero.
A
return
immediately
of
us
doesn't
really
have
meaning
like
they're.
Just
gonna
keep
the
connection
open
forever,
like
it's
kind
of
a
nonsensical
undefined
scenario
which
it
may
be
suggests
that
we
should
be
rethinking
how
these
parameters
work
in
general
or
how
they're
defined
in
general,
so
we're
not
creating
opportunities
for
undefined
scenarios.
I
agree.
J
J
A
K
G
C
J
F
J
Okay
and
there's
a
big
architectural
thing
in
this
draft
that
I
readily
admit
I,
don't
understand
why
it's
there.
It
says:
that's
that
sets,
may
reissued
may
be
reissued,
it
doesn't
define
any
conditions
in
which
they
should
or
must
be
reissued.
So
I
think
as
currently
written.
A
legal
implementation
could
never
reissue
them.
Other
implementations
might
reissue
them.
This
seems
like
a
source
of
interoperability
problems.
I
think
we
should
either
say
under
what
conditions
there
to
be
reissued
or
drop.
The
whole
reissuing
notion
entirely.
L
A
L
There's
nothing
along
those
lines
in
the
spec
that
you
know
theoretically,
I
think
you'll
be
given
the
way
it's
written.
That
could
be
a
compliant
implementation.
The
spec
does
define
a
mechanism
by
which
a
recipient
can
say
yes,
I
successfully
received
yes,
I
successfully
received
this
set
or
no
I
did
not
really
receive
this
set.
I
I
got
this
error
in
processing
that
one
so.
L
It's
about
there's
sort
of
a
state
management
problem
here
that
the
transmitter
has
to
deal
with
where
they
have
this
queue
of
sets,
some
of
which
have
been
downloaded
by
the
recipient
but
haven't
yet
been
acknowledged,
and
they
kind
of
have
to
sit
in
this
state
of
flux
and
at
some
point
those
either
transition
to
acknowledged
or
available
to
be.
Okay.
L
K
J
J
J
J
J
P
The
blasted
thing
is
going
to
want
to
be
able
to
read
a
thing
and,
most
importantly,
let's
face
it,
implement
the
examples
in
one
document
and
try
to
get
everything
that
they
need
in
there
without
surprises
having
implemented
Jose.
Having
implemented
the
assertions
framework
having
stuff
I'm
I'm.
Agreeing
with
the
point
that
I
think
Mike
is
about
to
make
having
to
reference
out
to
the
abstract
it
pieces
is,
is
awful.
P
P
M
L
Anabel
Beckman
Amazon
I
generally
agree
that
having
duplicate
text
is
something
we
want
to
avoid.
That
said,
I
think
there
are
situations.
For
example,
you
know
references
out
to
you
know,
insecurity
considerations
to
tell
people
to
refer
to
this,
the
BCP
on
how
to
do
OAuth
securely
if
you're
going
to
use
bearer
tokens
with
this
as
an
authentication
mechanism
like
that
I
think
is
text
that
you're
going
to
see
duplicated
across
a
wide
variety
of
traps,
just
because
they
happen
to
be
dealing
with
baritone
I.
L
L
Think
a
lot
of
the
other
text
in
the
current
drafts,
as
they
stand
right
now,
at
least
from
the
perspective
of
push
is
stuff
that
should
be
culled
from
the
document.
I
posted
some
analysis
of
this
on
the
list.
I'm
not
going
to
repeat
it
here,
but
I'll.
Let
people
review
that
I
think
it
would
help
us
make
the
right
decision
here.
L
If
and
I'll
take
this
as
an
action
item,
if
I
publish
an
o1
Draft
at
least
a
push
that
pulls
out
the
text
I'm
suggesting
we
pull
out,
and
at
that
point
that
then
we
can
see
what
really
is
duplicated
between
the
two.
As
far
as
a
real,
meaningful,
normative
text
is
concerned,
and
that
might
tell
us,
is
there
enough
here
to
pull
it
out
to
where
a
third
document
is
really
justifiable
or
do
we
keep
it
in
push
and
reference
it
from
poll
or
vice
versa?
Or
do
we
just
recombine
them
we'll
see.
D
K
K
J
J
So
it's
not
like
we
would
be
breaking
new
ground
and
doing
something
unprecedented
I,
think
editorially
and
in
terms
of
understanding
it
for
implementers.
That's
the
cleanest
thing
to
do.
There's
a
third
alternative
which
isn't
on
the
slides,
which
I
at
least
dick
and
I
and
Annabelle
talked
about
in
the
hallway,
which
is
we
could
do
like.
J
We
did
between
jws
and
jwe,
there's
a
bunch
of
normative
stuff
in
jws,
like
the
definition
of
base64
URL
that
when
referenced
or
when
used
in
jwe,
it
just
says:
do
it
like
you
did
in
jws,
for
instance,
we
could
do
a
push
spec,
which
is
complete
and
appalled
spec,
which
every
time
something
is
the
same.
You
have
a
section
that
says
this
is
the
same
as
that
section
in
this
other
dog
and
then
at
least
you're
out
of
the
duplication
world,
and
it's
still
easy
to
read.
A
L
About
Backman
Amazon,
so
two
points:
one
I
think
that,
if
set
is
broadly
successful,
it's
inevitable
that
we
will
have
other
distribution
specs
over
time
and,
most
of
or
at
least
a
lot
of
what
is
normative
and
duplicated
between
these
two
that's
shared
between
push
and
pull
I.
Think
a
lot
of
that
is
stuff
that
will
be
broadly
useful
to
other
distribution
methods
as
well,
for
example,
the
error
codes.
L
L
Take
that
the
other
point
I
wanted
to
make
is
I.
67
49
s
been
cited
as
an
example
where
this
sort
of
either-or
method
of
spec
writing
has
has
been
employed
and
has
been
successful.
I
question:
that
is,
somebody
who's
worked
with
a
lot
of
clients.
Who've
been
you
know,
trying
to
implement
OAuth,
2
I.
Think
the
collection
of
different
mechanisms
in
that
in
that
document
leads
to
a
lot
of
implementation.
Confusion.
Q
L
J
Agree,
although
I'll
note
that,
in
practice
having
to
delivery,
specs
or
whether
having
to
delivery
mechanisms,
no
matter
how
they're
factored
editorially
still
means
that
implementers
will
have
to
make
choices
about,
do
I
build
one,
do
I
build
the
other.
Do
I
build
both
just
like
they
have
to
make
those
choices
and
owe
us
so
we're
not
removing
that
need
to
understand
your
problem
space
in
order
to
decide
what
to
build.
I
L
J
K
Benkei
nook,
so
with
respect
to
error
codes
in
particular,
is
absolutely
the
common
thing
to
do
to
say,
you're.
The
first
document
in
a
given
space
defines
the
initial
set
of
error.
Codes
creates
the
registry
and
then
everything
else
that
follows
refers
to
the
registry
as
their
sources
are
correct.
You're
not
referring
to
the
document
you've
heard
of
the
registry.
K
H
K
So
you
know,
since
a
couple
of
implementation,
since
only
a
couple
of
imitations
exist,
you
could
also
consider
a
new
proposal
like
SSTP,
which
is
similar
to
both
and
unifies
the
method.
There's
only
one
implementation
of
push
transmitter
and
I
disagree
with
Annabel.
The
whole
point
of
forming
second
event
was
to
develop
a
universal
delivery
method,
so
we
don't
expect
to
have
you
know
new
to
the
free
methods
popping
up
willy-nilly
and.
I
So
I
think
it'd
be
useful,
just
to
drive
clarity
on
that
one
point
as
to
whether
people,
whether
there's
an
appetite
for
changing
from
what
we
have
now
with
multiple
delivery
to
a
single
delivery
and
maybe
get
a
show
of
hands.
The
two
options
would
be
continue
on
our
current
path,
where
we
have
a
push
and
pull,
and
the
other
option
would
be
to
a
single
delivery
that
Phil's
proposing
so
show
of
hands
aren't
to
continue
with
the
current
path.
K
J
I
J
K
Ben
cake
is
responsible,
ID
I
have
to
apologize
for
not
having
read
both
of
these
drafts
in
detail,
but
I
think
it
would
be
easier
to
make
a
decision
on
this
question
if
we
have
a
sense
of
what
types
of
things
are
actually
duplicated.
We
know
that
the
the
error
codes
are
duplicated,
I
assume
as
obvious
the
six
of.
J
All
the
background
of
the
introduction,
the
description
of
why
you
would
deliver
events.
What
events
are
terminology?
It's
all
duplicated.
The
only
thing
that's
not
duplicated
is
the
actual
delivery
mechanisms.
The
security
considerations
are
entirely
duplicated.
The
implementation
guidance
is
entirely
duplicated.
The
references
are
entirely
duplicated.
P
Just
enricher
I
am
actually
fine
with
that
approach
as
an
as
an
ultimate
goal,
but
again
I
encourage
the
editors
to
keep
an
engineer's
hat
on
for
at
least
part
of
this
cope.
Oh
sorry,
with
the
approach
that
mike
is
suggested
of
keeping
most
of
the
content
in
the
push
spec
and
have
it
reference
from
the
poll
spec,
but
I
encourage
the
editors
to
keep
in
implementing
engineers
hat
on
someone
who
doesn't
want
to
click
open.
Another
browser
tab
to
read
a
different
document,
because
it's
a
nightmare
to
cross-reference
absolutely.
P
L
L
I
do
think
that
once
we
do
the
editorial
pass
on
push
a
lot
of.
What
is
duplicated
right
now,
as
you
know,
are
things
that
just
don't
need
to
be
there
like.
If
you
look
at
the
definition
section,
for
example,
that's
that
should
be
a
one-line
section
that
says
we
use
things
defined
and
set
everything
all
of
the
definitions
listed.
There
are
things
already
defined
in
set,
except
for
a
numeric
date,
which
bush
does
not
actually
use
so
right
there
you
should
reference
John,
sure,
yeah.
L
D
I'm
not
like
I
think
you're
making
work,
because
this
is
the
specs
are
there
today
they
may
evolve
and
they
they're
separate
documents
today,
okay,
if
you're
gonna
get,
if
you
want
to
have
their
common
text,
you
need
to
combine
them
into
a
single
document.
So
so
the
people
that
are
implementing
don't
have
to
jump
back
and
forth
between
these
two
specs.
They
can
read
one
spec.
Some
people
are
only
going
to
implement
push,
some
people
are
only
going
to
implement
and
they
have
to
read
the
other
day.
Q
D
K
L
L
J
L
Front-Row
seats,
you're
stuck
okay,
Annabelle
Beckman
Amazon
again
to
talk
about
subject:
identifiers
for
security
event.
Tokens
next,
so
apologies
for
the
confusion
here.
This
was
something
that
originally
started
in
a
ID
insect
events
that
didn't
get
adopted.
So
he
pulled
it
into
risk
and
then
in
London
we
talked
about
hey.
Could
we
pull
this
out
on
its
own
and
just
cover
a
subject?
Identifiers
within
set
people
were
interested
in
that
I
submitted
it
as
an
ID
and
then
went
back
and
realized
hey.
L
L
It
doesn't
work
for
every
situation
as
far
as
identifying
the
subject
of
the
token
or
of
the
set
we
ran
into
this
in
risk,
where
we
have
use
cases
for
supporting
a
variety
of
different
ways
of
identifying
a
subject
could
be
email
could
be
phone
number
as
well
new
ones
that
we're
coming
up
with
over
time,
and
it
is
helpful
to
provide
a
unambiguous
way
to
state
what
kind
of
or
how
you're
identifying
the
subject.
So
we're
not
trying
to
parse
the
format
of
strings
to
determine
you
know.
Is
this
a
phone
number?
L
Is
this
an
email?
That's
not
a
place.
We
want
to
be
in
the
the
other
party.
It's
a
subset
of
that.
That
problem
is,
if
you
have
complex
identifiers
that
are
multi-part,
for
example,
issue
or
in
subject.
That's
two
claims
right.
It's
not
one
claim
if
you
have
a
scenario
where
the
issuer
for
your
subject,
identifier
is
different
from
the
issuer
for
your
set.
Then
you
need
some
way
to
put
that.
Subject.
Issuer
with
that
subject
claim
together,
and
you
can't
really
do
that.
If
all
you
have
is
a
single
string
field,
so.
L
Are
you
done
okay,
so
just
as
an
example
for
some
context,
what
this
looks
like
in
risk?
We
we
have
this
subject
claim
within
our
event,
payload,
and
this
shows
up
in
all
of
the
risk
events
and
that's
where
we
put
any
claims
that
we
use
to
identify
the
subject
as
well
as
a
subject,
type
claim
that
I'll
get
to
in
a
moment.
So
next.
L
So
what
do
we?
What
would
we
actually
have
in
this
draft?
We
start
with
defining
subject
identifier
types,
which
is
just
a
basically
a
schema
for
what
claims
you
use
to
identify
a
subject
using
some
type
of
data
using
an
email
using
a
phone.
You
know
what
claim
do
you
use
for
that?
What
format
do
you
put
the
data
in?
L
L
L
They
might
also
have
email,
they
might
also
have
phone
and
the
the
opie
does
not
necessarily
know
which
of
those
the
client
is
using
in
their
system
to
tie
their
local
account
to
the
the
account
at
the
opie,
ideally
they're,
using
issuer
and
subject,
but
a
lot
of
people
it
turns
out
in
practice.
Don't
do
that,
so
it's
helpful
for
the
the
opie
to
always
specify
in
a
set
all
of
the
potentially
identifying
claims
that
they
sent
in
an
ID
token.
L
L
R
R
L
R
L
Okay,
well,
then,
potentially
we
need
to
clarify
what
the
semantics
should
be
around
a
type
III
I,
don't
think
you
want
to
have
if
you
look
at
two
more
identifiers
with
the
same
type
and
with
the
same
claims
I
should
mean
the
same
thing,
and
so
you
know,
if
one
is
an
email
address,
the
other
should
be.
The
same.
Value
should
be
the
same
email
address.
So
you
know
just
if
we're
talking
about
like
names
facing
issues
of
things
that
look
the
same
but
are
actually
different.
P
Justin
you
wanna
yeah,
just
Richard
to
partially
respond
to
life
in
the
wild.
What
I
think
ends
up
happening
with
a
lot
of
these
you
know
use
a
URI
kind
of
thing
is
that
somebody
defines
a
you
RN,
and
then
you
have
to
register
underneath
that
you
RN,
and
so
you
basically
just
punt
the
registry
to
a
different
registry
for
a
little
bit.
We
have
this
with
the
the
OAuth
grant
types.
You
know,
there's
there's
no
Oh
auth
grant
type
registry,
except
that
there
is
it's
just
not
called
the
oauth
grant
types
registry
anymore.
P
It's
the
oauth,
Joran
thing,
because
that's
what
you're
supposed
to
use
and
yeah,
yeah
and
and
there's
stuff
like
this
all
over
sam'l
uh-huh
as
well,
there's
like
so
many
different.
You
RN
things
in
sam'l
that
so,
let's
just
register
the
short
strings
and
just
admit
that
that's
what
we're
going
to
do
anyway
and
leave.
L
O
A
These
don't
look
like
identifiers,
especially
when
you
have
a
token
idea,
whatever
that
is,
and
email
and
phone
number
in
the
same
so
cause
identifiers.
Well,
you
might
have
multiple
people
sharing
the
same
phone
number,
but
different
email
addresses
and
vice
versa,
and
so
there's
a
lot
of
hidden
semantics
behind.
How
do
you
actually
match
a
record
to
whatever
this
thing
is?
A
L
Think
he'd,
there's
probably
room
to
be
clearer
about
the
semantics
here.
I
think
that's!
That's
good
feedback
that
we've
heard
a
couple
of
times
now
regarding
things
like
phone
number,
the
phone
number
itself
is
essentially
the
subject
here.
If
you
look
at
again,
the
risk
use
case
is,
it's
say:
Google
sending
a
set
to
Amazon,
where
the
only
link,
the
only
common
piece
of
information
we
have
is
that
we
both
have
accounts
related
to
phone
numbers
and
it
on
our
side.
There
are
multiple
accounts
related
to
that
phone
number.
That's
fine!
L
G
I
Is
is
in
your
kind
of
open,
ID
connect
where
you've
sent
over
a
claim
like
this?
Each
of
these
is
a
global,
unique
identifier
for
the
user,
they're
all
for
the
same
user
and
the
recipient
might
affect.
One
of
these
two
stories
are
identifiers,
but
the
sender
didn't
know
which
one
and
so
I
need
to
send
all.
Q
L
A
L
L
Ideally,
you
know
if
people
are
doing
things
the
quote/unquote
right
way
as
a
relying
party,
you
are
storing
issuer
subject
in
your
database
and
using
that
as
your
lookup
key
to
match
things
to
account.
So
you
have
this
nice
one-to-one
relationship
in
the
real
world.
It
doesn't
work
that
way
and
you
have
a
lot
of
our
piece
who
do
matching
based
on
email
and
phone
number,
and
so
the
the
intent
here
is
to
again.
The
assumption
is
Dixit
is
all
of
these
belong
to
the
same
account
at
the
at
the
opie
and
the
the
RP.
L
Yet
they
have
to
pick
the
use,
whichever
ones
they
chose
to
use,
how
they
do
that
is
really
going
to
be
dependent
upon
how
they're
managing
their
mappings
and
I
don't
there's.
Probably.
We
should
probably
clarify
in
this
the
definition
for
this
type,
that
that's
the
purpose
here
and
that's
the
intent
but
yeah
I,
don't
think
we
can
be
prescriptive
about
how
that
matching
ends
up
working.
L
K
Actually
looks
very
good.
The
only
minor
thing
that
comes
up
is
that
you
are
creating
a
new
registry,
and
I
am
generally
wants
to
know
like
what
page
of
registries
it
should
go
under
I
think
there
is
a
page
of
set
registries,
but
I
don't
remember
offhand.
You
can
definitely
ask
them
to
take
a
look.
You.
K
They're
happy
to
take
an
early
look
see
if
it's
clear
with
respect
to
sort
of
the
point
that
your
own
raised,
that
we
were
talking
about
for
a
while.
It
seems
like
it's
pretty
reasonable
to
ask
the
document
that
is,
you
know
creating
that
registry
entry
to
nail
down
what
the
semantics
are.
You
know
like
for
this
ID
token
claims.
K
You
know
it
would
say
well
potentially
say
if
I
understand
correctly,
that
you
need
to
be
including
all
of
the
claims
that
were,
in
the
ID
token,
that
you're
referring
to,
because
you
don't
know
which
ones
are
being
used
as
the
database
key
or
your
whatever
semantics
we
actually
want,
and
you
should
nail
down
what
the
semantics
are.
John's.
P
K
K
Can
be
or
just
can
be
used
in
a
space
katrin's
environment
because
the
sets
are
jots
and
they
may
need
to
be
passed
and
constricted
spaces.
So
getting
towards
do
you
want
the
long
or
the
short
identifiers
and
I'm
also
hearing
that
some
set
scenarios
are
being
used
for
attestation,
so
using
your
eyes,
for
that
would
really
expand
the
size
and
costs
of
retention.
R
So
if
you're
in
the
standard
claims
right,
if
you
want
to
check,
if
you
want
to
add
a
standard
claim,
then
we
erase
the
bar
right
for
entry
right
and
if
it's,
but
it
was
using
your
eyes
anybody
any
group
of
collaborating
entities
can
do
what
they
want
without
risk
of
collision
and
I.
Think
what's
gonna
happen
here
in
practice
is
that
people
are
just
gonna
do
what
they
want
right
there.
It's
it
Jason
right.
R
The
expectation
is
that
your
stick
like
attributes
in
there
and
have
about
it
right
and
so
I,
don't
think
any
nobody's
ever
gonna
bring
a
registration
other
than
the
ones
we
defined
in
this
document
right
people
are
you're,
gonna,
I'm,
gonna
define
an
EP
p.m.
subject,
type
right
and
that's
the
edgy
person
principle
named
Wright
has
semantics,
but
these
things
are
gonna
leak
right,
somehow
right,
they're
gonna,
because
we
don't
have
like
hermetically
sealed
off
compartments
in
the
world
right,
so
I
and
I
think
that's.
The
research
is
to
avoid
those
kinds
of
collisions.
P
Justin
Richards
is
why
life
is
full
of
it.
No
I
mean
in.
He
is
absolutely
right
in
that
these
things
will
just
get
defined
and
used
and
leaked,
but
that's
because
the
IETF
has
no
enforcement
arm
as
much
as
we
like
to
pretend
that
our
rfcs
are
law
they're,
not
people
will
ignore
them
and
yeah,
because
URLs
never
have
weird
collisions
or
fun
things
like
that,
and
but
yeah
you
ever
tried
to
use
LOA
URLs
across
system
boundaries
dude
seriously.
P
Well,
it's
as
soon
as
VOT
is
published.
Yes,
I
agree
with
you
by
then
been
pushed
a
button
we're
on
our
way,
but
but
no
seriously,
URLs
don't
magically
fix
that
you
our
eyes,
don't
magically
fix
that
leakage
problem
anyway,
and
so
I
I
I
go
back
to
saying
that
so
the
short
may
claim
names
with
as
been
brought
up
very
clear
semantics
as
to
what
this
object
actually
means
is
probably
our
best
stab
at
having
well-meaning
implementers.
Do
the
right
thing
a
lot
of
the
time.
I
I
L
I
K
S
Can
I
comment
on
the
color
of
the
bike?
Real,
quick
well,
of
course,
I
know.
I
know
these
are
at
least
in
the
set
world
their
sizes,
maybe
not
a
huge
thing
but
like
I,
see
something
like
subject
and
then
subject
type
under
that
I'm
wondering
if,
like
the
tiny,
couldn't
just
be
type
or
underscore
type
or
something
that's
not
as
redundant,
and
maybe
just
a
little
bit
shorter
for
cases
where
these
might
might
end
up
in
more
space
constraint
needs
just
a
little
I.
S
L
Q
L
S
I
can
the
in
in
the
moderna
working
group
of
the
open
idea
foundation.
They
have
what
they're
calling
Seba
client
initiated
back-channel
authentication,
which
has
its
its
own-
that
there's
a
world
of
hurt
there,
but
one
one
of
the
things
is:
it's
basically,
a
back-channel
invocation
from
a
client
to
an
authorization
server
asking
for
user
authorization
around
something,
but
it's
all
out-of-band
user
authorizations,
out-of-band.
So
the
subject
that
the
user
has
to
be
identified
some
way
or
hinted
to
in
that
request
and
there's
a
few
different
ways
that
you
can
kind
of
do
it.
S
But
one
is
a
structured
token
where
the
client
can
say:
hey
here's,
what
I
know
about
this
person
and
being
able
to
say
what
the
type
of
subject
is
and
identify
the
type
inside
of
that.
Much
like
this
I
think
would
be
a
useful
way
to
not
constrained
but
just
narrow
down
how
how
the
input
sadaqa
works.
N
Dave
can't
better
say
this
may
be
a
color
of
the
bike
shed
coming
to,
but
it
looks
if
these
are
examples,
but
you've
mentioned
schema
before
it
looks
a
little
unusual
to
have
a
type
structured.
The
way
it
is,
in
other
words,
in
this
example,
your
subject
is
an
OAuth
token.
The
value
of
an
OAuth
token
has
three
fields
in
a
token
type
identifier
to
it.
N
L
L
So
is
it
really
that
big
of
a
deal,
maybe
not
but
I-
think
from
the
standpoint
of
a
implementer
reasoning
about
the
the
format
seeing
okay
get
subject:
type
and
I
look
at
that
and
then
you
know
I
I
case
on
a
statement
on
that
and
figure
out
what
what
I
need
to
read
from
there.
I
think
that
leads
to
a
clearer
path
to
implementation,
but
that
maybe
preference.
K
L
You're
talking
about
having
specifically
having
multiple
values
for
one
of
the
claims
within
a
subject
identify
are
not
having
multiple
subject
identifiers.
Is
that
right,
correct?
Okay,
we
talked
about
the
latter
some
and
it
might
apply
here
as
an
alternate
way
to
get
what
you're
you're
looking
for.
We
talked
about
whether
or
not
we
needed
in
risk
subject
itself
to
be
an
array
and
the
the
decision
we
made
there
was
subject
itself
can
be
a
single
value
or
so
an
object,
and.
L
Majority
case,
and
then
if
there
are
other
subjects
or
other
subject,
identifiers
is
that
the
sender
needs
to
include
in
that
then
we
they
could.
The
event
could
define
a
subject
aliases
or
aliases
value,
and
it's
excuse
me
and
aliases
property
in
its
event,
payload
and-
and
that
could
be
a
list
that
way
you're
only
putting
the
list
processing
work
on
the
handful
of
cases
that
might
actually
care
about
it.
P
P
This
whole
question
of
single
value
versus
multiple
value
is
going
to
keep
coming
up
and
I
think
this
actually
relates
to
the
the
comment
on
syntax
from
minute
ago,
and
one
of
the
things
that
I
regret
about
the
set
for
match
and
I've
been
very
public
about
this
in
this
group,
is,
is
proposing
the
format
which
is
now
in
the
RFC,
because
that
can
potentially
lead
to
cases
where
people
have
multiple
unrelated
things
in
a
single
object,
and
that
would
be
the
downside
to
that
key
style.
Syntax
is
that
I
could
give
you
a
subject.
P
L
Similarly,
one
of
my
concerns
about
just
making
subject
itself
an
array
right,
as
that
would
lead
to
likely
people
putting
identifiers
for
subjects
that
I
really
have
different
relationships
to
the
event,
and
that's
that's
where
we
ended
up
with
subject
versus
token
subject
as
explicitly
stating
this
is
the
relationship
that
this
the
the
thing
identified
by
this
subject.
Identifier
has,
with
this
set
right
and
I,
think
being
explicit
about
that
is
really
good.
I
agree.
P
And
I
also
believe
that
the
that
the
having
aliases
or
whatever
be
a
separate
member
at
the
same
level
as
subject
is
likewise
explicit.
Is
that
here's,
the
subject
that
we
say
is
primary?
It
could
be
an
arbitrary
choice
from
a
set
of
multiples
whatever
and
here's
a
bunch
of
other
things
that
we
say
are
the
same
as
that
one
that
that
can
be
defined
as
very,
very
clear
semantics
without
the
syntax.
Getting
in
the
way
of
simple
processing.
I,
wonder.
L
If
there's
any
implementation
experience,
we
could
draw
for
him
from
open,
ID,
Connect
and
the
audience
claim
rollin
and
john
general
in
the
audience
claim
being
either
a
string
or
an
array
of
strings.
I
I
think
we're
kind
of
talking
about
that.
Prob,
that's
trying
to
solve
the
same
problem
that
that's
trying
to
solve
and
wonder.
There's
history:
we
can
learn
from
there
Mike.
J
Jones
Microsoft
I
was
actually
going
to
talk
about
that
very
thing.
I.
We
have
experienced
that
with
the
audience
field
that
it's
typically
single
valued,
but
there
are
use
cases
where
it
can
be
multi,
valued
and
Sojat
defined
the
audience
claim
for
those
of
you
who
aren't
familiar
with
it
as
being
either
a
single
string
or
an
array
of
strings
and
there's
nothing
preventing
us
from
doing
that.
For
some
of
these
fields
that
might
be
multi
valued
in.
L
Practice,
how
has
that
worked
out?
My
my
concern
about
doing
it
here
with
a
lot
of
potentially
any
claim
is
that
you
end
up
with
implementations
that
are
only
built
to
handle
the
single
value
case,
because
that's
the
only
thing
they
encounter
on
99.99%
of
the
time
and
then
blow
up
at
some
point
in
the
future
when
they
hit
the
multi
value
case.
I,
don't
know
if
that's
come
up
with
John,
so
I
don't
know
if
the
distribution
pattern
is
more
equal,
they're.
P
Just
enricher
I
can't
speak
to
this
distribution
pattern
beyond
my
own
anecdotal
experience,
but
as
somebody
who
argued
for
the
the
multi
typed
audience
in
in
open
ID
connects
because
you
do
see
that
type
of
thing
in
other
JSON
and
JavaScript
style
processing
a
lot.
You
know
you
get
the
thing
and
then
figure
out
what
it
is
before
you
process
the
next
bit.
P
It's
kind
of
made
writing
libraries
a
bit
of
a
pain,
because,
ultimately
you
have
to
store
something.
There
are
most
libraries
that
I'm
personally
familiar
with
just
store
it
as
a
multiple
object
under
the
hood,
and
so,
if
you
ricci
realize
it's,
some
libraries
will
just
always
give
you
an
array
with
a
single
value,
which
is
what
we
exactly
what
we
were
trying
to
avoid
happening.
P
I
think
that,
in
my
experience
you
tend
to
not
see
the
whole
look
for
the
single
value
or
blow
up
in
case
people
do
seem
to
get
that
right,
but
that's
usually
amounts
to
they're
being
kind
of
like
a
big.
If
block
says
you
know,
if
is
array
then
do
this
else?
Do
this
other
related,
but
not
quite
exactly
the
same
thing
so
from
the
X,
the
expression
standpoint,
it's
very
powerful,
I
like
it
as
kind
of
a
you,
know,
language
and
semantics
mechanism
from
a
developer
standpoint.
It's
a
pain
in
the
butt
I
think.
L
It's
worth
thinking
about
the
next
level
down
to
write
your
processor
might
support
it,
but
it's
good
to
be
surfacing
that,
whether
it's
single
value
or
multi
value
it's
going
to
surface
that
as
an
array
structure
and
the
application.
That's
consuming,
that
API
chances
are
they're.
Just
I'd
worry
they're,
just
gonna
look
at
element
zero
and
go
from
there
and
not
really
think
about
the
broader
case.
Exactly.
P
P
I
Their
cart,
I,
echo
Justin's
comments
on
implementation
and
I.
Disagree
that
this
is
comparable
to
audience
an
audience.
You're
saying:
here's
all
the
people,
it
could
be
an
audience
for
and
in
that,
your
logic
is
to
check,
am
I
one
of
those
people
we're
here
we're
saying
here's
the
entity
I'm
referring
to
and
when
you
have
multiple
of
the
same
kind
of
identifiers.
That
seems
odd,
that
there
wouldn't
be
like
an
identifier.
I
There's
clearly
use
cases
where
you
know
you
know
in
say
the
open
idea
where
the
party
getting
it
may
have
used
one
of
a
number
of
identifiers
x'.
You
don't
know
which
one
they
use.
You
need
to
provide
each
of
those
ones,
but
those
aren't
necessarily
multiple
appears
a
different
phone
numbers
or
they
would
have
picked
a
phone
number
that
they
wanted
to
use
to
identify
I.
Think.
L
L
I
think
it
that
that
gets
to
the
point
you're
just
making
that
with
the
audience
there
isn't
an
expectation
that
those
values
are
related
to
one
another
appoints
of
the
same
thing,
whereas
I
think
here
there
really
would
be
at
that
expectation,
but
it
would
not
be
enforced
at
all
by
the
by
the
syntax.
So
that's
something
for
us
to
think
about.
I
suspect
this
is
something
people
want
to
discuss
this
on
the
list.
It
seems
like
a
good
topic
for
that.