►
From YouTube: IETF107-TXAUTH-20200323-1950
Description
TXAUTH meeting session at IETF 107
2020/03/23 1950
https://datatracker.ietf.org/meeting/107/proceedings
A
So
welcome
everyone.
This
is
the
first
session
of
the
first
ever
fully
virtual
IDF
and
the
wonder
it's
taking
us
a
little
bit
of
time
to
be
to
ramp
up
it.
Please
have
your
video
off
in
most
importantly,
please
be
muted
unless
you're
speaking
also,
if
you'd
like
to
to
speak.
If
you'd
like
to
be
on
my
queue
and
there's
a
just
a
chat
feature
to
WebEx,
please
say
plus
q
and
you
will.
We
will
note
your
name
and
we
will
call
you
to
the
mic.
A
B
A
A
C
A
D
A
Please
let
us
know
if
you
have
any
comments
on
the
agenda,
we'll
start
with
just
not,
then
we
will
have
a
shorter
discussion.
We
realize
that
there
are
still
open
points
that
people
want
to
discuss
about
the
shelter,
so
we
might
go
over
20
minutes,
but
at
some
point
we
will
need
to
cut
this
discussion
in
order
to
discuss
the
to
a
possible
starting
points
that
we
have
for
the
3x
or
protocol
which
are
X
Y
Z.
A
A
B
B
C
G
Hi
Annabelle
Backman
Amazon
we're
doing
a
bit
agenda.
Bashing
right,
I,
know
we're
past
the
agenda
slide.
So,
okay,
yeah
I,
want
to
kind
of
reiterate
what
I
asked
for
on
the
mailing
list,
which
I
really
think
we
need
to
add
a
little
more
structure
than
just
20
minutes
for
charter
discussion
because
seems
like
there's
a
handful
of
key
items
for
debate,
and
it
would
be
helpful,
I
think
for
us
to
make
sure
we
get
a
chance
to
talk
about
all
of
them.
A
B
G
G
I
think
my
my
question,
or
my
concerns
more
around
as
it
is.
The
Charter
discussion
is
just
sort
of
this
big,
unstructured
block
of
time.
I
guess
I'm,
hoping
the
chairs
are
going
to
be
ordering
that
or
orchestrating
that,
so
that
we
can
actually
try
and,
like
maybe
close
out
on
on
topics
and
not
just
kind
of
jump
around
or
keep
jumping
back
to
the
same
topics.
Just
a
little
concerning
since,
like
it's
not
assigned
to
anybody
to
lead
that
discussion
or
anything
on
that
on
the
agenda.
So,
hopefully
there's
some
organization
plans
there.
G
C
A
So
specifically,
you
mentioned
the
you
honorable
mention
their
identity.
I
think
we
should
start
there.
This
seems
to
be
the
the
most
important
subject
that
people
brought
up.
So
if
people
have
an
opinion
in
favor
of
including
identity
in
the
charter
against
or
something
in
between,
please
add
yourself
to
the
queue
and
let's
get
to
get
going
on
identity.
G
So
Annabelle
back
on
Amazon
again
up
before
that,
I
want
to
just
quickly
preface
all
of
this
discussion
with
the
way
I
see
it.
The
Charter
should
be
about
you
know
just
outlining
the
problems,
we're
trying
to
solve
and
I
think
a
lot
of
the
suggestions
on
the
discussions
and
debates
that
are
coming
up
on
the
mailing
list
stem
from
people
trying
to
put.
G
So
just
maybe
other
people
don't
see
it
that
way,
but
if
that
makes
sense
to
use
and
just
try
and
keep
that
in
the
back
of
your
mind
as
you
as
we
discuss
this
on
identity
I
think
there
a
again
specifically
as
there's
a
lot
of
room
for
us
to
go
into
to
to
to
get
clearer
about
what
it
is
we're
talking
about
and
what
problems
we're
trying
to
solve.
When
we
say,
oh
we're
going
to
put
identity
in
the
Charter,
does
that
mean
we're?
You
know
communicating
claims
about
a
subject.
G
G
G
A
C
I
D
Sure
and
put
the
discussions
on
the
list,
I
think
it
would
be
fairly
important
to
understand
what
are
the
uses
cases
we're
trying
to
solve
before
we
would
decide
to
rule
identity
in
and,
as
Annabelle
just
said,
identities
a
lot
of
things.
Sometimes
it
just
claims
when
you
dedicate
so
sometimes
it's
session
management.
C
A
I
D
Why
is
a
unique
solution
needed
for
some
of
these
things
and
to
the
identity
question?
What
aspects
of
identity
are
needed
by
these
use
cases
and
what
are
we
ruling
out
and
what
are
we
were
using
right
now,
it's
just
sort
of
a
grab
bag
I
do
appreciate
the
new
language
that
Justin
and
dick
came
up
with
a
few
days
ago.
I
think
on
Saturday
I
proposed
to
tweak
to
it
and
try
to
skip
that
to
something
achievable,
but
I'd
like
to
see
much
more
focus
on
reuse
and
writing
the
use
cases.
C
D
Other
again,
identity,
as
many
things
just
releasing
claims
on
medication
time.
It's
easy!
Are
you,
including
the
log
out
parts
of
open,
ID,
Connect
and
the
session
management
parts
I
mean
that's,
what's
needed
for
end
and
solution,
there's
more
of
identity
for
aggregated
and
distributed
claims,
there's
verified
claims,
there's
a
whole
bunch
and
the
Charter
is
not
at
all
clear
whether
you're
talking
about
releasing
claims-
and
you
know
have
a
nice
day
or
whether
you're
building
an
end-to-end
identity
system
and
I
think
the
latter
is
hard.
Having
done
it.
C
C
G
G
And
then
you
know
once
once
you
get
your
your
tokens,
your
just
doing
everything
that's
been
built
on
to
IDC
from
there
I
don't
know,
but
it
might
be
helpful
to
kind
of
to
put
the
Charter
language.
In
those
terms,
you
can
put
it
less
about
just
we're
going
to
do
identity
and
more
about
we're
going
to
enable
identity
to
work
over
this
thing.
G
So,
if
you're
trying
to
do
an
incremental,
so
you
get
access
to
you've
got
access
to
resources
a
now
you
need
access
to
resource,
be
in
that
same
resource
owner
account,
it's
possible.
What
you
end
up
with
is
access
to
resource,
be
in
a
totally
different
account,
and
you
don't
really
just
with
us.
You
don't
really
have
any
good
way
of
determining
that's
the
case,
and
that
can
lead
to
some
really
weird
broken
experiences.
G
So
that's
something
that
I
would
like
to
I
think
it's
squarely
you
know
needed
with
just
within
the
authorization
domain,
even
if
you're
not
doing
any
sort
of
like
authentication
into
the
client
using
that
or
any
sort
of
like
shared
session
management,
or
anything
like
that.
That's
something
that's
missing
an
auth
that
I
would
like
to
see
here.
G
One
thing
that
I
would
like
to
steer
clear
of
is
having
multiple
structured
languages
for
talking
about,
like
you
know,
one
structured
language
for
talking
about
resources
that
I'm
asking
for
authorization
for
and
another
structured
language
for
talking
about
claims,
and
so,
if
we're
keeping
those
as
two
separate
things,
I
think
there's
a
risk
of
that.
So
I
think
that
would
just
be
unnecessarily
complex,
unnecessarily
confusing.
So,
yes,
we
talk
about
reused.
Think
about
things
like
that.
G
E
Okay,
so
I
had
two
points,
one
of
which
is
real,
quick,
just
to
remind
everyone
that,
when
we're
writing
the
charter
text,
the
Charter
needs
to
be
understandable
by
people
who
are
not
conversant
with
the
details
of
open
ID
connect.
And
so,
if
we're
talking
about
doing
identity
in
terms
of
the
functionality
that
Open
ID
Connect
does
we
should
describe
that
a
little
bit
more
when
we
start
to
put
that
into
Charter
text.
E
You
know
some
information
or
claims
from
the
S
to
the
RS,
and
it
just
so
happens
that
some
of
those
claims
or
information
might
relate
to
the
identity
of
the
user,
saying
so
that
it's
just
sort
of
calling
that
out
as
a
particular
type
of
information
that
we
would
want
to
be
transacting.
As
opposed
to
being
necessarily
a
fundamentally
different
thing,
having
now
just
listens
to
what
Annabel
was
saying,
though
I'm
no
longer
sure
that's
the
case.
C
:
is
next
in
the
queue
so
dicks
answer
that
the
the
use
cases
were
they
like
the
the
oauth2
and
the
open
ID
connect,
use
cases,
sort
of
sort
of
surprised
me
and
I'm
wondering
if
anyone
can
speak
to
what
are
the
use
cases
that
we
want
to
solve
with
this
working
group
that
aren't
already
covered
by
one
of
those
existing
are
well
by
open,
I
need
connect.
Basically,
could
somebody
talk
about
that
and
get
those
into
the
charter
bit
more.
B
C
The
way
I
read
the
Charter
and
I
threat,
the
mailing
will
track
the
other
stuff
on
here.
It
almost
seemed
to
me
like
Oh,
ought
to
would
would
solve
most
of
the
things
that
I
tore
sit
there.
So
if
there
were
specific
use,
cases
that
ought
to
does
not
meet,
it
would
be
great
to
at
least
have
a
better
understanding
of
them
for
this
group
of
people
here
right
now,
and
maybe
that
would
result
in
update
of
the
Charter
as
well.
I
C
C
C
You
can
kind
of
view
those
fairly
broadly
and
so
there's
a
number
of
things
that
don't
work
today
with
OAuth
2
and
open
ID
Connect,
which
is
what's
driving
this
new
work.
And
while
you
can
solve
a
fair
amount
of
identity,
things
with
open
ID
connect
the
concern
and
why
I
wanted
to
have
identity
and
the
TX
off
charter.
Is
that
someone's
going
to
go
and
deploy
TX
off?
F
F
You
know
really
basic
claims
about
the
user
being
able
to
release
a
set
of
assertion
from
the
AAS
and
to
Annabel's
point
being
able
to
present
identity
information
on
the
request
and
beyond,
just
a
notion
of
who
the
user
might
be.
But
if
I'm
using
a
you
know,
verifiable
credential
proofs
I
can
actually
prove
that
you
know
the
user
really
did
authenticate
to
me
as
a
piece
of
software
cryptographically.
There
are
other
protocols
that
allow
me
to
do
that
and
txl
should
be
able
to
convey
that
information
as
well.
F
That's
a
different
discussion.
But
having
that
defined
here
in
this
group
and
to
Anabelle's
point,
you
know
extensions
on
where
you
can
kind
of
it
make
it
obvious
and
where
you
would
build
all
of
this
other
stuff,
whether
the
you
know-
and
that
should
probably
happen
in
another
group,
then
I
think
it's
that's
really
the
best
direction
that
we
can
go
now,
whether
we
pull
those
bits
and
pieces
from
Open,
ID,
Connect
or
from
skim
or
from
Facebook
or
from
verifiable
credentials
or
wherever.
That's
something
that
the
working
group
needs
to
decide.
F
J
J
J
E
J
E
C
F
C
D
If,
as
Justin
describes
it
all
that's
being
included,
is
releasing
some
identity
claims
at
authorization
time
you're,
guaranteeing
that
you're
going
to
have
to
build
some
additional
layers
which,
for
instance,
the
session
management,
the
logout,
you
don't
just
login,
you
have
to
decide
when
to
logout,
you
have
to
contact
the
logged
in
relying
parties,
you
have
to
get
them
logged
out.
You
have
to
do
the
cookie
management
underneath,
etc,
and
I
would
rather
there
be
a
clean
layering.
D
We're
sure
we
think
about
the
experience
we've
learned
from
sam'l
and
connect
and
Facebook
Connect
and
what-have-you
and
think
about
where
to
do
the
cut
for
the
layering.
But
you
know
to
towards
its
point
on
the
list.
Entities
identity
is
a
really
big
topic.
I
think
we
will
be
much
more
likely
to
succeed
in
refactoring
authorization.
If
that's
what
we
do
and
we
leave
the
hooks
there.
For
instance,
you
could
build
an
open
ID
connect
profile
for
TX
off.
Just
like
you
have
an
open,
ID
connect
profile
for
different
response
types.
D
D
H
Think
just
that
we'll
manage
that
cost,
Motor
City
s
have
come
hi
everybody
yeah
identity
is
a
broad
topic
and
I
personally
think
it's
all
first
of
all,
focus
on
on
defining
a
new
authorization
protocol.
Although
there
are
some
elements
of
identity
that
I
think
belong
to
the
core
of
this
of
the
new
authorization
protocol.
H
Anabelle
just
mentioned
the
incremental
authorization.
I
fully
agree,
that's
a
use
case,
that's
purely
soft
or
even
not
solved
in
the
off
two
and
open
and
econnect
space.
Today,
I,
even
don't
think
it's
really
an
identity
use
case,
because
I
would
like
to
see
a
solution
that
are
tries
to
not
really
expose
an
identity
to
allow
R'lyeh
clients
to
to
to
upgrade
an
existing
authorization
with
the
same
user.
So
we
have
done
some
work
in
that
in
that
regard,
in
the
grant
management
protocol
for
two,
so
I
think.
H
That's
that's
a
very
really
reasonable
in
this
case
that
I'm
supporting
second
use
case
is
are
providing
identity
and
the
at
the
AAS
to
RS
interface
as
I
as
I
said
under
on
the
on
the
mailing
list.
This
is
today
and
off
to
this
is
a
no-man's
land,
so
everybody
is
doing
it
differently
and
I
think
that's
that's
a
viable
use
case,
because
we
need
to
somehow
specify
this
interface
in
order
to
come
up
with
interim
bold
solutions
between
a
SS
and
our
SS,
and
it
brings
me
to
my
last
two
topics.
H
First
of
all
and
I
think
we
already
agreed
on
the
list
to
to
make
that
part
of
the
Charter
intro
bility
of
all
the
three
interfaces.
Client
to
AF,
AF,
2,
RS
and
client
to
RS
must
be
in
scope
for
that
shorter
I
even
went
one
step
further
and
asked
for
testability,
so
the
goal
my
goal
would
be
to
have
intro
bility,
really
on
the
on
the
on
the
on
the
wire
level.
H
And
last
but
not
least,
we
have
discussed
that
over
the
course
of
the
last
week
intensively.
I
would
like
to
see
support
in
the
new
protocol
for
a
great
number
of
different
designs
for
ways
to
manage
tokens
from
single
single
access.
Token
designs
to
multiple
for
LSM
access.
Token
designs
I've
got
some
extensive
conversations
with
the
with
the
editors
of
their
proposals
that
we
have
right
now
and
I
feel
that,
with
we
came
up
with
a
common
understanding
that
this
is
covered
by
the
current
charter.
H
B
F
B
I
think
that
for
adoption,
we're
going
to
have
to
hook
into
a
bunch
of
existing
identity
infrastructures
right
when
we
start
talking
about
the
kinds
of
things
that
might
talked
about-
and
you
know
in
identity
management,
we're
doing
all
sorts
of
full
life-cycle
kinds
of
things,
only
a
small
piece
of
those
cut
and
authorization
flow.
So
if
the
core
element
of
what
we're
talking
about
is
how
do
we
represent
an
identifier?
What
are
some
core
elements
of
identifiers,
some
standardization
around?
B
How
those
you
know
core
attributes,
get
communicated,
or
maybe
even
some
sort
of
scheme,
as
it
allows
you
to
specify
here's
the
the
here's
the
the
way
I'm
talking
about
these
things
and
multiple
can
get
slotted
in
I.
Think
for
me,
that's
a
lot
clearer
right
and
effectively.
The
aspects
like
Tony
was
talking
about
of
authentication
or
Mike.
Was
talking
about
session
management?
Those
things
are
left
out
of
scope
from
a
TX
off
perspective
and
we're
just
talking
about
where
the
intersection
happens,
as
it
relates
to
authorization.
A
A
I
So
this
is
Roman
jumping
it
as
the
idea
I
think
it's
going
to
be
very
tricky
to
do.
The
humming
we're
gonna
have
to
take
just
to
the
mountain
list.
I
think
we
have
a
fairly
fairly
long
list
of
items,
we're
going
to
need
to
sort
out
and
what
I
be
interested
in
and
kind
of.
The
chairs
kind
of
help
me
out
here
is
I'm,
going
to
read
a
list,
and
if
someone
feels
like
this
is
not
a
bigger
topic
that
we
need
discussion
on
or
you
I'm
sorry
you
need
to
add.
I
You
know
add
something
too.
Unless
you
please
kind
of
speak
up,
so
you
know
going
backwards.
Mike.
You
just
mentioned
session
management.
We
have
multiple
folks,
tell
us
that
we
need
to
have
more
precision
on
on
kind
of
what
is
the
definition
of
identity.
We
talked
a
little
bit
about.
We
need
precision
on.
Are
you
inventing
new
stuff
or
are
you
going
to
be
referencing
other
stuff,
and
then
we
have
some
feedback
from
multiple
parties
around?
You
know
clarity
and
use
cases.
I
A
F
C
F
For
yeah,
just
a
quick
procedural
bit
would
it
be
helpful
if
I
tried
to
do
a
revision
of
the
Charter.
Based
on
the
comments
that
we've
had
over
the
last
week
and
a
couple
of
comments
here
like
what
George
was
just
saying
and
put
that
out,
because
there's
a
couple
of
things
that
it
seems
clear,
we
need
to
change
so
I'm
asking.
Should
we
do
a
revision
first
and
then
consensus
on
that.
A
F
C
F
E
C
B
E
F
Okay,
so
I'm
going
to
do
my
best
to
be
quick
here
and
talk
about
the
XYZ
project,
which
is
something
that
I
started
almost
a
year
and
a
half
ago
now
to
make
a
concrete
set
of
suggestions
to
address
things
that
I
was
seeing
in
the
wild.
You
know,
including
avoiding
using
the
front
channel
to
pass
security
information,
assuming
everybody
had
web
browsers
and
making
a
lot
of
assumptions
about
how
clients
and
keying
and
everything
works
really
just
based
on.
F
You
know
the
last
decade
of
experience
with
how
a
walk
to
works
and
where
it
is
falling
short
today.
So
the
goals
of
the
project
are
to
take
care
advantage
of
what
we
can
do
on
the
web
today
and
kind
of
how
deployments
work,
including
things
like
being
able
to
post
JSON
to
an
API
who
would
have
thought
but
to
enable
things
like
rich
resource
requests,
different
kinds
of
interaction,
modes,
different
kinds
of
key
presentation
and
a
key
point
through
the
XYZ
project
was
to
allow
choose,
use
cases.
F
But
not
necessarily
repeat
it
exactly
always
questioned
why
something
was
put
in
a
wall
and
take
a
step
back
from
that.
One
of
the
technologies
that
we
make
use
of
in
designing
the
protocol
is
polymorphic
JSON,
which
just
very
quickly
means
that
if
you've
got
a
JSON
object,
the
same
field
name
could
have
a
string
value
or
a
boolean
value
or
really
any
kind
of
JSON
value.
In
different
circumstances.
This
doesn't
mean
that
it's
untyped.
It
means
that
each
of
those
types
has
a
very
specific
semantics
associated
with
it.
F
So
there's
a
lot
of
ideas
and
XYZ
that
aren't
in
the
spec
speaking
of
implementations,
we've
got
several
in
Java,
no
js'
from
multiple
teams,
and
we
run
you
know
point-to-point
interoperability.
With
these
things,
for
both
clients
and
server
side,
different
signing
and
proofing
mechanisms,
there
is
an
ID
in
the
data
tracker
for
a
more
full
write-up,
for
the
entire
project
is
on
the
website.
Althought
XYZ.
F
Specification
text
so
there's
a
lot
more
information
there,
so
that
I'm
going
to
dive
straight
into
the
protocol
and
I
am
going
to
be
going
fast
and
skimming
over
the
tops
of
things
so
that
you
fill
out
a
little
bit
of
time
for
questions.
Everything
in
Xyz
starts
with
a
the
client
starting
a
transaction
at
the
AAS
or
the
client
tells
bas.
Here's
who
I
am
what
I
want
that
looks
like
a
JSON
object
and
all
of
these
different
fields
in
the
JSON
object
need
different
means,
specific
things.
F
So,
for
example,
as
a
delegation
protocol,
we
want
to
know
what
we're
delegating
access
to
and
we've
got
a
rich
description,
language
saying
what
I
want
where
I
want
it.
What
I
want
to
do
that
kind
of
stuff
here,
and
if
this
reminds
you
of
offer
each
authorization
request
is
very
very
good
reason,
for
that
is
that
rar
is
basically
kind
of
a
the
content
abroad
was
kind
of
a
backcourt
of
what
we
have
done
in
Xyz
is
that
that's
intentional
I
think
that
that
should
continue.
F
Clay
needs
to
be
able
to
have
you
know
some
user
facing
fields.
That's
not
that
interesting,
what's
more
interesting
as
the
client
needs
to
be
able
to
identify
itself
and
instead
of
identifying
itself
with
an
abstract,
client
identifier,
we
identify
clients
using
the
keying
material
that
they
use
to
prove
that
they
also
prove
with
the
presentation
of
the
request.
In
this
case
it's
a
jwk
and
one
of
the
places
where
we
thought
it
was
really
important
to
have.
F
Flexibility
was
in
the
key
proving
mechanisms,
so
there's
a
way
that
you
can
do
this
XYZ
by
using
detached
jws
signatures
again
we're
using
stuff,
that's
out
there
and
just
signing
the
JSON
of
the
HTTP
message
body.
This
is
you
know,
fragile,
but
functional.
In
some
cases
you
could
also
use
HTTP
message
signatures,
which
was
a
community
draft
that
Annabel
and
I
are
actually
just
just
now,
as
it's
supposed
to
be
this
week,
bringing
it
into
the
HTTP
working
group.
So
that's
going
to
be
doing
work
going
forward
as
well.
F
That
I
think
we
should
be
able
to
leverage
here.
It's
also
MPLS,
even
deep
on
style,
header
signatures,
there's
a
lot
of
things
that
different
deployments
of
clients
should
be
able
to
do
here.
So
at
this
point,
the
a
s
can
look
at
that
incoming
request
and
decide.
Well,
maybe
I've
got
all
of
the
information.
I
need
and
I
can
just
easily
even
access
to
it
because
we're
starting
in
the
back
channel.
We
can
actually
do
that.
This
covers
client
credentials.
F
We
signal
that
by
allowing
the
client
to
say
to
the
authorization
server,
here's
all
of
the
ways
that
I
am
able
to
interact,
because
ultimately
it's
the
client
software
that
decides
how
it
is
able
to
interact
with
the
user.
It
knows
whether
it's
a
web
browser
or
an
SP
a
or
a
light
switch.
It
knows
what
it
can
do,
so
it
sends
all
of
that
information
over
not
going
to
go
over
all
of
the
combinatoric
here,
but
I'm
going
to
cover
a
couple
of
common
combinations.
F
The
server
is
going
to
return
and
say
yes,
send
the
user
to
this
URL,
which
I've
just
created
in
response
to
this
request
and
by
the
way
since
you're,
using
a
call,
here's
mine
owns
that
we're
going
to
also
use
to
secure
that
call
back
and
the
next
time
you
come
talk
to
me.
Here's
a
handle
you
can
use
to
to
reference
all
the
stuff
that
we've
been
doing
so
far.
So
the
client
say
it's
a
web
browser
sort
of
web
server
based
client.
It
can
just
redirect
her
over
or
it
can
open
heads.
F
You
know
the
protocol
doesn't
actually
matter
as
long
as
the
user
gets
there.
The
user
interacts
with
the
server
logs
in
authorizes,
whatever
all
they
need
to
do,
and
then
we
called
call
back
of
the
clients,
and
that
has
two
bits
of
information,
not
sure
if
my
mouse
is
coming
through,
but
this
interact
reference
down
at
the
bottom
plays
the
role
of
the
authorization
code
from
aloft
to,
and
the
OAuth
verifier
from
one,
and
this
hash
right
here
is
that
security
component.
F
The
client
then
takes
that
reference,
along
with
the
handle
that
it
got
back
and
sends
those
back
to
the
server
in
order
to
go,
hopefully
get
its
access
to
it
and
stop
at
this
point.
The
client
here
also
has
to
prove
possession
of
the
same
key
that
it
used
to
start
the
transaction
so
that
the
server
knows
that
it's
the
same
piece
of
software.
That's
coming
and
doing
this
follow
up
this
pattern
right
here
already
closes
tons
of
potential
attack
vectors
that
existing
off
to
today.
F
If
the
client
can't
redirect,
but
can
only
maybe
trip
out
a
user
code,
we
allow
them
to
say
that
this
is
the
only
interaction
method
that
I
can
do
and
the
server
come
back
with.
Oh
for
the
thing
that
you're
asking
for
sure,
that's
fine
send
the
user
to
this
static
URL,
which
maybe
you
can't
even
display,
so
you
know
put
it
on
your
packaging
or
something.
But
this
is
this
is
not
going
to
bury
but
tell
them
this
user
code.
That
will
be
very.
F
This
is
the
device
flow
from
OAuth
2,
while
the
user
is
sent
off
to
go
to
that.
The
question
is
going
to
be
pulling
with
its
transaction
handle
and
the
server,
incidentally,
can
come
and
say
you
know
hold
up.
You
know,
wait
another
30
seconds
before
you
call
me
again
and
here's
another
handle
they
used
to
to
keep
updating
this,
because
we
have
an
opportunity
to
rotate
that
a
lot
of
people
when
they
see
this
ask
you
know
what
about
being
able
to
combine
these
two.
Well,
we
realized
in
Xyz.
F
We
didn't
actually
need
a
separate
modes.
Do
that
because
it
turns
out
that
really
what
you're
saying
is
I
can
get
the
user
to
an
arbitrary
URL
or
show
them
a
code.
But
I
can't
have
a
I,
don't
have
a
callback,
you
know,
I,
don't
have
a
front
channel
callback,
so
we
can
reuse
that
same
mechanism,
because
we've
decoupled
the
various
parts
of
the
interaction
and
the
server
comes
back
and
says
here's
an
interaction
URL,
which
we
can
then
render
it
as
a
QR
code.
F
Here's
a
user
code
that
the
user
can
type
in
and
then
the
rest
of
the
protocol
falls
out
exactly
the
same
as
it
did
before.
Access
tokens
on
the
surface.
There's
nothing
really
new
here
we
can
do
a
bearer
token,
just
like
in
but
syntactically
since
this
is
coming
back
as
a
substructure
of
the
response.
We
now
have
an
opportunity
to
hang
additional
information
on
it.
So
all
of
the
questions
that
we're
having
about
how
do
we
bind
you
know
keys
to
tokens
whether
it's
embedded
in
the
token
or
not,
or
you
know
not
where?
F
F
F
Then
an
API
designer
in
working
with
their
authorization.
Server
would
say
you
know,
there's
this
common
set
of
dimensions
that
people
are
asking
for
so
say
they
want.
You
know,
email
addresses
from
the
user
info
endpoint
or
the
current
user.
I
can
bundle
that
up
and
say
that
is
now
the
string
email.
F
In
other
words,
this
is
the
OAuth
2
scope
mechanism
and
we
can
use
it
alongside
of
the
rich
authorization
request,
type
objects,
the
multi-dimensional
objects
and
these
sort
of
predefined
scopes,
because
the
semantics
of
how
these
combine
is
exactly
the
same
as
how
the
multiple
bits
of
those
fully
specified
objects
combine.
So
it's
reusing
components,
but
in
a
way
that
allows
them
to
be
extended
a
lot
more.
F
Additionally,
we
can
get
these
handles
back,
not
just
from
a
static
registration
but
the
first
time
the
client
goes
and
talks
to
the
a
s.
The
a
s
can
come
back
and
say:
oh
hey,
that
key
that
you
sent
me
again,
not
sure
if
my
mouse
cursor
is
pointing
up
at
that
key
that
you
sent
me
instead
of
sending
the
key
object,
send
this
key
handle
as
the
fourth
field
down
here
so
and
I
will
know
what
that
means.
You
know.
Maybe
this
is
going
to
be
a
thumbprint
of
a
key.
F
Maybe
it's
not
because
it
could
ultimately
be
kind
of
like
the
kind
of
like
a
client
ID
in
that
case,
and
we
can
tie
the
the
rights
of
other
stuff
to
that.
So
this
gives
us
dynamic
and
Static
registration
and
fully
walk-up
non
registered
client
interaction
all
using
the
same
structure
into
me.
That's
really
really
powerful.
So
how
do
I
think
identity
fits
into
it
and
how
does
it
fit
into
XYZ?
F
As
I
said
on
the
list,
I
said
earlier
on
the
call
you
really
should
be
querying
what
I
like
what
George
said,
really
just
kind
of
identifiers
and
assertions
about
the
current
user.
I
call
them
claims
again
to
try
and
reuse
what
was
what
was
already
out
there
and
other
protocols
to
just
say
that
hey
here's
stuff
that
that
I
know
about
I.
This
is
stuff
that
I
want
to
know
about.
The
current
user
and
I
get
that
back
from
the
authorization
server
I.
F
Like
that,
that's
you
know:
I
think
that
is
outside
of
the
scope
of
what
we're
after
and
not
what
I
was
intending
when
I
wrote
the
Charter
text,
but
anyway,
all
of
this
comes
just
like
Open
ID
Connect
right
alongside
the
access
token
in
the
same
JSON
structure
and
Aaron
pranky
did
a
great
blog
post
kind
of
laying
out
sort
of
the.
Why
and
how
that
it
makes
sense.
F
F
What
we're
doing
instead
is
taking
these
concepts
like
a
client
ID
and
putting
them
into
a
space
where,
instead
of
still
calling
it
a
client
ID
we're
saying
it
we're
tying
it
in
to
the
overall
architecture
in
ways
that
actually
is
consistent
with
other
things
same
with
all
the
proofing
mechanisms,
we
can
do
that
consistently
across
the
things.
I
showed
you
how
scopes
work.
F
We
can
do
refresh
tokens
even
advanced
stuff,
like
persistent
claims,
tokens
and
ID
tokens
those
concepts
inside
of
XYZ,
which
means
that
from
a
developer's
perspective,
you
can
sit
them
down
and
say:
hey
here's,
these
arbitrary
values
that
make
your
program
do
what
it's
supposed
to
do,
put
them
into
this
JSON
object
and
send
it
to
the
server
and
it's
going
to
work
for
you.
This
client
simplicity
is
absolutely
important
here
and
there's
a
lot
of
stuff.
F
That's
been
going
on
in
the
oauth2
world
as
well,
making
a
lot
of
these
concepts
available
to
the
oauth2
world.
What
we
try
to
do
with
XYZ
is
really
kind
of
collect
this
stuff
and,
in
some
cases,
invent
this
stuff
in
a
way
that
wasn't
a
that
wasn't
tied
down
to
the
assumptions
and
background
of
oauth2.
F
A
F
C
My
goal
of
that
was
really.
You
know
to
expand
the
marketplace
ideas
or
what
are
the
different
things
we
could
be
doing
so
the
goals
one
want
to
make
sure
it
was
extensible
in
a
number
of
different
dimensions.
To
me,
I
think
it's
really
important
that
it's
easy
to
migrate
from
bought
to
an
open,
ID
Connect
that
we're
just
you
know.
People
can
very
easily
understand
how
they
drop
that
in
and
work
with
it.
Also.
Let's
reuse,
what
we've
already
got
before?
C
Let's
not,
we
don't
need
to
reinvent
everything
scalable
having
worked
in
AWS
for
a
while
I
have
a
much
bigger
appreciation
for
how
decomposable,
and
you
know
how
you
want
different
security
parameters
and
similar
to
Justin.
You
know
simple
things
are
simple
and
hard.
Things
are
possible,
something
that
I
learned
from
Larry
wall
back
in
my
Perl
days.
So
here's
a
party's
the
same
parties
that
Justin
talked
about,
except
that
I
call
it
a
grant
server
instead
of
an
authorizer
server
which
I'll
go
into
in
more
detail
later.
Our
key
terms
claims.
C
You
know
this
is
information
about
the
user
provider
by
the
GS
when
I
think
of
identity.
This
is
essentially
I'm
scoping
it
around
to
claims
that
are
being
moved
around
I.
Don't
think
that
session
management
is
in
there
to
answer
Mike's
question
authorization.
Is
you
know
what
has?
What
does
the
client
have
is
access
to
the
resource
server?
The
grant
is
a
collection
of
authorizations
and
claims,
and
so
the
grant
is
what
the
client
is
asking
the
grant
server
for
and
so
I
renamed
it
to
grant
server
to
encompass
both
authorizations
and
claims.
C
C
And
yeah,
so
here's
the
general
sequence,
the
besides,
once
a
create
a
grant.
The
GS
says:
okay,
I
need
to
interact
with
user,
so
something
interaction,
response
use
the
client
redirects
user
over
to
the
GS,
the
user
is
authenticated.
N
Achatz
at
the
GS
then
authorizes
what
the
client
asks
for
the
GS
redirection
user
back
to
the
client
and
the
client
reads
a
grant,
and
then
it
gets
a
grant
response.
C
So
I'll
go
into
detail
on
each
of
those
steps,
so
the
creating
the
grant
it's
an
HD
post
to
the
GS
URI,
which
is
the
endpoint,
includes
information
as
the
client
ID.
The
things
in
red
I'll
go
into
more
detail
later
aren't
about,
and
it
says
what
kind
of
interaction
is
going
to
be
now
go
to
more
detail
about
that
interaction.
Response,
then,
is
the
GS.
C
You
know
creates
a
grant
URI
and
a
redirect
URI,
and
so
the
grants
are
represented
by
a
URI
and
so
you'll
see
that
as
being
the
URI
and
we'll
pop
that
up
later
on,
when
you
see
things
and
then
the
redirect
URI
is
where
the
user
is
going
to
get
redirected
to
what
Justin
are
called
interaction.
Uri.
It's
all
these
things
in
red.
You
know
this
is
pretty
much
the
same
way
as
have
an
ID
connect.
C
Work
usually
gets
redirected,
stuff
happens,
bounces
back,
not
really
it's
part
of
the
protocol,
but
isn't
part
of
the
API.
It
was
kept
to
the
7
which
is
reading
the
grant,
and
so
here
the
client
is
doing
a
gift
of
the
grant
URI
and
then
the
response
is
going
to
be
the
grant,
and
you
know
so,
there's
some
stuff
on
top
and
then
you
know
the
key
thing
from
the
response
with
the
authorization
and
the
claims.
C
So
the
request,
client
objects,
you've
got
the
two
types
of
clients,
I,
sort
of
view,
there's
like
the
registered
clients
that
have
an
ID
and
for
this
corrupt
and
from
being
the
same
ID
that
you
have
an
open,
ID
connect
and
in
a
lost
deployment.
So
the
existing
deployments
don't
have
to
come
up
with
some
new
identifiers
for
their
client
and
then
for
a
dynamic
client
itself
declares
what
it
is
and
the
self
the
dynamic
client
is.
C
The
interaction
object,
so
I
sort
of
a
little
bit
similar
to
Justin,
but
a
little
more
coarsely
grained.
The
plan
can
either
get
a
redirect
or
not
and
think
those
are
that
that's
the
key
interaction
mechanism,
because
if
you
can
redirect
back
to
the
client
you
can
deal
and
with
such
an
fixation.
But
if
you
can't
redirect
back
to
the
client,
then
you
know
if
you've
got
a
scannable,
you
are
code
or
something
like
that.
An
attacker
could
take
that
and
try
to
trick
some.
C
You
know
a
victim
into
clicking
on
that
and
granting
access
and
the
victim
won't
know
that
they're
just
granted
access
to
an
attacker
using
a
client,
so
I
split
it
like
that.
And
then
you
provide
different
information
so
that
the
completion
URI
is
where
the
a
GS
would
redirected
use
when
it's
done
and
information
URI
is
also
where
the
if
there
is
where
the
GS
would
redirect
a
user
when
that's
done,
but
that
would
not
be
to
the
client.
C
The
authorization
object
in
the
request,
so
you
can
just
have
a
to
scope
type
and
so
in
the
authorization
you
can
say
it's
a
type
of
scope
and
then
PAP
scope,
but
it
also
can
support
other
authorization
types.
You
know
rar
or
XYZ
cell,
which
are
similar
to
each
other,
but
it
also
from
an
accessibility
point
of
view.
People
might
have
other
languages
and
other
places
or
other
ways
of
describing
authorizations,
and
so
by
having
a
type
you
can
go
and
have
different
types
of
authorizations.
You
want
to
request
authorization
z'
in
the
current
spec.
C
I
have
it
as
an
array,
and
so
you
either
have
authorization
or
authorization
in
the
request,
and
so
we
have
the
GS.
I
would
imagine
many
GS
s
initially
will
only
support
what
they're
already
doing
in
coop,
so
they
would
only
support
authorization,
but
if
they
can
support
multiple,
then
the
client
can
ask
for
multiple
authorizations,
which
I've
currently
got
as
a
array
of
objects,
or
it
could
be
a
dictionary
of
objects
summer
to
the
model
that
is
in
Xyz
now
or
you
can
do
authorizations
with
polymorphism
Utz
number
of
different
choices.
C
I
think
it's
a
good
discussion
point
to
figure
out.
What
do
we
think
is
going
to
be
easier
for
people
to
understand
and
then
the
claims
object?
You
have
claims,
there's
number
of
different
claims
types,
so
you
can
request,
though
ID
see,
you
know
an
ID
token
or
information
and
user
info,
and
you
have
other
claim
types
like
the
open,
ID
connect
for
identity
at
cessation.
That's
coming
out
or
verified
credentials
that
a
w3c
d-did
and
then
you
can
extend
and
ask
for
other
types
of
claims
in
here
as
well.
C
So
now
we're
moving
over
into
the
response
as
to
what
comes
back
so
coming
back
in
the
authorization
is
your
is
in
that
authorization
object,
and
so,
if
there's
only
one
of
those,
it's
either
a
URI
that
you
then
use
to
go
and
get
the
access
token,
or
if
it's
a
single-use
or
limited
time
authorizations
lose
no
management
that
you
know
you
can't
renew
it
or
anything.
Then
you
actually
get
the
token
and
the
metadata
about
that
and
then
in
the
authorization
object.
C
C
Also
added
discovery,
and
so
if
you
do
an
options,
call
to
the
GS
URI
you
get
back.
Essentially,
what
is
the
grant
server
support
for
you
if
it's
an
authenticated
call,
if
it's
an
unsent
educator
call,
then
potentially
the
grant
server
might
only
return
back
the
types
of
authentication
that
it
supports.
C
So
here's
a
list
of
all
the
API,
so
I
only
covered
sort
of
some
of
the
ones,
but
as
you
can
see,
it's
very
much
of
a
URI
resource
with
an
HTTP
verb
for
the
different
types
of
requests.
Now,
so
you
create
a
grant
with
a
post
to
the
GS
URI
and
then
you
can
verify
a
grant.
Read
a
grant,
update,
bolita
graph,
all
with
different
birds.
C
C
So
summary
of
the
different
your
eyes
I've
got
the
GS
URI
you
can
see
sort
of,
in
example
the
structure,
so
the
grant
and
AZ
URI
start
with
the
GS
URI,
and
so
another
feature
of
that
is
that
if
you've
got
a,
you
know
GGO
a
URI
of
a
grant
or
a
authorization.
You
know
which
grant
server
came
from
as
opposed
to
just
a
random
string
like
a
Tokyo
that
usually
you
get
with
a
token
that's
like
well.
C
C
So
some
other
features
that
I
didn't
go
into.
You
know
that
if
GF
isn't
ready
to
respond,
it
could
say
wait,
and
so
that
could
map
into
a
mile
of
where
the
GS
needs
actually
go
and
maybe
get
authorization
from
some
other
place,
and
so
it
says
tilt
it
to
wait
until
it's
all
done
before
the
client
should
call
back.
You
have
a
bunch
of
different
mechons.
C
You
can
do
on
a
grant
you
an
update,
verify
deleted,
update
and
delete
an
authorization
in
the
flow
I've
got
a
flow
in
there,
where
you
can
have
a
GF
initiated
grant
creation
so
that
the
sort
of
a
open
ID.
You
know
the
idea
of
a
provider,
and
you
see
a
login
to
an
application.
So
you
could
start
off
at
the
GS
click.
A
button
and
the
user
could
pop
over
into
the
app
and
the
app
would
be
able
to
use
the
grant
URI
to
make
a
call
to
go
and
get
information
about
which
user.
C
It
is
reciprocal
delegation,
which
is
where
the
client
and
the
GS
are
essentially
a
party
a
and
party
B
and
each
party
is,
has
both
roles,
and
so
how
does
each
of
them
get
authorization
to
the
other
ones,
resources
and
then
a
couple
of
other
features
instead
of
our
for
more
advanced
use
cases?
One
of
them
is,
you
know,
similar
to
Justin,
there's
an
idea
of
being
able
to
identify
which
user
you
think
it
is
in
making
the
call,
and
so
with
this
the
client
could
say:
I've
got
a
user.
C
B
C
The
client
may
need
to
ask
for
different
kinds
of
claims,
the
different
kinds
of
authorizations,
and
so
it
can
update
the
grant
as
the
user
moves
through
and
add
different
things
that
then
the
user
is
prompted
for,
while
still
in
the
experience
at
the
GAF
and
then
get
sent
back
to
the
GS.
So
a
number
of
these
advanced
ones,
I
did
sequence
diagrams
in
the
document
sort
of
helped
them
out.
So
it
looks
like
a
lot
of
sequence
diagrams,
but
they're,
really
just
using
the
same
API
is
in
a
few
different
ways.
C
One
of
the
other
things
that
I
did
is
I
included
a
authentication
mechanism
in
the
draft
to
simplify
for
people,
picking
it
up
that
they're
not
having
to
go
and
look
at
some
other
thing
for
how
to
do
it.
You
know
it
could
be
broken
out
into
a
separate
document
and
one
of
the
great
pieces
of
feedback
Dustin
gave
me
early
and
some
earlier
drafts
was
to
factor
how
authentication
happens
out
of
the
rest
of
the
protocol,
and
so
now
it's
all
in
one
section
and
it's
independent
of
everything
else.
C
If
it's
a
get
bleeped
or
options
method,
then
it
just
puts
it
in
the
header.
That's
the
payload!
You
can
see
an
example
of
get
endpoint,
you
know,
which
is
a
grant
call,
and
it's
including
it
as
author
as
a
Jose
type
in
an
authorization
header
and
if
it's
a
post,
put
or
patch
you
take
all
the
JSON
and
that's
the
payload,
and
you
sign
that
and
you
send
that
Jose
token
over
as
the
payload
to
the
endpoint.
C
And
then
you
can
use
that
same
Jose
mechanism
when
the
client
is
calling
an
RF.
So
for
all
of
the
verbs
you
know,
here's
a
header
and
the
payload,
and
once
again
you
can
see
at
the
bottom
that
is
used
an
authorization,
header
type
Jose
and
then
that's
the
example
Jose
token
being
sent
over,
and
so
that
allows
you
to
have
proof
of
possession
API
calls
to
an
RF
using
where
the
client
is
able
to
use
the
same
key
that
it
used
for
calling
the
GS
six
two
minutes
you'll
probably
want
to
skip
them.
C
Yep
I've
got
three
slides,
so
reviewing
the
goals,
the
first
one
is
extensible,
so
I
think
we're
extending
on
all
these
different
points.
In
the
request
and
in
the
response
and
authentication
mechanism
from
a
migration
you
know
here
is
the
what
the
request
would
look
like
from
a
client
I.
Can
you
drop
in
your
existing
client,
ID
os
copes
and
which
claims
you
want
to
have
and
reuse
reusing,
an
awful
lot
of
existing
things
and
scalable
on
the
grant
server,
because
you've
got
different
methods
and
different
your
eyes.
C
You
can
go
and
do
routing
to
different
services
that
are
doing
different
types
of
things
and
break
apart
your
thing,
as
opposed
to
one
big
monolith,
the
sign
body
and
and
header
in
the
calls
to
the
GS,
enable
those
to
be
passed
down
so
that
each
of
the
components
in
your
server
can
independently
verify
it.
You
know
proof
of
possession
is
so
much
better
as
a
technician.
The
shared
secret.
Now
each
of
the
components
can
verify
who
call
without,
of
course,
having
the
secret
to
verify
it.
C
The
client,
you
have
a
certificate
chain
of
proof
of
possession
versus
shared
secret
for
the
client,
and
so
that
enables
different
instances
of
the
client
to
have
their
own
private
key
in
the
resource
server.
In
the
proof
of
possession
mechanism,
you
could
have
a
certificate
on
the
GS,
a
delegates,
a
client
ID,
so
that
the
RS
knows.
Okay,
you
are
the
client
that
was
talking
to
my
D
s.
A
C
A
A
A
F
C
J
I
F
F
You,
okay,
okay,
so
people
people
can
hear
me
I'm,
not
sure
what
happened
to
dick
so
I'll
just
start
this
bid
and
until
we
get
back
so
basically
in
X
Y
Z,
the
client
says
these
are
all
of
the
things
that
I
can
do,
including
separating
whether
or
not
I
can
get
a
user
out
to
you
versus
whether
I
can
get
a
user
back.
Those
are
two
separate
fields
in
X,
Y
Z.
F
So
that's
for
the
same
reasons
that
call
splits
out
the
authentication
type
and
the
a
s
responds
to
all
of
the
capabilities
in
that
list
that
it
can
actually
support
and
that
match
what
the
client
is
asking
for,
because
different
policies
might
say
that
it
can
do
different
things.
X
off
uses
a
type
based
system
where
the
client
states,
as
per
the
current
version,
really
only
whether
or
not
it
can
do
a
redirection,
so
either
you
can
redirect
or
you
can't,
but
with
the
type
field.
F
F
Still,
all
right
so
dick
is
unmuted.
Oh
I
can
hello.
There
we
go
I
got
my
little
window,
I
will
say
for
from
my
part
here
on
the
XYZ
project.
We
actually
started
with
a
type
based
system
like
X
auth
has
and
after
we
implemented
it,
realize
we
didn't
like
it
and
then
we
once
we
had
decoupled
the
different
parts
of
the
interaction
request.
We
found
that
that
drastically
simplified
our
code,
especially
on
the
authorization
server
side.
Honestly
didn't
change
things
that
much
for
the
client,
because
the
client
was
always
fairly
simple.
A
A
G
G
Makes
good
sense
are
L
on
the
interaction
note
then
I
guess
is.
We
talked
about
this
on
the
list
back
and
forth
a
bit,
but
to
me
it's
it's
very
important
for
the
client
to
be
able
to
request
multiple
capabilities,
because
it
is
there
a
variety
of
scenarios
where
the
client
may
not
exactly
know
until
it
tries
whether
or
not
it
can
successfully
redirect
and
also
may
not
necessarily
know
which
mechanism
the
end
user
is
going
to
prefer
to
do.
G
There's
situations
where,
where
it
might
be
capable
of
technically
opening
but
might
technically
be
capable
of
opening
a
URL,
but
the
end
user
won't
actually
want
it
to
do
that
in
the
whatever
environment.
It's
in
whatever
environment
the
client
is
running
and
it
would
prefer
to
do
a
indirect
flow
instead,
so
yeah
I'm
very
much
in
favor
of
the
client
being
able
to
request
multiple
interaction
mechanisms
and
either
decide
or
or
give
the
end
user
the
option
of
choosing
which
one
to
move
forward
with.
C
F
G
C
G
C
G
Whether
or
not
the
GS
can
get
it
back,
get
back
to
the
client
depend
on
which
interaction
method,
the
end
user,
chooses,
for
example,
I,
could,
as
a
native
app
open
a
URL
in
my
environment
and
also
fire
up
a
web
server.
That's
listening
on
localhost,
and
so
that
means,
if
the
end
user
goes
in
through
the
direct
route.
Basically
on
that
device,
they'll
be
able
to
get
back
to
me,
but
if
they
were
to,
you
know
open
that
URL
on
another
device
or
if
they
were
to
opt
for
the
indirect
route.
G
Instead,
they're
not
going
to
be
able
to
redirect.
You
know
the
GS.
At
that
point,
it's
not
gonna
be
able
to
redirect
back
to
me
because
they're
going
to
be
on
a
different
device
that
I'm,
not
you
know,
doesn't
have
my
web
server
listening
on
it.
The
the
scenario
for
this
would
be
if,
if
an
app
is
running
in
an
environment,
that
technically
is
capable
opening
a
browser,
but
not
one
where
the
customer
actually
wants
it
to.
For
example,
if
it's
a
a.
C
Out
an
idea
because
to
me
the
time
you
can
come
back
or
not
it's
important,
because
the
the
GS
may
say
I
am
NOT,
going
to
interact
with
clients
that
are
indirect.
I
am
only
going
to
go
and
hand
this
hour
or
there's
only
certain
types
of
information
when
a
hand
to
a
client
if
it's
indirect,
yep,
yeah.
G
I
I
agree
in
the
because
and
I
think
you
mention
it
either
in
the
slides
in
Ex
off
doc.
The
you
know
the
issue
fundamentally
being
about
whether
you
can
have
that
session
fixation
or
whether
you
can
confirm
that
you're
in
the
same
session,
when,
when
you
come
back
to
the
client
and
that's
an
important
security
property
and
I,
think
we
want
to
make
sure
that
GS
is
have
have
an
ability
to
understand
whether
or
not
that
capable
capability
is
in
play.
F
And
I
will
say
it
is
exactly
that
decoupling
that
drove
us
to
current
structure
in
Xyz.
It
was
figuring
out
that
we
we
could
decouple
it
and
get
both
the
behavior
that
a
type
based
interaction
system,
gifts
and
additional
kinds
of
stuff
and
additional
kinds
of
flexibility
that
we
really
wanted.
So
we've
got
a
case
where
users
might
be
able
to
go
to
a
web
page
or
might
be
able
to
send
a
message
to
an
agent
that's
installed
on
their
device.
You
know
we
don't
know
necessarily
ahead
of
time.
F
What
is
going
to
be
the
right
answer,
it's
kind
of
up
to
what
the
users
doing
in
the
client
and
what
they're
asking
for
what
that's
going
to
be
so
the
client
basically
says
I
can
send
you
to
a
web.
I
can
send
someone
to
a
web
page
or
I
can
relay
a
message
that
you
might
have
to
their
agent.
What
would
you
like,
and
the
off
server
can
come
back
with
I
can
do
I
can
do
both
of
those.
F
C
Our
ATS
signaling,
we
should
probably
move
on
to
the
next
thing.
You
know,
and
then
we
should
mean
take
this
onto
the
list.
The
to
me.
It
was
important
that
the
GS
knows
or
am
I
going
to
be
able
to
redirect
the
user
back
or
not,
and
that's
a
better
signal
that
the
client
can't
choose
which
one
it
wants
to
do
afterwards.
So
I'm
going
to
go
to
the
next
slide.
Everybody
see
you
see
that
Dustin.
Yes,
yes,.
F
C
F
Maybe
sang
yeah,
and
so
I
will
say
here
that
what's
specified
in
X,
auth
is
in
the
direction
of
what
we
had
talked
about
at
one
point
and
X
Y
Z,
but
never
never
went
down
to
implementing
and
in
all
honesty,
I
think
that
the
right
answer
is
somewhere
in
between
these
two
I.
Don't
know
exactly
what
that
looks
like
I
have
to
actually
thing,
but
you
know
I,
don't
think
that
there's
a
lot
of
I,
don't
think
that
there's
a
lot
of
contention
here.
F
Especially
if
we're
going
to
be
going
in
the
direction
of
multiple
access
tokens,
which
again
we
you
know,
we
just
implemented
like
what
last
Thursday
or
whatever
then
I
want
to.
It
makes
sense
to
start
to
separate
management
of
individual
access
tokens
as
opposed
to
the
transaction
overall
or
what
Excel
calls
Monroe's
overall.
C
F
Yeah
client
authentication,
there's
there's
actually
a
fair
amount
of
overlap
between
the
two
drafts.
Now
because,
fundamentally
it's
about
you
know,
presenting
JSON
in
the
biggest
question
is
kind
of
you
know
what
the
signalling
discovery
and
mandatory
to
implement
mechanisms
are
in
Xyz,
at
least
as
we've
written
it.
F
C
C
C
B
G
C
G
F
F
But
only
when
it
have
been
required
to
do
it
and
yeah
now
ed
slide
sign
doesn't
just
live
any
heart
yep.
So
what
we
tried
to
do
with
XYZ
was
to
map
concepts
into
a
structure
that
was
internally
consistent
instead
of
just
applying
things
that
existed
before.
Just
because
we
had
taken
one
solution
in
OAuth,
2
did
not
mean
that
we
would
take
that
same
solution
in
XYZ,
and
so
what
that
basically
means
is
that
there's
a
lot
of
translation
between
the
two
worlds,
that
that
makes
sense.
F
So
you
know
there's
a
there's
a
key
handle
if
you've
got
a
registered
client
and
you
don't
want
to
pass
the
public
key
itself,
but
that
always
represents
the
key
which
is
used
for
dynamic
clients.
And
you
know
little
little
things
like
that
in
order
to
simplify
the
overall
the
overall
protocol
structure
and
to
make
things
easier
to
understand
both
from
a
developer
and
from
a
conceptual
perspective,.
C
And
in
excess
I
went
with
much
more
of
a
let's
take
those
values
and
find
a
place
for
them
within
the
request,
so
that
it's
that
the
friction
aren't
somebody
knowing
where
and
what
to
do
is
lower
and
that's
easy
for
them
to
understand,
and
also
that
there's
likely
going
to
be
different
ways
of
requesting
claims
in
different
ways
of
requesting
authorizations
and
so
typing
those
as
opposed
to
defining
a
new
language
in
it
and
I
see
no
one
in
the
queue.
Let's
move
to
our
last
slide
because
we're.
F
Right,
so,
if
you
don't
mind,
I'll,
just
summarize
that
in
Xyz
we've
got
an
inline
discovery
mechanism,
X
all
uses
options,
I
really.
You
know
and
I've
said
this
on
the
list.
I
think
our
eventual
solution
will
have
some
mix
of
both
I
think
that
it
makes
sense
to
do
some
preflight
on
on
one
XYZ.
You
would
call
the
transaction
endpoint
I
I'm,
not
convinced
on
the
others,
but
I
understand
that.
That's
you
know.
F
That's
part
of
the
idea
of
X
off,
but
I
also
think
that
being
able
to
do
things
fully
dynamically
without
a
discovery
step
beyond
knowing
just
the
transaction.
Endpoint
is
a
really
really
really
powerful
thing
that
that
clients
can
do
so.
I
think,
eventually
we're
probably
going
to
have
some
expose
Nick,
your
house.
C
Well,
I
think,
there's
always
you
know
here's
what
I'd
like
to
get
and
you
get
back
with
what
happened.
Some
negotiation,
but
I
did
think
it
was
important
to
have
I
would
like
to
know
what
you
can
do
before
I
start
doing
things
and
have
an
API
for
that.
So
the
options
call
and
since
we've
got
your
eyes
for
each
different
thing,
then
you
can
go
and
you
know
new
options
on
each
of
them
right.
F
And
to
me
and
I
think
that
this
is
this
is
true
for
both
of
the
protocols.
Something
that's
really
important
for
XYZ
was
that
the
client
has
one
piece
of
information
to
start
off
and
that's
the
transaction
endpoint.
There
are
a
lot
of
attacks
against
oo-ahh,
because
the
authorization
endpoint
in
token
endpoint
and
discovery
endpoint
key
endpoint,
all
this
other
stuff.
C
I'm
and
I'm
fully
aligned
on
that
because
you
know
effectively.
X
auth
works
like
that.
You
have
the
GS
URI
and
all
the
other
endpoints
are
ones
that
you
got
from,
calling
that
and
they're
all
you
know
dynamic
and
specific
to
the
client.
The
client
doesn't
know
them
until
it
gets
them
right
in
many
ways.
C
It's
sort
of
you
know
packing
the
identifiers
and
the
you
know
the
TX
endpoint
of
the
the
XYZ
endpoint
and
the
same
thing,
but
just
making
that
a
URI,
so
it's
kind
of
like
a
handle
plus
a
URI,
was
Mali,
but
then,
when
I
realize
I
was
doing
that
I
thought.
Oh,
if
I'm
doing
that,
then
I
can
just
have
different
methods
on
it,
because
it's
a
URI
I,
don't
see
anybody
in
the
queue
we're
almost
out
of
time.
Was
there
something
else
you
wanted
to
conclude
with
Justin,
otherwise
I'm
going
to.
K
D
Yeah,
this
is
a
very
old
comment
that
I
was
going
to
make
on
Justin's
XYZ,
but
it
also
pertains
to
X
off
that
the
XYZ
claimed
slide
showed
some
claims,
some
of
which
came
from
the
JSON
web
token
claims
registries
such
as
email
and
few
others,
but
it
also
invented
some
and
it
didn't
say
where
that
invention
was
occurring.
This
to
me
as
an
example
of.
D
De
facto
inventing
a
new
identity
schema
without
trying
to
reuse
the
others,
whereas
X
auth
presentation
showed
explicitly
that
it
was
reusing
cleans
already
in
our
existing
registries,
which
is
part
of
what
makes
me
much
more
in
favor.
If
we
have
a
starting
draft
of
starting
with
X
off
XYZ,
because
it's
not
trying
to
reinvent
identity
schema.
F
And
I
mean
I
repeat
what
I've
said
during
the
Charter
discussion
is
that
there
are
a
lot
of
different
identity
schemas
out
there
open
ID
Connect
is
one
of
them
and
for
the
types
of
information
that
that
we
want
to
get
back,
I
mean
I,
don't
think
we
want
to
adopt
all
of
open,
ID
connect
or
or
jot
inside
that
response.
I,
don't
think
we
want
to
encourage
people
to
put
all
of
that
information
in
there.
F
I
do
think
it
should
be
limited
and
I'm
never
explains
whether
those
claims
that
we
use
come
from
open,
ID
or
from
skim
or
from
some
schema.org
thing.
I
think
is
a
working
group
decision
and
I.
Don't
think
that
that
should
really
be
input
to
to
which
is
the
starting
draft.
I
think
that
that's
a
syntactical
bike
shedding
question
our.
A
And
a
thank
you
to
everyone
for
lots
of
good
inputs.
We
need
to
do
some
more
work
and
on
the
Charter,
and
we
would
continue
doing
that
on
the
mailing
list.
We've
had
really
good
discussion
over
the
last
week
and
so
I
expect
more
that
in
the
coming
days,
we
will
discuss
with
the
ad
whether
we
need
to
have
a
discussion
specifically
on
the
deltas
from
the
Charter
that
was
previously
published
or
whether
we
want
to
have
a
repeat
consensus
called
a
once.
I
Hi
yeah:
this
is
Robin
wrapping
up
yeah
I,
second,
that
thank
you,
everyone
for
your
flexibility
of
patience
with
this
all
virtual
format.
Given
this
unprecedented
these
unprecedented
circumstances
and
to
you
taking
your
on
as
well
you
you
ran
kind
of
this
first
meeting
of
the
week
for
us
and
that's
kind
of
tricky,
and
hopefully
we'll
also
learn
how
to
iron
outs
of
the
details
for
the
rest
of
the
week
for
this
bhave.
I
What
really
excites
me
is,
you
know
we're
talking
about
solutions,
we're
talking
about
running
code,
but
I
would
really
urge
us
not
to
get
ahead
of
ourselves.
I
mean
we
need
to
refine
the
scope.
The
discussion
here
enumerated
a
number
of
places
where,
where
we
need
to
get
that
clarity,
we're
of
course
going
to
have
to
take
that
back
to
the
list
and
I
think
in
the
absence
of
that
scope
and
that
clarity,
it's
going
to
be
difficult
to
really
top
them.
Talk
too
quickly
about
implementations.
I
So,
as
was
just
mentioned,
I
mean
the
next
step.
Is
we
need
to
take
this
feedback?
We
just
got
here
back
to
the
manual
list,
see
how
that
see.
How
that
relates
to
the
Charter
text,
we
have
and
cut
it
from
there
figure
out
kind
of
the
plan,
so
the
chairs
and
I
will
chat
about
how
how
we
can
do
that
with
an
incremental
tip
or
whether
we're
going
to
reissue
consensus,
but
again
kind
of
thank
you
for
all
that
feedback
and
for
those
all
online.
I
Please
do
you
know,
please
do
kind
of
watch
the
mail
list
for
discussions
and,
as
one
last
call
administrative
ly,
you'll
please
fill
out
the
blue
sheets
before
you
exit.
There
is
a
noticeable
death
between
the
number
of
participants
in
WebEx
and
in
on
the
virtual
blue
sheet
place.
So
please
do
who,
in
there
so
again
kind
of
thanks
everyone
out.
F
Alright,
so
as
as
I
mentioned
earlier,
I
will
take
an
action
to
propose
a
gift
to
the
the
original
charter.
Just
like
I
did
the
other
day
I'm
going
to
dip
from
the
original
one
that
Yaron
made
the
consensus
call
on
not
the
latest
one,
so
it'll
be
a
it'll,
be
a
complete
diff,
incorporating
the
MV
pack
from
the
secondary
one,
and
also
from
some
of
the
discussion.