►
From YouTube: IETF102-OAUTH-20180719-0930
Description
OAUTH meeting session at IETF102
2018/07/19 0930
https://datatracker.ietf.org/meeting/102/proceedings/
A
Dick
okay,
so
what
welcome
to
the
second
session
of
us
a
we
have
90
minutes,
so
we
we
don't
have
the
full
two
and
a
half
hour,
so
only
that
first
day
in
90
minutes,
and
so
this
is
not
well
a
fill
up
from
here.
With
this
make
sure
to
look
at
it.
Everything
you
say,
and
you
contribute
is
still
under
that
in
on
well
a
thanks
to
a
Dan
for
being
our
jabber
describe
and
for
Tony
for
a
voluntold
to
our
to
be
I
mean
it.
A
B
D
B
That's
not
you
guys,
remember,
okay,
but
I
will
very
briefly
go
through
this,
so
that
the
story
was,
and
you
see
that
sort
of
manifested
in
in
different
documents
is
that
and
particularly
also
in.
There
is
also
it's
a
little
bit
of
an
a
so
as
a
high-level
introduction.
If
you
will
see
it
that
way,
then
so
they
we
had
these
two
slightly
different
patterns
for
symmetric
versus
a
symmetric
keys
if
this
start
with
a
symmetric
key
version.
B
First,
when
the
client
talks
to
dollarization
server
to
get
the
access
and
the
Refresh
token
it
it
made
that
request
and
indicated
that
it
wants
over
here
he
wants
and
a
symmetric
key
version,
and
there
are
few
parameters
that
are
pass
along,
which
I
will
describe
in
in
subsequent
slides.
But
the
important
part
is
that
the
token
comes
back,
a
pop
token
comes
back
and
along
with
it,
keys
that
are
sent
from
the
authorization
server
to
the
client
for
use
by
the
client.
B
The
access
token
itself
also
has
keys
it's
a
pop-rock
natural,
but
those
us
are
in
sort
of
like
they
are
so
this
is
the
usual
pop
token.
So
it's
actually
consumed
only
by
the
resource
server,
but
in
the
symmetric
key
solution.
The
symmetric
key
has
to
be
sort
of
carried
encrypted
in
that
payload
and
we
have
that
data
structures
defined
for
doing
so
in
in
all
AHS.
We
had
all
the
work
with
the
JSON
web
token
and
then
the
corresponding
pop
token
extension
has
been
long
done
and
we
are
about
to
finish
so.
B
The
asymmetric
version
is
a
little
slightly
different
because
the
client
doesn't
need
to
have
the
authorization
server
generate
the
public/private
key
pair,
but
instead
it
just
the
client
shows,
tells
the
authorization
server.
What
public
key
to
include
in
the
in
the
bottle
and
that's
described
here,
and
we
use
the
same
mechanisms
for
doing
so
and
as
the
access
token
in
this
case
just
contains
the
the
public
key
or
fingerprint
of
it
and
there's
nothing
that
needs
to
be
sent
back
from
the
authorization
server
to
the
client,
because
the
client
already
has
that
public.
B
Key
okay
and
then,
of
course,
then
the
client,
when
he
talks
to
the
resource
server.
It
has
to
use
the
pop
token
in
to
demonstrate
possession
of
the
and
the
key,
and
it
does
this
in
a
variety
of
different
ways
and
specifically
in
in
work
done
in
AIDS.
There
are
different
ways
defined
to
tie
it
to
specific
security
protocol,
there's
a
DTLS
based
version
as
oscar
version
and
so
on,
and
so
on.
B
B
That
group
also
believed
that
they
have
come
up
with
a
solution
for
HTTP,
but
that's
a
separate
topic
that
I
don't
want
to
go
through
here
now.
So
what's
the
status
of
this
of
all
of
this,
so
in
in
the
ace
of
our
specification,
there's
a
there's,
a
framework
document
which
builds
on
on
OS
as
the
name
indicates
and
it
uses
it
uses
the
pop
token
functionality.
B
Only
it
doesn't
use
bearer
tokens,
and
it
also
has
this
points
to
the
CW
teen
instead
of
the
JWT
for
efficiency
reasons,
and
as
I
mentioned
earlier,
there
are
also
other
protocols
used
in
HTTP.
We
have
also
worked
on
other
protocols
in
OS
on
other
than
HTTP.
If
you
remember
that
the
sample
is
AP
gssapi
for
email,
that
was
a
little
longer
ago,
there
was
actually
I,
wasn't
wasn't
done
in
hours,
but
then
under
the
supervision
of.
B
In
any
case,
in
one
of
the
use,
so
the
different
use
case
isn't
there
so
long
a
use
case
document
available
in
is
that
tells
what
you
could
use
the
whole
framework
for,
but
one
of
the
use
cases
is
where
the
client,
for
example,
is
a
smartphone
or
tablet
that
talks
to
an
IOT
device
and
to
control
it
to
configure
it
and
do
something
and
their
client.
The
OERs
client
uses
HTTP
to
talk
to
the
authorization
server,
just
a
regular
OS
authorization.
Server
that
supports
opto.
B
Can
you
such
a
instead
of
since
the
authorization
server
can
issued
tokens
with
different
types.
It
can,
in
this
case,
for
performance
reasons,
can
issue
CWD
pop
tokens,
but
then,
as
the
client
gets
all
this
stuff,
it
passes
it
on
to
the
IOT
device,
for
example
using
coop
or
some
of
the
other
IOT
related
protocols
like
imputed
ease,
and
so
the
current
status
is
that
in
that
document,
which
is
going
to
end
the
working
group
last
call
fairly
soon
in
I,
think
Jim
said
in
September.
B
Additionally,
it
turns
out
that
the
web
RTC
guys
they
have
also
defined
and
dokin
format.
It
was
one
sent
for
review
to
the
list,
and
so
they
have
a
binary
encoding
that
is
not
C
bore
at
that
times.
I
think
CBO
didn't
wasn't
finalized
or
this
met
up,
so
they
have
a
separate
but
open
format.
Then,
of
course,
o
us
allows
different
formats.
So
that's
perfectly
fine
and
we
did
a
review
of
that
and
they
use
this
with
their
thumbs.
B
Turn
fireball
traversal
technology,
great,
so
more
usage
in
this
web
RTC,
real-time
communication
on
the
web
mechanism
and
I
provided
a
little
bit
more
details
of
that
work.
Also
in
pointers
in
the
link
you
can
see
on
the
screen.
In
any
case,
what
that
means
is
that
we
are
trying
to
at
least
in
two
different
groups
outside
of
us,
trying
to
finish
the
pop
token
work,
which
was
in
this
in
this
working
group
a
little
bit
underappreciated,
at
least
with
respect
to
that
document.
B
We
have
worked
on
other
pop
token
solutions,
so
there
it
does
that
I
tried
to
update
the
documents
with
the
help
of
my
co-authors
and
get
them
in
line
with
what
the
latest
statuses
and
it
turns
out
that
we
ran
into
three
issues
which
I
would
like
to
get
some
guidance
on
from
the
working
proof
to
actually
then
execute
those
changes.
I
didn't
want
to
surprise
you
all
with
suddenly
totally
different
documents
and
the
three
issues
I
believe
are.
Maybe
there
are
others.
B
The
HTTP
based
parameters
which
were
previously
in
in
in
the
document
and
now
in
the
ACE
document,
is
that
something
you
guys
are
comfortable
with
or
where
should
they
go?
Should
they
go
back
into
the
oils
group
form
and
I
will
talk
a
little
bit
more
about
this?
The
other
one
is
there's
this
there's
some
misalignment
between.
B
B
Finally,
do
because
the
read
the
authorization
server
needs
to
have
that
information
in
are
doing
crypt,
the
symmetric
key
that
goes
into
the
the
CWD
pop
token.
Otherwise,
it
doesn't
know
how
to
do
that
unless
it
uses
some
some
other
some
other
mechanisms.
So,
but
that's
where
we
use
that
parameter
now.
The
second
parameter
is
this
conformation
parameter,
which
is
used
to
carry
the
keys
from
the
authorization
server
to
the
to
the
client
and
also
to
provide
some
parm
I.
B
Think
parameters
to
the
public,
key
fingerprint
from
the
client
to
the
authorizations
onto
other
systems,
also
as
a
shoe
seller,
there's
also
one
other
R
parameter
that
you
may
not
have
seen
before.
This
is
called
RS
underscore
CNF.
This
parameter
gives
the
client
information
about
bra
public
key
to
be
used
with
the
by
the
resource
server.
B
E
B
So
there
are
other
protocols
used
in
the
ID
context
where
solutions
have
been
worked
out
on
how
this
request
signing
looks
like,
and
maybe
you
can
elaborate
on
that,
but
the
mechanism
that
was
defined
for
co-op
is
apparently
also
applicable
to
other
protocols
that
use
a
restful
paradigm,
including
HTTP.
That's
what
the
presentation
was
about
some
odd
years
ago,
when
this
topic
was
brought
up
on
the
mailing
list.
You
may
remember:
I
I
can
post
a
link
again
to
the
presentation,
ludwik.
F
Sites
but
there's
also
the
in
ACE
the
the
Els
profile,
which
defines
how
to
use
this
conformation
keys
in
the
detail.
S
handshake
in
order
to
prove
the
possession
of
these
keys
and
I
would
guess
that
this
is
applicable
for
TLS
as
well.
I
mean
there
was
a
draft
in
off
by
Samuel
and
me
recently
saying
how
how
we
did
that,
and
there
was
not
a
lot
of
interest
in
itself.
We
dropped
that,
but
basically
I
assume
that
the
stuff
we
do
with
DTLS
is
really
really
easy
to
transfer
to
TLS.
G
Couple
of
observations
from
the
token
binding
work,
making
changes
to
the
TLS
stack
and
exposing
the
ekm
and
all
of
the
other
things
that
might
be
easier
in
other
newer
environments
is
really
really
hard
to
impossible.
So
if
you
know
it
probably
reusing
token
binding,
which
is
already
going
through
all
the
pain
of
exposing
those
additional
parameters,
maybe
yeah
is
a
way
of
doing
it.
The
other
yeah
and
we
already
have
work
going
on
on
that.
The
other
thing
Brian
and
I,
put
out
a
draft
on
resource
which
replaced
audience.
G
We
discovered
that
in
practice,
audience
AUD
is
a
parameter
to
the
token
endpoint
is
really
really
problematic.
So,
yes,
we
need
the
parameter.
It's
just
don't
call
it
audience
that
it
causes
all
sorts
of
issues
once
you
start
sending
a
jot
to
authenticate
which
has
an
audience
which
is
it
the
audience
of
the
resource
server
in
the
jot
or
the
audience.
That's
supposed
to
be
the
the
the
token
endpoint
it
just.
G
B
I
B
I
B
G
G
Not
again,
it
probably
depends
on
whether
maybe
the
problem
with
having
it
in
co-op
is
that
other
things
make
people
may
not
find
it
etc
as
part
of
of
OAuth
I'm
not
violently
opposed
to
having
it
defined
there.
But
that
may
confuse
people
and
or
cause
it
to
be
attempted
to
be
reinvented
any
number
of
times.
G
G
G
G
B
B
That's
actually
the
downside,
because
we,
as
I
mentioned
earlier,
the
plan
is
to
go
to
working
group
last
call
in
September,
whereas
this
has
been
worked
on
in
ours,
for
whatever
reason,
because
of
different
objections
are
like
four
years,
and
it
would
be
unfortunate
if
then
there's
this
dependency
that
where
we
start
things
etc.
Well,
that's
also
have
something.
B
E
B
J
G
B
B
J
K
G
B
G
G
B
G
L
B
G
N
B
L
G
I'm
not
saying
use
it
as
a
different
name
in
the
access
token
I'm
saying
that
as
a
request
parameter
where
it
conflicts
with
the
audience.
So,
when
you're
talking,
when
you're,
making
a
request
to
the
token
endpoint,
adding
an
extra
parameter
that
says
audience
which
is
actually
the
identifier
for
the
resource,
server
that
audience
and
the
audience
of
your
request
conflict
once
you
put
them
in
a
jot
and
send
it
as
a.
I
That
is
one
of
the
can.
I
can
I
try
to
clarify
that,
because
John's
confused,
although
he's
sort
of
right
audience,
has
been
a
little
bit
confusing.
We've
used
a
Johnny,
we
we've
used
a
Edie
in
our
own
implementation
and
it's
caused
confusion
with
people,
but
the
actual
like
conflict
problem
that
John's
talking
about
is
related
to
the
authorization
request
where
we
have
drafts
that
define
a
JWT
encoded
set
of
the
parameters
passed,
the
authorization
request
and
thus-
and
it
also
allows
for
the
the
audience
then
is
a
parameter
value
in
the
JWT.
I
B
I
B
With
but
so
I
think
it's
perfectly
fine
that
there's
a
there's
a
claim
with
the
term
audience,
because
that
goes
from
the
authorization
server
all
the
way
to
the
resource
server
and
that's
exactly
what
we
want.
We
essentially
want
the
client
to
say:
I
want
to
talk
to
example.com
in
an
audience
when
it
parameter
when
it
goes
from
flying
to
authorization,
server.
The
authorization
server
supposed
to
then
take
that
information
actually
dump
it
into
the
token
and
to
pass
it
along.
This
is
a
this
is
exactly
what
we
want.
I
understand.
I
But
but
the
problem,
the
the
actual
technical
conflicting
problem,
is
around
the
authorization
server
when
it
when
it
says
audience
that
that
audience
has
multiple
meanings
in
some
contexts
and
with
that,
that's
sort
of
the
root
reason
that
you
can't
use
audience,
at
least
in
the
broader
ooofff
context,
as
a
request
parameter.
But.
B
I
Standard
the
audience
claim
is
defined
Indian
and
that's
the
one
we
want
to
reuse
well.
We
want
to
reuse
that
in
the
tokens
that
are
issued
yes,
but
there
is
a
standard
two
standards
actually
to
keep
it
interesting
about
how
to
use
a
jot
to
encode
the
request
to
the
authorization
endpoints
and
within
that
applauded.
Ians
is
part
of
the
John.
You
thought.
L
G
Jar
uses
it
as
defined
in
job.
The
problem
is
that
we're
inventing
new
parameters
which
are
not
those
parameters
in
it,
we'll
trying
to
call
them
the
same
name.
The
problem
is
in
these
new
specs
that
are
trying
to
overload
the
existing
semantics.
So
this
is
the
requested
audience,
not
the
audience
of
the
token,
so
you
just
have
to
call
it
something
else.
This
is
not
the
the
confirmation
method
of
this
token,
it
is
the
requested
confirmation
for
the
token
that
you're
going
to
issue
me,
we
just
have
to
have
different
names
for
them.
O
F
N
Dunk
overload
claim
name,
that's
the
problem,
because
some
of
the
requests
are
going
to
be
put
in
jobs
and
those
claim
names
are
already
used
in
those
jobs.
So
don't
call
it
CNF
in
your
request.
Don't
call
it
AUD
in
your
quest.
You
could
call
it
requested
confirmation,
you
could
call
it
requested
audience.
There
would
be
no
problem,
just
don't
use
exactly
the
same
string.
L
G
L
H
G
G
A
CWT
because
they'll
both
have
the
same
problem.
Yeah
things
are
both
defined.
If
you
try
and
say
put
some
parameter
of
I
want
you
to
issue
a
token
with
these
things
as
those
claims.
In
the
token
you
issue
me
if
you,
since
both
tokens,
can
have
both
the
confirmation
method
and
and
an
audience
and
a
issue
or
etc.
If
you
use
the
same
parameter
names,
you
only
have
one:
it's
going
to
be
a
problem.
The.
P
So
we
have
this
exact
same
problem
when
we're
using
J
to
be
keys
for
URI
signing
and
initially
in
the
early
drafts.
We
use
the
odd
for
something
very
similar
to
what
it
looks
like
here
and
it
confused
implementers
and
the
solution
was
really
simple.
We
moved
it
to
a
cDNA,
specific
claim,
name
that
was
specific
to
our
particular
purpose
and
we
could
define
it.
F
I
cut
the
line,
two
quick
things:
first
of
all,
I'm
not
opposed
to
rename
stuff
I
just
want
to
know
why?
Because
it's
for
me,
that
is
more
confusing
like
if
I
have
a
parameter
name
that
is
telling
the
auth
authorization
server
to
put
another
claim
claim
with
another
name
into
the
token
that
feels
confusing
to
me,
but
okay,
I'm
not
going
to
fight
this.
F
I
Brian
Campbell
again
a
few
few
things:
John
proxy
and
John
I'm.
Sorry,
it's
against
the
rules,
but
he
the
the
proof
of
possession
stuff
that
we've
done
to
date
in
OAuth.
The
drafts
that
are
proceeding,
mutual
TLS
and
token
binding,
haven't
run
into
this
problem
because
the
key
material
is
implied
by
whatever's,
going
on
relative
to
that
and
mutual
TLS
is
the
client
certificate
took
no
combining.
So
there's
none
of
these
parameter
conflicts.
It's
just
a
point
of
observation.
That's
how
the
the
current
sort
of
proof
of
possession
work
is
proceeding.
I
So
it
works.
Okay,
even
though
scope
is
used
in
both
places.
It's
alright
I
didn't
explain
that.
Well
at
all.
No,
it's
a
weird
subtle
sort
of
overlap
of
when
you
overlay
a
jot
onto
the
authorization
request,
claims
that
have
context
about
the
the
validity
of
that
JA
audience,
expiration
confirmation,
potentially
then
override
request
parameters
that
might
have
the
same
name.
So
those
are
the
ones
you
need
to
worry
about.
So.
B
B
I
My
last
day,
one
in
the
point
I
also
come
up.
Captain
like
that
I
did
have
the
resource
indicators
draft,
but
much
of
that
content,
or
at
least
the
concepts
have
been
rolled
into
the
distributed.
Ooofff
draft
that
dick
is
going
to
talk
about
here
shortly,
which
which
itself
also
tries
to
find
a
resource
parameter.
So
we'll.
A
Okay,
so
so
I
guess
I
get
the
feeling
that
most
people
kind
of
in
agreement
that
we
don't
want
to
use
that
audience
parameter,
and
we
want
to
call
it
some
some
something
else
and
do
I
think.
Maybe
we
need
a
home
of
that,
because
I've
seen
some
nods
not
clear
about
this,
maybe
maybe
there
is
still
a
people
I'm
not
clear
on
this
one,
so
I
would
ask
for
a
hum
for
this,
and
and
maybe
just
to
continue
with
this-
is
that
that
fair
enough
god.
N
A
Would
be
one
of
them?
It
probably
comes
after
that,
but
I
just
want
to
make
sure
that
people
understand
that
there
is
a
conflict
and
agree
that
is
on
conflict
first
right
and
that's
my
sense
of
that
of
the
meat
of
that
of
the
room
that
most
people
agree,
that
that
is
the
case,
but
I
want
to
just
make
sure
that
this
is
the
case
right.
B
So,
for
example,
I
listed
one
here,
which
is
the
DTLS.
A
co-op
underscored
idealist
profile
which,
as
the
name
sort
of
indicates,
it
refers
to
a
specific
specification
and
that
happens
to
use
coop
secured
by
DTLS,
and
it
is
finds
on
how
the
keys
that
come
out
of
the
US
I
associated
with
the
Bob
talk
now
used
in
that
to
secure
that
exchange.
That's
what
what
is
called
profile.
It
turns
out
in
the
key
distribution
document.
B
B
What
algorithm
it
supports
for
use
with
the
resource
server
back
then
he
was
motivated
by
the
work
that
Justin
did
on
the
HTTP
signing
and
it
supported
different
algorithms,
so
their
authorization
server
was
basically
in
charge
of
figuring
out
or
knowing
what
the
common
or
what
resource
of
algorithm
support
is,
and
then
it
would
tell
first
of
all
during
the
key
generation,
but
also
it
would
know
what
parameter
to
select.
So
it
would
basically
make
that
determination
and
it
would
send
the
corresponding
parameter
down
to
the
client.
L
Shot
I'm
not
sure
that
I
actually
see
a
conflict
here.
If,
for
example,
in
the
ACE
world,
you
were
using
a
profile
of
a
score
of
co-op,
our
score
is
your
profile.
You
may
still
want
to
be
able
to
specify
an
L
to
say
which
algorithm
in
aw
score.
You
want
to
use
so
I,
don't
know
that
there's
necessarily
a
conflict
in
terms
of
that.
Okay,
those
are
actually
be
different
parameters
right
now,
you
couldn't
specify
the
out
one,
but
that
would
make
sense.
Okay,.
B
So,
maybe
maybe
that's
maybe
the
solution
is
not
either-or,
but
both
okay-
maybe
that's
a
that's
a
solution.
Micros
are
objecting
at
least
to
the
idea
of
the
profile,
our
parameter,
so
I
try
to
elaborate
on
what
is
actually
needed
to
successfully
establish
the
communication
session
between
the
client
and
the
resource
server.
So,
first
of
all,
a
couple
of
different
profile
protocols
being
available
different
ones
used.
There's
the
tokens
come
in
different
flavors
as
well.
B
So
currently
we
have
three
standardized
token
format
defined
in
the
IDF,
most
prominently,
the
CWT
JWT
and
then
there's
also
for
the
web.
Rtc
guiity,
debased
encoding.
There
is
different
security
protocols
currently
from
the
ACE
working
group.
There's
a
DTLS
/
TLS,
there's
also
an
application
layer
oscar
solution.
B
There
are
different
trenches,
torrential
types
used
which
need
to
be
somehow
indicated
and
and
I
talked
about
the
problem.
The
algorithm
sent
the
parameters
already
so
there's
quite
a
bit
of
information,
and
that
needs
to
be
somehow
either
avoidable
out-of-band
or
needs
to
be
conveyed
in
the
in
the
protocol
exchange
to
make
it
make
all
of
this
work
depending
on
the
security
protocol.
You
use,
for
example,
on
DTLS
that
goes
in
here.
B
Details
can
do
a
lot
of
negotiation
on
TLS
negotiation
for
you,
so
you
don't
need
the
authorization
server
to
pass
this
information
along
for
the
profiles.
Some
of
that
information
is
fixed,
so
to
speak
at
the
specification
time
rather
than
literally
negotiated
during
runtime,
but
deployments
may
have
a
different
different
solution.
So
the
question
was:
what's
the
story
with
the
ID
in
their
profile?
So
is
the
profile
myq.
You
had
a
strong
view
on
this
and
and
I've
just
heard
chips.
Yeah.
N
Profile
is
in
the
earth
world,
typically
something
that
is
known
by
both
parties
via
an
out-of-band
mechanism.
I
know
of
no
deployed
instances
in
which
100
auth
client
uses
two
different
profiles,
which
are
selected
at
runtime,
and
the
only
purpose
of
sending
this
as
a
parameter
is
to
select
profiles
at
runtime.
So
I
think
that
this
is,
you
know
not
even
in
the
10%
case.
This
is
in
the
beyond
the
1%
case,
and
you
should
delete
the
parameter.
B
B
G
John
Bradley
yubico
I
largely
agree
with
Mike.
This
is
really
a
discovery
and
registration
problem
rather
than
a
runtime
decision
problem,
maybe
algorithm
at
runtime,
but
it's
that
also
seems
a
bit
unlikely
to
me
really.
We
have
to
we
have
this
general
problem
of
resource
discovery
and
allowing
the
client
to
magically
know
stuff
and
then
tell
it
to
the
server.
You
know
we're
just
you
know
it's
Turtles
all
the
way
down.
Unless
we
actually
deal
with.
B
F
N
Excuse
me
in
October
I
sent
a
review
of
the
a
south
spec
explaining
why
profile
was
an
encouragement
of
complexity
and
should
be
deleted
because
clients
do
not
dynamically
choose
profiles
at
runtime
and
the
review
comment
was
ignored
by
the
editors.
So
we
did
say
this
in
the
ACE
mailing
list.
Yeah,
you
didn't
do
it
yeah.
N
B
A
So
I
guess
maybe
I
will
take
a
hum
here.
First,
do
people
I
want
to
ask
first
if
people
understand
that
the
issue
in
if
they
have
enough
information
about
and
and
and
then
later
on,
one
or
the
other,
and
so
the
first,
the
first
one
is
just
to
ask
if,
if
you
have
enough
information
to
understand
the
issue
right,
so
if
you
have
enough
info,
oh
the
parameters,
those
parameters,
whether
okay
there's
a
removal
or.
N
A
B
It
is,
it
is
a
working
group
item
that
is
needed
by
two
other
groups
and
then
this
dependency.
We
can,
of
course,
shuffle
content
around.
That's
what
we
always
what
we
can
always
do,
but
it
is
I,
don't
think
we
are
now
getting
rid
of
a
concept
that
is,
coin
is
and
also
needed
with
web
RTC
or
I
use,
suggesting
that
Brian.
Just
because
you
you
don't
like
it.
Q
Just
in
richer
I'm,
not
gonna,
speak
for
Brian,
but
having
something
be.
A
working
group
item
that
is
needed
by
lots
of
people
all
over
the
world
has
not
been
sufficient
motivation
for
us
to
actually
get
anything
done
in
the
past
and
I
am
not
convinced
that
it
is
still
motivation.
So
I
feel
that
your
counter-argument
rings
hollow.
Q
Given
the
attitude
of
this
group
in
the
past
towards
similar,
and
in
fact
this
exact
set
of
problems
while
I
think
we
should
probably
you
know,
get
our
heads
out
from
under
the
rocks
and
do
this
I'm
still
not
convinced
that
we
are,
and
so
I
agree
with
Brian
statement
that
that
is
one
of
the
open
questions.
If
we
are
going
to
do
this
or
not
I,
don't
think
it's
settled
so.
B
Q
B
Q
A
I
B
B
A
B
That
was
exactly
my
worry
that
we've
essentially
bounced
back
and
forth
between
the
two
different
groups
are
the
area
directors,
unfortunately
not
here,
to
raise
their
head,
which
I
had
actually
asked
them
to
do
so
it's
ultimately
a
decision
about
the
area
directors
from
where
they
won't
want
to
do
the
work
right.
It's
like
50
and
and.
A
L
M
So
well
presented
early
draft
of
this
and
Singapore
anybody
got
Singapore
saw
this
yeah
because
I've
got
something
since
Singapore,
Brian
and
Knapp
joined
me
as
co-authors
incorporated.
You
know
what
we've
been
talking
about
here,
the
resource
indicator
context
into
here
and
that
had
some
stuff
around
metadata
that
we
incorporated
so
the
resources
a
URI
and
the
earlier
draft.
M
M
M
So,
for
example,
if
you
got
a
token
and
says
you
had
certain
scopes,
but
there's
no
enforcement
as
to
whether
it's
a
an
China
or
the
u.s.
right,
you
could
that
client
potentially
could
access
the
same
resource
with
the
same
scope
in
both
places
and
then
another
challenge,
of
course,
is
that
when
you
have
a
bunch
of
resources,
one
resource
could
be
malicious
and
just
reuse
that
access
token
access.
All
the
resources
that
that
same
client
is
accessing.
If
that
tokens
can
be
used
different
places.
M
So
there's
two
ways
of
solving
that
and
this
document
we
work
with
the
first
one,
which
is
audience
you're
sticking
the
access
token,
but
there's
other
models
where
you
want
to
constrain
the
sender
so
in
the
audience
restricted.
Essentially
you
get
a
token
for
each
resource
and
you
use
the
right.
The
client
needs
to
track
which
token
is
for
which
resource
and
then
the
other
examples
where
the
parties
are
both
a
client
and
a
resource
server.
So
in
this
one
you
want
a
sender
constrained
access
token,
where
there's
the
same
access
tokens
used.
M
M
Uas
is
unmanned
aircraft
system
so
essentially
for
a
traffic
management
system
for
drones,
to
talk
to
each
other
and
talk
back
to
their
base
about
where
they're
flying
to
and
in
in
this
example,
the
aviation
authorities
such
as
FAA,
would
be
the
authorization
server
that
says
who
are
all
the
people
that
can
be
operating.
They
want
to
minimize
what
infrastructure
they
Iran.
M
All
the
operators
talk
to
each
other
to
communicate
and
coordinate
flight
information,
so
each
party
can
call
any
other
party,
and
so
you
want
to
make
sure
that
that
you
know
the
FAA
is
issued
one
access
token
to
that
party
saying
that
they're
authorized
to
participate
and
then
they
each
on
each
call
each
party
you
once
approve
that
they're
authorized
by
presenting
that
access
token,
but
you
don't
want
one
party
to
use
somebody
else's
access
token
to
call
other
ones.
That's
a
similar
problem.
M
How
that
salt
isn't
covered
in
the
current
draft,
and
so
one
of
the
things
I'm
wondering
is
whether
other
people
have
similar
use
cases.
Whether
it
makes
sense
to
put
this
in
this,
because
it's
another
example
of
distributed
a
lot.
So
we
in
the
current
draft
in
the
you
call
the
resource,
is
how
the
whole
flow
kicks
off.
You
call
the
resource
and
in
the
4a
one
response
you
get
two
additional
things
that
are
in
a
link.
M
Header,
one
is
the
identify,
are
the
resource
and
the
other
one
is
where
to
go
to
get
information
about
the
authorization
server
to
go
and
call
the
authorization
server.
There
was
some
feedback
this
morning
on
the
list
about
these
pieces,
whether
it's
the
full
URI
in
awhile
server,
metadata
your
I.
Well,
there
was
a
better
name
for
that.
I
think
actually,
just
turning
it
down
to
the
issuer
makes
more
sense
on
that.
I
have
some
comments
on
that.
M
So
in
this,
the
key
thing,
of
course,
is
the
client
is
able
to
know
that
the
thing
that
it
just
called
that
the
it
matches
that
identifier
for
the
resource
that
the
resource
URI
is
part
of
the
path
that
it
called
and
the
identity
of
the
resource
is
partly
determined
then
by
the
TLS
certificate.
In
that
call,
then
the
clan
goes
in.
You
know
from
that.
M
If
we
were
take
that
out
and
have
that
be
a
separate
document.
I,
don't
think
we'd
have
an
issue
with
that,
but
it
seems
to
make
sense
if
it's
useful
other
places
and
so
then,
in
the
access
token,
it
includes
your
I.
If
that
access
token
happens
to
be
a
JWT,
then
it
would
be
the
audience
claim
and
then,
when
you
call
the
resource
server,
you
check
that
that
that
your
resource
URI
is,
in
your
token,
so
here's
third
of
the
discussion
points.
G
G
So
doing
there
isn't
a
single
URI
there
isn't
a
single
base,
URI
that
you
can
use
if
it's
a
multi-tenant
server,
so
we're
probably
best
off
just
specifying
the
whole
URI,
because
now
it's
hostname
dot
well
known
10/10
anti-d,
so
you'd
have
to
actually
have
two
different
parameters:
to
be
able
to
fully
specify
a
hoie
server
on
a
multi-tenant
host.
So
I
think
it's
just
more
straightforward
to
use
the
entire
URI
rather
than
trying
to
explain
that
to
people,
but.
G
B
M
G
Was
the
good
thing
about
the
Open
ID
Connect
format?
So
it's
it
hard
it's
hard
because
it
was
limited
to
the
one
path
hop
below
the
well-known
I
mean
we.
We
would
have
to
look
at
how
you
could
constrain
that
or
valid
with
the
the
OAuth
discovery
for
format
for
for
multi-tenant
and
notes.
It
would
be
it's
it's
a
real
problem
for
sure
in
some
of
the
other
other
multi
tenant
hosting
things,
so
something
that
we
would
have
to
address
how
that
would
actually
work.
B
On
a
UI
but
I
also
agree
with
Mike
that
defining
this
barometer
and
a
separate
document
would
make
much
more
sense
because
there's
a
lot
of
context
with
the
distributed
o
us.
That
I
think
is
not
relevant
or
not
applicable
in
other
in
other
environments,
and
then
there's
also
a
timing
issue,
because
this
work
has
just
started,
and
so
so
that's
why
I
would
prefer
to
have
it
ident
a
separate
door
to
just
keep
it
in
an
ace
or
sake.
H
J
J
B
If
you
think
this
is
a
different
resource
again
from
the
previous
discussion,
but
I'm
referring
to
what
Dick
said,
because
he
once
wanted
to
defer
the
call
for
that
reflect
was
supposed
to
make
on
the
audience
slash
resource
on
parameter
to
later,
because
dick
thought
that
this
would
be
exactly
the
same
and
equally
relevant.
Is
that
did
I
understood
you
correctly,
dick
that.
J
M
G
M
M
M
Another
comment
in
the
list
was
supporting
multiple
resources
in
the
access
token
request
for
students
or
talked
about
that
I,
don't
I,
don't
know
it's
unclear
to
me
a
use
case
where
that
could
happen.
You
describe
a
use
case,
but
but
that
doesn't
really
map
into
how
the
sort
of
distributed
off
kicks
off,
which
is
that
you
call
a
resource
and
you
get
12
where
to
go
so
you're
only
dealing
with
one
resource
I
just.
F
G
List
so
I
I'm
gonna,
stick
with
the
sort
of
previous
position
of
we
have
refresh
tokens.
If
you
need
you
know,
multiple
resources
for
a
single
access
token
adds
to
the
complexity.
Let's
just
if
you
need
multiple
yeah,
if
you
have
multiple
resources
get
multiple
access
tokens
there
may
be
different
keys
or
different
transports
or
other
things
that
you
will
eventually
have
for
those
resource
servers.
So
I
tried
trying
to
optimize.
It
is
probably
counterproductive.
So.
M
Q
Justin
Richard
one
repeating
what
John
said
from
the
floor
years:
that
developers
hate
security,
which
is
marginally
true,
but
what's
more
true,
is
that
most
developers
don't
care
about
security.
They
care
about
functionality,
and
so,
as
you
know,
complex
as
we
can
make
a
security
system,
if
it's
too
complex,
they'll
duct
tape,
it
open
in
ways
that
we
don't
anticipate
I'm,
not
saying
that's
what
this
is
destined
for
specifically,
but
but
it
is
definitely
something
we
need
to
keep
in
mind,
especially
because
this
is
I
think
relevant
to
the
larger
resource.
Uri
discussion.
Q
O
M
M
K
M
G
So
to
Lucy's
point
you
know
we
designed
refresh
tokens
so
that
we
could
have
short-lived
access
tokens
to
deal
with
some
of
these
issues.
You
know
allowing
you
know,
we
don't
want
to
encourage
people
to
have
long-lived
access
tokens
that
are
good
for
multiple
resources
and
start
getting
ourselves
into
these
these
issues.
So
it's
you
know
encouraging
people
to
properly
use
refresh
tokens,
keeping
that
keeping
that
and
adding
a
whole
bunch
of
dubbings
for
multiple
resources
just
adds
to
the
complexity.
G
M
M
M
It's
my
last
question
is
you
know
that
the
proof
of
possession
stuff
is
really
between
the
client
and
the
resource?
One
of
the
challenges
in
a
distributed
OAuth
is
the
authorization
server
reusing
the
client
credentials
at
a
different
authorization,
server
and
impersonating
the
client,
and
so
that
sort
of
drives
you
to
wanting
to
have
a.
F
G
G
Ideally,
you
know
you
shouldn't
be
using
symmetric
credentials
in
a
distributed
system
like
this.
That's
just
gonna
go
wrong.
So,
yes
propane,
you
know
that's
something
that
I've
been
fighting
the
GSMA
and
other
people
with
large
distributed
networks.
You
know
just
you
have
to
bite
the
bullet,
use
a
symmetric,
client
credentials
and
either
use
JWT
assertion
or
mutual
TLS
to
authenticate
the
client.
Everything
else
will
inevitably
go
wrong
in
some
horrible
way.
Yeah
actually.
B
M
There
is
another
point
which
is
sort
of
in
the
code
flow.
The
resource
you
are
I
could
be
a
useful
piece
that
seems
to
make
sense,
although
I'm
still
trying
I'm
Ser
of
any
clear
use
cases
on
the
code
flow,
whether
we
wanted
to
do
Senator
constrain
access
token,
and
then,
of
course,
this
is
still
a
ID
and
is
this
work,
that's
interesting
for
the
working
group
and
whether
we
should
adopt
this.
A
A
So
I
think
that
the
feeling
that
from
the
room
that
there
they
don't
want
it
to
overload
that
a
audience
so
I
wanna
ask
for
adoption
of
that
document
that
defines
the
resource
in
server
or
the
resource
as
a
separate
or
the
parameter
versus
a
overloading
that
M
that
the
audience.
So
if
you're,
right,
John
I.
G
Think
those
are
slightly
two
different
questions.
One
is
whether
or
not
we
should
be
using
audience
or
resources
of
parameter.
The
other
question
is:
should
we
adopt
the
other
spec
and
back
out
some
of
the
stuff
that
went
from
that's
back
into
this
fact,
so
that
this
spec
refers
to
the
the
resource,
but.
B
M
F
F
G
R
M
M
C
I
guess
I've
heard
a
few
different
use
cases
for
that
parameter
over
the
years
and
I'm
kind
of
wondering
if
all
these
people
consider
themselves
to
be
distributed
or
I
think
that's
actually
probably
highly
likely
so
kind
of
makes
sense
to
me
to
do
that.
Work
here.
That
I
know
like
tossed
in
the
nose
a
few
other
people
that
will
see
interested
in
the
resource.
C
G
G
B
S
B
B
B
G
Okay,
I'm
gonna
be
quiet,
yeah,
the
security
best
practices
document.
Okay,
this
is
gonna,
do
something?
Okay.
What
is
it?
You
should
already
have
been
paying
attention
to
this.
It's
an
overview
of
the
security
topics,
dealing
with
all
the
feedback
that
we've
gotten
from
the
security
researchers.
We've
divided
it
based
on
the
feedback.
We've
divided,
it
up,
reorganize
the
work,
so
we've
got
upfront
recommendations
and
then
the
detailed
threat,
analysis
and
proposed
countermeasures.
G
Our
recommendations
are
exact,
redirect
URI
matching,
avoiding
open,
redirect
errs
through
various
mechanisms,
one
time,
parameters,
tokens
or
values
in
the
state,
parameter
or
cross-site
request
forgery.
They
s
specific,
redirect
your
eyes
clients
using
pixie
to
prevent
the
reinjection
of
code
using
TLS
based
methods
for
constraining
the
resentment
of
access
tokens
and
end-to-end
TLS.
Wherever
possible,
our
current
status.
We
got
some
review
feedback
after
101.
We've
incorporated
that
into
the
latest
version
we
haven't
had
any.
G
Torques
company's
reasonable
feedback.
Perhaps
we
got
some
unreasonable
feedback,
we'll
have
to
ask
Torsten
what
he
meant
by
that.
We
have
two
proposals
which
we
have
to
decide:
what
we're
going
to
deal
with
one
about
audience
restriction
which
we
should
probably
add,
I,
think
that
makes
sense.
Crypto
agility
people
can
look
at
the
proposal
on
the
on
the
on
the
mail
archive
and
decide
whether
or
not
we
want
to
do
something
with
that.