►
From YouTube: IETF103-OAUTH-20181105-0900
Description
OAUTH meeting session at IETF103
2018/11/05 0900
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
D
The
first
is
JWT
BCP
I,
said
to
review
of
that
I
think
in
August,
so
I'm
stating
rate
waiting
for
a
revised
version
might
tells
me
he's
working
on
it.
So
I
assumed
that
I'll
be
impending
I've,
sent
a
review
of
em
TLS
this
morning,
so
I'm
expecting
a
revised
ID.
If
people
want
to
chat
about
the
review,
I'm
happy
to
do
that,
sorry
was
so
close
before
the
meeting.
Okay
in
any
way,
what
I
defer
to
the
chairs?
No,
they
want
to
manage
that.
D
Let
me
just
run
through
these,
and
then
we
can
talk
about
logistics.
The
token
is
change.
Document
is
on
the
member
21st
tell
a
chat,
so
everything
seems
fine
there.
It's
just
gotta,
be
you
know,
tell
chatted
the
the
device
flow
document
has
been
approved
by
the
iesg.
There
were
a
big
pile
of
comments,
so
I've
asked
the
chairs
to
go
through
the
comments
and
basically
tell
me
which
ones
they
think
they've
addressed
or
which
ones
they
have
not
addressed
in
a
way.
D
That
is,
but
there
I
you
know
typically
I
do
want
people
to
take
IHG
comments
seriously
and
on
then
last
one
is
jws
rec
which
for
no
obvious
reason
has
been
improved
announcement
to
be
send
for
200
days.
So
it's
an
maybe
it's
me,
but
we
can't
figure
out
why
it
would
be
so
I've
emailed
the
Secretariat
nasan
to
send
the
approved
announcement.
It's
approved
well
as
pin
points
out.
It's
like
it's
not
approved
all
the
messages
sent,
but
as
far
as
I'm
concerned
it's
approved.
D
A
I
think
it
would
make
sense
to
go
through
the
the
comments
in
a
in
a
small
group
and
then
see
whatever
you
have
some
questions
back
for
you
doing
this
week.
I
think
it's
definitely
something
we
want
to
submit
an
update
if
some
of
the
comments
that
are
sort
of
low-hanging
fruits
and
then
see
whether
there's
something
bigger
that
we
need
to
maybe
discuss
tomorrow,
so
maybe
having
a
short
conversation
today
would
be
useful.
A
Also,
as
like
I
said,
before
the
device
flow,
we
would
have
to
go
through
the
resource
comments
and
then
see
which
ones
got
resolved
by
which
text
proposals
in
there
in
the
document
to
get
this
finalized
and
get
this
out
of
the
door.
So
I
guess
after
this
meeting
we'll
sit
together
and
figure
out
what
use
so.
E
D
On
the
device
flow,
basically
Richard
now
I
did
ask
me
the
other
day
and
what
we
did
was
we
just
pasted
it,
the
Google
Doc,
and
then
we
just
went
through
them
one
at
a
time
and
like
Richards
able
is
dealt
with.
This
is
dealt
with
and
this
is
why
and
then
so,
if
you
want
to
write
me
an
email
or
gee
doc
or
whatever
that's
fine
but
I'm,
happy
to
sit
down
and
do
it
manually
you
take
about
20
30
minutes.
D
It
just
turns
out
to
be
like
really
really
hard
for
the
eighty,
this
all
sticker
through
and
track
all
the
mental
illness
traffic.
It's
the
people
who
did
the
resolution,
it's
easier
for
them
to
say
this
is
what
I
did
and
why
I
didn't
do
it
or
whatever
so
I'm
happy
made
time
for
that
if,
at
the
author's
on
her
sheriff's
decision
so.
A
A
I
got
some
emails
for
agenda
bashing
and
so
I
restructured
the
agenda,
slightly
Prime's
presentation
on
the
dough
combining
our
stock
combining
was
moved
to
the
first
presentation,
and
then
we
have
toast
and
talking
about
the
security
topics.
The
jwp
introspection
response
Torsen
had
submitted
a
proposal
for
discussing
a
financial
api,
and
then
I
have
at
the
end
the
presentation
about
the
updated
document
and
a
pop
key
distribution.
That's
a
gender
for
today
tomorrow,
we'll
continue.
We
have
the
resource
indicators
document
the
mpls
and
dick
is
going
to
speak
about
reciprocal
hours
and
distributed
hours.
A
F
A
A
good
point,
so
a
few
of
us
met
that
I,
aw
I
think
it
was
two
weeks
ago
and
Mountain
View
California,
and
we
talked
about
different
well
as
as
always
they
talk
about
different
OS
topics
and
one
of
the
sessions
that
Aaron.
Let
was
on
a
PCB
for
browser
based
apps,
similar
to
what
we
have
for
the
native
apps,
and
he
promised
at
that
workshop
to
put
a
draft
together,
which
he
did.
It's
just
I,
think
the
gates
are
now
open.
D
G
H
They
have
slides
so
I
was
just
trying
to
ingest
ecers
review
of
them
TLS
this
morning,
right
before
this
meeting
so
I'm
a
little
luck,
trying
to
switch
contacts
here
and
talk
about
MTL
or
talk
about
whatever
the
hell
I'm
talking
about
this
morning.
Talking
behind
me
good
morning,
a
little
jet
lag
in
there
do
we
have
slides.
I
C
H
H
H
So
what
token
binding
is,
basically,
it
enables
a
long
live
binding
of
cookies
or
other
security
tokens
specifically
OAuth
tokens
in
this
context
to
a
client
generated
public/private
key
pair
use
of
this
functionality
is
negotiated
in
the
TLS
handshake
via
a
TLS
extension,
and
then
what
happens
is
after
negotiation
on
every
HTTP
request.
Proof
of
a
key
or
keys
is
proven.
H
Possession
of
those
keys
is
proven
by
signing
the
TLS
exported
key
material
and
and
a
few
other
things
and
sending
that
signature
and
the
public
key
in
an
HTTP
header
on
every
single
HTTP
request,
cookies
and
other
tokens
again.
Oauth
tokens
can
be
bound
to
that
key
and
then
on
issuance
and
then
the
binding
can
be
checked
on
subsequent
use,
and
that
proves
that
the
presenter
of
the
token
holds
the
corresponding
key
that
it's
bound
to
these
keys
are
scoped
to
the
effective
top-level
domain
plus
1.
So
there's
particular
in
the
browser
use
case.
H
That's
used
with
a
different
site
with
a
different
HD
LD
you
+1
and
under
certain
conditions
you
can
have
that
revealed
to
us
to
another
site.
You
can
set
both
of
those
bindings
so
that
you
can
issue
a
token
which
is
bound
to
the
key
that
would
be
used
with
the
referred
site
and
basically
allow
them
to
combine
into
across
the
main
case,
bind
a
token
that's
issued
for
use
at
a
different
domain
and
the
ways,
though,
that
actually
works
right
now,
is
in
the
spec
there's.
H
There's
sort
of
some
weasel
language
around
here
that
says
token
binding
implementation
should
provide
API.
Is
that
generate
token
binding
messages
containing
token
binding
IDs
of
various
application,
specific
tow,
combining
types
to
be
conveyed
by
the
souks
ecto
combining
header?
Basically,
this
is
just
saying
for
general
purpose:
api's
that
do
token
binding.
H
So
there's
a
kind
of
the
two
two
ways
that
you
can
right
now
reveal
the
referred
token
binding
either
through
this
redirect
mechanism
or
through
some
client
provided
API
and
whatever
language
you're
using
to
develop
to
develop
the
function,
they
make
the
actual
HTTP
requests,
and
this
would
be
on
the
the
OAuth
client.
Basically,
it's
making
these
requests
next
slide.
Please.
H
Really
smooth,
thank
you
guys
so
then,
a
quick
overview
of
ofö
combining
building
on
that
functionality.
We
have
Olaf
token
binding,
and
this
provides
an
oauth2
proof
of
possession
mechanism
based
on
token
binding
that
basically
prevents
replay
or
cross-play
of
stolen
or
lost
tokens.
There's
a
couple
of
different
things.
It
does
one,
and
maybe
the
most
interesting
is
binding
access
tokens
using
that
referred
token
binding
ID,
and
this
is
there's
functionality
specified
or
described
in
the
draft
that
allows
for
binding
access
tokens
that
are
issued
from
the
token
endpoint
through
normal
grant
type.
H
Any
grant
type
you
send
of
the
token
point
you
can
bind
that
way
and
then
also
for
access
tokens
issue
from
the
authorization
endpoint
via
the
so-called
implicit
flow.
We
provide
a
mechanism
to
represent
this
binding
in
and
access
token,
if
it's
a
JWT
through
a
confirmation
claimed
that
with
tbh
member,
that's
just
shorthand
for
token
binding
hash
and
basically
it's
just
a
hash
of
the
token
binding
ID
and
that
took
a
binding
ID
is
an
effect.
H
H
So
some
things
that
have
happened
notable
happening
since
Montreal
I'm.
Sorry
I
can't
see
my
own
writing
very
well,
actually
just
prior
to
Montreal,
a
question
was
posed
to
lists
and
basically
the
the
thrust
of
it
was.
Is
it's
not
very
clear
how
an
access
token
and
issued
from
the
authorization
endpoint
the
implicit
flow
access
token
it's
actually
took
and
bound
had
a
little
conversation
about
that.
But
it's
a
it's
a
valid
question.
H
Unfortunately,
a
widely
used
web
browser
browser
decided
to
drop
its
support
for
token
binding,
which
unfortunately,
I
think
is
a
major
development
towards
the
the
long
term,
sort
of
viability
and
usability
of
this
stuff.
It's
not
the
end
for
sure,
but
it's
certainly
a
blow
to
it.
The
token
binding
protocol
negotiation
and
HTTP.
H
So
those
the
core
functionalities
described
in
three
different
drafts,
all
went
to
RFC
and
then
I
published
draft
eight
of
tutto
combining
and
basically
all
it
did,
was
update
references
to
the
RFC
versions
of
ASAS
metadata
and
the
the
three-quarter
combining
specs
and
then
not
long
after
that.
I
got
a
question
off
the
list,
but
it
was
more
or
less
the
same
question.
There
was
the
first
question
up
there,
which
is
don't
really
understand
how
the
token
binding
ID
of
the
RS
is
determined
using
these
implicit
laws.
H
So
a
bit
of
a
bit
of
a
thematic
issue
and
in
terms
of
the
questions
that
are
then
coming
up
around
how
that
works
next
slide.
How
so
how?
How
does
token
binding
of
an
access
token
in
the
implicit
flow
work
anyway?
And
the
truth
is
it
doesn't
work
very
well
and
it's
a
little
bit
awkward,
but
this
would
be
intended
for
an
OAuth
client
that
is
running
a
script
JavaScript
in
the
user
agent
and
the
AAS
is
going
to
bind
the
access
token
to
the
referred
token
binding.
H
That
is
sent
to
the
authorization
endpoint
in
the
authorization
request
and
that's
the
token
binding
between
the
user
agent,
where
the
client
is
residing
and
running
and
the
protected
resource
or
API
or
resource
server.
Whatever
you
want
to
call
it.
In
that
request,
the
include
referred
token
binding
ID
response
header
on
an
HTTP
300.
Redirect
is
the
only
way
currently
within
the
browser
landscape.
It's
assuming
the
browser
even
supports
it,
but
if
it
does
to
have
the
browser,
send
the
refer
to
combining
to
the
authorization
endpoint.
H
What
this
implies,
then,
is
in
order
for
this
flow
to
work
for
toe
about
access
tokens
through
the
authorization
endpoint.
There
has
to
be
some
HTTP
request
from
the
browser
in
a
full
page
context
to
some
endpoint
or
resource
at
the
protected
resource
resource
server,
which
in
turn
gets
full
page
redirected
to
the
authorization
endpoint
with
a
properly
formed
authentic
authorization
request
at
the
authorization
endpoint
there
at
the
at
the
AAS,
and
so
that
has
to
include
the
client
generated
State.
The
client
ID,
the
proper
response
type,
the
correct,
redirect
URI.
H
Another
awkward
bit
of
this
not
specifically
related
to
OAuth,
but
when
you
combine
it
with
open
ID
Connect,
which
has
the
concept
of
token
bound
ID
tokens
for
login
cross
domain,
login,
there's
some
oddities
that
come
up
as
well.
In
particular
the
token
and
ID
token
response
types,
don't
really
work
together,
because
you
get
tokens
issued
for
different
parties
that
are
bound
to
the
token
binding
ID
that
that
isn't
going
to
work
in
one
context,
the
other.
H
So
if
you
have
the
form
post
response
mode,
the
access
token
love
the
wrong
binding
it'll
be
bound
to
the
token
binding
ID
between
the
client,
the
the
user
agent
and
the
client.
But
it's
actually
being
delivered
to
the
client,
so
it
can't
be
used.
Basically,
if
you
have
the
fragments
response
mode,
the
token
binding
ID
doesn't
really
make
sense
for
the
ID
token,
since
there's
no
channel
that's
being
delivered
to
on
a
request,
it's
just
being
delivered
directly
back
in
the
response
to
the
to
the
client.
H
Unless
it's
somehow
passed
to
the
back,
the
clients,
back-end
and
also
then
the
bound
access
tokens
are
used
to
call
protected
resources.
That
happen
to
be
in
the
same
ETL
d,
effective
top-level
domain
+1
as
the
client
back-end.
So
it's
a
little
bit
awkward,
basically
token,
by
name
when
you're
doing
it
together.
Token
binding
ID
tokens
and
access
tokens
doesn't
really
work
in
this
particular
response
mode.
It's
just
one
sort
of
awkward
variant
of
a
use
case.
That's
not
particularly
well
understood.
H
The
the
off
list
asked
her.
The
question
happened
to
be
Torsten
and,
in
the
course
we'll
explain
in
the
discussing
it.
He
worked
up
this.
This
flow
diagram
to
help
understand
exactly
how
it
would
work
to
get
access
tokens
bound
when
issued
from
the
authorization
endpoint,
and
it
might
be
helpful
to
just
sort
of
walk
through
it
and
look
at
it
visually.
Basically,
you
have
the
user
agent.
The
client
they're
shown
as
different
lines
here,
but
they're
running
together.
So
the
client
is
executing
a
script
inside
of
the
user
agent.
Something
happens.
H
The
client
then
directs
the
browser
to
make
this
request
in
a
full
page
context,
to
some
endpoint
at
the
resource
server.
That
says,
hey,
please
direct
me
over
to
the
to
the
ass
and
it
includes
its
state
and
probably
also
its
client,
ID,
a
and
and
other
things
to
tell
it
how
to
form
that
authorization
request.
H
That
has
been
bound
to
the
refer
token
binding
ID
and
you
can
turn
around
and
the
client
can
use
that
then
to
access
resources
at
this
resource
server
or
really
any
resource
server
in
that
in
that
effective
top-level
domain
plus
one
and
it's,
the
onus,
then,
is
on
the
resource
server
to
check
the
tow
combining
at
that
point,
all
right,
I
think
it
helps
some
to
sort
of
visualize
it
this
way.
But
but
basically
it's
it's.
H
H
So
I
led
me
to
the
question
of
what
what,
if
anything,
we
should
be
doing
about
token
binding
and
the
implicit
flow
and
I
don't
really
know,
but
I
wanted
to
pose
a
few
questions
up
here.
The
first
thing
would
be
just
leave
it
as
it
is
now
and
let
people
figure
it
out
on
their
own
or
not,
as
seems
to
be
the
case
so
far
like
it
hasn't.
Really,
people
have
had
trouble
figuring
it
out.
H
Another
thing
would
would
be
to
attempt
to
add
some
sort
of
explanatory
or
cautionary
text
about
how
it
works
and
what
would
be
needed,
or
at
least
required
to
kick
off
the
flow
to
actually
get
it
to
happen,
basically
explaining
what
was
just
explained
in
the
previous
slides
and
the
emails
around
it
that
have
come
up
and
then,
from
there
at
least
give
people
the
tools
understand
what's
necessary
or
what's
what
is?
It
is
impossible
and
then
sort
of
leave
it
up
up
to
them
to
figure
it
out.
H
We
could
do
that.
It
seems
super
super
awkward
to
try
to
put
in
the
spec
language
there's
a
lot
of
discovery
problems.
Where
would
you
even
tell
the
client
about
this
special
resource
at
the
RS?
How
do
you
ensure
that
the
client
can
make
the
request
to
the
RS
that
appropriately
results
in
the
kind
of
authorization
request
that
it
wanted,
etc?
So
I'm
not
really
proposing
that
we
do
this,
but
it's
it's
out
there,
it's
something
we
could
try
to
do.
I'm,
not
sure
it's
wise.
A
Because
just
have
your
attention
option,
three
more
or
less
is
the
pattern
that
we
would
propose
for
native
apps
or
any
kind
of
OAuth
client.
That
first
discovers
the
issues,
a
pre-flight
request
to
the
resource
server
to
obtain
the
token
mining
ID,
which
is
then
used
in
the
request
to
the
authorization
server
to
make
that
mint
and
access
token,
which
is
bound
to
that
refer
to
a
combining
option.
H
Three
is:
it
is
sort
of
like
a
preflight
kind
of
requests,
sort
of
to
to
get
the
whole
flow
started
with
the
right
pieces
in
the
right
places,
but
I
think
it
would
only
be
applicable
to
browser-based
clients.
You
wouldn't
need
to
do
and
probably
couldn't
even
do
any
of
this
stuff
in
native
clients,
it's
strictly
for
implicit
type,
clients,
script
script
in
the
browser
spot
icons.
Okay,
then,.
A
A
H
J
H
H
Depending
on
what
it
is,
the
the
issue
still
exists
for
requests
to
the
authorization
endpoint,
but
if
there
was
a
proper
API
in
place
around
fetch
that
you
could
have
a
JavaScript
client
call
the
token
endpoint
directly
and
send
the
refer
to
combining
ID,
then
we
would
have
some
facility
to
make
this
work
in
in
spa
type
script,
clients
using
a
code
flow,
and
we
wouldn't
necessarily
need
any
of
the
front
channel
stuff.
But
I,
don't
know
that
a
fetch
API
would
even
accommodate
this
use
case.
H
K
K
A
So,
prime
so
1
&
2
is,
is
it
would
be
a
little
bit
unsatisfactory
for
a
document
so
like
we
couldn't
figure
it
out,
so
let
the
reader
figure
it
out.
Kind
of
story
in
I
was
following
whether
yours
played
with
the
idea
that
maybe
dough
combining
in
the
implicit
flow
is
maybe
not
a
good
thing
that
goes
to
get
out
too
well.
Is
that
is
that
so
that.
H
Removes
suborders
number
4,
so
we
did
for
4
different,
but
maybe
similar
reasons
in
in
the
Intel
M
TLS
draft
basically
came
out
and
said
this.
This
isn't
support,
it
doesn't
work.
You
shouldn't
try
to
do
it
binding
binding
access
tokens
to
the
client
certificate
when,
when
for
implicit
slows,
we
could
maybe
do
the
same
here,
which
is
just
take
that
out,
provide
some
explanatory
text
or
not
just
have
it
unsupported,
which
is
sort
of
where
I
was
going
with
this
when
I
started,
making
the
slides.
H
That
was
my
idea
that
I
thought
I
was
gonna
put
for
I'm,
not
so
sure
now,
because
of
the
note,
underneath
that
that,
basically
noting
that
JavaScript
clients
can't
really
send
the
refer
to
combining
ID
to
the
token
endpoint.
So
if
we
took
away
short
of
some
changes
in
the
API
that
may
or
may
not
happen
in
the
fetch
spec,
they
may
not
support
it.
If
we
took
away
given
everything
that
it
the
way
it
works
now,
the
api's
that
are
available
in
the
standards
that
exists.
H
A
A
H
H
Just
want
to
understand,
I'm,
not
sure
it's
that
black
and
white,
but
it's
it's
very
difficult.
He
and
right
now,
given
the
way
things
are
written.
If
your
browser
supports
it
and
you're
willing
to
go
through
the
awkwardness
of
that
we've
described
before
in
flow
three,
you
could
do
it
with
implicit.
B
H
Don't
know,
but
it's
not
not
a
promising
landscape
right
now
and
for
some
of
the
reasons
that
John
mentioned.
Even
if
there's
a
lot
of
support
from
the
browser,
vendors,
the
what
they
came
up
with,
might
not
facilitate
a
nice
cross
domain
type
of
use
case
because
of
all
the
issues
and
concerns
around
tracking
dick.
L
H
That
so,
it
would
be
I
think
they're
still,
potentially
a
lot
of
use
for
other
types
of
clients,
particularly
native
clients
or
even
web
server
type
clients.
I
am
making
a
bit
of
a
leap
that
may
or
may
not
be
proven
true,
which
is
without
strong
support
from
the
browser
vendors
for
the
functionality.
It's
unlikely
to
see
really
widespread
API
support
for
this
stuff
in
programming,
languages
and
platforms,
both
on
the
client
side
and
the
server
side.
H
Cuz
I,
don't
think
the
incentive
structure
to
build
that
stuff
is
really
there,
in
which
case,
even
though
it's
useful
for
those
types
of
clients,
I'm,
not
sure
it's
ever
going
to
be
practically
possible
to
do
that
development.
That
said,
that's
just
my
expectation
and
opinion.
The
the
question
at
hand
here
really
is
more
about
what,
if
anything,
to
do
about
JavaScript
clients
itself,
given
the
state
of
the
specs
and
what
what
you
can
do
and
can't
do
sure.
L
I
understand
the
limits
from
the
JavaScript
clients,
but
there's
lots
of
other
clients,
and
maybe
something
different
should
happen:
either
do
something
different
for
JavaScript,
but
maybe
all
the
other
clients,
but
you're
thinking.
You
don't
think,
there's
going
to
be
value
which
piece
do
you
think
won't
happen
if
there's
not
support
from
JavaScript
I,
don't
think
Java.
H
A
On
Brian,
with
would
also
be
an
issue
in
native
apps,
because
you
are
bouncing
back
and
forth
between
sort
of
the
browser
sort
of
thirty
into
the
operating
system
and
back
to
the
native
app.
Would
that
be
a
negative
I
sort
of
could
have
been
impact
as
well.
So
if
I
only
want
to
build
a
token
binding
based
OS
implementation
on
a
native
with
that
bead
and
impacted
by
some
of
the
developments
in
the
project.
Yes,
not.
H
L
H
L
You're
sort
of
saying
that
this
isn't
going
to
happen
unless
we
have
support
for
JavaScript
and
I
want
to
poke
at
the
value
we
get
in
a
number
of
other
environments.
You
know
like
a
native
app,
you
know
the
odds
of
native
apps
tons
of
you
know
just
devices.
You
know
where
we
are
able
to
do
a
proof
of
possession
like
flow
and
enhance
the
security
of
OAuth
I
without
having
to
go
and
do
proof
of
possession
right
into
the
OAuth.
L
I
You
see
Lucille
intercept
so
I
I
leaned
towards
the
remove
it
if
it
doesn't
work
for
the
JavaScript
piece
of
this
and
in
terms
of
your
incentives.
There's
a
market
forces
argument
here
that,
if
it's
important
for
it
to
work
in
JavaScript,
that
someone
else
will
push
the
browser
vendors
and
it
doesn't
this
draft,
that's
gonna.
Do
it
no.
K
John
Bradley
yubico,
so
I
believe
the
the
authors
believe
that
the
other
use
cases
are
actually
really
important
in
this
use
case
would
be
really
important.
The
question
I
think
Brian
and
some
of
us
have
is:
can
we
actually
achieve
critical
mass
with
without
broad
support
in
the
browsers?
So
are
people
actually
going
to
update
their
TLS
implementations
to
support
exported
key
material?
Why
happens
when
boring
SSL
removes
token
binding
support?
Is
microsoft
going
to
pick
that
up
in
their
branch
of
chromium
etc?
K
So
there
are
many
things
still
in
play,
but
you
know
people
tend
to
put
time
and
effort
into
things
that
they
think
are
going
to
succeed
and
right
now
there
are
questions
about.
You
know
how
broad
the
support
for
token
binding
is
actually
going
to
be.
If
it's
only
in
perceived
to
be
in
one
browser.
You
know
the
other
browsers.
You
know
that
you
know,
although
Google
may
be
removing
it
from
chrome
and
chromium.
There
are
people
of
different
minds
inside
of
Google
still
for
for
various
enterprise
use
cases.
K
K
So
it's
really
a
matter
of
perhaps
when
we
can
get
that
critical
mass.
It's
not
probably
not
going
to
happen
as
quickly
as
we
had
once
imagined.
That
doesn't
mean
it's
not
going
to
happen
but
to
to
Lucy's
point.
If
we
can't
reliably
tell
people
how
to
do
it
from
JavaScript
apps,
we
should
probably
not
hold
out
the
illusion
that
that's
a
practical
thing
in
the
short
term.
K
We
should
look,
remove
it
and
look
for
for
other
alternatives,
but
we
should
continue
on
with
the
other
types
of
clients
where
we
do
have
ways
of
doing
token
binding.
You
know
we
can
do
it.
Certainly
the
Windows
10
platform
supports
it
well,
and
20
points
out
does
have
visual
basic
support
the
so
you
know.
K
So
we
stand
a
better
chance
of
you
know,
and
it's
still
in
boring,
SSL
and
and
other
things
that
could
make
it
work
on
both
iOS
and
Android.
Assuming
those
those
libraries
continue
to
be
supported.
So
if
there
is
a
will
to
make
it
work
on
those
other
in
those
other
environments,
then
certainly
we
can
do
that.
There's
nothing!
That's
actually
standing
in
our
way.
A
Just
I'm
leaning
towards
roaming
support
for
JavaScript
lines
now
and
working
towards
alternative
mechanisms.
I
assume
we
need
prologue
browser
vendor
support
for
that
to
happen
either
in
the
fetch,
API
or
something
like
that.
But
we
should
definitely
some.
Let
me
do
that
because
there
is,
as
far
as
I,
understood
no
dependency
and
there
on
the
response
type.
It's
just
the
environment
that
the
client
runs
in
so
and
my
assumption
is
for
JavaScript
clients
or
any
kind
of
client
that
runs
directly
in
the
in
the
browser
sandbox.
We
need
browser
and
the
support.
A
Following
up
on
the
question
that
they
asked
for
the
other
clients,
we
can
pursue
this
draft
for
the
other
clients,
but
I
would
like
to
state
if
obvious
right,
we've
got
an
alternative
for
all
our
clients
right
for
native
apps
and
web
applications.
John
you
can.
You
can
even
flecked
on
my
comment
afterwards,
but
MPLS
solves
exactly
the
same
problems
that
gives
us
proof
of
possession
and
it
just
works.
It's
based
on
mature
technology.
N
Bachmann
AWS
I
wonder
how
much
the
focus
on
browsers
and
the
JavaScript
and
whatnot
is
a
little
bit
premature
and
that
it's
hard
to
imagine
people
clamoring
to
use
token
binding,
giving
how
much
of
the
rest
of
the
infrastructure
just
isn't
there
to
support
it.
We
here
we
don't
really
have
TLS
stacks
supporting
it.
We
don't
have
a
web
server
applications
supporting.
We
don't
have
infrastructure
supporting
it.
N
If
you're
getting
your
TLS
terminated
somewhere,
not
your
end
host,
so
it
it
seems
to
me
we
should
be
thinking
about
how
do
we
get
those
two
entities
of
the
system
up
to
where
people
can
start
playing
with
this
and
experimented
with
this
element?
Disks
I
think
that's
the
big
blocker
here
right
now,
it's
incredibly
hard
for
somebody.
Did
you
start
playing
with
this
and
discover
hey?
This
is
really
cool.
Why
isn't
chrome
supporting
this
I'm
gonna
go
yell
at
them.
H
That's
certainly
the
different
way
to
look
at
it.
Having
spent
a
lot
of
time
on
it
myself
at
having
having
it
readily
available
in
a
in
a
client,
that's
widely
deployed,
I
think
makes
it
possible
to
play
with
in
some
environments
and
I
always
felt
like
that
would
be
sort
of
the
the
leading
edge
to
drag
other
pieces
of
structure
and
functionality
along
it.
You
know
it's
really
really
hard
to
find
the
incentive
to
build
in
the
support
in
a
TLS
Terminator
and
when
nothing
else
does
it
may
be,
because
that
alone
won't
do
anything.
H
The
same
is
kind
of
truth
for
a
web
server,
so
well.
Well,
if
those
things
were
in
place,
maybe
that
would
help
incentivize
but
but
I
always
sort
of
viewed.
The
browser
support
is
sort
of
leading
leading
the
push
and
without
it
it's
hard
for
me
to
imagine
those
other
pieces
falling
in
place.
I
don't
know,
I've
invested
a
lot
of
time
and
I
hope
I'm
wrong,
but
I
I'm
struggling
with.
N
Seen
how
that
would
play
out
I
think
the
emphasis
is
a
little
bit
unbalanced
in
that
like
in
order
to
make
any
of
this
work.
You
have
to
have
kind
of
the
full
end-to-end
story
and
right
now
we
really
have
only
talked
about
one
relatively
small
piece
of
it
and,
if
you're
a
service
provider
on
the
web.
Thinking
about
hey,
how
would
I
implement
this?
N
You
look
around
and
you
realize
there
is
nothing
in
place
for
you
to
start
playing
with
it
like
you
could
spin
up,
maybe
a
toy
application
that
you
know
plays
with
it
in
the
browser
and
talks
to
one
web
server
and
you
custom
build
a
whole
bunch
of
crap
to
try
and
glue
it
together.
But
that's
not
going
to
get
you
very
far,
so
I
really
couldn't
convince
you
that
it's
viable
to
the
point
where
you're
going
to
pursue
talk
to
your
vendors
and
say
hey.
N
N
A
So
maybe
so
after
this
longer
discussion,
maybe
it's
time
to
ask
the
room
for
feedback
on
whether
we
should
remove
that
implicit.
What
Oh
companion
for
implicit
flow
for
a
moment
and
provide
a
justification
or
why
why
it's
not
there
I
think
that's
what
I
see
where
the
discussions
are
currently
meaning
it
doesn't.
A
H
H
One
of
the
questions
here
was
take
some
action
on
the
aforementioned
issue
or
not
it's
sort
of
an
open
issue
right
now.
Maybe
we
just
want
to
think
about
it
for
a
little
while
at
least
raise
the
issue
and
have
it
on
people's
mind
because
I'm
not
sure
it
wasn't
necessarily
a
parent
without
spending
some
time
looking
at
it.
So
hopefully
it's
a
little
more
obvious
now
I
just
wanted
to
mention
I'm,
not
gonna,
make
it
to
Prague.
H
So
you
won't
have
to
hear
me
do
this
again,
at
least
at
least
that
I've
got
vacation
which,
according
to
my
wife
of
my
family,
takes
precedence
over
hanging
out
with
all
you,
lovely
people.
I
know,
I
know.
Last
time
I
chose
you
all
I
got
a
lot
of
troubles,
oh
and
then
I
guess
I
believe
this
with
what
we
really
need
here
is
implementation,
experience
and
feedback,
and
that's
the
area
where
I'm
really
struggling
without
the
support
from
platforms
from
from
TLS
terminators
from
TLS
stacks
from
client-side
libraries
from
web
servers.
L
Where
we
are
yeah
on
that
I
think
it'd
be
useful
and
maybe
building
on
what
Torsen
is
going
to
talk
about
for
us
to
go
out
and
talk
about
what
implementations
need
to
be
done
to
make
a
number
of
the
proposals
we
have.
So
we
can
get
an
idea
around
not
just
from
a
protocol
point
of
view.
But
what
are
the
blockers
of
like
who.
A
L
Where'd
we
need
changes
made
in
certain
kinds
of
code.
That's
out
there
in
order
for
stuff
to
happen,
I
think
that
could
help
us
in
evaluating
what
might
be
the
most
pragmatic
path
forward
on
solving
some
of
these
problems.
Well,
architectural
II.
There
may
be
a
preferred
solution.
You
know
we
put
our
pragmatic
hat
on
around
what
has
to
happen
to
enable
it
that
probably
pride
us
a
bunch
of
guidance.
So
I
would
just
take
that
as
work
item
for
the
list.
H
J
A
A
A
Just
reflecting
on
what
dick
proposed
I
mean
we
could
set
together
and
here
in
a
side
meeting
and
talk
about
what
or
joint
picture
is
on
how
totem
bound
stuff
could
work
that
would
be
I
would
I
would
strongly
prefer
that
all
right
security,
BCP
I,
would
like
to
present
you
the
current
status
and
the
development
that
has
taken
place
since
Montreal.
A
The
security
BCP
enhances
the
oauth2
data
security
threat
model
and
security
considerations
and
discusses
threats
that
had
been
seen
in
the
wild
since
Oh.
After
that,
Oh
was
published
in
2012
and,
along
with
the
discussion
of
the
different
threads
and
and
potential
countermeasures,
we
also
distilled
a
set
of
recommendations
that
complement
the
security
considerations
in
RC
sixty
seven,
forty,
nine.
A
They
mainly
concern
the
the
way
the
redirect
flow
is
being
used
and
OAuth
and,
as
we
all
have
learned
in
the
course
of
the
last
year's,
the
redirect
flow
is,
is
the
source
of
most
of
the
issues.
We
have
seen
so
token
leakage.
Why
I
refer
ahead?
Our
open
redirect
us
mix-up
access,
RF
and
so
on,
and
so
on.
So
that's
that's
a
point.
We
focused
on
I
won't
go
through
all
the
details.
A
So
if
you
want
to
get
all
the
details,
please
read
the
draft
I
would
like
to
focus
on
the
new
staff
that
we
have
added
in
the
last
couple
of
months.
So,
besides
all
the
the
redirect
based
off,
we
clearly
state
that
we
recommend
any
implement
of
off
and
that's
something
we
have
heard
in
this
in
the
previous
session
to
use
TLS
based
math.
That's
for
a
binding,
any
access,
token
to
a
sender,
we're
not
saying
token
binding,
because
we,
you
could
use
token
binding.
You
could
use
mutual
TLS
for
all
for
that
purpose.
A
What
we
strongly
recommend
to
use
this
kind
of
proof
of
possession
in
order
to
detect
if
someone
wants
to
replay
a
leaked
access
token-
and
we
also
added
to
the
draft
some
text
and
access
token
privilege
restriction.
This
is
more
or
less
giving
the
recommendation
to
use
audience
restriction
for
any
kind
of
access
tokens
plus
to
restrict
the
action
that
a
client
is
allowed
to
conduct
with
this
particular
access
token,
which
will
prevent
any
kind
of
privilege
escalation
I
mean
in
the
end,
it's
good
good
security
practice
for
ID
law.
A
A
A
Just
due
to
the
fact
that
the
access
token
is
directly
issued
in
the
front
channel
from
the
authorization
endpoint,
there
is
no
way
to
use
one
of
those
established
mechanisms,
because
there
is
no
exchange
of
a
temporary
credential
to
something
the
access
token
is
directly
being
issued.
So
the
only
option
we
have
today
to
really
secure
that
flow
is
Towe
combining
and
that's
why
I
asked
Brian
to
give
his
presentation
first,
because
he
clearly
Illustrated
that
so
combining
right
now
is
more
or
less
an
academic
option.
A
It's
not
really
a
practical
option
that
can
really
be
used
in
a
deployment
today
as
we
speak
and
there
are
potentially
other
options,
but
they
are
all
in
in
a
really
really
early
stage
of
adoption.
So
drama
is
one
that
I'm
going
to
present
afterwards
and
that's
why
we
came
up
with
the
recommendation
and
that's
something
I
would
like
to
discuss
with
you
guys.
A
That's
the
recommended
recommendation
from
our
perspective
from
security
BCP
perspective
is
to
not
further
use
the
implicit
brand,
but
to
use
the
authorization
code
instead
on
all
kinds
of
front-end
browser-based
redirect
flow,
because
the
authorization
code
flow
can
be
protected
for
against
replay
open
connect
of
MIDI
connect
lines
can
use
other
mechanisms
such
as
hybrid
response
types,
but
for
plain
vanilla,
or
we
would
like
to
publish
the
recommendation
to
the
brawler
audience.
The
authorization
code
flow
is
the
way
to
go,
and,
yes,
we
have
to
answer
the
question
how
single-page
applications
could
be
implemented.
A
We
had
this
session
about
that
at
ILWU
as
well,
and
our
perspective
is
that
SPS
can
be
implemented
using
authorization
code
because
in
the
beginning
and
that's
what
people
need
to
understand
and
remember,
the
implicit
grant
had
been
employed
been
invented
in
a
time
before
course
cross
resource
origin
sharing.
Thank
you.
So
in
the
beginning,
JavaScript
clients
were
not
allowed
to
perform
or
sent
requests
to
any
host
outside
of
their
our
region.
Thanks
to
course,
that's
now
possible,
which
means
that
a
JavaScript
application
can
send
a
request
to
the
top
main
point.
A
So
we
can
use
the
authorization
code
flow
for
that
there
are
some
needy
greedy
details
that
we
need
to
answer.
So
John
came
up
yesterday
with
with
the
cage
with
the
our
browser,
cache
management
and
so
on,
but
we
think
we
are
growing
confident,
that's
the
better
way
to
go
forward,
because
that's
the
root
of
the
most
robust
way
and
I
would
like
to
get
your
feedback
on
that.
C
N
And
about
background
AWS:
yes,
we
actually
that
there
was
a
panel
at
iaw
a
couple
weeks
back
that
were
we
talked
about
JavaScript
applications
and
auth,
and
so
and
and
and
best
practices
around
that
and
one
of
the
things
that
came
out
there
was,
if
you
don't
have
to
use
implicit
grant,
then
don't
on.
We
talked
a
lot
about
ways
that
you
can
use
an
authorization
code
approach
or
other
other
ways.
You
can
design
around
that
problem.
The
general
consensus
was
no
one
likes
it.
No
one
thinks
it's
a
good
idea.
N
F
K
John
bradley
yubico,
so
the
the
conversation
that
Torsten
and
I
have
had
really
to
be
precise.
What
we're
talking
about
is
killing
the
token
response
type.
So
they,
the
language
in
the
spec
around
implicit,
is
implicit
and
not
really
explicit.
So
almost
everybody
has
a
different
notion
of
what
the
implicit
flow
is
means,
whether
you
know
people
make
do
native
apps
and
try
to
do
the
implicit
flow
because
they
think
the
spec
talk
implies
that
if
it's
not
a
confidential
client,
you
must
use
implicit
so
eliminating
the
code
response,
type
I'm,.
B
A
Don't
know
I,
don't
know
how
to
proceed
with
this
kind
of
stuff.
I
mean
we
are
basically
saying
that
RFC
6067
for
them
not
for
the
nine
is
or
we've
removed,
something
from
the
core
specification.
I,
don't
know
how
to
proceed
with
that
I
mean
we
can
say
that
in
the
Security
BCP.
A
J
A
But
let
me
ask
into
the
room
the
question
to
confirm,
at
least
at
the
meeting
on
whether
whether
their
proposed
by
Austin
is
actually
the
way
forward.
So
please
tell
me
if
you
agree
with
those
from
Austin's
recommendations
to
recommend
the
use
of
the
authorization
code
instead
of
the
implicit
flow
hum
now
in
hum
a
few
dis
and
hum.
If
you
disagree
with
that
recognition,
I
don't
hear
anyone
so
I
I
would
say
it
was
a
very
strong
preference
to
follow
what
you
recommend
it
to
us.
A
A
A
A
If
the
RS
also
wants
encrypted
response
or
certain
algorithms,
then
it
is
supposed
to
set
up
a
relationship,
a
policy
with
the
RS,
so
the
RS
das
knows
what
how
to
process
the
the
introspection
response.
The
specification
uses
the
same
pattern
for
setting
up
this
metadata,
as
it
has
been
established
by
the
omadi
connect
dynamic,
client
registration.
A
A
What
has
been
changed
since
Montreal?
First
of
all,
in
Montreal,
the
working
group
were
on
shortly
after
Montreal.
The
working
group
decided
to
adopt
this
work
as
a
working
group
document,
so
we
published
the
first
version
as
a
working
group
document,
and
then
we
mainly
changed
or
an
enhanced
the
text
around
the
management
of
in
CRO,
because
it's
been
raised
on
the
list.
A
A
So
you
are
sure
that,
on
the
other
side
of
the
TLS
connection
is
a
legend,
a
legitimate
party
that
is
allowed
to
receive
the
document
or
you
just
set
up
encryption,
and
we
have
added
some
text
that
will
prevent
all
kinds
of
downgrading
attacks
so
that
a
client
or
an
attacker
could
not
try
to
obtain
introspection
responses
that
are
not
encrypted.
If
the
client
had
been
set
up
to
just
receive
encrypted
responses,
yeah,
we
changed
the
default.
A
G
Jim
Shaw
darkest
cellars,
okay,
you
partially
answered
my
question,
but
I
don't
think
it's
a
complete
answer
to
what
I
want
I'm
kind
of
curious
to
know
why
we're
not
going
ahead
and
allowing
a
JWT
request
using
JW's
on
the
request
side,
as
well
as
the
response
side,
so
that
we
can
basically
hide
some
additional
information
there.
In
the
case
of
things
like
referrals
and
whatnot.
A
The
introspection
request,
so
it's
a
direct
server
to
server
requests,
typically
or
at
least
it's
it's
a
request
by
a
TLS
connection.
So
it's
it's
protected.
Basically,
as
I
said,
a
signature
is
mainly
meant
to
to
add
a
non-repudiation
to
them
to
the
construct.
The
request
itself
only
contains
the
token,
so
we
could
make
a
chart
that
contains
the
token
I.
Don't
see
a
real
benefit
for
that.
Well,.
G
A
A
G
G
A
A
You
need
to
somehow
determine
based
on
the
access
token
which
a
s
to
talk
to,
and
there
is
no
no
draft
in
the
working
group
right
now.
That
would
support
this
kind
of
use
case.
Well,
we
can
talk
about
that
later
on
everyone.
We
had
a
discussion
about
that,
but
this
is
a
really
simple
use
case.
The
RS
knows
which
a
s
is
talking
to.
It
knows
the
end
point
until,
as
is
used
to
protect
the
communication.
So
that's
that's
the
use.
F
N
F
J
Mike
Jones
Microsoft
I'll
point
out
as
background
something
you
know,
but
a
lot
of
the
room
may
not,
which
is
you
already
have
an
open,
ID
financial
grade.
Api
draft
for
signed
Roth
responses.
That's
an
implementers
draft,
meaning
it's
in
reasonably
mature
shape,
given
you've
already
done
that
for
general
auth
responses.
J
It's
not
clear
to
me
that
also
doing
so
in
this
draft
makes
any
sense
and,
as
Annabelle
points
out,
there's
some
nuances
about
the
different
end
points
that,
among
other
things,
may
require
different
key
declarations
and
different
kinds
of
specifications
about
what
the
two
parties
are
willing
to
do.
That
I,
don't
think
we
should
try
to
gloss
over
in
a
general
way.
Yeah.
A
A
H
Well,
he's
doing
that
this
is
Brian
Campbell
from
pain.
I
just
want
to
throw
my
two
cents
into
that
I
think
trying
to
generalize
it
in
one
draft
across
all
types
of
responses
would
be
to
use
your
wording.
Maybe
more
academic
than
valuable
in
nature
and
I
would
I
would
urge
caution
before
we
try
to
do
that.
I.
Don't
think,
there's
really
a
good
use
case
for
thin,
like
revocation
responses.
H
The
token
in
point,
I,
think,
is
kind
of
suspect
and
having
something
that
that's
very
different
for
an
authorization
response.
I
think
it
makes
sense
to
have
that
completely
separate
and
not
try
to
use
a
completely
sort
of
generic
framework
for
the
two
so
I
would
I
would
be
against
trying
to
generalize
it
in
that
fashion.
A
So
am
I
for
presentation
today,
I'm
going
to
present
a
work,
that's
being
done
in
the
Febby
working
group
at
the
open,
ID
foundation,
because
I
think
that
could
be
of
general
interest
for
the
hoff
community
I've
written
the
draft
together
with
Brian
as
kind
of
a
bit
of
introduction.
There
are
some
use
cases
where
we
would
like
to
have
a
signature
over
the
authorization
request
and
potentially
response,
depending
on
the
threat
model
and
the
API
we
are
gonna
serve
and
we
already
have
a
solution
for
authentic
authorization
request,
which
is
the
chart.
A
A
Without
this
coupling
with
an
open
ante
connect-
and
we
called
it,
Judge
security
authorization
response
mode.
Why
it's
called
mode
I
will
explain
in
a
second.
But
let
me
first
start
with
the
basics.
The
idea
is
in
the
same
way
as
for
the
judge,
secured
authorization
request
to
carry
all
the
response
parameters
in
a
jot.
A
In
the
first
version
of
the
draft
I
made
it
a
new
response,
type
I
think
it
called
it
signed
underscore
code
or
something
like
that,
and
then
Brian
came
up
with
the
proposal.
Just
let's
make
it
a
response
mode,
and
the
difference
is
the
response
mode.
Is
a
spec
I
think
it's
also
in
the
open
ad
space
so
far,
which
allows
to
have
different
representation
for
the
same
response
type
it's
being
used,
for
example,
to
introduce
a
post
method
forum
post
method.
A
Thank
you,
Mike
and
we've
built
up
in
this
functionality
and
introduced
a
set
of
new
response
mode
values
which
allow
to
query
response
parameters
for
the
different
response
types.
So
it
could
use
charm
in
combination
with
code
implicit
or
we
no
longer
need
that
hybrids,
response
types
and
so
on
Annabelle,
Annabelle.
N
Backman
AWS
I'm
gonna
be
a
pedantic
jerk
here
and
say
that
you
miss
characterized
response
mode.
It
does
not
define
different
representations.
It
defines
different
transport
mechanisms.
The
three
response
modes
that
I'm
aware
of
having
been
standardized,
our
query,
fragment
and
forum
post,
the
the
representation
of
the
response
and
all
of
those
is
as
a
URL
encoded.
You
know,
query
string
basically
is,
but
it's
where
it
it's
being
placed
in
the
request
is,
is
what's
going
to
vary
between
them.
I
agreed
with
not
with
wanting
to
make
this
work
with
any
kind
of
response.
A
That's
what
I
said:
we
have
different
response
mode
values,
so
the
chart
can
be
either
in
a
fragment,
can
be
transported
by
a
forum
post
or
there's
a
query
string
parameter.
How
is
that
specified?
Oh
just
a
combination
of
jot
point
I
think
it's.
It
starts
with
the
arm
representation
just
as
query
period
JWT,
for
example,.
J
A
Please
give
me
a
rate
and
give
give
give
us
feedback.
I
mean
this
is
the
reason
why
I'm
presenting
this
here
to
make
you
aware
there
is
some
work
and
it's
it's
still
in
the
early
stage,
even
if
it
went
through
implementers
draft
already.
So
please
keep
feedback
on
that
yeah
right
now.
It's
best
to
give
feedback
on
the
fabulous,
because
that's
where
this
dis
draft
right
now
lives
all
right,
so
just
to
give
an
example
of
how
this
would
look
like
for
a
code
in
bold,
you
see
the
the
well-known
response
parameter.
A
A
That's
how
the
request
looks
like
so.
You
can
just
use
response
mode
JWT.
In
that
case,
the
default
transport
is
used
for
the
certain
response
type.
So
for
code,
it's
a
query
parameter
for
implicit
should
be
fragment,
but
you
can
basically
specify
what
you
want
to
achieve
it
by
adding
a
period
and
the
transport
mechanism,
and
the
response
just
contains
the
jot.
A
That's
it
and
the
client
then,
is,
as
opposed
to
first
decrypt,
the
jot
and
check
all
the
all
the
different
well
use
within
the
starting
with
the
state
so
verifying
the
state
ensures
that
a
request.
It
was
really
also
issued
on
the
same
device
that
the
response
is
being
processed,
so
that
gives
basic
as
he
is
a
ref
protection
and
that
also
helps
to
detect
injection.
A
What
the
drum
draft
provides
the
drum
charm
draft
provides
different
mechanism.
It
provides
signing
encryption
as
I
as
I
said,
which
also
means
that
there
is
confidentiality
over
the
data
of
the
authorization
response,
something
we
we
didn't
have
before.
We've
got
sender
identification,
the
identification
and
authentication.
We've
got
all
the
instruction
protection
from
replay
leakage
and
mix-up,
and
this
all
packaged
in
a
single
mechanism,
so
no
need
for
additional
pixie
nuns
or
something
like
that
which
I
really
like
with
the
draft.
A
N
Annabelle
Bachman
AWS
again
now,
armed
with
30
seconds
of
having
looked
at
your
draft,
I
I
do
think
it's
worth
pursuing
this
in
Roth,
I.
Think
the
subject
matter.
Expertise
is
more
likely
to
be
found
in
this
space
as
far
as
understanding
how
to
do
this
in
a
way
that
is
going
to
play
well
with
other
aspects
that
may
come
along
a
couple
concerns
I
see
with
the
way
you're
doing
things
currently
is
you're.
You
you're,
defining
sort
of
a
cross
product
of
two
values
or
values
right,
which
means
anytime.
N
Another
approach
would
be
to
look
at
this
as
a
response
format
parameter
mm-hmm,
which
feels
a
little
bit
weird,
because
it's
like
reinventing
it's
essentially
doing
what
the
accept
header
is
doing,
except
we
don't
have
a
way
of
applying
the
anok,
the
accept
header
to
say
the
query
string.
So
we
kind
of
need
to
fill
that
gap
just.
A
N
N
The
other
concern
I
see
is
that
one
of
the
mistakes
that
we
made
with
Jah
requests
is
that
we
made
the
assumption
that
there's
no
collisions
between
Jacque
claims
and
request
parameters
with
the
result
being
now
that,
like
we
have
to
be
very
careful
about
making
sure
that
that
remains
to
be
the
case,
and
we've
had
discussions
in
this
very
group
where
that
oops,
that
was
a
problem,
and
now
we
have
to
figure
out
how
to
solve
it.
Oh
yeah
is.
N
N
A
F
So
Matthew
Miller
speaking
for
himself
I,
think
I
mean
and
also
after
about
thirty
seconds
of
looking
at
this.
It's
very
interesting
but
I
think
the
fact
that
there's
so
much
discussion,
happiness
Mike,
means
that
maybe
this
work
ought
to
be
happening
here
to
cover
some
of
these
cases
that
seem
to
be
cropping
up
with
this
audience.
Even
if
there
is
a
tremendous
amount
of
overlap
between
Open
ID
Connect
in
here
and.
N
About
backup
in
AWS,
I
think
it
as
far
as
how
do
we
handle
putting
the
response
parameters
into
the
jaw?
Ultimately,
I
think
it
depends
on
what
you
want
the
scope
of
this
to
be.
If
you
want
this
to
be
something
that
is
used
within
the
OAuth
space
in
our
specs
and
nowhere
else,
then
yeah
you,
you
could
maybe
get
away
with
saying:
hey
just
make
sure
that
your
response
parameters
don't
collide
with
John.
N
If
you
want
this
to
be
something
that
is
more
broadly
adoptable
such
that
it
could
be
employed
with
as
a
response
format
for
other
protocols
that
already
exist
out
there
or
anything
that
people
might
be
building
in
the
future,
we're
avoiding
collisions
with
claims
may
not
necessarily
be
practical
than
I.
Think
it's
worth
avoiding
that
problem,
since
it's
easy
for
us
to
do
so,
I
think.
J
Knew
I
was
going
to
say
something
else,
like
Jones
I've,
seen
in
practice
that
people
already
developers
get
confused
and
do
things
wrong.
Given
we
have
the
combination
of
response
type
in
response
mode,
despite
the
combinations
all
being
well
defined,
I've
seen
implementations
not
follow
the
specs
I
really
really
don't
want
a
third
parameter
called
response
format
or
something
which
you
would
have
to
understand
all
three
values
and
the
communicational
permutations
thereof.
You
know,
don't
know
how
to
and
could
requests
and
or
responses.
H
This
is
Brian
Campbell,
I
guess
I
like
to
agree
with
Mike.
Although
I
appreciate
the
pedantic
Ness,
I'm
annabelle
I
do
want
to
read
the
the
definition
of
response
mode.
Is
the
response
mode
determines
how
the
authorization
returns
result.
Parameters
from
the
authorization
endpoint,
so
I
think
that
what's
being
done
in
here
is
well
well
within
the
definition
of
that,
although
it's
sort
of
mixing
the
encoding
and
the
generalized
form
out
of
it
I
think
it's
close
enough
to
satisfying
it
and
the
possibility
of
introducing
a
new
format
burst
mode.
H
H
As
far
as
the
collisions
go
I
the
I
don't
know
what
to
do.
The
only
practical
collision
we've
had
is
around
odd.
In
the
JWT
requests
that
came
up,
it
was
specified
in
a
standard.
That's
still
out
there,
so
it's
in
some
ways
it's
sort
of
an
academic
collision.
We've
only
had
one
actual
instance
of
it
and
another
way
that
this
could
deal
with.
It
is
registering
those
parameters
that
are
meaningful
and
jata
in
this
context,
so
that
they're
taken
as
response
parameters,
I.
H
H
A
That
I
mean
we
started.
We
started
at
work
and
fappy
because
there
wasn't
sure
direct
need
for
this
kind,
but
it's
obviously
something
that
could
live
in
the
working
group
as
well.
And
the
question
was
raised
in
the
beginning
of
happy
working
group
as
well.
So
I
don't
have
a
solution
for
that,
and
I
would
like
to
come
up
with
the
same
specification.
Just
working
group
referring
to
the
other.
J
J
Second,
I
just
wanted
to
provide
background
information
for
those
of
you
who
may
not
be
also
in
the
ACE
working
group
that
the
100
auth
parameter,
conflict
that
did
arise,
live
excites
fixed
in
his
perimeter,
strapped,
which
was
submitted
a
month
ago
or
something
I
know.
Hannes
and
I
have
reviewed
that,
and
we
believe
that
that's
now
sorted
out
the
conflicts,
so
I
think
in
practice
were
in
good
shape.
J
A
Okay,
thank
you,
so
Boston
and
and
Brian
so
I
think
you
heard
some
good
feedback
about
how
this
could
be
of
generic
use.
Besides
just
the
financial
API.
So
maybe
you
could
write
up
a
draft
and
then
socialize
it
somehow,
since
there's
a
certain
overlap
of
people
with
the
Open
ID
Connect
foundation
is
that
is
that
a
good
way
forward?
I.
A
A
A
So
next
presentation
is
one
that
I'm
going
to
get
from
behalf
of
these
people.
At
the
last
IDF
meeting,
we
had
a
longer
discussion
on
pop,
a
yes
to
flying
key
distribution,
and
it
was
in
also
in
relationship
to
some
of
the
work
that
happened
at
the
same
time
in
the
ACE
working
group.
Mike
hinted
to
that
a
few
minutes
ago
at
the
microphone,
and
we
came
up
after
some
discussions
in
Montreal
with
a
couple
of
suggestions
for
way
forward.
A
One
of
the
decisions
that
we
took
at
that
meeting
was
the
adoption
of
the
resource
indicator
document,
and
but
there
were
also
some
changes
to
this
specification,
and
then
there
was
his
Connors
corresponding
activities
in
in
the
ACE
working
group,
and
the
easte
working
group
meeting
is
later
this
week,
so
we'll
capture
this
one
first.
So
this
is
sort
of
the
picture
taken
from
the
document
just
illustrating
the
classic.
All
stands,
augmented
with
some
additional
fields,
namely
this
is
the
resource
indicator.
The
request,
confirmation,
the
RS
confirmation,
regular
confirmation
and
the
token
type.
A
Skip
that
there
is
the
use
of
these,
so
that
a
few
parameters
India,
which
are
the
idea,
is
that
the
document
has
the
corresponding
parameter
just
for
a
different
encoding,
namely
for
use
with
co-op,
and
this
one
is
encoding
for
HTTP,
which
is
what
we
agreed
on
in
terms
of
work
split
at
the
last
idea
of
meeting.
So
the
request
confirmation
is
a
parameter-
is
only
used
for
for
the
case
when
you
want
to
bind
an
asymmetric
key
pair
to
the
token,
and
so
so.
This
is
called
the
request.
A
Confirmation
in
case
of
the
response
for
this.
In
the
symmetric
key
case
you,
the
service,
actually
generating
the
key
pair,
so
ordered
unoccupied
the
symmetric
key,
and
he
needs
to
send
it
back
to
the
client
and
can
do
that
in
two
cases
or
in
two
different
formats.
One
is
ID
encrypted.
It
would
be
in
any
case
encrypted
using
Transportation
Security,
but
him
the
authorization
server
may
additional
encrypted
using
a
jwe
or
it
sends
it
as
a
jwk.
A
A
G
There
was
one
case
that
we're
having
some
arguments
in
the
ACE
group
on
the
request
see
enough
where
we
wanted
to
put
a
key,
ID
and
potentially
for
symmetric-key,
and
the
question
that
we
basically
had
for
the
OAuth
group
is
how
much
of
a
concept
of
there
is
issuing
a
secondary
token
with
additional
privileges
on
the
same
key,
and
is
that
something
we
should
be
doing?
Or
we
should
be
just
replacing
the
token.
G
E
G
J
So
Mike
Jones
follow-up
to
Jim's
question
in
standard
OAuth.
The
only
way
to
get
an
additional
access
token
is
to
use
the
Refresh
token,
in
which
case
I
think
it
makes
perfect
sense
to
key
it.
The
same
as
the
previous
access
token,
unless
an
explicit
key
rollover
has
occurred.
Is
that
the
ace
use
case
you're
talking
about
or
is
it
a
different
mechanism?
That's
not
part
of
normal
o
auth.
G
A
After
that
would
resolve
that
issue,
so
there
are,
as
I
was
preparing
the
slides.
I
noticed
that
I
had
to
still
have
a
few
bucks
in
it
specification
I
would
try
to
issue
a
new,
a
new
document
based
on
this
I
just
copy
and
paste
errors.
There's
also
some
the
WebRTC
guys
are
using
a
different
token
format,
so
they
I've
come
up
if
their
own
token
format
a
while
ago,
which
is
published
as
an
RFC,
which
was
reviewed
by
this
group,
so
I
think
having
them
review.
A
This
document
obviously
makes
a
lot
of
sense,
and
one
of
the
the
guys
who
joined
as
a
co-author
is
actually
part
of
that
community.
So
if
it
I
Missy,
so
I
probably
have
already
reviewed
it,
but
it
would
be
good
to
get
a
confirmation.
We
may
need
a
few
more
detailed
examples
to
illustrate
the
case
specifically.
Currently,
their
argument
is
full
of
examples
that
use
the
JSON
based
encoding,
but
this
mechanism
can
also
use
with,
of
course,
other
token
encodings,
like
the
CW
T.
A
So
there's
nothing
that
prevents
it,
and
this
is
what's
partially
also
where
the
relationship
to
ace
came
from.
Besides
having
a
sort
of
alignment
with
the
parameter
names
when
used
in
coop,
because
one
possibility
is
to
just
have,
for
example,
a
smart
phone
that
interacts
with
an
authorization
server
using
regular
HTTP,
but
it
actually,
when
itself
talks
to
an
IOT
device,
it
will
want
to
use
a
smaller
token
encoding
using
the
the
CW
T.
And
so
it
then
basically
talks
requests.
They
see
WT
using
the
HTTP
based
mechanism
and
passes
that
on
so
right.
A
Some
at
the
moment,
the
examples
don't
sort
of
illustrate
that
and-
and
maybe
the
similar
example
should
be
for
a
web
RTC
in
there
as
well,
to
just
give
a
a
broader
range
of
deployment.
Flavors
yeah
and
we
talked
about
the
alignment
with
with
a
switch.
We
been
sort
of
exchanging
messages
back
and
forth,
and-
and
some
of
you
are
probably
also
registered
on
the
on
the
east
list
and
and
I've
seen
the
interaction
between
Mike
Ludwick
and
myself
on
that
list
and
Jim
yeah
good
I
need
any
questions
on
that
one.
A
Maybe
I
should
have
put
that
on
there.
One
open
issue
that
shows
up
once
in
a
while
is
currently
what
the
document
talks
about
is
really
about
binding
the
access
token
to
a
key,
and
we
obviously
use
the
existing
mechanisms.
For
doing
so.
It
doesn't
say
anything
about
what
happens
to
the
Refresh
token
itself,
which
we
talked
numerous
times
in
a
group,
and
we
may
need
to
mention
that
in
in
some
some
way
or
the
other.
A
Nothing
so
that's
good
and
I
believe
with
this.
We
are,
unless
you
have
some
other
some
other
questions.
We
are
done
for
today's
meeting
and
will
continue
in
tomorrow
with
the
agenda
and
I
will
add.
One
additional
item
based
on
Aaron's
document
submission
on
the
JavaScript
JavaScript
based
application,
PCB.
A
Vicki,
do
you
want
to
go
to
the
microphone?
Oh,
no!
Oh.
We
wanted
to
talk.
We
also
wanted
to
have
a
side
conversation
and
regarding
MPLS
and
the
stuff
that
akka
talked
about
earlier,
so
I'm
proposing,
maybe
two
since
we
want
to.
We
could
give
a
brief
summary
or
a
brief
update
on
this
tomorrow
at
the
meeting
already
so
maybe
we
could
get
together
for
lunch.
That's
if
you
guys
have
fun.