►
From YouTube: IETF104-OAUTH-20190325-1610
Description
OAUTH meeting session at IETF104
2019/03/25 1610
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
B
A
Oh
thanks,
Tony
and
blue
sheets
are
going
around
here.
So,
let's,
okay,
so
let's
say
give
an
update
on
some
of
those
same
in
drafts,
are
thinking
that
a
browser-based,
a
apps
will
be
discussed
to
him
on
Thursday
the
device
flow
I
think
it's
I
think
it's
waiting
for
an
update
from
from
William
I.
Don't
know
the
latest
that.
C
A
B
D
Had
a
session
on
it
at
the
security
workshop
last
week,
so
we
resolved
a
bit
of
the
language,
but
now
that
we
have
the
server
metadata
done,
there
was
a
request
for
now
that
we
actually
have
a
place
to
register
server
metadata
parameters.
There
was
a
consensus
or
a
sense
in
the
room
that
some
of
the
parameters,
we
should
add
a
nayana
consideration
section
and
register
a
couple
of
extra
parameters
that
would
make
it
easier
for
people
to
use
it.
E
D
F
D
G
H
A
F
A
Okay,
good
so
I'm
jut,
introspection
response
that
will
be
discussed
today
and
TLS
of
its
custom.
Thursday
GOP
will
be
discussed
on
Thursday
a
reciprocal.
This
is
again
named
Dixie
document
and
resource
indicator.
This
was
submitted
to
the
IDF
to
the
eyes
G
just
recently
like
yeah
a
few
days
ago
on
three
weeks
ago,
right,
good,
the
security
topics
is
gonna,
be
discussed
later
today
and
a
token
binding.
So
this
is
I,
don't
think.
B
B
E
B
L
B
Also
wanted
to
point
out
that
we
are
holding
these
conference
calls
every
second
week
to
discuss
working
group
matters
and
if
you
guys
have
want
something
moving
along
or
if
there
are
some
questions
just
Eileen.
We
stayed
there
for
half
an
hour
and
and
chat
with
you
about
the
ongoing
topics,
so
just
to
make
sure
that
we
are
not
letting
anything
fall
between
the
cracks.
B
A
M
It
will
update
or
updates
the
threat
model
and
describes
our
newly
discovered
attacks
along
with
mitigations,
where
we
also
use
new
technologies
and
mechanisms
such
as
M,
TLS,
token
binding
and
so
on.
So
we
nicely
weave
them
into
our
recommendations
and
our
goal
is
to
give
implementers
simple
and
actionable
actionable
recommendations,
how
they
can
securely
implement
OAuth
applications.
M
M
M
So
this
means
the
implicit
grant
as
well
as
some
of
the
Odyssey
grants,
are
no
longer
recommended
by
this
working
group.
Anyone
is
free
to
use
them
or
to
continue
to
use
them,
but
our
recommendation
is
to
drop
them
and
replace
them
by
using
authorization
code
plus
pixie.
And
in
my
observation
and
last
week
we
had
a
very,
very
good
or
security
workshop.
M
Adoption
of
this
has
already
been
started
so,
for
example,
the
financial
grade
api
working
group,
if
the
open
and
ethan
Foundation
recently
are
removed
the
code
token
ID
token,
from
the
mod
or
to
spec
and
I,
also
learned
that
already
a
JavaScript
libraries
are
starting
to
to
support
code
plus
pixie,
and
there
are
some
more
changes
in
the
course
of
the
discussion
around
this
call
for
consensus
on
the
working
group.
A
lot
of
additional
topics
came
up,
for
example,
by
developers
of
s
pas.
They
ask.
M
How
are
we
supposed
to
work
with
refresh
tokens,
for
example,
and
that's
why
we
decided
to
add
some
more
text
around
the
use
of
refresh
tokens
to
the
BCP,
along
with
texts
on
how
replay
detection
can
be
achieved
for
refresh
tokens?
And
obviously
there
is
sender
constraining
there
is,
or
one
can
binds
the
Refresh
tokens
to
a
client,
ID
and
authenticate
a
client,
but
in
scenario
where
both
of
those
mechanisms
are
not
available.
For
example,
in
the
JavaScript
application
running
in
the
browser,
then
you
could
potentially
use
a
mechanism.
We
call
refresh
token
rotation.
M
M
Thanks
to
Daniel,
we
were
working
on
the
different
working
assumptions
than
for
the
original
thread
model,
meaning
the
attacker
model
has
changed,
and
that
was
one
of
the
main
reasons
why
we
why
we
started
to
work
on
that
PCP,
because
when
off
was
initially
published,
the
set
up
was
quite
simple.
There
was
one
client
one
a
s
and
a
fixed
set
of
resource
server,
so
a
rather
static
setup,
where
the
client
could
be
configured
at
runtime
to
some
URLs
and
then
could
use
TLS
server
authentication
to
make
sure
it's
talking
to
the
right
guy.
M
This
has
changed
completely.
Now
we
have,
we
are
facing
dynamic
scenarios
where
an
attacker
could
potentially
also
set
up
a
fake
RS
on
an
AS
and
steal
tokens.
So
we
already
considered
that
in
our
threat
analysis,
but
we
never
had
documented
in
you
attack
model
or
the
enhanced
and
tech
model,
and
we
did
that
now.
M
Ok,
are
we
done
yet?
We
don't
think
so,
because
there
are
some
open
topics.
We
would
like
to
bring
to
your
attention.
First
of
all,
during
the
security
workshop
last
week,
the
overall
security
works
up,
I,
think
net
raise
the
question
and
it's
in
the
end
it
wasn't
an
obvious
question:
how
shall
we
proceed
with
the
resource
owner,
password
credentials
and
I?
M
Yet,
although
we
recommend
sender,
constraint,
access
tokens
and
that
typically
includes
some
kind
of
public
key
cryptography,
either
em
TLS
or
some
application
level
stuff,
the
PCP
doesn't
talk
about
client
authentication.
Yet
does
it
mean
that
we,
like
client
secrets
Tony?
Where
are
you?
Do
you
like
client
secrets,
yeah?
Okay,
great?
M
So
our
proposal
is
to
to
add
a
recommendation
to
the
draft
to
for
implementers
to
move
towards
public
key
based
crypto
for
client
authentication.
For
these
reasons,
Tony,
do
you
want
to
say
something?
Okay,
you
smile.
That's
great
yeah!
That's
one
other
topic
we
would
like
to
include
and
third
since
we
now
made
pixie
a
mentor
feature
of
all
web-based
flown
off
for
the
purpose
of
replay
detection.
We
could
also
just
recommend
its
use
for
Caesar
after
that
prevention
because
it
basically
works
along
the
same
lines
as
a
state.
It's
a
it's
a
nun.
M
It's
it's!
A
one-time-use
nuns
with
even
better
protection
and
Daniel
are
also
after
having
talked
to
the
Stuttgart
researchers
that
they
are.
The
formal
analysis
of
Olaf
came
back
and
said
we
should.
We
should
get
rid
of
that,
meaning
that
the
state
parameter
would
be
freed
again
for
application
purposes.
So
if
we
just
go
for
pixie
as
the
mechanism
for
tying
or
authorization
sessions
to
a
certain
user
agent
and
to
detect
replay,
we
no
longer
need
to
recommend
state
to
be
used
for
CSRF
protection
and
the
last
one
is
the
pixie
mode.
M
We
don't
talk
right
now
about
a
pixie
mode
and
what
we
propose
is
to
go
with
our
sha-256,
because
it
is
better
by
the
properties,
since
the
code
challenge
can't
be
used
as
a
very
file.
So
if
an
attacker
gets
hold
of
a
of
a
coal
challenge
in
the
authorization
request
and
that's
part
of
our
new
attack
model,
it
can
be
used
to
in
the
end
completed
transaction.
So
those
are
the
three
proposed
changes
and
if
you've
got
an
opinion,
I
would
like
to
we'd
be
really
appreciate
to
hear
them.
N
Tony
nedelin,
so
are
you
just
gonna
propose
as
far
as
the
password
is
concerned
and
you're
just
proposing
totally
deprecating.
This
I
mean
it
is
used
like
a
heck
of
a
lot
out
there
today
I
mean
that's
where
people
started
from
and
it's
an
easy
way
to.
You
know
to
do
to
do
things
so.
I'm
just
I
understand
the
desire
to
not
promote
it,
but
I
worry
about.
You
know
the
input
in
the
implementations
that
are
out
there
today,
yeah.
M
I
read
and
dr.
Taylor
can
be
used
it
all
over
the
place
after
after
we
had
started
with
the
code
flow,
we
went
to
the
to
the
resource
owner
password
and
then
we
went
back
to
code
because
we
wanted
to
introduce
federated
identity
and
and
two-factor
authentication.
So
there
are
not
only
security,
our
reasons
for
not
no
longer
recommending
it.
First
of
all,
as
you
said,
well,
that's
what
I
heard.
M
If
we
recommend
that,
then
it's
called
kind
of
a
blessing
for
people
to
do
it
so
I
have
I've
met
developers
that
when
I
told
them,
oh,
it's
really
risky
what
you
do,
because
all
of
your
applications
are
gonna,
handle
credentials
yeah
sure,
but
you
can
find
that
brand
type
in
RFC
67
49.
So
it
must
be
okay
and
one
really
that
reads
the
security
considerations.
N
M
O
P
M
P
M
We
use
pixie,
as
it
is
just
as
a
nonce
to
to
tie
the
session
to
a
certain
user
agent.
The
only
difference
is
that
now
we
are
no
longer
limiting
pixie
to
public
clients.
We
also
recommend
to
use
of
pixie
with
confidential
clients,
because
it
addresses
a
different
need.
The
need
is
not
to
authenticate
the
client
but
to
authenticate
the
originator
of
a
certain
transaction.
D
So
just
declare
John
Bradley
so
that
clarification,
we're
not
proposing
deprecating
state
we're
proposing
no
longer
using
state
requiring
state,
be
used
for
CSRF,
because
90%
of
the
implementations
who
are
using
state
don't
properly
use
it
for
CSRF
and
since
pixie
provides
the
CSRF
protection.
We
can
say
you
can
just
use
state
for
state,
don't
worry
about
using
it
for
CSRF,
because
you're,
probably
not
going
to
do
it
right
anyways
for
applications
taking
yeah,
which
is
it
was
kind
of
a
dual-purpose
thing
here.
D
D
We
suspect
that
that
using
pixee
4cs
frf
protection
is
actually
going
to
be
more
effective
than
the
current
use
of
state
for
that
which
then
makes
it
easier
for
developers.
But
we're
not
saying
you
can't
use
state
for
CSRF
if
you
want
you're,
not
using
pixie.
For
some
reason,
you
still
need
to
use
state
for
that.
F
H
Q
O
M
Really
a
difficult
task,
as
we
learned
last
year
last
week,
we've
got
a
BCP
on
the
way
for
that,
for
that
specific
topic,
so
I
just
wanted
to
just
wanted
to
point
out
to
people
in
the
room.
There
is
another
sba:
BCP
are
being
worked
on
by.
They
would
wait
and
help
me
Aaron
Aaron
yeah
to
describe
how
SBA
should
be
implemented
on
top
of
OAuth.
Doesn't.
M
What
does
a
Stanford?
Thank
you
very
much
finial
to
each
application,
so
basically
all
kinds
of
applications
running
in
the
user
agent
and
they
have
different
properties
and
can,
for
example,
not
use
our
or
properly
or
simply
use
mutual
TLS
for
sender,
constraining
as
we
recommend
it
to
be
used
for
other
kinds
of
apps.
So
we
have
to
find
our
way
either
by
proposing
completely
different
architectures,
where
all
the
OAuth
stuff
is
put
into
a
back-end
where
all
those
other
mechanisms
can
be
used
again
or-
and
that's
that's
the
second
bullet.
M
We
come
up
with
a
mechanism
for
sender,
constraining
that
can
be
used
in
SPS
and
we
just
recently
discussed
at
the
or
security
workshop.
A
mechanism
john
bradley
proposed
something
and
we
gonna
gonna
do
a
write
up
and
we
hope
to
have
something
we
can
present
on
Thursday
and
there
are
two
other
aspects:
I
just
want
to
just
want
to
bring
that
up
here
for
your
information.
There
is
some
work
in
the
financial,
great
API
working
group
at
the
Open
ID
foundation.
M
That
is
dedicated
to
really
high
security
use
cases
where
we
are
working
on
protecting
what
I
call
rich
authorization
request.
So
authorization
request
carrying
a
lot
of
authorization
data
such
as
lists
for
of
accounts,
lists
of
documents
to
be
signed,
and
so
on.
That
needs
to
be
protected
against
modification
and
also
using
signatures
for
protecting
authorization
responses.
That's
not
work
being
done
in
the
or
working
group,
but
in
a
yeah
I
would
say
in
the
close
neighborhood
I'm
done
Mike.
Do
you
wanna.
H
So
Mike
Jones
Microsoft
I'm
gonna
challenge
I'm
gonna
challenge.
You
made
a
statement
you
made
fairly
quickly
early
in
your
presentation
where
you
said
there
was
working
groups
consensus
to
deprecate
the
implicit
flow.
There
was
a
vote
in
Thailand
without
much
prior
discussion
about
in
the
room.
Should
we
do
that,
but
I
just
looked
on
the
list
and
to
my
knowledge
there
never
been
a
working
group
consensus
call
on
that
topic.
H
Indeed,
what
happened
on
the
list
after
you
made
your
blog
post,
which
you're
welcome
to
do
right.
There
was
a
lot
of
people
saying
that
the
reality
is
more
complicated
than
a
black/white
choice
and
we
should
be
describing
the
security
trade-offs
of
preventing
token
injection
attacks,
preventing
token
theft
and
giving
people
as
much
actionable
information
as
we
could
so
I
guess.
My
request
is:
if
we're
going
to
actually
deprecated
that
there
should
actually
be
a
working
group.
M
So,
first
of
all,
as
you
may
know,
when
you've
read
the
PCP
the
PCP
he
gives
advise
so
it's
discouraged
use
of
those
flows,
and
it
also
gives
advise
what
to
do,
and
we
also
have
a
PCP
that
gives
advice
on
that
and
exactly
this
text
that
I
have
shown
you
was
the
result
of
a
working
group.
Consents
there's
a
threat
on
the
mailing
list.
You
can
look
it
up.
It
has
120
messages.
How
much
wanted
messages.
M
O
M
B
M
We
we
turned
around
over
the
over
net
recommended
to
make
it
a
must
not
I
leaned
in
favor
of
a
should
not
because
basically,
what
I
want
to
achieve
is
to
get
a
movement
rolling
right.
So,
in
the
end,
any
anybody
out
there
can
can
can
do
implicit
as
long
as
they
want,
but
I
don't
want
to
give
them
the
blessing
that
we
as
a
working
group,
recommend
this
kind
of
stuff.
If
you
take
a
look
into
our
see,
67
49
security
conservation
section,
it
explicitly
states
that
implicit
grant
is
vulnerable
to
injection
attacks.
M
I,
don't
know
exactly
why
we
ever
made
that
part
of
OAuth
seriously
speaking.
The
only
reason
I
know
of
is
at
the
time
when
we
published,
oh,
of
course,
didn't
exist.
That's
the
only
rationale,
and
since
that
this
is
no
longer
a
problem.
We
can
go
ahead
and
community
use
code
which,
in
the
end,
simplifies
all
as
a
whole.
So.
A
A
M
Tell
you
I
can
I
can
I
can
tell
you
what
my
observation
is.
My
observation
is
people
have
blamed
me
for
fear,
uncertainty
and
doubt,
but
basically
what
happened?
Is
the
community
started
to
move
in
the
direction
we
recommend
them
to
move?
As
I
said
they're
already
the
people
that
that
blamed
me
on
Twitter
started
to
to
migrate
their
JavaScript
library
to
support,
offer
recommendations
and
I
mean
what
can
we
hope
for.
P
R
M
H
C
B
So
to
hear
what
what
sort
of
impression
of
the
room
is
so
I
just
go
through
one
by
one
to
see
what
the
views
are
so
who,
who,
in
the
room,
is
in
favor
of
discouraging
the
use
of
the
resource
owner
password
credential
strand,
raise
your
hand
and
who's
who's
against
it?
Who
thinks
that
we
shouldn't
discourage
the
use
of
it,
so
I
I
would
say
that
be
blind
in
favor
of
discouraging
this,
of
course,
will
confirm
it
on
a
mini
list
who,
in
the
room
recommends.
Do
you
have
some
from
someone
from
under.
B
H
O
B
B
B
B
Well,
but
I
still
want
to
ask
because
I
think
it's
here,
it's
an
easier
one
and
and
others,
but
okay,
so
I
think
that
was
pretty
clear
and
that
people
want
to
follow
the
recommendations
you
put
on
that
slide
for
the
next
version
of
the
of
the
document.
But
we
still
do
a
consensus.
Call
on
the
mailing
is
to
make
sure
that
we
also
catch
those
who
are
not
on
the
online
Noah
in
the
room.
Okay,
you.
M
M
Thank
you
so
next
topics
I
would
like
to
give
you
an
update
on
a
draft
that
I
have
written
together
the
Vladimir
omnia.
So
we
enough
it's
about
just
protected
responses
from
the
introspection
endpoint,
so
what
it
basically
does
is
it
enhances
or
FCR
7660
to
by
the
ability
to
not
only
respond
with
a
JSON
response
from
the
token
introspection
endpoint,
but
make
it
a
jot,
which
then
allows
for
signing
especially
signing
the
introspection
response.
M
M
Basically,
some
auditing
and
non-repudiation
requirements
that
we
see
in
open
banking
and
also
in
the
electronic
signing
signing
sphere
and
the
problem
is
in
those
use
cases
you
not
necessarily
can
use
jots
as
access
tokens,
which
would
provide
you
with
this
kind
of
non
repudiation
by
auditor
signatures,
because
you
use
the
access
token
to
interact
with
different
resource
servers
and
in
those
situations,
introspection.
Much
better
fits
and
adopting
this.
M
M
Draft
was
adopted,
I
think
midlist
year
last
year
as
a
walking
working
group
item,
and
we
haven't
had
much
changes
since
Bangkok.
Basically,
we
updated
some
references,
for
example,
for
the
server
metadata,
but
the
draft
is:
is
here
it's
it's.
It's
a
it's
a
role
of
all
draft
they're,
all
a
simple
draft:
it's
being
implemented,
it's
being
used,
but
not
many
changes.
M
There's
one
open
issue
with
that
draft
and
I
would
like
to
bring
that
to
your
attention.
I
would
like
to
get
your
advice
on
that
just
since
it
suggested
to
change
the
draft
into
a
more
general
mechanism
to
enable
Church
responses
at
any
kind
of
o
of
end
point,
meaning,
introspection,
registration,
relocation
and
so
on.
I
brought
that
question
up
at
the
last
meeting
and
also
post
it
to
the
mailing
list
exactly
that
question,
and
there
were
exactly
two
postings
reacting
on
my
question
and
exactly
both
in
completely
different
directions.
M
So
Mike
just
said:
let's
do
one
thing
well
and
Justin
revised
his
support
or
its
proposal
to
make
it
a
more
general
generic
mechanism.
I
try
to
keep
niche
neutral
on
that
point,
but
my
my
objective
is
to
get
it
get
it
through
because
we
have
deployments,
depending
or
depending
on
that
draft
and
I
think
it's
a
useful
extension
I
would
like
to
get
your
advisors
of
working
group
and
us
working
co-chairs
how
to
proceed
with
that
topic.
S
A
Q
I'm
mark
I'm,
just
thinking
there
is
a
there-
are
use
cases
for
returning
a
job
from
introspection
endpoint,
but
returning
a
job
from
discovery
or
registration.
I
think
it's
been
soaked
already
in
a
standardized
way.
Isn't
it
like
that
you
have
assigned
metadata
document
as
a
job
as
part
of
the
discovery
response?
So
if
you
were
to
add
that,
then
you
would
have
to
change
it
as
well.
Those
specs
as
well
I,
don't
know
if
that's
worth
it
to
be
honest,.
I
N
Tony
Nadler
and
I
would
say:
let's
keep
it
simple
and
get
done
and
out
the
door.
I
think
it
solves
the
case.
The
use
case,
at
least
for
things
that
we
have
going
on
and
that
the
end
stuff
that
we
need
to
need
to
worry
about
right
now,
I'd
like
to
see
a
drag
you
up
for
another
year
and
we
don't
get
a
get
something
out
the
door.
That's
the
only
that's
my
concern.
A
M
O
So
from
from
Jabbar
just
insists:
well,
that's
my
point:
we're
doing
a
point
solution
in
parallel
and
shouldn't.
We
just
do
one
thing
everywhere:
I
think
the
end
state
might
be
the
same
thing
anyway
and
then
prior
that
Brian
said
in
my
opinion,
given
where
things
are
right
now,
I
think
keeping
this
document
to
be
introspection
only
in
scope
is
the
right
thing
to
do
so.
It
looks
like
Brian
adjust
their
since
again.
D
So
I
well
I
do
have
some
sympathy
for
Justin's
position.
The
reality
is
that
we
have
mime
content-type
negotiation.
Jots
have
a
mime
type.
There
is
a
clearer
way
to
ask
for
different
mime
types
that
people
already
have
for
other
specs.
The
difference,
I
think
is
all
of
the
trust
stuff
around.
It's
not
just
asking
for
a
jot
it's.
How
do
you
define
all
of
the
trust
relationships?
I
think
if
we
start
to
pulling
those
other
trust
relationships
into
this
spec
we're
not
going
to
finish
so.
D
Yes,
it
would
be
nice
in
in
principle
to
have
the
same
way
to
do
it
and
other
specs
can
do
it
in
a
similar
way,
but
they're
probably
going
to
have
to
define
their
own
trust
relationships,
so
I
think
other
specs
having
some
sort
of
profile
to
say
how
they
do.
It
is
going
to
be
required
anyways.
Yes,
they
can
follow
this
pattern,
so
I
would
come
down
on
the
side
of
keeping
this
not
dragging
those
other
things
into
this
back
and
just
getting
it
done.
R
C
B
C
G
Can
you
hear
me
okay,
hi
everybody
so
so
matcha
and
I
are
both
presenting,
so
we'll
be
going
back
and
forth.
Matcha
you'll
probably
want
to
turn
on
your
microphone.
If
you
haven't
so
we've
got
a
lot
of
material.
We're
gonna
be
just
doing
some
highlights
and
sort
of
treating
the
slides
leave
behind.
In
addition
to
matcha
and
myself
we're
both
presenting
remotely
there's
a
couple
of
other
relevant
folks
in
the
room
Pedro.
G
Can
you
just
identify
yourself
if
you're
there
it's
a
little
reading,
so
Pedro
is
a
an
uma
implementer
from
kee
cloak
from
Red,
Hat
and
also
ishaara.
Are
you
there
as
well?
You
say
hello
from
wso
to
another
implementer
and
they
are
willing
to
have
some
sort
of
evening
discussion
if
people
want
to
get
together
later
have
additional
questions,
maybe
over
a
beer,
so
you
can
figure
that
out
yourselves
later
on,
which
may
be
much
I
and
I
can
just
have
a
beer
ourselves
at
home
in
on
earth.
G
So
next
slide,
please
so
we're
just
going
to
cover
a
bunch
of
topics
pretty
quickly.
Those
last
two
topics
before
the
conclusion
or
just
if
we
have
time
I've
got
a
timer
set
here,
so
that
we'll
keep
an
eye
on
things
we
do
want
to
get
to
the
conclusion
and
next
steps.
Most
importantly,
so
I'll
keep
an
eye
on
that.
We're
gonna
take
a
progressive
disclosure
approach,
so
we'll
hit
a
few
topics
several
times.
G
S
Guys
can
you
hear
me?
Well,
yes,
okay,
fantastic
all
right,
so
we
we
all
know
right.
It
enables
like
constraint
allegation.
So
it's
a
pretty
straightforward
from
a
high
level
perspective.
We
have
a
resource
owner,
a
client
that
interacts
with
a
resource
server
at
the
authorization
server,
and
you
can
see
in
here.
We
have
these
kind
of.
We
have
that
kind
of
a
colocation
of
the
authorization
server
and
the
resource
server.
If
we
can
go
to
the
next
slide
and
uma
differs
in
outside
to
main
in
two
main
points.
S
The
first
thing
is
that
it
does
enable
a
cross-party
sharing.
So,
firstly,
the
sharing
of
a
very
sort
of
a
protected
resource
does
not
happen
to
just
a
different
application
to
a
different
client,
but
it
happens
to
a
different
to
a
different
party.
So
we
have
a
concept
of
a
resource
owner,
but
we
also
have
a
concept
of
a
requesting
party
with
which
can
be
different
from
the
resource
owner.
So
we
have
that
notion
of
a
cross-party
sharing
and
we
also
have
a
notion
of
a
wide
ecosystem.
S
So
if
you
take
a
look
at
the
at
the
bottom
of
the
other
diagram,
you
see
that
there's
no
dotted
kind
of
line
between
the
authorization
server
and
the
resource
servers.
It
means
that
those
resource
server
can
realistically
reside
in
different
domains.
They
can
be
kind
of
managed
by
different
organizations
and
still
talk
to
the
same
single
authorization
server
and
that
is
achieved
through
introduction
of
a
number
of
different
I
would
say
concepts,
but
also
endpoints.
S
S
S
The
upper
part
of
the
diagram
is
the
federated
authorization
for
OMA,
and
it
discusses
how
we
can
make
this
white
ecosystem.
I
would
say,
concept
a
reality,
so
a
single
organization,
server,
multiple
different
resource
servers
and
in
uma
we
have
this
new
set
of
tokens.
So
you
see
that
we
have
a
protection
API
token.
We
have
a
requesting
party
token,
we
have
a
persistent
claim
stock
and
we
will
discuss
them
on
examples
and
int
flows
in
the
next
in
the
next
slides.
So
next
slide,
please
so.
G
A
little
bit
of
history
of
how
all
this
came
to
be
so,
the
work
of
user
managed
access
has
been
done
at
the
Cantera
initiative,
where
people
had
wanted
to
sort
of
empower
users
to
share
data,
but
we
have
actually
had
some
interaction
with
IETF
over
time.
Why?
All
these
contributions
that
we've
been
making?
We
actually
had
a
goal
to
sediment
some
modular
pieces
into
wider
communities
where
appropriate,
so
we've
been
assessing
over
time
appetite
for
a
broader
adoption
and
and
doing
this
helps
promote
adoption.
G
So
actually
the
original,
dynamic,
client
registration,
spec
came
from
early
uma
works,
uma,
1.0,
work
and
matcha
is
one
of
the
authors
of
the
ultimate
oo,
auth,
dynamic,
client
registration
spec
from
this
history.
All
of
these
that
you
see
here
on
the
screen
are
expired,
except
for
the
new
uma
to
dot
o
drafts
and
any
questions
at
this
point
before
we
move
on
just
to
check.
Ok,
I'm,
not
actually
there
may
be
some
stuff
in
the
chat
that
just
flag
us
since
we're
remote.
Ok,
great!
G
S
So,
let's,
let's
discuss
the
uma
grant
for
authorization,
so
I
printed,
the
the
spec
and
I
think
it's
best
to
write
if
write
discuss
that
on
the
from
the
example
that
we
have
in
the
specification.
So
let
me
read
that,
and
let
me
relate
it
to
these
three
concepts
that
we
see
on
the
slide,
the
first
one
being
party
to
party
sharing
the
second
one
being
a
synchronous
and
the
third
one
mentioning
mentioning
policies.
So
the
example
that
we
have
in
the
spec
basically
says
the
following.
S
So
we
have
a
bank
customer
Alice
who
has
a
bank
account
service,
which
is
the
the
resource
server
and
she
can
use
a
sharing
management
service.
The
authorization
server
hosted
by
the
bank
to
manage
access
to
her
various
protected
resources
and
she
can
manage
access
to
her
spouse
of
an
accounting,
professional
Charlene
or
a
financial
information
aggregation
company.
S
So
all
of
those
kind
of
parties
that
can
potentially
access
they
are
the
requesting
party.
So
we
see
that
the
actual
sharing
happens,
not
you
know
from
Alice
Alice,
but
from
Alice
to
Bob
or
different
different
other
parties.
The
second
thing
is
that
it's
it's.
It's
a
synchronous,
so
in
the
case
of
it's
a
typical
scenario
that
we
would
authorize
access
to
a
protected
resource
in
case
of
uma,
what
happens
is
that
Alice
would
be
able
to
use
the
authorization
server
and
go
and
set
policies
not
at
the
time
the
actual
access
happens.
S
So
in
respect
to
the
to
the
grant?
It's
it's
not
a
it's,
not
a
synchronous,
interaction
and
the
second
thing
are
those
fall,
and
the
third
thing
are
those
policies,
so
at
the
other
is
a
server.
What
Alice
does
is
that
she
can
manage
I
would
say
various
different,
complex
policies
for
access
to
protected
resources,
so
it
doesn't
have
to
be
just
authorized
or
deny
it
can
be
a
more
complex
policy
that
requires
some
claims
gathering,
as
we
will
discuss
later,
that
mentions
some
conditions,
etc,
etc.
S
S
So
the
example
is
following:
it's:
it's
pretty
much
a
similar
similar
example.
We
have
a
bank
customer,
a
resource
owner
Alice,
who
has
a
bank
account
service,
a
resource
server,
but
also
a
cloud
file
system
which
is
a
different
resource.
Server
and
Alice
uses
a
dedicated
sharing
management
service,
which
is
an
authorization
server
hosted
by
the
bank.
So
she
can
manage
access
to
both
the
bank
account
service
and
to
the
cloud
service
from
a
single
authorization
server,
and
that
shows
this
1
to
n
relationship.
S
Again
she
manages
access
to
various
different
various
different
parties
and
during
the
sharing,
what
she,
what
she
can
do
is
that
she
can
define
whether
access
to
a
resource
is
of
video
type
of
edit
type
that
can
relate
to,
let's
say
files
or
in
relation
to
the
bank.
You
know
few
financial
data,
maybe
move
money,
etc,
etc.
So
this
scope,
scope,
grained
access
control
means
that
we
are
really
able
to
have
various
different
scopes
associated
with
various
different
resources
and
those
resources
and
scope
concepts.
They
kind
of
differ
in
the
uma
case.
S
S
Next
slide,
please:
okay
and
a
quick
reference
to
token.
So,
if
you,
if
you
recall
the
diagram
that
was
presented
earlier,
showing
the
the
two
specs
and
the
kind
of
the
two
different
mechanism
that
we
had,
we
have
two
in
Omaha,
then
the
three
main
tokens
that
are
in
the
in
the
flows
that
that
we
use
I'll
start
with
the
protection
API
access
tokens
with
the
path
token.
So
in
the
protection.
Api
access.
Token
is
a
token
that
allows
this
interaction
between
the
resource,
server
and
the
authorization
server.
S
So
the
authorizations,
sorry
between
the
resource,
server
and
the
authorization
server
the
resource
server
in
that
interaction,
acts
as
a
outside
playing
or
client.
The
token
has
to
have
the
uma
protection
scope
associated
in
it.
So
it's
a
probably
the
simplest
token
to
explain
the
other
two
tokens
which
are
very
much
uma.
Specific
is
the
requesting
party
token
and
the
persisted
claims
docket.
So
the
RPT.
That's
the
token
that
represents
the
permissions
when
a
client
tries
to
access
a
protected
resource
on
the
resource
server.
S
So
this
is
the
token
that
has
to
be
in
the
request
that
is
fast
from
the
client
to
the
resource
server
and
it
has
to
be
associated.
It
has
to
have
a
set
of
permissions
associated
for
the
access
to
the
protected
resource.
To
be
successful,
the
persistent
claims
talkin
as
we'll
explain
further
in
the
during
the
presentation,
is
some
kind
of
a
correlation
handle
that
allows
the
authorization
server
to
kind
of
remember
the
requesting
party.
That's
interacting
with
that
server
before
and
our
pretty
so.
N
G
The
RP
t
is
literally
just
an
access
token,
and
we
gave
it
a
nickname
because
we
had
a
couple
of
other
things
floating
around
in
the
environment.
So
it's
literally
an
access
token.
It
could
be
called
the
access
token,
except
that
the
Pat
is
also
an
access
token,
so
we
gave
them
nicknames.
That's
all
it
is
Thanks
thanks
for
the
question.
G
Okay,
implementation
and
use
in
the
wild
next
slide,
please
so
here's
some
typical
use
cases
we've
been
seeing.
Uma
was
originally
designed
for
this
Alice
to
Bob
use
case.
So
when
you
want
to
be
able
to
have
other
autonomous
third
parties
who
are
not
Alice
wielding
clients-
and
here
we
see
use
cases
like
patient
directed
health
data
and
device
sharing
financial
use.
Cases
like
this
discovering
and
aggregating
pension
accounts
and
sharing
access
to
financial
advisors.
G
That's
from
UK
pensions
dashboard,
which
is
where
the
UK
Department
for
Work
and
Pensions
has
been
doing
a
profile,
but
we've
seen
other
use.
Cases
arise
because
it
tended
to
be
sort
of
a
generative
use
case
once
solved
so
enterprise
k,
Alice,
so
enterprise,
API
access
management
and
access
delegation
between
employees,
because
the
initial
resource
owner
is
basically
the
enterprise,
as
well
as
an
Alice
Alice
use
case
where
you
want
Alice
to
be
able
to
proactively
set
policy
for
which
applications
get
access
to
her
stuff.
G
So
and
you
can
see
on
the
right
where
people
have
been
profiling
or
pointing
to
Emma.
So
those
are
some
use
cases
and
next
slide.
Please,
you
can
see
a
list
of
known
implementations
so
far,
so
as
I
mentioned
as
some
people
in
the
room
who
represent
some
of
these
implementations
as
well
as
I,
see
some
people
participate,
participating
and
observing
remotely.
If
you
want
to
ask
questions,
there
may
be
some
people
who
can
also
answer
through
the
chat.
G
Okay,
so
now
we're
going
to
change
gears
a
little
bit
in
the
next
section,
with
basic
flows
in
the
immigrants.
So
this
is
the
immigrant
spec,
which
is
kind
of
a
the
major
main
spec,
abstract
sequence,
for
the
uma
to
grant.
So
we're
just
going
to
build
on
this
swimlane
as
we
go
here.
These
are
sort
of
the
the
entities
getting
to
the
grant.
This
means
we're
focusing
on
the
client
perspective,
the
client
interacting
with
a
s
and
the
RS.
G
The
RO
is
not
in
the
picture.
Therefore,
we
said
it's
asynchronous,
so
they
may
not
be
around
at
all.
By
the
way
the
Illuma
clients
can
be
a
public
or
confidential.
So
a
little
similar
to
the
assertion
grant
the
client
can
have
learned
of
the
protected
resource
location
in
any
way.
So,
for
example,
maybe
the
requesting
party
role
of
Bob
role
might
have
clicked
on
an
email
link
or
whatever
next
slide.
Please
continuing
here.
G
So
the
initial
resource
request,
unlike
other
Roth
grants,
but
but
like
some
other
things
we
might
know
of
the
client,
goes
to
the
the
resource
server
first,
so
that's
kind
of
familiar
from
web
access
management
or
as
we're
seeing
from
some
ace
work.
One
of
the
ace
patterns
is
Planet
RS.
First,
so
we'll
discuss
some
implications
of
this
in
a
bit
next
slide.
Please!
G
So
now
we're
getting
into
the
response
to
a
token
las'
resource
request
for
something
that
turns
out
to
be
protected,
so
we've
got
a
client
that
is
Uma,
enabled
it's
going
to
know
how
to
respond
to
what
the
RS
sends
it.
In
this
response,
the
RS
is
going
to
get
what
Emma
calls
a
permission
ticket
and
yes,
then
send
that
in
a
header
called
ticket
the
clients
gonna
have
to
present
that
at
the
a
s
and
the
next
step,
the
RS
also
indicates
in
this
step
of
what
is
to
go
to.
G
G
G
If
we'll
have
time
today
or
if
there
will
be
some
discussion
time,
Thursday
I'm,
gonna
miss
it
will
be
a
little
my
night,
but
I
know
that
there's
some
pay
s
discovery
stuff
going
on
and
there's
been
some
discussion
on
the
list
back
in
the
fall,
but
I'm
just
gonna
suggest
that
we
go
to
the
the
next
slide.
At
this
brief.
S
Right,
yes,
so
so
we
have
this
permission,
as
you
saw
on
the
earlier
slide,
we
have
this
permission.
Ticket
that
gets
returned
to
the
client,
that's
trying
to
access
a
protected
resource
and
the
permission
ticket
is
kind
of
like
an
authorization,
it's
just
that
for
the
interesting
partition
and
the
client
and
it
binds
the
server
and
the
application
server.
S
Right
and
now
we'd
like
to
discuss
the
basically
the
way
that
we
exchange
sorry
the
way
we
actually
obtain
the
or
the
the
way
we
enter
the
entire
notes.
I
promise
were
like
an
abstract
assistant,
the
sequence
for
the
main
immigrant,
and
there
are
like
two
ways
that
we
can
that
we
can
enter
the
first
one
is
by
so
when,
when
the
client
obtains
the
permission,
ticket
M
decided
to
push
it
claims
directly
to
the
authorization
server
or
and
decide
that
it
will
redirect
the
requested
party
for
a
more
of
an
interactive
claims
gathering
flow.
R
G
S
G
G
So
I'm
gonna
I'm
gonna
leave
aside
some
of
this
the
the
lower
bubble
there
there's
you
know
some
sort
of
standard
access,
token
behavior
a
little
bit
of
behavior,
that's
unfamiliar
I'm,
not
gonna.
We're
not
gonna
spend
time
on
on
the
persistent
claims.
Token
today,
just
maybe
discuss
that
in
the
fullness
of
time,
but
the
reason
why
we
have
that
authorization
assessment
and
set
math
stuff
is
to
account
for
the
fact
that
there's
policy
conditions
that
the
resource
owner
can
set
up.
So
let's
talk
about
that
next
slide,
please
so
authorization
assessment.
G
The
reason
why
there
are
those
constraints
is
that
the
the
resource
owner
gets
to
say
if
you
think
about
like
uma,
is
sort
of
standardizing
a
little
bit
of
what
goes
on.
If
there's
like
a
Google
Docs
share
button
or
an
access
approval
loop,
the
resource
owner
has
a
chance
to
impose
some
wishes
on
the
process,
and
so,
if
Alice
gets
to
impose
some
wishes
and
then
Bob
has
to
prove
he's
him
or
prove
that
he
meets
some
criteria.
Well,
some
of
that
has
to
be
taken
into
account.
So
this
will.
G
G
G
So
so
this
is.
This
is
the
most
popular
flow
through
the
grant
sequence.
So
far,
among
the
options,
all
the
implementers
that
we
know
of
have
implemented
the
pushed
claim
option.
So
this
starts
with
the
back-channel
option
and
just
stays
there.
It
basically
just
uses
the
token
endpoint.
It
illustrates
kind
of
a
narrow
ecosystem,
in
that
the
AAS
is
also
the
IDP
that
Bob
uses.
So
the
client
lets
the
requesting
party
Bob
log
in
to
this,
a
s
that
is
the
IDP
and
then
it
hangs
on
to
the
resulting
ID
token.
G
It
pushes
that
ID
token
to
that,
is
the
IDP,
silently
to
prove
that
Bob
is
Bob
unrequired,
because
Alice's
policy
demands
that.
So
it
is
it's
kind
of
very
approximately,
like
IDP,
initiated
single
sign-on
or
something
so
there's
kind
of
this
narrow
oka
system
that
agreed
that
that's
what
was
needed,
or
it's
kind
of
like
Google
Docs
when
bob
has
already
logged
in
because
Alice's
policy
said,
share
this
document
with
Bob.
S
Okay
and
as
he
mentioned,
the
previous
one
was
more
of
a
more
popular
flow.
This
one
is
the
less
popular
one,
and
this
one
involves
the
actual
front
channel
interaction
of
the
of
the
requesting
party
at
the
TAS.
So
it
you
can
see
like
there
is
a
front
channel
redirect
of
a
requesting
party
to
the
claims,
interaction
endpoint
at
the
das.
G
One
quick
comment
about
that
last:
one
just
want
to
say
a
comment
that
we've
heard
at
least
from
one
or
two
implementers
is
that
that
claims
interaction.
It
kind
of
functions
like
an
authorization
endpoint
only
a
little
bit
more
flexible
because
you
don't
have
to
start
with
it.
You
a
go
to
the
token
endpoint.
First,
you
could
go
to
the
claims,
interaction.
First,
you
can
sort
of
mix
them
up,
so
it
functions
a
little
bit.
That's
why
we
call
it
the
authorization
token.
If.
N
Some
questions
in
reading
the
spec
it
was
hard
to
figure
out.
You
know
the
dynamic
claims
gathering
actually
works.
It
looks
like
if
there
was
some
undocumented
stuff
going
on
there
as
far
as
the
actual,
how
the
claim
the
protocol
to
actually
do
the
claims
gathering
and
the
other
thing
is,
you
know
you
know
we
I
looked
at
it
and
it
looked
like
resource
sharing
can
be
done.
You
know
by
some
some
of
the
token
exchange
work.
That's
been
done
in
here
and
have
you
guys
looked
at
that?
N
Integrating
the
token
exchange
work
in
this
stuff
and
then
I
still
am
curious
of
how
this
fits
with
current
authorization
servers,
because
they
have
a
different
pattern
today
and
I'm
a
little
bit
concerned
over.
You
know
changing
that
or
is.
Do
you
believe
that
this
is
just
for
users
that
have
to
go
through
the
uma
process
for
resource
registrations
and
stuff
so
I
mean?
Do
you
see
I
mean
you're,
proposing
this
as
a
standalone
document
as
I
understood
the
the
great
the
right.
G
G
G
So
there's
some
folks
who
are
wanting
this
for
privacy
purposes
basically,
and
they
have
not
found
something
that
actually
packages
it
up
for
privacy
purposes,
so
so
I
I
have
looked
at
it.
We
have
not
found
anything
that
actually
meets
all
of
the
needs
packaged
up,
and
that
is
part
of
the
challenge.
N
N
G
N
G
The
problem
is
that
you'd
have
to
build
a
lot
of
stuff,
I
believe
on
token
exchange,
which
is
a
building
block
spec
to
get
it
to
actually
solve
this
use
case
end
to
end.
That
is
what
people
have
been
discovering
I,
don't
know
anybody
who's
actually
used
token
exchange
to
solve,
share
button
and
access
approval,
loops
for
Alice
to
Bob,
sharing.
G
S
Right
questions,
or
should
we
come
to
the
next
slide,
yeah
all
right,
so
some
some
observations
of
the
clients
that,
like
I,
don't
know
if
Joe
is
in
the
room,
but
if
he
is
then
I
believe
some
of
those
are
his
comments
in
the
case
of
the
uma
clients,
what
we
realize
is
that
the
the
clients
themselves,
they
can't
be
a
little
bit
dumber
than
our
case
right,
so
they
don't
have
to
Caesarea,
understand
all
the
Scopes
etc.
They
can
start
making
requests
to.
S
They
can
make
a
request
or
a
resource
server,
obtain
the
permission,
ticket
and
kind
of
follow
the
interaction
based
on
that
permission
they
get
without
understanding
what
you
know.
What
cops
are
associated
there,
so
we
can
externalize,
this
entire
I
would
say
entitlement
logic
and
because-
and
then
the
second
aspect
is
that
also
the
outsid
error
flows
are
really
kind
of
well
defined
in
in
the
spec,
so
the
clients
can
based
on
whatever
they
receive
they
can
act.
S
B
G
S
Okay,
can
we
go
back
sorry?
This
light
is
fine
yeah,
so
so,
firstly,
in
the
federated
authorization.
So
what
we
have
is
that
the
AAAS
presents
a
standard,
what
we
call
a
protection
API
for
resource
servers
and
there
are
three
main
functions
of
the
protection
API.
The
first
one
is
for
resource
registration.
The
second
one
is
for
permission,
registration
and
the
third
one
is
for
token
introspection
and
there
are
respective
endpoints
for
that
old,
which
we
should.
S
We
chose
registration,
endpoint
permission,
endpoint
and
the
token
engine
and
the
enhanced
token
introspection
endpoint
for
the
resource
server
to
interact
with
the
protection
API.
As
we
mentioned,
it
has
to
have
a
part
which
is
a
plane
of
a
token
with
the
unmarked
protection
scope
associated
and
it's
typically
it's
a
issued
to
the
sorry
it's
issued
to
the
resource
server
with
with
the
resource
owner
in
place
unless
it's
a
unless
it's
a
kind
of
like
an
enterprise
resource
owner.
So
then
a
different
flow
happens.
If
you
can
go
to
the
next
slide.
O
O
F
G
S
S
It's
a
it's
a
restful,
endpoint
kind
of
like
a
crude
type
and
endpoint
that
allows
the
resource
server
to
start
managing
resources
for
protection.
So
it
allows
to
create
the
resource
description.
It
allows
to
list
the
available
the
registered
resource
descriptions
to
update
the
descriptions
to
eat,
etc,
etc.
S
Again,
all
the
research
all
the
requests
have
to
have
a
path
associated
next
slide.
Please
the
resources
and
the
scope
that
get
registered
are
so
two
things
on
the
resources.
The
resources
are
just
descriptions
that
get
registered
on
das
right,
so
the
earth
pretty
much
does
not
learn
what
the
resource
is.
The
information
that
gets
registered
is
something
that
should
allow
the
resource
owner
to
manage
a
policy.
So
there
are
a
number
of
things
like
a
description
and
icon
a
type,
etc,
and
importantly,
the
scopes
are
resource
specific.
S
S
Permission
and
point
very
simple:
once
the
client
executes
a
request
to
a
resource
server
the
resource
server.
What
it
does
is
that
it
registers
a
permission
at
the
authorization
server.
It
uses
the
permission
and
point
for
that
purpose.
You
can
see
an
example
of
a
request
at
the
bottom,
which
references
a
particular
resource
and
the
Scopes,
which
should
be
kind
of
added
to
that
permission.
S
So
to
that
permission
ticket
importantly,
the
the
resource
server
can
register
like
a
single
resource
or
an
like
an
a
set
of
resources
that
it
thinks
should
be
linked
with
the
permission
ticket
and
next
slide.
Please
and
the
talk
and
introspection.
So
the
packet
introspection
follows
the
the
OAuth
1
one
important
change,
so
it
does
not
return
the
scope
a
value.
Instead,
it
has
the
permissions
value
and
that's
because
we
have
this
kind
of
layered
structure,
so
we
have
a
resource
and
associated
scopes
for
that
resource.
G
Yeah,
let
me
let
me
sort
of
take
this
and
we
can
sort
of
go
to
the
end
right
after
this
I
just
wanted
to
point
out
that
we've
been
watching
with
interest.
What
ace
has
been
doing
also
watching
the
resource
indicators,
conversation
and
the
RS
offline
use
cases
is
of
interest
to
us,
given
some
a
lot
of
IOT
use
cases
that
that
almost
seems
to
have
so
I'll
just
sort
of
let
that
sit
there
in
case.
There's
people
interested
to
go
down
that
path.
G
And
we
can
skip
all
these
next
slides
and
I
think
go
to
slide
39,
and
we
can
go
to
the
conclusion
and
if
you
don't
mind,
I
can
just
I
could
just
take
these.
This
is
just
a
kind
of
quick
summary.
We
tried
to
put
together
based
on
stuff
that
we've
been
hearing
from
all
the
folks
who
have
been
implementing
and
using
uma,
so
I'm,
just
gonna
sort
of
let
that
be
there
as
a
sort
of
a
sort
of
a
leave
behind
I.
G
Suppose,
if
we
can,
we
can
take
Justin's
point
about
the
really
dumb
point.
Again.
That's
a
quote
so
I
put
it
in
quotes
on
the
client
side,
but
there's
benefits
that
we've
been
hearing
on
the
RS
side
about
externalizing
authorization,
that's
feedback
that
we
gathered
and
putting
this
together
standardizing
management
of
protected
resources,
again,
feedback
gathered
benefits
to
the
resource
owner
around
controlling
data
sharing.
G
That's
a
privacy
benefit
that
we've
been
hearing
from
those
who
are
you
know
those
were
in
the
position
of
deploying
this,
for
consumers
benefits
to
an
AS
and
to
the
requesting
party,
as
well
around
things
like
revoking
access
meaningfully
when
you're
actually
sharing
with
an
autonomous
third
party
that
becomes
really
different
than
we're
sort
of
sharing
it
with
yourself
using
a
client
and
so
I'll
just
go
to
the
last
slides
that
we
can
hopefully
have
a
little
bit
of
discussion
here
and
to
Tony's
point.
You
know
if
there's
ways
to
incorporate
specs
that
already
exist.
G
That's
you
know.
It's
part
of
the
point
of
sedimenting
things
down
and
part
of
the
point
of
you
know
leveraging
more
OAuth,
that's
actually
how
Huma
2
happened.
It
was
to
leverage
watts
to
more
fully
because
a
lot
one
was
based
on
a
auth
one,
but
apparently
not
enough
actually
and
then
os/2
happened
and
we
were
able
to
sort
of
leverage
o
auth
to
more
fully
and
that's
how
we
have
a
formal
extension
grant,
for
example.
G
So
you
know
we're
trying
to
solve
real
use
cases
that
people
seem
to
have
and
sedimenting
further
into
the
ecosystem
is
part
of
our
goal,
because
there's
seems
like
there's
pretty
high
demand
right
now
for
for
the
flows,
the
the
use
cases
that
that
we've
described
we're
trying
to
figure
out
a
way
to
leverage
the
expertise
of
this
group,
and
so
on.
So
here
you
can
see
the
proposal
on
the
screen
so
figure
out
how
to
open
it
up
and
the
time
remaining.
Okay,.
B
So
let
me
get
a
sense
of
who
has
had
a
chance
to
look
at
those
documents
and
thanks
for
submitting
them
and
say,
please
raise
your
hand
if
you
had
a
chance
to
look
at
them
three,
four,
if
a
few
five
six
yeah.
So
we
have
a
bunch
of
folks
who
actually
looked
at
the
documents
so
clearly,
this
is
currently
another
one
on
the
on
Java.
B
Clearly,
this
is
something
that
would
require
a
reach
on
train
because
it's
because
it's
obviously
not
in
our
Charter
today,
but
we
both
are
interested
to
hear
on
what
you
guys
think
in
in
terms
of
sort
of
adoption
for
this
group,
which
is
what
even
danmachi
are
asking
for.
In
this
specific
case,
John
John.
D
Bradley
hi
I'm
AJ,
unless
I
guess
my
question
is
exactly
what
are
you
asking
for?
Is
this
proposal
that
the
work
technical
specification
work
moves
to
the
OAuth
work
group
and
the
lumo
working
group
at
Cantara
winds
down
or
that
to
the
Covenant
parallel?
It
you're
you're,
probably
well
aware
that
once
something
becomes
an
IETF
spec,
the
working
group,
it
feels
obliged
to
make
breaking
changes
and
put
its
own
stamp
on
it.
So
I
mean
it's
I
mean
the
working
group
would
publish
a
fully
compatible
spec
with
what
Cantara
has
already
published.
D
G
If
there's
interest
to
your
question
about
what
would
happen
to
the
existing
work
group
in
Cantara,
there's
actually
existing
work,
as
I
pointed
on
the
slide.
That
would
probably
continue
at
least
for
a
time
number.
One
interrupt
processes
for
the
current
specs,
which
are
Cantara
recommendations,
were
we're
planning
to
have
an
interrupt
results
report
out
effectively.
G
It
identifies
for
one
and
there's
work
that
I
didn't
report
on
right
here
for
times
sake,
but
work
that
we
call
business
model
work,
and
you
know
we
can
just
treat
it
as
a
lead
behind
that
are
in
the
slides
here,
I've
presented
on
it
previously
over
the
last
year.
Plus,
that
would
probably
continue,
as
you
know,
as
long
as
the
specs
are
stable
enough
or
you
know,
would
continue
in
some
form
to
whatever
state
the
specs
are
in
you
know,
breaking
changes
would
be
on
fortunate.
G
F
O
B
D
D
D
B
B
R
B
Because
we
ran
out
of
time,
but
maybe
we
clarify
this
high-level
point
and
if
so,
the
question
of
a
surrounding
here
is
like
in
the
contributions
that
you're
making.
If
these
documents
do,
you
expect
them
to
be
published,
as
our
sees
as
they
are
today,
like
as
you
have
submitted
them,
or
are
they
supposed
to
be
input
to
the
working
group
with,
but
then
most
likely
there
would
be
changes
sort
of
specification,
as
we
have
seen
all
our
specifications
change,
which
one
of
those
two
do
you
are
you
aiming
for.
G
G
We
had
not
talked
about
it
or
consider
it
considered
it
I
would
have
thought
that'd
be
confusing,
but
constrained
or
IOT
use
cases
are
definitely
something
we
had
been
striving
for
in
our
work
over
the
last
few
years.
I
I,
don't
know
how
it
would
work
to
contribute
them
to
two
groups
with
the
same
aim
that
I
just
expressed.
So
maybe
somebody
could
say
that
no.
O
B
Think
I
think
the
most
likely
route
in
that
context
is
like
it
was
done
by
the
age
group
in
other
contexts.
They
define
different
transports
for
stuff
that
we
define
in
this
working
group.
So
sorry
right,
oh
yeah,
but
we
would
double
check
that,
but
we
would
we
are
going
to
send
a
mail
to
the
list
about
this
and
continued
discussion
from
there
and
see
what
the
level
of
interest
is.
Thanks
even
ma
che
for
the
presentation.
Thank.
G
U
Right
I
know
you
guys
have
tired
and
bored,
so
I
will
try
to
keep
you
alive
for
the
next
fourteen
minutes,
I'm
gonna
present
on
a
new
work
which
occurred
basically,
all
in
the
last
20
days
and
too
long,
alekhya
long
didn't
read.
We
are
trying
to
find
an
interoperable
profile
for
access
tokens
that
uses
credibility
can
I
have
the
next
slide.
Please
thank
you.
U
So,
to
give
you
just
a
bit
of
context,
I'm
sure,
vector
in
your
professional
life,
you
have
stumbled
the
countless
times
in
situations
in
which
access
tokens,
which
are
not
are
shapeless
according
to
off
to
in
fact,
have
been
implemented
by
particular
vendors
in
JWT
format.
Now
it
doesn't
mean
that
the
scenarios
in
which
you
have
in
no
format
access
token
are
not
valid.
U
However,
given
that
verses
the
guidance,
they
all
do
this
in
a
slightly
different
way,
different
enough
that
you
can't
standardize
on
SDKs,
you
can't
sterilize
on
approach
and
sometimes
they
the
same
concept
is
interpreted
differently.
So
it's
a
mess.
Also,
there
are
many
specifications
that
somehow
always
talk
about
these
mythical
audience
in
the
access
tokens,
but
we
never
refer
to
it
anyway.
So
clearly,
I
believe
that
there
is
a
need
for
some
guidance
where
that
will
help
unify
and
avoid
reinventing
the
wheel
across
multiple
providers.
U
U
This
proposal
and
I
have
to
say
that
that
was
a
really
amazing.
Let's
say
that
the
progress
was
really
fast.
Many
ideas
which
were
not
particularly
well
advised
were
killed
right
away.
Other
really
great
ideas
were
contributed
in
it
and
then
on
my
flight
back
from
Germany
I
wrote
everything
in
a
draft
yesterday,
I
changed
it
in
your
silly
XML
syntax,
which
is
really
really
I,
felt
like
when
I
first
learned
about
Fortran
as
a
fix.
U
The
columns
like
really
like
what
sentries
vis
but
anyway,
never
mind,
I,
somehow
managed
to
convince
the
uploader
to
accept
a
draft,
and
now
a
draft
is
now
and
I've
sent
a
mail
to
Melissa.
I
already
got
interesting
feedback
and
I
know
that
others
are
talking
about
this
on
Twitter
another
eye,
deep
release
and
similar
so
clearly
I
believe
a
very
some
interesting.
Can
we
go
to
the
next
slide?
Please
thank
you,
and
even
the
next
one.
U
Thank
you
okay,
so
this
packet
isn't
longer,
it
shouldn't
be,
and
it's
relatively
simple:
it
just
tries
to
bring
you
some
fix.
The
points
in
here
so
here
in
these
short
presentation,
I
just
want
to
give
you
a
taste
of
it,
but
of
course,
I
think
that
the
the
discussion
is
much
done
on
this
back
here
in
itself.
So
here
there
is
a
Model
S
ver,
a
layout
that
emerged
from
the
cross
analysis
of
all
these
different
access
tokens.
U
Where
is
a
bunch
of
claims
that
are
typically
used
for
establishing
validity
or
a
token,
and
those
are
all
good
friends
that
we
know
we
have
been
known
for
a
long
time
we
needed
to
know
Vera,
we
need
to
know
exploration.
We
really
want
to
scope
these
access
tokens
down
to
an
audience
in
11,
more
to
say
about
it
when
in
a
couple
of
sides
from
now,
and
then
we
have
like
a
classic
information
about
the
issuance
time
or
authentication
time
which
can
occasionally
come
in
useful,
but
not
mandatory.
U
It's
just
a
matter
of
like
convenience
and
reliability
of
a
kind
of
information
that
is
in
there.
But
anyway,
that's
already
in
the
list
to
discuss.
Then
we
discussed
the
possibility
of
giving
some
guidance
on
how
to
include
identity
claims
in
Access
sockets,
and
we
know
that
there
are
privacy
concerns
and
saw
in
the
current
draft
their
various
language
which
wants
the
reader
that
always
should
be
done
with
care.
However,
we
know
for
a
fact
that
the
vendors
do
v's.
U
Let's
say
that
the
day
samples
that
I
got
contain,
identity,
permission
model
user,
so
ad
waiver
links
giving
guidance
of
a
flavor
of
a
claims.
What
we
used,
and,
in
particular
the
one
that
we
got
from
the
open
area,
connect
profile
and
the
introspection
seem
to
be
good
their
starting
points.
Then,
of
course,
now.
Finally,
we
have
a
way
of
specifying
for
certain
the
scope,
and
there
is
some
logic
that
I'm
suggesting
about
how
to
map
between
scopes
in
requests
and
how
they
would
appear.
U
Of
course,
we
know
that
authorization
is
a
Cambrian
explosion,
so
we
wouldn't
probably
want
to
get
into
the
details
of
what
goes
inside
of
a
sphinx
but
in
terms
of
type
I.
Think
that
we
the
benefit
everyone
by
suggesting,
at
least
that
we
claim
types
that
we
still
act
are
from.
One
agreed
upon
scores
and
the
best
one
that
we
identified
during
the
the
workshop
last
week
was
a
scheme
core
which
has
some
good
times.
Tony.
Do
you
want
to
do
visa
at
the
very
end?
U
U
One
minute:
okay,
I'm
gonna,
go
even
faster,
so
instead
of
a
wave
client,
ID,
okay,
perfect
doing
really
good.
So
one
very
important
thing
is
that
we
want
to
make
sure
that
the
people-
don't
sir,
don't
misinterpret
the
access
tokens
expressing
should've
left
me
as
ID
tokens
make
use
of
that
would
lead
to
issues.
So
we
are
using
stronger
typing
and
I'm,
suggesting
that
we
created
your
mime
type.
In
fact,
it
makes
very
clear
that
in
season
actually
spoken
and
should
not
be
interpreted
as
an
access
token
next
slide.
U
Thank
you
just
give
you
a
flavor.
This
would
be
the
smallest
access
token
each
other,
but
you
from
our
materials
we
can
obtain.
There
should
be
no
surprises
in
there.
As
you
can
see,
there
is
no
PII,
so
good
stuff,
next
fence,
okay,
when
we
request
an
access
token,
you
know
whatever
a
traditional
way
we
are
doing.
We
can
get
back
into
the
ability
access
token
just
like
before
when
we
use
the
express
indicator
and
we
pass
the
resource.
U
Unfortunately,
in
my
opinion,
resource
indicator
allows
using
multiple
audiences,
and
that
is
a
problem,
because
when
you
have
a
list
of
scopes,
unless
the
new
scopes,
nothing,
you
might
get
in
EPS
no
confusion
in
which
you
don't
know
what
scope
is
relevant
for
what
lasers,
so
so,
for
the
sake
of
simplicity
and
the
effectiveness
in
here.
This
rejection
is
to
restrict
resource
on
single
resources,
as
course
to
leave
the
resources,
and
that
should
prevent
scope.
Confusion
for
vacation
in
which
a
resource
is
not
provided.
At
the
request
of
time,
the
novelization
said.
U
Where
is
suppose
that
you
have
some
resources
string
that
will
be
used
in
the
audience.
This
can
be
a
different
value
extracted
from
context
or
it
can
be
extracted
from
scopes
if
it's
Corp,
somehow
in
in
one
particular
resource,
your
physicians
are
where
should
be
able
to
pull
this
out.
Of
course,
it
is
open
up
the
possibility
of
scopes,
giving
contrasting
resources,
and
so
a
veg
with
some
kind
of
battle.
Next,
please,
but
it
isn't
even
gonna,
be
surprising
for
anyone.
U
The
idea
is
if
we
are
using
a
symmetric
crypto,
we
can
publish
of
the
valley
different
coordinates
through
rayon
organization
server
metadata
or
they
open
the
connect
discovery,
which
is
what
almost
every
vendor
does
already
today.
The
checks
are
substantially
we
needed
to
check
in
every
type
is
the
80
plus
2ws
and
then
all
the
other
tracks.
U
You
can
see
the
spec,
but
we
are
largely
what
you
would
expect
from
the
claim,
not
with
your
being
possible
open-ended
is
whether
we
should
explicitly
say
that
we're
physician
server
should
look
and
air
actor
on
the
slopes,
because
that's
something
that
we
don't
do
else.
One
next
place
I
already
made
even
easier
security
concentrations
nor
next
and
a
for-profit.
Here
we
just
be
extra
certain
that
we
remind
the
reader
so
respective
actor.
Now
the
client
will
be
able
to
see
inside
the
token,
even
if
they
are
not
cause
look.
U
These
remains
of
big
for
clients,
but
in
practice
someone
might
see
the
content,
and
so,
if
you
content
is
not
even
user
single,
his
or
her
own
information,
we
should
take
measures
to
protect
it
and
then
a
row
concerned
disclosing
it
sponsor
to
the
resource
server
like
identities
and
similar.
We
have
to
make
sure
we
have
everything
by
the
book
Xena.
If
we
add
it
to
ask
for
consent,
you
got
it.
If
we
add
it
to
have
a
users
agree
on
a
some
time
of
use.
U
B
That
that's
you
know
like
not
only
you
you,
as
you
know,
like
I'm,
not
going
to
ask
you
and
now
for
adoption,
because
that
would
be
a
little
bit
too
fast,
but
I
would
like
to
get
a
sense
of
the
room,
but
are
there's
interest
in
doing
anything
like
this
at
all,
regardless?
What
exactly
the
recommendations
are
that
we
will
come
out
at
the
end
of
the
tunnel.
B
So
I
guess
what
we
will
do
is
drop
a
major
to
the
list
and
encourage
people
to
read
the
document
and
provide
some
comments
and
then
we'll
obviously
have
to
talk
to
the
ABS
to
find
out
or
ad
to
find
out
whether
that
fits
in
the
scope
of
the
group
or
reach
out
during
or
milestone
editions
are
needed.
Definitely
milestone.
Editions
of
reach
out
during
probably
not,
but
the
milestone
Edition
will
need
to
figure
this
out,
but
yeah
I
think
that's
where
what
we
should
do
Vittoria.
What
do
you
think.