►
From YouTube: IETF103-OAUTH-20181106-1120
Description
OAUTH meeting session at IETF103
2018/11/06 1120
https://datatracker.ietf.org/meeting/103/proceedings/
C
C
B
A
F
Quiets
down,
okay,
second,
all
session.
Welcome
everybody
talk
real
quickly
about
OAuth
2
resource
indicators,
just
for
the
record.
I
hate
this
name,
but
I
came
up
with
it
years
ago
and
I
can't
think
of
anything
better.
But
if
you
have
any
real
suggestions,
I'm
happy
to
hear
them
on
the
list
or
in
person
or
whatever,
but
yeah
resource
indicators.
Here
we
go
it's
a
little
bit
of
context
about
what
this
draft
is.
F
Basically,
there's
not
a
lot
to
it
on
the
surface
anyway,
it
defines
a
resource
parameter
that,
basically,
is
just
a
URI
or
you
are,
is
where
the
client
is
requesting
access,
and
this
is
applicable
both
at
the
authorization
endpoint
to
convey
basically,
the
requested
access
of
the
whole
grant.
That's
being
asked
for-
and
it's
also
applicable
at
the
token
end
point,
which
is
more
specifically
about
the
the
scope
of
use
of
the
access.
Token.
That's
being
requested
right
there.
What
what
resources
are
you
going
to
use
that
particular
access
token
app?
F
Why
are
we
doing
this?
There's
a
lot
of
reasons,
but
largely
because,
knowing
the
the
target
resource,
where
the
access
token
is
going
to
be
used,
enables
that
token
to
be
minted
and
constructed
appropriate
to
that
resource
itself,
and
that
might
involve
encryption.
The
various
content
are
claims
and
the
token
might
vary
based
on
the
target,
whether
you
want
to
do
a
reference
style
token
or
a
self-contained
token.
F
Various
keys
or
algorithms
that
are
used
might
vary
based
on
the
on
the
target,
resource
and
etc.
It
also
facilitates
proper
audience
restricting
of
access
tokens.
So
by
knowing
where
it's
going
to
be
used
versus
just
the
scope
of
access
you
can,
you
can
put
a
proper
audience
restriction
in
there.
The
draft
right
now
says
that
the
das
can
take
the
resource,
URL
value
and
use
it
exactly
as
provided
or
it
might,
map
map
to
an
audience
value.
F
That's
a
more
general
URL,
or
even
potentially,
depending
on
the
deployment
of
abstract
identifiers
for
that
resource
or
set
of
resources
that
it's
value
determined
for
and
a
question
that
came
up
at
least
when
we
talked
about
this
in
the
past
is
what
about
scope,
and
at
least
conceptually.
The
idea
here
is
that
scope
is
about
the
what
what
kind
of
access
is
being
requested,
while
resource
allows
for
the
actual,
where
to
be
conveying
independently
of
the
scope.
F
That's
sort
of
the
idea
there
I'll
go
to
the
next
slide,
I'm
worried
about
what
sources
and
I
say
so
a
couple
of
notable
happening
since
Montreal.
This
documents
been
around
for
quite
a
while,
but
it
got
adopted
as
a
working
group
document
shortly
after
Montreal
talked
about
it,
the
meaning
we
published
the
0-0
draft
and
it
was
just
the
zero
zero
was
just
a
copy
of
the
individual
draft
which
honestly
hadn't
been
updated
in
any
substantial
way
for
a
number
of
years.
So
a
few
months
later,
I
got
around
to
publishing
a
version.
F
F
They
drifted
in
earlier
stages
by
editing,
but
I
hated
this
draft
again
to
come
in
alignment
with
token
exchange
and
the
resource
parameter
is
now
allowed
to
have
a
query
component
I've
had
some
I
tried
to
simplify
things
by
taking
that
out,
but
to
be
consistent,
and
they
were
use.
Cases
expressed
that
that
desired
that
so
it's
now
allowed
here
and
I,
don't
know
how
to
summarize,
at
all
other
than
to
say,
I,
really
significantly
reworked
the
whole
main
section
and
content
of
the
document
to
try
to
explain
how
it
works.
F
Better,
explain
how
the
resource
parameter
might
be
used
on
the
authorization
and
important
to
request
total
sort
of
location,
I
wanted
to
say
scope,
but
that
words
a
little
overloaded
too.
Although
all
the
resources
requested
for
the
whole
access
grant,
that's
being
requested
there
versus
how
would
be
used
on
the
token
endpoint
to
specifically
request
a
narrowly
targeted
audience
restricted
token,
and
and
just
try
to
explain
that
out
of
examples
through
it.
F
F
Conversation
post
that
so
try
to
clarify
those
things,
make
it
more
straightforward,
hopefully,
a
little
bit
easier
to
read
and
I
can't
really
summarize
anything
more
than
to
say
that
and
requests
people
take
a
look
at
it
and
hopefully
they
find
it
is
easier
to
read
and
understand
so
that
basically
just
leaves
us
looking
ahead
to
the
next
meeting.
I'll
not
be
able
to
be
in
Prague,
so
you
won't
have
to
be
subject
to
my
photographs,
at
least
that
time
and
I
just
think.
F
Ask
at
this
point
that
people
review
the
the
version
1
of
the
draft,
because
it
has
been
largely
reworked
from
the
original
version.
Again,
like
I
said
it
hasn't,
changed
functionally
so
much
as
just
tried
to
explain
the
use
cases
in
the
usage
and
how
it
would
be
applied
a
little
bit
better.
That's
all
on
this
one.
G
F
F
And
in
practice
those
things
already
are
getting
confused,
I've
tried
to
clarify
how
they
might
be
used
and
what
you
can
do
with
one
or
the
other
in
the
document,
as
best
I
can,
but
you
know,
I
think
it's
a
legitimate
concern
that
I
don't
know
it's
made
any
worse
by
this
document.
Hopefully
it's
made
a
little
bit
a
little
bit
better,
or
at
least
given
possibility
to
express
things
more
more
accurately
to
what
they
are.
I
It's
not
a
perfect
solution
because
it
disentangle
resource
and
scopes,
and
you
know
my
personal
opinion
on
that
is.
We
should
have
a
solution
that
allows
us
to
specify
the
resources
and
what
can
happen
on
those
resources
which
would
allow
yeah,
but
nevertheless
I'm
fine
with
that
and
now
I
contributed
to
the
to
the
rework.
So
it
dresses
a
lot
of
use
cases
I'm
worried
about,
for
example,
that
we
need
a
mechanism
to
really
implement
audience
restriction,
something
that
we
are
also
pointing
out
in
a
security
PCP.
I
F
You
I
think
there
are.
You
know
where
we
starting
from
scratch,
there's
a
lot
of
things.
We
could
do
to
kind
of
capture
both
sentiments,
more
expressively
in
a
single
parameter
value,
but
we're
not
so
the
goal
of
this
was
to
very
pragmatically
layer
on
an
extension
on
top
what
we
have
in
order
to
facilitate
this
kind
of
stuff,
it's
not
to
say
it's
the
best
solution,
but
it's
a
pragmatic
approach.
I'm.
I
C
F
F
I
wasn't
getting
any
other
work
done,
but
I
was
trying
to
sleep
unsuccessfully.
So
what
what
is
this
and
why
are
we
doing
it?
Basically,
the
draft
defines
an
enhanced
security
for
oauth2
and
it's
based
on
TLS
client
certificates
and
a
lot
of
this
stuff
is
already
being
done
and
being
used
by
open
banking
and
PSD
to
type
regulatory
regimes
that
are
demanding
things
like
API
based
payments,
but
they
want
to
have
a
stronger
security
profile
than
just
pure
bearer
tokens
for
that.
F
So
there's
already
a
suite
of
standards
out
of
not
IETF
but
but
other
types
of
organizations
and
consortiums
that
are
building
on
top
of
the
functionality
provided
in
this
standard.
So
what
is
it
exactly?
It's
it's
two
things
largely
it's
an
asymmetric
key
based,
client
authentication
mechanism
from
the
OAuth
client
to
the
authorization
server
relying
on
mutual
TLS
and
then
there's
two
sub
components
of
that
two's
ways
to
do
it.
One
is
a
PKI
based
mode
where
the
subject
DN
is
provided
during
registration
time
to
the
authorization
server.
F
You
just
do
proof
of
possession
at
the
TLS
layer
to
ensure
that
the
private
key
is
held
associated
with
the
certificate,
and
then
you
just
match
up
this
two
ticket
certificates
verbatim
to
what's
what's
in
in
client
configuration,
then
on
top
of
that
or
on
side
of
that.
In
addition
to
that,
I
guess:
there's
a
mutual
TLS
certificate,
bound
access
tokens
for
proof
of
possession
on
protected
resource
access.
F
So
it's
a
way
to
bind
these
access,
tokens
that
are
issued
to
the
client
certificate
and
then
have
the
client
prove
possession
of
that
that
certificate
and
corresponding
private
key
when
it's
doing
doing
protected
resource
access,
which
you
know
prevents
me
cross-play.
It
prevents
a
stolen
token
from
being
used
and
it
prevents
a
resource
server
that
receives
that
token.
F
Some
things
that
have
happened
with
this
document.
Since
Montreal,
we
went
through
a
working
group.
Last
call.
We
had
the
Shepherd
right
out
done
shortly
after
that
updated
in
draft
10
to
use
the
RFC
version
of
s
metadata
and
the
associated
registry
and
draft
11,
updated
and
added
a
reference
to
TLS.
One
three
got
some
developer
feedback
us
off
list
that
basically
asked
for
some
clarifications
around
some
things,
particularly
around
exactly
how
the
confirmation
hash
of
the
certificate
was
generated
and
the
encoding
of
that
so
try
to
clarify
some
wording.
F
That
may
be
clarified
again
based
on
some
ad
feedback,
but
that
also
resulted
in
adding
an
example
certificate
and
corresponding
value,
so
that
you
know
developers
could
could
actually
check
their
work
and
make
sure
it
matches
up
to
what's
specified
after
that
got
some
more
feedback
off
list,
but
it
was
feedback
that
came
in
to
list
this
morning.
I'll
talk
about
a
little
bit
more
in
some
detail
section
here
and
then
yesterday
morning
the
ad
review
rolled
in
so
we'll
be
looking
at
that
as
well.
F
So
then
the
first
question
that
came
up
from
that
most
recent
developer
feedback
is
around
support
for
subject.
Alternative
names.
I
say
here
basically
that,
although
all
the
cool
kids
are
using
sans
nowadays
and
contrary
to
what
I
was
thinking
they're
even
doing
it
for
a
non-issue,
Beth
server
certificates.
F
Thank
you
yeah,
and
it's
been
suggested
that
the
usefulness
and
useful
life
of
this
draft
could
be
greatly
expanded
if
we
supported
subject
alternative
names
in
the
PKI
off.
So
as
I
said
before
right
now,
all
that
supported
is
specifying
and
expected.
Subject
the
end
and
folks
are
asking
for
equivalent
type
functionality
to
allow
for
specifying
an
expected
subject:
alternative
name,
the
one
specific
request
was
specifically
for
a
URI
SAN,
but
I
think
you
know
thinking
about
this.
F
F
It's
really
appealing
because
we're
so
close
to
being
done
with
us,
but
I
think
there's
really
merit
in
in
the
request,
particularly
for
for
the
way
the
way
the
winds
are
kind
of
blowing
now
and
certificate
usage,
there
seems
to
be
a
real
impetus
towards
using
subject
alternative
names
rather
than
the
subject
the
in
itself.
So
I'd
like
to
see
the
the
use
of
this,
the
the
usefulness
of
this
expanded
and
and
try
to
accommodate
these
these
cases,
I
think.
G
D
Yeah
I
mean
I,
guess
so
so
I
mean
it
seems
to
me
like
maybe,
and
then
we
try
making
a
hopefully
uncontroversial
assertion,
which
is
that,
if
nothing
we're
deployed,
it
would
be
better
to
use
Sam,
and
if
people
disagree
with
that,
then
probably
should
fight
about
that
and
field.
If
you
agree
with
that,
then
we're
talking
about
what's
better
to
have
in
the
case
where
we
have
a
bunch
of
stuff
to
play
that
uses
that
uses
DM.
J
J
So
the
basic
protocol
works
independent
of
this
really
we're
talking
about
how
in
dynamic
client
registration
would
you
register
what
was
to
be
matched,
and
once
we
start
opening
it
up,
it
becomes
quite
large
and
I
guess
the
concern
is,
how
do
we
actually
get?
Interoperability
I
mean
immediately.
We
have
European
a
I'd
ask
certificates
that
have
unique
extension
points
so
in
some
cases
to
actually
be
useful
for
banks
in
Europe.
J
They
may
actually
have
to
look
at
a
specific,
a
I'd
ass
extension
to
determine
what
kind
of
financial
institution
they
are
it's
like
so
for
in
the
in
the
generic
case.
How
much
do
we
put
in
for
interoperability
versus
maybe
just
saying,
okay,
you're
gonna
have
to
sort
it
out
amongst
yourselves.
Whoever
is
registering
is
gonna
have
to
understand
and
whatever
the
AAS
is,
is
going
to
have
to
negotiate
what
the
fields
are.
That's
going
to
be
matched
I,
don't
know.
I
Just
another
statistic:
I
agree:
it's
more
about
the
client
model
and
the
way
the
identifiers
matched
journey,
often
occasion
process,
but
nevertheless,
I've
got
one
question:
John.
Are
it
suggesting
that
we
stick
with
TM
and
just
at
a
statement
if
you
want
to
use
other
attributes
of
the
certificate
to
match,
please
do
so
and
specify
somewhere.
J
J
So
if
we
add
one
subject,
alt
name
match
for
URI:
that's
going
to
satisfy
a
small
subset
of
people
who
are
then
going
to
be
angry
or
believe
that
their
use
case
can't
be
satisfied
because
they
have
no
way
of
getting
a
certificate
with
a
URI
subject
called
name
because
well
the
ID
ass
or
whoever
just
doesn't
produce
it.
Just.
F
I
F
F
F
I
am
personally
still
really
like
the
idea
of
just
a
field
that
carries
the
string
and
be
able
to
say:
oh
whatever,
just
match
them
all
I
realize
there's
a
potential
for
sort
of
name,
conflicts
across
types
and
and
maybe
some
crazy
sort
of
way
to
get
a
certificate
issued
where
you
could
impersonate
someone
else
based
on
that,
but
I
feels
awfully
unlikely.
I
know
I'm
in
the
manured
minority
on
that
statement,
but
anyway
I
don't.
I
Very
bad
to
just
skim
across
all
the
educators
and
try
to
match
the
name.
So
from
my
perspective,
either
we
go
and
define
a
registration
parameter
per
subject:
alternative
name
and
potentially
the
organizational
identifier
for
eaters
as
well,
or
we
just
specify
you
can
use
other
attributes
to
match.
But
do
it
in
a
reliable
way?
That's
very,
but
I
think
we
should.
We
should
try
to
to
really
support
the
use
case.
I
I,
don't
mind
about
subject
alternative
name,
but
the
use
cause
that
the
gentleman
brought
up
is
use
of
an
TLS
in
the
context
of
a
micro
service
architectures.
We
use
em
TLS
in
that
and
there's
a
kind
of
architecture
as
well
and
but
typically
happens,
MTA
or
TLS.
That
is
directly
used
to
authenticate
and
authorize
access
among
services
and
until
as
gives
the
ability
to
just
do
the
MTL
as
once
and
then
use
access
tokens
to
authorize
micro,
service
access
and
I.
Think.
That's
that's
really
important
that
we
have
support
for
that.
D
D
My
concern
is
like
that
managing
DNS
has
proved
to
be
extremely
difficult.
The
semantic
information
in
a
DN
is
like
largely
meaningless
for
most
for
most
environments,
and
so
like
that's
the
reason
why
we've
I
started
moving
towards
San,
you
know
took
towards
an
attending
structure,
something
that
and
ability
to
have
multiple
identities.
Obviously
so
I
mean
it
seems
to
me
that
it's
so.
D
Like
I,
don't
think
it's
like
define
every
single
possible
kind
of
say
on
I
think
you
could
pick
one
and
be
like
you
know
what
this
RFC
22
name
or
you
know,
or
whatever
I
mean
like
it's
just
like
I,
mean
I
guess.
My
point
is
like
that.
They'd,
like
historically
like
see
like
like,
like
Dan's,
been
very
hard
to
work
with,
and
so
unless
they're
gonna
be
like
you
know,
and
the
fact
that
you're,
like
oh
that's,
like
go
to
the
textual
track.
Textual
version
of
this
is
like
also
for
her
to
work
with.
F
I
think
that's
legitimate
I.
Don't
think
that
removing
the
support
first
must
find
the
subject.
The
end
is
really
on
the
table
right
now,
or
at
least
I-
don't
want
it
to
be
because
there
are,
there
are
large-scale
deployments
that
may
be
too
much.
There
are
definitely
real
production
deployments
that
are
relying
on
the
DN
functionality,
currently,
whether
that's
in
line
with
the
direction
of
things
or
not.
That's
that's
what's
happening
so
at
this
point
it's
about.
K
C
G
Mike
Jones
Microsoft
I'll
actually
ask
the
use
case.
Question
I,
understand
that
for
open
banking
and
perhaps
or
Lynn
group
implementations
what
you've
already
specified
is
used
in
practice.
So
we
should
obviously
keep
that
I
understand
ecers
another's
point
about
the
sands
being
at
least
you
know
the
the
current
future
in
the
past
x509
PKK's
world,
but
I'm
curious.
Whether
anybody
actually
has
a
use
case
where
they're
going
to
use
each
will
TLS
what
it
was.
The
use
case.
My.
G
G
F
F
Basically,
they
have
this
concept
of
a
spiffy
document
that
identifies
a
service
there's
a
there's
one
binding
for
that,
which
is
next
five,
a
nine
certificate
right
now
and
they
represent
their
identity
as
a
spiffy,
schemed
URL,
with
a
trust
domain,
basically
in
a
path
that
follows
it.
That
indicates
the
service.
C
C
F
F
Fix
it
adjust
the
draft
to
allow
for
some
kind
of
representation
of
San
for
a
client,
okay,
but
but
that
was
the
first
question
I
guess
was,
was
wanting
to
gauge
the
acceptance
of
that
within
the
working
group.
Again,
my
sense
is
it's
a
yes,
but
we
we
sort
of
jumped
past
that
to
trying
to
solution
it
so.
J
John
Bradley
yubico
again,
so
one
of
the
things
that
is
sort
of
inevitable
is
that
the
authorization
server
is
the
one
that's
going
to
decide
what
the
acceptable
matching
is.
So
maybe
one
way
around
this
is
to
have
the
authorization
server
say
what
subject
all
it
actually
intends
to
match
and
then
have
a
generic
field
for
the
client
to
say
this
is
what
I
want
you
to
match,
but
let
the
server
decide.
So
no
one.
C
F
What
can
I
do?
The
draft
currently
describes
how
you
can
do
certificate
about
access
tokens
with
public
clients.
There's
a
use
case
for
that
I
think
it's
really
valuable.
It's
been
suggested
by
some
that
it
also
be
useful.
Describe
how
to
do
certificate
binding
for
refresh
tokens
for
those
public
clients
is
the
first
time
has
come
up
with
the
question
earlier.
Should
we
do
this
and.
C
F
I,
don't
know
I
guess
it
is
a
question.
Well,
it's
a
question.
I
guess
and
then
somebody
else
got
all
fired
up
on
the
list
about
the
fact
that
client
certificates
are
something
that
clear
in
versions
prior
to
TLS,
1
3,
and
it's
suggested
that
some
privacy
or
security
considerations
be
added
to
the
drafter
on
that
I
honestly
questioned
whether
that's
really
useful.
F
In
this
context,
I
mean
we're
talking
about
certificates
that
represent
software
entities
and
oftentimes
software
entities
that
have
thousands
or
millions
of
users
and
and
don't
actually
have
the
certificates,
don't
have
any
user
identify
and
information
in
them
I
could
go.
Try
to
say
all
that,
but
I
feel
like
the
end
result
of
that
section
would
be
this
isn't
really
a
problem.
Maybe
that's
valuable
I,
don't
know,
but
the
question
is
really
do
we
need
this
or
not
I
feel
like
the
list
kind
of
got
ahead
of
itself
and.
G
D
I
kind
of
didn't
say
his
interview,
but
I
think
next
about
this
I'm
sorry
I'd
be
going
you
a
sentence
or
two
but
I
think
you
should
add
something:
ok,.
F
Good
enough
I'll
try
to
must
or
something
up
and
then
looking
ahead,
there's
going
to
need
to
be
a
new
draft
because
of
the
review,
there's
a
bunch
of
editorial
stuff
that
actors
asked
for
and
then
we
need
to
figure
out
what
to
do
with
some
of
these
open
issues.
I
guess
at
this
point
take
them
to
the
list
to
try
to
sort
out
if
and
what
to
do.
A
E
N
N
Hi
Mike
I,
don't
have
any
pretty
pictures
or
comics
I'm,
like
Brian
who's
used
up
a
bunch
of
my
time,
little
refresher
that
really
fast.
So
the
idea
of
distributed
OAuth
is,
as
things
scale
out.
We
end
up
with
all
much
larger
systems
where
there's
a
bunch
of
different
relationships,
so
no
off
to
it.
N
One
of
the
issues
in
that,
then,
is
that
it's
easier.
You
got
to
make
sure
that
the
access
token
doesn't
get
reused.
So
the
solution
is
to
audience
restrict
the
access.
Token
oops
is
that
forward
forward
step
forward.
Okay,
so
discovery
you
hit
the
resource,
it
says
your
unauthorized
returns
back.
So
currently,
we've
got
link
rel
information.
That
says,
essentially,
where
is
the
authorization
server
and
then
we
I
in
the
draft
I'm
calling
the
resource
URI,
but
that's
kind
of
weird,
because
universe
resource
indicator.
N
So
if
it's
a
JWT,
the
AUD
includes
a
resource
identifier,
since
the
last
draft
really
only
updated
made
was
to
reference
the
IETF
draft
resource
indicators
as
a
spec
for
how
to
represent
the
resource,
open
issues
kind
of
moving
quickly.
Since
then,
a
lot
of
time-
and
it's
been
some
discussion
about-
should
we
use
linked
headers
or
authenticate
header.
N
My
original
draft
had
dubbed
of
authenticate.
Nat
was
a
big
fan
of
linked
headers.
Some
people
pointed
out
that
a
number
of
existing
libraries
just
look
at
the
dub-dub-dub
authenticate
header
and
move
that
up
through
how
the
library
works
with
Brian
and
I
chatted
about
this
yesterday
and
sort
of
looked
at.
You
know
what
are
the
issues
in
that
and
6750.
The
specification
says
that
extra
attributes
are
allowed,
so
the
spec
has
said
you
could
have
other
things
in
there.
C
N
M
M
Either
way,
Dave
Robin
for
speaking
for
bacnet
I
would
also
approve
I
would
also
prefer
you
just
overload
lwith
enta
Kate.
If
you
need
to
add
an
extra
parameter
or
whatever,
but
don't
you
know,
don't
confuse
it
with
some
links
so
we're
just
now
getting
used
to
looking
at
that,
w
authenticate
don't
tell
us
to
look
somewhere
else.
N
O
C
I
N
You
it
is
discovery
currently
we're
providing
the
full
URL,
so
that
would
be
easier
for
the
client.
You
know
just
go
fetch
that
you
know
there's
some
security
challenge
in
there,
because,
of
course,
who
knows
whether
it's
really
the
right
URL
opposing
change
that
to
the
issuer
value
per
and
do
the
discovery?
/
84
14
since
84
14
says
how
to
take
an
issuer
value
and
get
the.
I
I
N
G
N
E
N
And
there
was
some
discussion
as
people
we're
somewhat
confused
between
sort
of
the
whole
URL
that
you're
fetching
you
know
making
a
call
versus
a
URI,
I
sort
of
changed
name
to
be
more
resource
identifier
and
that's.
What's
in
the
ITF
draft
resource
indicators
and
the
resource
URL
is
the
URL
the
clients
calling
so
I'll
add
more
descriptions
in
the
doc
to
clarify
between
the
two
of
those.
N
I
I
N
K
C
N
N
A
N
N
So
we'll
a
refresher
Roth
is
usually
said
that
one
party's,
a
client
and
the
other
party
is
a
resource.
We're
hitting
a
bunch
of
scenarios
where
both
parties
are
clients,
and
both
parties
are
resources.
We
need
to
get
tokens
back
and
forth.
The
user
experience
flow
is
horrendous.
When
you
try
to
do
that,
just
go
through
one
flow,
and
then
you
gotta
figure
out.
N
The
update
was
changing
where
you
could
include
reciprocal
scope.
We
don't
use
this
and
our
deployments
now,
because
it's
a
pre-configured
thing,
but
if
you
wanted
to
go
and
send
that
signal
previously,
it
had
been
in
overloading
are
in
a
flow
and
at
the
Montreal
meeting,
suggestion
of
putting
it
into
the
request
for
the
in
the
response
to
the
access
token
request.
G
G
C
N
P
They're
muddy
the
waters
and
about
back
in
AWS,
so
keep
in
mind.
This
is
the
access
token
response,
so
this
is
coming
back
from
the
token
endpoint
scope,
as
a
parameter
name
already
has
a
clear
definition
here
in
sixty
seven,
forty,
nine,
it's
the
Scopes
that
are
being
granted
in
the
access
token
being
returned,
so
we
need
a
way
to
represent
in
this
same
response
body.
What
is
the
scope
that
the
the
V
service
sending
this
response
back
to
us
would
like
in
return?
P
N
N
N
C
N
So
could.
G
C
The
document
and
you
would
be
Mike-
is
it
okay?
If
you,
you
are
one
of
the
reviewers
just
to
make
sure
that
before
we
start,
the
working
group
class
called
actually
sufficient
number
of
people
have
read
the
document
in
feel
comfortable
with
it
Mike
you
get
some
to
other
folks,
just
Dawson
Matt.
Thank
you.
Can
you
Mike?
Can
you
take
that
in
the
nuts
Matt
three?
A
C
C
K
K
So
I
good
morning
today,
I
want
to
talk
about
last
I
started
to
walk
on,
and
you
alternate
last
holiday
block
in
first
I'm
talking
about
the
dog
I
want
to
talk
about.
Why
do
we
need
a
new
dog?
Something
might
remember
that
identity
in
ITF
101
together
and
to
answer
some
questions
on
the
previous
one.
Hey.
Can
you
move
an.
K
K
And
so
yeah,
so
just
click
as
I'm
talking,
so
the
fan
generate
piloted
public
keys
and
the
public
into
the
server
and
then
the
clients
and
just
do
the
face,
so
it
will
go
a
and
then
the
client
can
answer
generate
two
numbers
I'm
calling
the
previous
and
next
and
they
both
will
be
kept
on
them
and
it
said
in
send
this
two
numbers
also
to
the
server
now
to
request
authentication.
The
client
can
sign
these
two
numbers
send
this
Seinfeld
over
to
the
server
and
the
server
can't
violate
it.
K
K
So
this
is
a
very
high-level
overview
of
the
protocol,
how
it
works
and
and
why
we
need
it.
I
discussed
more
in
depth
all
the
details,
why
we
needed
difference
from
existing
flow
in
the
docks
and
so
there's
already
actually,
two
versions
of
the
last
publish
and
now
I'm
looking
for
failures
and
comments.
This
is
why
I'm
also
presenting
him
today
and
so
I
think
it's
time
for
questions.
I
know
it
was
very
quick,
but
I
hope
it
still
was
a
understood
event.
K
K
Our
production
authentication
solution
itself,
a
millions
of
users,
is
based
on
this
protocol
and
exact
same
protocol
with
a
big
difference
in
the
namings
change
with
names
to
make
it
more
understood
of
elements.
It's
the
same
for
the
bottom
up
introductions
for
two
years
already,
and
we
are
very
highly
satisfied
with
its
service
and
a
problem
that
we
faced
and
now
we
have
stolen
a
different
solution
between
our
mobile
devices
to
our
back-end.
C
C
Unfortunately,
that's
so
far,
nobody
has
read
each
I
think
step
for
you
is
to
see
whether
you
can
get
some
reviewers
and,
of
course,
we
will
try
to
help
if
that
is
well,
but
I
encourage
people
to
sort
of
go
through
it
and
see
whether
they
have
the
same
or
they
have
the
same
problems
and
that
need
a
solution.
I
think
that
would
be
a
good
next
step.
K
C
You
should
being
a
few
people.
Typically
from
my
experience.
It's
always
so
thick
thick,
can't
we'll
do
a
review,
but
typically
hurts
in
my
experience
is:
if
you
review
other
papers
document
paper,
then
return
a
favor
and
preview
spend
a
time
and
preview
your
solution,
but
so
we
at
least
have
one
reviewer,
that's
good.
Okay
and
another
one
tells
you
to
us.
Mike.
Did
you
capture
that
so.
C
Well,
I
guess
we
will
have
to
just
look
at
the
document
that
he
posted.