►
From YouTube: IETF99-OAUTH-20170721-0930
Description
OAUTH meeting session at IETF99
2017/07/21 0930
https://datatracker.ietf.org/meeting/99/proceedings/
C
E
D
F
F
There
have
been
a
couple
of
changes
proposed,
so
I'll
go
over
those
changes,
but
hopefully
we
can
get
this
thing
done
pretty
soon,
so
a
bit
of
a
recap.
First,
what
is
the?
What
is
the
device
flow
device
flow?
Is
authorization
flow
designed
for
devices
that
have
internet
connection,
but
maybe
they
don't
have
a
browser
or
they
only
have
a
very
limited
input
mechanism.
F
In
that
case,
the
user
will
be
reviewing
the
authorization
request
on
a
secondary
device
like
a
laptop
or
a
smartphone,
so
how
it
works.
Some
like
this,
the
TV
app
as
an
example,
the
TV
app,
will
display
a
URL
that
the
user
will
need
to
visit
on
their
secondary
device
and
a
code
that
they'll
need
to
enter
user,
then
visits
that
URL
on
their
second
device
and
is
the
code,
and
from
that
point
it
looks
a
little
bit
like
regular
or
from
a
consent.
F
Point
of
view,
during
that
the
device
continues
to
poll
one
of
the
endpoints,
the
token
endpoint,
with
a
with
the
device
code
to
see
if
the
user
has
completed
their
action
and
if
they
have
completed
their
action,
they'll
get
back
the
Refresh
token
an
access
token.
So
it's
kind
of
like
the
authorization
service
sort
of
issued
like
an
authorization
code,
that's
not
actually
yet
valid
and
at
some
point
in
the
future
it
may
become
valid
or
may
become
invalid.
It's
gonna
work
all
right
so
on
at
the
important
stuff.
What
changed
since
98?
F
The
first
thing
is:
we
had
a
fairly
lively
debate
on
an
if
you
recall
in
Chicago
on
the
user
code
pram.
So
this
was
a
proposal
by
James
manager
from
Telstra,
and
the
idea
was
what,
if
we
could
include
the
user
code
in
the
verification
URL.
So
if
you're
not
familiar
with
the
draft,
the
authorization
server
responds
with
a
number
of
different
fields
in
the
authorization.
F
Sorry,
the
verification
URL
is
a
separate
field
to
use
a
code
and
the
intent
is
that
these
things
are
separately
consumable.
But
you
know
what,
if
you
want
to
do
something
like
this
right?
So
what
if
you
want
to
have
a
QR
code-
or
you
know
any
kind
of
like
non
textual
transmission
of
that
URL,
depending
on
kind
of
where
you
are
like
I,
think
I?
Think
in
America
people?
Don't
all
really
know
what
QR
codes
are.
So
we
don't
actually
see
this
a
lot,
but
it's
kind
of
a
good
example.
F
You
could
replace
that
with
a
Bluetooth.
It
would
if
you
want
any
any
way
of
transmitting
URL.
So
what
we
talked
about,
this
was
kind
of
generated,
a
lot
of
debate,
particularly
because
I
said
that
actually,
my
own
company's
server
won't
be
using
this
for
people
like
well.
Why
are
you
putting
in
there?
F
F
This
is
an
optional
enhancement,
so
it's
fairly
well
interoperable,
because
the
authorization
server
will
still
display
all
the
information
and
we're
actually
requiring
that
the
client
still
actually
display
the
two
pieces
of
that
information
separately.
So
if
the
user
doesn't
know
how
to
process
that
thing,
whatever
that
may
be,
they
can
still
sort
of
fall
back
into
it
manually
and
the
authorizations
have
actually
doesn't
support
that,
and
the
user
happens
to
scan
it.
They're
just
gonna
end
up
at
that
URL
and
have
to
type
in
the
code
anyway.
F
F
These
are
kind
of
one
of
the
nice
things
about
this.
This
flow
is
that
it's
sort
of
very
fairly
durable.
What
we
see
a
lot
of
people
doing
is
they
might
try
some
more
advanced
method
of
pairing,
say
the
TV
to
the
phone.
You
know,
maybe
they
have
their
own
app
installed.
So
you
know
you
you
you
might-
and
this
is
like
out
of
this
spec,
but
you
might
like
to
open
up
that
app
and
do
something
and
then
kind
of
fall
back
to
to
this
stand
flow.
F
So
Justin
I
think
is
joining
us
at
3:00
3:30
in
the
morning.
Apologies
he's
online
at
3:30
in
the
morning.
He
posted
there's
a
couple
of
open
questions,
at
least
I'd
like
to
go
through
and
just
remember
that
the
draft
is
sort
of
beyond
working
group
last
call,
but
so
this
is
the
last
chance
to
finalize
some
of
these
normative
things.
So
the
first
thing
he
suggested
was,
instead
of
specifying
the
user
code
parameter
in
in
at
your
old
construction.
F
G
G
So
this
picture
is
actually
impossible
with
the
current
spec,
because
what
you
would
actually
get
is
example.com,
slash
device,
:
user
code
equals
wdg,
boobarella,
what's
etc
and
yeah
that
thank
you.
You
would
get
that
on
the
top
line
that
URL
and
if
you
go,
go
back
to
the
other
thing
you
would.
You
would
get
the
plain
code
on
the
next
line
and
then
then,
that
QR
code,
so
this
this
picture
you,
you
can't
actually
get
this
picture
with
the
current
spec
I
think
you
can
actually.
F
Possible
right,
I
kept
you
out
because
the
device
authorization
employees
returning
HTTP
colon
slash
slash
example,
comm
device
that
part
as
the
verification,
your
I,
then
it's
returning
a
separate
Jason
parameter
called
user
code.
Without
with
that
value,
spec
is
basically
named
as
an
optimization.
If
you
wish-
and
you
want
to
display
that
verification-
your
I
non
so
textually,
then
you
can
use
a
parameter
standard,
URL
parameter
that
happens
to
match
the
key
of
the
jason
called
user
code
and
pass
in
the
euro.
So
this
basically
tells
you
how
to
construct
this
optimized
euro.
G
A
Different
reason-
and
that
is
as
it
stands
with
just
the
two
parameters
you
are
then
requiring
the
client
to
do
this.
Construction
of
the
complete
URL
you're,
requiring
that
the
user
code
parameter
then
be
standardized.
So
the
client
knows
what
that
is:
that's
putting
a
bunch
of
work
on
the
client
which
historically
doesn't
always
go
so
well.
A
Additionally,
it's
limiting
flexibility
on
the
part
of
the
the
server,
because
now
the
the
endpoint
that
receives
the
user
code
via
query
string
and
the
end
point
that
the
customer
would
type
that
quick
user
code
into
have
to
be
the
same,
which
may
or
may
not
work
out.
They
may
want
to
use
a
different
URL
for
the
parameterize
endpoint,
perhaps
one
that
is
going
to
be
captured
by
their
mobile
app
if
it
is
on
the
device,
whereas
the
simple
to
enter
shortened
form
of
the
URL
may
not
be
that's
a
good
point.
Oh
buddy.
F
Okay
well,
firstly,
to
discuss
your
point:
yeah
I
think
it's
a
good
point.
I
guess
you
could
potentially
two
different
targets
for
that.
A
couple
of
other
things,
I
thought
about
in
trying
to
trying
to
come
up
with
an
opinion
on
this
was
also
an
you
see,
end
of
a
higher
entropy
code
for
that
magical
one
so
that
that
could
be
beneficial
in
some
way.
F
Yeah
I,
guess
I'm.
It
is
why
the
other
thing
is
that
you
would
actually
know
that
the
authorization
server
supports
that
yeah
on
the
flipside.
I.
Guess
it's!
You
know
it's
one
extra
piece,
information
coming
down:
yeah
I,
don't
know
I
just
broke
both
his
I
complex,
like
you
said
in
this
case,
I,
think
the
construction,
the
URL
is
very
simple,
so
as
much
as
I
would
normally
agree
like.
Let's
get
everything
away
from
the
client
as
possible.
I
would
really
hope.
F
That's
a
good
point
that
probably
should
be
added.
If
we
keep
the
context
sofa
pill,
they
didn't
quite
catch.
That
D
card
asked
is:
is
the
either
a
requirement
that
the
existing
user
code
be
you're
all
safe
and
I'm,
not
intelligible?
We
may
specify
an
alphabet
for
it.
We
may
specify
a
character
range
for
it.
I.
H
F
A
There's
some
kind
of
weird
malformed
girl,
something
in
my
experience,
I've
seen
with
clients
implementing
our
os/2
based
services.
Is
they
frequently
aren't
reading
these
specs,
so
yeah
I
know
right
yeah,
so
it's
a
banking
on
clients
having
an
understanding
of
what
is
in
the
spec
and
isn't
and
and
what
the
actual
you
know
what's
reasonable
to
expect
around
the
values.
These
parameters
isn't
necessarily
a
safe
assumption.
As
far
as
right,
hoping,
that's
gonna
make
things
easier
for
them
right.
G
A
Yes,
Annabelle
back
then
Amazon
reiterating
just
in
suggestion
that
we
have
a
separate
parameter
that
contains
the
I
guess,
clickable
URL,
that
has
the
code
embedded
in
it.
So
there's
two
experiences
we're
talking
about
here,
one
which
is
the
the
primary
one
that
Williams
presented,
that
is
the
customer
user
types
in
a
URL
and
then
types
in
a
code.
The
alternative
is
the
automated
experience
where
they
engage
with
the
QR
code
or
through
some
other
mechanism.
A
URL
is
opened.
A
That
already
has
two
code
embedded
in
that
have
a
separate
parameter
for
that
URL,
so
that
the
client
does
not
have
to
try
and
construct
it
that
reduces
the
amount
that
we
have
to
standardize
on
these
endpoints
cuz.
Then
we
no
longer
have
to
standardize
a
query,
string
parameter
for
the
the
user
code
and
it
opens
up
flexibility
for
the
server
to
use
a
different
endpoint
for
that
express
the
code
in
some
other
means,
or
have
a
higher
entropy
code
that
just
decouples
that
from
the
streamlined
four
user
entry
experience.
E
K
K
L
M
L
M
M
D
F
K
F
A
complete
URI
I
got
my
gear
ID
to
an
image
which
you
download
and
it's
the
card
yeah,
so
I
guess
the
only
drawback
with
that
is
that
it
assumes
that
a
secure
code,
so
this
is
in
my
example,
was-
was
the
example
I
guess.
I
could
see
like
NFC
being
another
way
to
represent
that
that
Europe
potentially,
oh
you,
you
mean,
like
you,
mean
like
adding
another
parameter.
K
F
K
K
N
N
Know
that
you
need
to
send
a
set
unless
you're
doing
something
super
complicated,
just
sending
the
you.
If
we
had
a
separate
URI
having
the
device
send
that
over
NFC,
you
ought
not
to
need
another
parameter
or
must
be
conveniently
horribly
wrong.
So
the
only
question
is
whether
or
not
devices
have
a
library
to
create
the
QR
code
locally.
A
N
F
That's
ridiculous:
it
doesn't
history
that
could
be
a
remote
okay,
Jerry
yeah,
so
I
guess
like
as
as
currently
written,
even
with
the
even
disregarding
the
decision
between
the
composability
or
not.
The
kind
of
point
was
like
he's
this
year.
All
that
you
can
use
transmitted.
However,
you
want
to
transmit
URLs,
and
so
I
I
did
like
this.
It
was
FET
and
yeah
yeah.
A
To
that
point,
I
think
if
we
try
and
get
into
tailoring
the
spec
to
particular
transmission
technologies,
where
we're
gonna
go
down
a
huge
rat
hole
of
never-ending.
Do
we
want
to
support
this?
Do
you
want
to
support
that
yeah
if
we
limit
the
spec
to
getting
the
code
from
the
server
to
the
device
and
give
it
with
it
with
enough
flexibility
that
the
device
can
then
get
it
to
a
secondary
device
through
whatever
transport
makes
sense,
then
I
think
we're
solving
the
right
problem
right,
yep.
M
M
M
F
M
F
M
Noise-
okay,
right
so
in
the
Alexa
world,
right,
there's
many
third
parties
that
are
putting
out
devices
where
you
want
to
enable
that
third
party
to
make
calls
into
Alexa
okay.
So
we
do
require
some
inter
out
there,
although
we
could
just
say
what
to
do
correct
our
world
yeah.
But
it
would
be
nicer
if
it
was
standardized
and
was
more
of
a
practice,
but
we
would
probably
want
more
of
a
flow
like
that
right,
I
described
in
a
flow,
that's
very
web
oriented
I.
That.
F
N
John
bradley
yubico,
so
I'm
influenced
by
the
arguments
that
having
a
separate
precomposed
uri
that
could
have
a
different
endpoint
and
perhaps
different
into
amount
of
entropy,
then
the
user
type
of
all
one
is
probably
a
good
idea,
given
that
a
lot
of
this
will
be
either
NFC
your
QR
codes
to
to
an
app
which
is
I,
think
they
growing
or
even
audio
to
an
app
there's
a
number
of
different
ways.
I,
don't
know
that
we
should
add
the
QR
code
directly.
N
So
I
think
that
you
know
trying
to
generically
add
QR
codes
or
sound
files,
etc
should
probably
be
left
as
an
extension,
but
I
guess.
The
other
thing
is
that
doesn't
Google
already
do
this
sort
of
thing
with
printers
there
are,
you
know,
Google
doesn't
yet
make
printers,
but
there
are
printers
that
use.
We.
F
N
What
we
have
to
do
is
care
about
the
interrupts
where
the
device
manufacturer
I
ye
Epson,
isn't
there.
They
even
still
make
printers
I,
don't
know
that
they're
they're
not
providing
the
Oh
hot
server,
it's
ready,
their
personal
or
some
print
service,
which
is
offered
by
Microsoft
or
Google
or
whoever
right.
So
we
have
to
think
about
some
of
the
interrupt
things.
Oh
I
can
also
by
making
the
code
numeric
for
four
reasons,
at
least
as
a
recommendation.
F
M
F
N
N
M
F
B
F
B
F
I
I
O
N
Something
like
I
believe
the
suggestion
is
to
add
a
new
parameter
which
has
a
pre
composed
version
of
the
URI
which
enables
the
user
code
to
be
have
higher
entropy
and
be
pretty
URL
encoded,
which
gets
around
the
problem
I.
We
also
need
to
think
about
the
user
displayable
user
code
if
we
are
actually
using
utf-8.
What
is
the
script?
N
That
immediately
leads
one
to
having
a
separate
precomposed,
URI
I.
Believe
Ana
bio
made.
The
suggestion
that
if
you
had
a
separate
URI
that
you
were
sending
precomposed,
you
or
riot
could
actually
have
a
different
path,
but
that
would
be
an
implementation
detail.
We're
not
saying
that
you
need
a
different
endpoint,
but
as
an
implementation
detail,
if
you
wanted
to
do
if
the
AAAS
wanted
to
do
an
optimization,
nothing
forces
it
to
have
exactly
the
same
path.
I.
F
Could
comment
on
the
you
gf8
concern
because
I
think
we
like
not
to
walk
away
here
and
have
that
whole
thing
blow
up
so
I
guess
we're
not
gonna
require
our
clients
can
display
any
character
they
ascend
at
them.
You,
the
authorization
server,
would
have
to
use
its
best
judgment
for
the
market.
No
he's.
I
N
These
are
actually
interoperable
separate
devices.
If
you
had,
you
know,
I
have
a
Korean
printer
that
knew
that
it
was
going
to
use
Korean
script
that,
but
as
soon
as
that
shipped
to
South
America,
that's
not
gonna
work
so
well,
so
somehow
we
are
actually
allowing
international
like
characters
as
opposed
to
numbers.
F
E
F
A
Backman
Amazon
just
to
completely
bury
the
utf-8
discussion.
They
keep
in
mind
that
the
more
complicated
the
display
requirements
for
the
client,
the
more
devices
and
use
cases
we
exclude
from
being
able
to
use
this.
The
whole
point
of
device
code
is
that
it
is
usable
in
scenarios
where
the
device
has
constrained
input
and
output.
So
if
you're
agree,
if
you're
trying
to
output
everything
in
Unicode,
that's
gonna
be
really
hard
on
a
really
low
res
LCD
display
I,
agree.
A
That
looked
possible
and
then
quickly
to
further
address
Mike's
comment
and
John
is
right.
That
I
think
we're
we're
not
talking
about
necessarily
a
defining
a
separate
endpoint,
we're
just
talking
about
defining
a
separate
parameter
with
a
URL
that
may
or
may
not
point
to
a
different
endpoint
and
bear
in
mind
that
the
spec
itself
says
nothing
about
what
those
endpoints
do.
It's
very
deliberately
leaves
that
up
to
the
a
s
just
as
oweth
leaves
the
process
of
resource
owner
identification
and
authorization,
and
all
of
that
up
to
the
implementers
did.
O
Alright,
later
on
so
so
we
went
from
here's
a
URL
type,
this
in
and
type
in
these
characters
to
you
know
multiple
at
least
two
ways
you
can
get,
hopefully
to
the
same
place
as
anybody.
Don't
security
analysis
on
this.
Are
there
any
aspect?
Is
there
any
security
aspects
involved
in
you
know
two
ways
that
are
supposed
to
take
you
to
the
same
place.
We
should
we
could
talk
to
the
security.
O
That,
in
their
formal
analysis,
they
like
today,
I
am
no
idea.
I
mean
I,
guess
part
of
the
discussion
we
had
at
the
last
idea
force
that
that
there
are,
you
know
when
you,
when
you
present
that
the
like
the
first
generation
of
this
user
interface,
here's
an
input
box,
you
know
type
this
right,
that's
like
maybe
harder
to
to
confuse
or
you
get
confused
users
over
or
get
wrong.
I
have
no
idea.
But
again,
this
seems
like
something
crankiest
crank
this
out
in
a
in
our
last
call
comment.
B
B
Be
big
enough
in
the
end
to
have
another
working
group.
Last
call
I,
don't
know,
but
it
shouldn't
be
a
big
deal
anyway,
and
then
that
was
not
a
joke
with
the
security
researchers
like
they,
we
had
this
this
meeting
and
they
they
offered
help
with
some
of
those
activities.
So
we
can,
we
could
yeah
yeah
I
mean.
F
Definitely
one
of
the
things
I
liked
about
the
old
way
is
that
it
kind
of
full
it
sort
of
falls
back
very
nicely
if,
if
the,
if
the
server
didn't
understand
the
ural,
it
just
displays
the
original
you're
all
anyway,
but
I
guess
it
shouldn't
be
sending
something
it
doesn't
understand
in
the
revised
proposal
anyway.
So
dave.
J
I'm
curious
to
make
sure
we
understand,
where
we're
ending
up
and
where
we're
going
with
this,
because
I
think
I
heard
two
different
things.
One
is
that
if
we
make
the
code
URL
safe,
then
composition
by
the
client
there's
no
problem,
we
don't
have
to
worry
about.
We
don't
say
a
lot
of
things
about
it,
but
also,
then
we
have
this
idea
of
providing
you
the
complete
URL,
which
requires
no
composition.
So
the
question
is
implementations
aside.
Yeah,
are
we
deprecating
what
you
show
on
the
screen
right
now?
J
In
other
words,
the
code
is
only
for
typing
into
web
pages,
and
the
compose
URL
is
only
for
you
know,
sending
it
as
a
parameter
having
what
you
have
on
the
screen
now
of
user
code
equals
that
which
is
composed
by
the
client
somehow
based
on
these
two
P.
The
first
piece
is
one
and
two
to
make
this
URL.
Is
that
option
still
on
the
table
other
than
I
mean
other?
J
In
fact,
that
implementations
are
doing
it
today,
perhaps,
but
if
we
have
option
three,
if
we
have
parameter
three
I
might
make
the
case
that
client
composition
should
never
be
done,
and
this
server
parameter
of
user
code
equals
should
never
be
allowed
that
it's
opaque,
because
you
know
I'm
that
that
just
that
user
code
equals
URL
parameter
is
just
not
a
thing
yeah.
It's
either
opaque
in
case
three
parameter
three
or
it's
never
used
in
one
and
two
you
go
to
one
you
type
yep
I
do.
A
Let's
not
do
both.
Let's
pick
one
Annabel
Backman
Amazon,
the
security
considerations
point
there
is
text
in
version
zero.
Six
of
the
draft
that
brings
up
remote
fishing
concerns
around
the
composed
URL,
so
that
the
current
draft
does
actually
address
the
or
at
least
raised
the
risk
of
increased
ability
to
trick
the
user
when
you're
not
forcing
them
to
type
in
a
code
that
they
see
on
a
screen,
so
I
encourage
anyone,
who's,
who's,
interested
or
concerned
about
that
risk.
A
No,
it's
it's.
It's
more
guidance
for
the
authorization
server
around
making
sure
that
the
experience
they
present
through
that
composed
URL
still
gives
the
the
end
user.
The
ability
to
detect
that
phishing
might
be
going
on
yeah.
It
yeah
it
kind
of
raises
the
bar
necessary
for
that
experience.
Basically,
yeah.
F
And
comment
on
phishing
I
guess
like
one
of
the
things
that
we
were
trying
to
establish
is
basically
are
you
setting
up
a
device
and
use
that
device
currently
in
your
possession?
That
was
sort
of
the
the
challenge
that
we
were
trying
to
answer,
and
so,
when
were
think
about
like
what
UI
to
show,
we
really
think
of
asking
that
question.
Like
is
the
device
in
front
of
you
and
is
a
display
nice
coat.
You
know
to
try
and
mitigate
that
you
know
might
be
the
draft
Lucy.
P
F
Right
we
do
it.
There
is
another
another
open
question,
so
let
me
let
me
go
this
say:
yeah
we
added
some
ascii
diagrams.
That's
so
good
justin
pointed
out
that,
after
discussion,
at
least
that,
while
it's
a
polling
protocol,
there
is
no
actual
requirement.
You
have
to
pull
at
it.
There's
no
requirement.
You
pull
that
anymore.
You
can
follow
a
slower
interval.
You
can
wait
for
user
interaction
to
initiate
a
a
poll
that
would
look
more
like
a
single
request.
F
I
F
I
B
B
I,
don't
think
they
wanted
to
definitely.
My
sense
is
more
like
people
and
I've
seen
this
in
other
environments,
since
we
are
further
along
in
the
process.
People
look
at
this
and
found
out
that
they
can
actually
use
this
document
to
cover
some
of
the
use
cases.
Specifically
some
of
the
IOD
use
cases,
and
it's
actually
experienced
that
myself
in
the
healthcare
space
some
people
look
at
it,
isn't
that
I.
Actually,
this
is
what
I
want.
M
F
Okay,
so
they,
the
other
kind
of
major
change
that
was
proposed,
is
is
relate
to
this
fact
that
you
may
have
multiple
device.
Is
that
our
actual
the
same
so
take,
for
example,
a
Roku
device?
If
you
have
say
two
TVs,
you
may
have
two
Roku's
both
authorizing
to
YouTube
or
or
however,
and
both
would
actually
the
same
client
ID,
and
so
the
reason
proposed
around
ok.
F
So
if
they
both
have
the
same
client,
ID
and
the
user
say
loses
upgrades
or
souls
or
stolen
or
something
if
one
of
those
devices
is
gone,
how
do
they
revoke
just
that
one
device
and
as
written
the
the
spec
is,
doesn't
really
provide
any
help
to
the
authorization
server
to
provide
a
good,
revoke
experience?
I
guess
you
could
look
at
when
the
token
was
last
used,
but
that
probably
doesn't
help
a
hollow
someone
bought
it
off
you
and
is
continuing
to
use
it.
So
this
this
is
an
edition.
F
It
doesn't
really
change
the
actual
protocol
at
all.
It
just
passes
a
little
bit
more
information
about
the
device
to
the
authorization
server
it
to
allow
the
authorization
server
to
store
this
information.
These
three
fields
associated
with
the
grant
the
motivation
is,
is
for
revoking.
So
let
me
give
you
an
example:
with
the
with
the
Roku,
the
device
ID
would
be
a
unique
ID
of
the
Roku.
The
purpose
to
revive
that
is
so
that
that
device
can
be
represented
as
a
single
entity
for
revocation.
F
F
Hopefully
this
is
available
to
the
app
they
can
just
like
kind
of
query
like
what
am
I
running
on
like
oh,
it's,
an
Xbox
360
is
Xbox,
one
or
whatever,
which
may
actually
have
the
same
client
ID
depending
on
on
the
implementation,
and
then
the
final
is-
and
you
know
this
week-
extremely
optional-
they're
all
optional,
but
this
would
be
the
most
optional
it's
kind
of
like.
Does
it
have
my
secretary
name,
if
so
past
that
as
well?
So
then
you
can
imagine
this
revoke
experience
or
it's
a
William.
F
A
Annabelle
vacuum
and
Amazon
this
problem
doesn't
seem
unique
to
the
device
flow
to
me.
It
would
equally
apply
to
a
native
apps
running
on
mobile
devices,
where
you
do
have
rich
user
input
and
you
are
potentially
entering
credentials
right
on
the
device,
so
this
spec
does
not
feel
like
the
right
place
to
solve
this
problem.
Yeah.
F
Yes,
so
he
can't
had
this
idea
all
those
years
ago,
I
hadn't
actually
seen
that
tool.
Until
recently,
we
kind
of
came
up
with
this
to
try
and
solve
that
revocation
experience.
There
was
another
contribution
on
the
list
as
well.
It
was
similar.
I
will
point
out
that
the
device
authorization
endpoint
is,
strictly
speaking,
a
different
endpoint.
A
My
other
concern
here
is
that
if
we
are
overly
prescriptive
about
what
pieces
of
information
we're
asking
for
for
device
identification,
we
run
the
risk
of
ruling
out
use
cases
where
right,
potentially,
we
need
more
than
just
these
three
pieces
of
information
that
we've
identified
here
that
work
for
the
cases.
People
are
immediately
familiar
with.
Okay,
two.
F
B
William
I
think
this
issue
came
up
in
Chicago
already
like
in
a
question
of
like
what
are
we
actually
identifying
in
terms
of
client
in
there
I
had
the
impression
that
we
also
talked
a
little
bit
more
about
our
more
extended
functionality
than
just
having
some
parameters
that
are
obviously
non
cryptographic.
So
one
could
argue
that
maybe
you
actually
want
to
do
some
form
of
authentication
potentially
at
the
station
that
stuff
you
have
been
proposing
in
a
different
context.
B
B
F
F
I
guess
I
guess
I
should
get
your
other
point
to
that
you
know.
Maybe
these
aren't
enough
premise.
My
hope
is
add.
You
know
if
there
is
a
common
minimum
set,
that
we
think
a
lot
of
devices
need.
You
know
if
you
drop
reasons,
let's,
let's
document
that
column
unit
of
Z,
I
guess
not
trying
to
capture
the
every
possible
field
ever
but
I
mean
I.
F
I
do
have
a
very
specific
use
case
and
a
reason
for
including
these
for
potentially
including
these
parameters
like
I
mean
honestly
I,
don't
really
mind
if
it
doesn't
get
included.
This
is
something
that
you
can
always
don't
miss
separately.
You
can
say
like
hey
if
you're
talking
to
Google
like
won't,
you
just
add
these,
and
then
we
can
give
you
as
abetik,
revocation
experience.I.
F
F
B
Attestation
is
obviously
on
the
sort
of
more
extreme
and
in
the
middle
that
would
be
some
form
a
cryptographic
form
of
this,
and-
and
this
is
sort
of
like
on
the
on
the
on
the
on
the
other
extreme.
It's
basically
some
parameters
that
the
device
can
easily
sort
of
free
flow
right:
okay,
I,
just
I,
don't
really
have.
M
Could
do
that
the
other
two
are
useful
from
a
UX
and
and
because
users
not
going
to
know
whether
it's
the
right
device
ID
thing
easily
or
anything
right.
So
what
you're
trying
to
do
is
is
it
in
the
authorization
on
the
web
app
or
whatever
app
the
user
is
when
they're
deciding
whether
they
want
to
enable
this
device?
Is
you
can
be
showing
the
model
and
the
name
as
part
of
that
to
sort
of
complete
the
flow
of?
Am
I
authorizing
the
device?
M
F
M
F
Are
let's
say
the
one
authorization
set
has
two
apps
say
like
YouTube,
Google,
Play,
Music,
right
and
so
I
have
two
devices.
You
know
living
room,
Chrome,
car
Roku
and
like
bedroom,
Roku
and
then
rather
having
like
four
four
things
displayed
on
for.
Revocation
we
could
just
have
to,
for
example,
write
could
just
be
okay,
you
have
the
living
room,
Roku
and
the
bedroom
Erica.
If
you
revoke
one
of
them,
it
revoked
both
grants
so
just
knowing,
which
are
different,
clients
right,
which
are
different
client
IDs.
Instead
of
knowing
all.
A
F
F
F
F
B
Really
it
really
gives
you
just
used
client
ID,
because
in
this
case
you
have
one
client
ID,
but
then
use
it
on
on
many
different
devices.
So
you
wouldn't
you
wouldn't
necessarily
know,
or
you
could
definitely
not
know
the
device
name
or
the
authorization.
So
it
wouldn't
be
able
to
infer
the
device
name
just
from
the
client
ID,
because
if
you
have
the
app
running
on
thousands
of
millions,
I'm.
F
F
Just
to
comment
of
the
the
last
one
first,
so
you
said:
what
is
the
value
of
the
client
providing
this
information
I
would
say.
One
of
the
value
is
that
assuming
legitimately
provide
information.
Is
that
every
vacation?
You
know
if
I
just
see
some
random
things.
What's
that
I
can't
be
bought
racing
I'm
gonna
revoke
it
right
if
it
says
hey,
this
is
like
your
Roku.
Don't
Rover!
You
know
this.
E
F
Comments
on
it.
Firstly,
if
we
add
this,
let's
make
sure
we
do
have
that
security
consideration.
That's
a
great
point.
A
lot
of
the
thinking
I
was
doing
around
this
was
revocation
but
you're
talking
about
consent,
yeah,
I
think
from
a
concern
point
of
view.
I
agree
you,
you
might
wanna
have
a
whitelist,
so
here's
one
possible
implementation
is
not
not
wouldn't
be
normative,
but
you
could
have
say
like
a
known
list
of
ten
that
way:
you're,
not
just
rendering
random
attacker
provider
text
button.
F
Let's
say
it's
like
Xbox
I
think
you
know
the
U
badge
of
that
is
when
I
said
before
is
like
one
of
the
main
questions.
We're
asking
trying
to
prevent
against
phishing
is:
is
this
your
device
and
is
it
in
your
possession
right
now
being
able
to
say
it?
Is
this
your
Xbox?
Now,
if
that
was
from
a
whitelist
of
ten
I
I,
don't
particularly
see
how
replacing
this
device
with
Xbox
would
be
bad.
F
A
E
A
M
Maybe
it
is
in
the
dock
and
I,
don't
remember
it,
but
there's
a
number
of
uses
of
this.
It
isn't
asleep
clear
to
everybody.
Some
people
view
that
the
device
there's
only
one
thing
on
the
device,
but
the
model
is
that
there
could
actually
be
a
bunch
of
other
apps
running
on
the
device,
and
so
the
device
knows
who
it
is
but
rap
is
trying
to
install
and
boot
up.
M
You
know
so
it's
you
know
you're
trying
to
enable
Netflix
on
your
Roku
right
which,
as
opposed
to
just
enabling
the
device
right,
you
may
want
to
call
that
out,
because
it
may
not
be
obvious
to
everybody.
Okay,
yeah
thanks
at
that
point,
now
it's
deadly
true
and
then
sometimes
people
are
just
trying
to
revoke
the
service
as
opposed
to
across
all
devices
and
sometimes
they're,
trying
to
revoke
the
device
right
and
all
the
surfaces.
Aren't
it
right
so.
F
F
N
Curious
Cala
people,
John
and
Bradley
from
yubico,
so
before
Lucy
gets
up
to
throw
this
particular
cold.
Water
I'll
beat
her
to
it
that
device
ID
is
actually
a
correlative
all
identifiers
and
many
device
manufacturers
go
to
great
lengths
to
prevent
different
apps
on
the
same
device
from
knowing
that
they're
on
the
same
device.
So
there's
going
to
have
to
be
some
significant
amount
of
security
considerations.
I'm
minded
to
privacy
considerations.
I
minded
to
separate
this
from
the
spec.
That's
about
to
go
into
last
call.
N
This
probably
needs
to
be
its
own
spec
and
consider
what
how
this
relates
both
to
mobile
devices,
mobile
devices,
limited
display
devices
and
attestations,
etc.
I
think
this
is
its
own
fairly
large
ball
of
wax
I.
Think
that
trying
to
stick
this
into
the
device
back
at
the
last
minute
is
going
to
cause
the
whole
thing
to
blow
up
in
iesg
review,
with
all
sorts
of
just
she's
already
got
a
list
of
discusses
that
would
completely
tie
us
up,
so
I
would
say,
don't
fall
into
that.
Let's
not
fall
into
that
hole.
E
F
B
F
F
B
B
B
But
I,
don't
I
I
think
we
shouldn't
get
hung
up
on
the
last
call.
So
we
thought
that,
like
coming
from
the
last
night
yet
meeting
with
that,
we
are
done,
but
often
the
last
call
is
away
for
people
to
look
at
it
and
actually
raise
things.
So
last
call
is
not
always
the
last
call,
so
so
I
think
this
is
it's
as
good
as
any
other
time
to
raise
these
issues
so
Justin,
yes,
Justin.
C
G
So
a
couple
of
things
about
that
one.
Actually,
this
this
loops
back
into
Mike's
question
earlier
of
you
know:
why
are
people
bringing
up
all
these
things
now
and
part
of
it-
is
that
this
spec
has
sat
kind
of
pseudo
stable
and
dormant
for
years,
so
people
have
actually
been
implementing
this
for
a
really
long
time
in
non-standard,
but
mostly
kind
of
compatible
ways,
and
so
now
that
it's
finally
going
through
the
standardization
process,
people
are
starting
to
pay
attention
to
a
wait.
G
So
this
is
the
right
time
for,
for
all
of
this,
to
get
hammered
out
and
I.
Think
that's
why
we're
seeing
that
all
that
said
everything
I'm
hearing
is
that
this
stuff
belongs
in
a
separate
spec
I
threw
a
link
to
just
such
a
spec
into
the
chat
just
now,
because
I
don't
know,
I
thought
it
was
a
good
idea
back
in
2010
and
in
in
any
event,
I
agree
with
the
sentiment
that
that
this
really
should
kind
of
live
in
its
own
space,
because
what
Annabel
said
is
also
true.
B
G
E
F
H
H
But
if
you
think
about
like
my
Roku
I
I'm
authorized
with
yeah
with
YouTube
and
Pandora
and
Netflix,
and
so
and
those
are
different
services,
so
there's
no
even
physical
way
to
there's
no
way
to
group
those
anyway.
I
have
to
go
to
the
different
things,
so
maybe
within
a
single
service
having
to
give
up
that
particular
grouping
is,
is
a
worthwhile
in
terms
of
avoiding
some
of
the
other
issues.
He
said.
H
In
favor
of
just
a
name
hint,
you
know
what
was
the
thing
you
were
proposing.
Basically,
just
drop
in
device.
I
got
from
this,
and
and
I
was
using
different
names
like
Kent.
Just
yeah,
maybe
alleviate
other
fears,
but
but
really
just
taking
the
device
idea
in
the
grouping.
Out
of
it
might
be
a
way
to
accomplish
more
or
less
the
same
usability
functionality
with
one
small
loss
and
maybe
getting
rid
of
a
lot
of
the
concerns
around
privacy.
Yeah.
F
Just
what
one
bit
of
feedback
on
that,
the
only
things
I
guess,
I
sort
of
see
that
users
mostly
visualize
their
their
equipment
as
devices
not
as
like
YouTube
on
my
Roku
and
like
play
music
on
my
Roku
I.
Think
the
mental
model
is
more
like
hey
I'm,
like
you
know,
I
don't
want
my
Roku
anymore.
Here
it
is
Brian.
F
You
take
it,
but
I
better
go
in
and
like
to
leave
my
account
from
it
and
I
think
I
think
that
Mandal
model
does
suited,
but
yeah
I
agree,
you're,
saying
it's
a
trade-off
and
maybe
it's
just
not
worth
with
a
cost
to
say
just
yeah
absolutely
well.
Maybe
we
should
consider
that,
with
with
the
with
also.
M
F
N
I
J
E
F
Are
no
more
new
changes
to
propose
so
just
to
go
over
to
run
encode
did
an
update.
Google's
a
s
is
actually
now
a
hundred
percent
spec
compliant
with
the
zero
six
version.
Three
we
had.
There
was
like
one
difference
since
IETF,
98
and
I.
Don't
think
we
invalidate
that
today,
so,
let's
hope
not
miter,
ID
I
believe
1.3
should
be
released.
Now,
since
it
was
that's,
we
get
released
in
Chicago,
that's
another
and
this
one's
an
open
source
implementation.
On
the
server
side,
we
have
also
an
open
source
client
implementation.
F
F
H
All
right,
Oh
token
exchange
been
out
there
for
a
while,
in
fact,
I
think
it
was
the
last
time
in
Prague
that
I
came,
but
it
heads
with
Mike
a
little
bit
of
trying
to
reverse
the
direction
of
this,
and
we
came
to
some
compromises
to
move
forward
which
which
were
done
shortly
thereafter,
and
that
was
about
two
years
ago,
so
yeah.
Here
we
are
that's
a
picture
from
last
time,
we're
in
Prague
next
slide.
Please
so
I
try
to
give
a
little
bit
of
context,
even
though
it's
been
around
for
a
long
time.
H
Just
for
people
aren't
totally
familiar
with
it
a
reminder-
and
this
is
a
slide
of
one
specific
use
case-
that's
available
with
token
exchange.
Token
exchange
is
an
extension
to
OAuth
that
allows
for
basically
arbitrary
exchange
of
tokens.
Some
client
doesn't
matter
who
it
is,
how
the
token
needs
to
get
a
different
token
for
some
other
context
of
use
and
token
exchange
is
just
a
framework
to
facilitate
that.
H
One
particular
use
case
that
we
hear
a
lot
is
a
client
in
sub-zero
obtains
a
regular
old
auth
token,
through
whatever
flow
device
flow
authorization
code,
though
it
doesn't
matter,
it
gets
won
through
a
normal
offload.
It
has
it
and
it
sends
it
in
step.
1
the
resource
server
through
a
normal.
You
know,
RFC
6750
request
would
be
the
resource
server
received
that,
but
it
needs
to
get
a
new
token,
with
similar
content
suitable
for
a
back-end
service
that
it
has.
So
it
does
in
steps
2,
&
3.
H
It
does
a
token
exchange
here,
Sansa
token
up
to
the
authorization
server
in
exchange
for
it
for
a
different
token
that
is
suitable
to
send
to
the
back-end
server
and
then
passes
that
along
just
as
an
authorization
token
as
well.
This
isn't
the
only
use
case,
but
it's
one.
That's
that's
enabled
by
it
by
this
protocol
and
is
pretty
common.
So
these
these
two
spec
encompass
senator
kokkonen,
get
it
took
them
back
now,
there's
some
other
concepts
in
there.
H
H
A
H
To
give
a
little
bit
of
context,
because
the
next
slide
doesn't
have
a
lot
of
context,
just
the
status
update,
so
draft
9
of
this
was
published
earlier
in
July,
with
pretty
small
changes
which
were
addressing
working
group
last
call
feedback
and
I
do
highlight
here
that
these
were
addressing.
What
I
feel
like
are
actionable
and
meaningful
working
group
last
call
feedback.
H
There
was
one
set
of
comments
from
someone
that
has
made
a
lot
of
other
comments
on
this,
and
other
specifications
that
are
are
not
necessarily
meaningful
or
actionable
and
I've
addressed
them
to
the
best
extent
that
I
can
but
I.
Don't
think
that
there's
anything
additional
that
can
be
done,
I
don't
think
he
represents
any
sort
of
consensus,
opinion
and
I
further.
B
H
Language
etc,
attitude.
It's
certainly
possible
just
for
what
it's
worth
he's
been
active
in
a
number
of
other
groups
which
consistent
behavior,
but
the
things
that
we
have
changed
based
on
that
changed.
One
word
from
a
non
normative
can
to
may
just
to
try
to
clarify
things
that
was
actually
a
result
of
his
feedback
added
a
statement
clarifying
that
the
validity
of
the
subject,
token
or
actor
token.
H
H
Actually
I
stole
some
wording
from
from
ws-trust
to
sort
of
be
all
encompassing
about
the
privacy
considerations
of
this
use,
because
it's
very
difficult
to
cover
them
all,
but
I
wanted
to
address
some
feedback
that
those
were
missing
and
and
provide
a
little
bit
of
a
little
bit
of
guidance
or
at
least
awareness
of
the
privacy
considerations
involved.
So
those
are
the
changes
that
have
been
made,
they're
all
relatively
minor,
as
I
said
so
yeah
next
steps
next
up
series,
I'm
pending
your
review
of
the
other
feedback
and
discussions
with
with
people.
H
I'm
not
exactly
sure
what
I
meant
by
it,
but
it
feels
a
little
bit
like
the
state
of
this
draft
sort
of
like
waiting
and
boredom,
but
with
some
sort
of
impending
danger
of
this
giant
snake
around
his
neck
at
the
same
time.
But
it
was
probably
lated
I
like
photos,
and
so
you
can.
You
can
interpret
that
how
you
will.
B
H
All
right,
the
other,
the
other
presentation
I
have
today
has
a
very
similar
title
and
I
get
confused
typing
in
URLs
and
end
up
with
the
wrong
one
all
the
time,
but
this
is
off
to
two
combining
we
have
another
photograph
from
Prague
the
last
time
we
were
here
because
that's
what
I
want
to
do
so
try
to
set
a
little
context
here
without
getting
too
deep
into
it.
This
this
draft
is
intended
to
provide
an
OAuth
to
you
proof
of
possession
mechanism.
H
We
talked
a
lot
about
the
value
of
proof
of
possession
on
Monday
I,
believe
it
was
in
terms
of
what
what
that
can
bring
you
in
terms
of
preventing
issues
with
lost
or
stolen
access
tokens.
So
this
is
a
one
mechanism
to
provide
that
proof
of
possession
and
defeat.
You
know,
play
or
replay
inadvertent
play
by
the
wrong
party
of
lost
or
stolen
tokens
and
OAuth
context,
and
that
that
includes
access,
tokens,
refresh
tokens
and
authorization
codes.
H
Next,
please
so
current
status
here,
jumping
out
of
the
context
into
the
weeds
on
the
token
binding
working
group
documents,
there's
three
of
them:
GLS
negotiation,
the
protocol
itself,
the
message
format
and
how
it
all
applies
to
HTTP
are
all
very,
very
close
to
being
submitted
to
the
ISP
for
publication.
As
my
understanding
is
that
they're
waiting
for
the
working
group
chair
go
ahead
and
or
the
Shepherd
right
off.
If
any
of
you
know
the
chairs
of
that
work,
I
can't
quite
recall
who
they
are.
H
Any
way
they
are
in
a
relative,
relatively
good
state
and
and
very
very
close.
So
that's
good
in
this
draft
that
token
Bonnie
draft
four
of
that
was
published
also
early
in
July,
apparently
I
did
it.
On
the
same
day,
there's
some
very
minor
editorial
fixes
more
clearly
defined
how
to
convey
the
token
binding
information
of
an
access
token.
In
an
oauth2
token,
introspection
response.
H
So
this
just
just
calls
them
out
very
explicitly
and
as
a
part
of
all
this,
there
is
now
an
introspection
request,
introspection
response,
parameter,
request
registration
to
ion
are
being
made
in
the
OAuth
M
TLS
specification,
which
sort
of
broadly
encompasses
all
of
this
and
is
applicable
here
because
we're
using
the
confirmation
method
as
well.
My
expectation
is
that
that
document
will
progress
more
quickly
than
this
document.
H
I'll
talk
a
little
bit
about
that
on
the
next
slide,
so
getting
into
open
issues
in
the
document
I'm
defined
the
conventional
wisdom
here
about
having
a
lot
of
text
on
a
slide,
mostly
because
I
wasn't
sure
how
to
narrow
all
this
stuff
down
to
a
slide,
and
it's
meant
more
for
me
too.
As
a
reminder
of
what
to
talk
about,
you
get
a
picture
excellent.
H
So
one
of
the
open
questions
has
been
there
from
the
beginning
is
what
should
we
do
in
the
case
that
a
refresh
request
for
a
token
bound
access,
token
is
received,
but
the
Refresh
token
itself
was
not
token
bound.
That's
a
it's
a
fair
question.
It
leads
into
the
next
question
if
I
won't
read
the
whole
thing,
but
it's
about
web
server
clients
so
tow
combining
at
its
core
is
developed
for
use
cases
where
there
are
many.
H
Many
many
different
clients,
web
browsers
native
applications
on
phones
and
it's
a
nice
way
to
sort
of
dynamically,
create
additional
trust
and
bind
tokens
from
those
individual
devices.
When
it's
brought
into
the
OAuth
fold,
there
are
different
kinds
of
clients
and
one
of
those
clients
is
is
potentially
a
web
server.
H
H
H
Think,
that's
probably
the
the
most
straightforward
solution.
It's
easily
implementable,
easily
understood
the
metadata
parameters
already
largely
exists,
so
I
think
it
would
be
just
some
some
wording
around
their
usage
and
some
normative
language
about
Bom
right
now,
they're
just
sort
of
suggested
of
and
indicated,
and
they
could
be
enhanced
a
little
bit
to
say
in
these.
In
this
case
we're
you
know
this
indication
is
false.
The
authorization
server
should
not
took
combined
refresh
tokens
getting
back
to
the
rebinding.
H
The
refresh
tokens
to
just
sort
of
further
complicate
the
one
of
the
main
problems
is
the
only
way
to
request
token
by
an
access.
Token
is
through
the
presentation
of
the
sec
token
binding
header
after
negotiating
token
binding
and
including
a
referred
token
binding
in
that
and
the
only
in
in
order
to
do
that
by
definition
aspect,
you
also
have
to
provide
a
provided
token
binding.
So
there's
no
way
to
make
that
request
without
providing
the
data.
H
H
H
Allow
would
be
to
allow
for
some
sort
of
parameter
on
the
token
endpoint
request
for
the
client
to
express
the
token
binding
ID
that
it
would
like
the
access
tokens
to
be
bound
to
it
could
do
that
without
negotiating
token
binding
without
providing
the
provider
token
binding,
which
would
then
mean
that
the
the
authorization
server
would
have
no
way
to
bind
the
Refresh
token,
but
it
would
have
data
sufficient
to
find
the
access
tokens.
I
was
I
was
kind
of
liking.
N
N
If
it's
a
server,
we
could
direct
people
to
use
a
sign
jot
or
or
other
stronger
mechanism,
so
they're,
not
passive,
using
HTTP
basic
and
passing
them.
The
that,
on
the
on
the
line,
so
I
think
we
can
give
good
advice
about
using
mutual
TLS
sign,
jots,
etc.
In
combination
with
token
binding
for
the
for
the
access
tokens,
I
think
we
still
need
to
have
a
just
a
discussion
point
on
whether
or
not
in
these
clustered
environments.
It's
actually
reasonable.
That
the
token
binding
API
that's
provided
can
get
the
refer
token
binding
from
another
node.
N
N
L
F
E
F
Probably
falls
in
the
category
of
hey,
you
really
should
token
buying
the
Refresh
tokens,
yes
and
secondly,
I
guess
like
I,
do
we
want
Iran
to
be
using
two
combining
for
OAuth
eventually
so,
ideally
yeah
I
guess
the
only
risk
I
would
see
is
like
you
know.
If
we
all
have
too
many
people
to
opt-out
of
too
many
things
and
then
I
just
like
it's
too
hot
I,
don't
implement
it.
F
H
I
hadn't
thought
about
it
so
much
in
in
that
context,
more
the
other
side
of
it
that
I
felt
like
not
providing
this
opt-out
would
de
facto
mean
that
people
won't
be
able
to
enter
a
minute
so
but
I
think
some.
There
may
be
some
guidance
or
wording
around
this
that
that
helps
address
or
alleviate
those
rights
issues
like.
F
For
example,
could
you
see
a
world
where
refreshed
recombining
like
potentially,
where
refresh
token
binding,
is
optional,
but
access
to
combining
could
be
compulsory
like
for
a
particular
ization,
Center
and
I'm,
saying
like
in
five
years,
but
like
yeah?
Is
that
a
post
like
from
from
DS
design,
yeah
I,
think
so.
N
John
Bradley
again,
so
we
do
have
the
mutual
TLS
option
and
in
some
cases
mutual
TLS
for
access
tokens
might
better
fit
somebody's
deployment
use
case,
I
wouldn't
say,
maybe
mandatory
proof
of
possession
access
tokens.
There
may
be
more
than
one
mechanism
for
doing
that.
He
did
say
in
in
the
context
of
a
particular
authorization.
Server
might
very
well
well,
but
even
in
particular,
authorization
server
might
might,
but.
N
We
don't
want
to
be
overly
prescriptive,
but
I
mean
the
concern.
I.
Think
at
the
moment
is
the
only
way
for
somebody
to
turn
off
being
broken
because
they
have
a
cluster
and
by
default,
the
Refresh
tokens
are
being
token
bound
would
be
to
disable
token
binding
on
their
calls
to
the
to
the
token
endpoint
which
mean
that
they
can't
do
access
tokens,
talk
them
down
to
access
tokens,
so
this
at
least
allows
somebody
to
have
that
to
be
able
to
do
talk
about
access
tokens
without
without
token
binding.
The
Refresh
token
correct.
F
William
Dennis,
just
to
clarify
I,
wasn't
saying
that
we
should
be
prescriptive
in
that
sense,
but
just
that
a
particular
authorization
server
itself
could
say
for
us
access
token
token.
Money
is
mandatory
still
even
with
this
sort
of
real
like
say,
even
if
they
implement
these
minute
of
it,
yeah
I
think
so.
H
All
right
great
next
one,
it's
a
little
better,
a
couple,
more
openness,
open
issues.
One
is
a
question
of
whether
the
scope
of
this
document
should
include
some
kind
of
standardization
or
at
least
guidance
on
using
token
binding,
with
client,
authentication
and
or
authorization
from
yeah.
The
75
23,
which
is
the
client,
authentication
and
authorization
draft
in
in
some
ways.
I
feel
like
this
is
easily
inferred
from
the
existence
of
the
confirmation
claim
how
it's
used
and
would
be
using
this.
You
know
in
this
context.
H
N
H
Not
again
not
real,
controversial
yeah,
looking
forward
to
see
it
there,
okay,
yeah
and
then
this
was
this
is
all
sort
of
related,
but
the
metadata
needs
some
work.
The
main
problem,
I,
think,
is
that
there's
a
reference
to
the
OAuth
to
protected
resource
metadata,
which
is
not
a
ongoing
draft,
so
we've
got
a
kind
of
a
hanging
dead
reference
I
think
it
needs
to
be
removed
and
some
some
clarity
about
what
canon
cannot
actually
be
inferred
at
runtime
from
the
metadata
values
and
what
can
be
enforced
should
be
added
there.
H
This
has
been
sort
of
an
ongoing
reminder
to
myself
that
it
exists
as
well
as
a
hope
that
mike
the
look,
the
original
text
would
go
back
and
fix
it.
Although
we
we
chat
a
little
bit
about
this
yesterday
and
in
the
context
of
a
similar
problem
with
the
open
ID
connect
layer,
so
combining
spec
that
has
similar
issues
and
I
believe
I
believe
I
have
some
ideas,
basically
about
a
roadmap
about
how
to
how
to
keep
the
same
intent,
remove
the
hanging
reference
and
clarify
the
text
in
a
meaningful
way.
H
B
H
That
particular
metadata
field
are
gonna,
go
away,
and
there
will
be
the
text
around
what's
currently
there
of
detecting
attacks.
What
to
do
in
cases
where
bound
tokens
are
expected,
but
not
received
we'll
be
just
reworded
to
clarify
what
what
what
is
and
isn't
possible
and
perhaps
provide
some
guidance
on
what
to
do.
H
Alright
next
slide,
please
so
just
looking
ahead.
Hopefully
the
the
core
underlying
token
binding
documents
progressed
RFC
here
pretty
soon
I
know.
Andre
is
looking
forward
to
that.
Not
even
though
he's
not
listening
right
now,
work
through
these
open
issues,
I
think
I've
a
way
forward
for
a
lot
of
them.
So
that's
good.
We
definitely
need
implementation,
experience
and
feedback
here.
There's
there's
growing
implementation
experience
in
tow
combining
in
general,
but
most
of
the
client-side
implementation
is
currently
in
the
browser.
H
So
we
haven't
seen
like
client-side
widely
available
libraries,
yet
server
sides
also
questionable,
but
coming
along.
So
this
is
still
early.
I
think
there's
a
lot
of
room
to
learn
and
work
from
there,
but
it's
progress
and
then
get
the
band
back
together,
again:
I
100
and
in
Singapore
and
here's
a
John
Belushi
impersonator,
just
just
to
help
you
get
the
band
back
together
or
get
in
the
mood
for.
M
H
Would
view
that,
as
out
of
scope
for
this
document,
because
it
prescribes
how
it's
done
with
OAuth,
there
is
a
document
that
was
just
accepted
as
a
working
group
item.
In
the
token
binding
working
group
that
describes
how
to
convey
the
information
from
the
TLS
terminating
layer
as
a
reverse
proxy
convey
the
token
binding
information
that
was
verified
to
any
applications
in
the
backend
which
would
allow
them
to
to
do
what's
implied
by
the
the
auth
layer.
M
Which
is
trust
in
the
TLS
layer
around
what
doing
yes
right
yep
so
that
doesn't
provide
the
same
security
characteristics
of
other
proof
of
possession
mechanisms
that
go
from
client
directly
to
the
application?
That's
correct!
So
is
there
not
interested
in
doing
I,
mean
I,
consider
it
an
OAuth
problem.
It's
a
proof
of
possession
type
token
we're
trying
to
go
and
add
proof
of
possession
in
200
auth
to
flow
of
witches.
M
H
M
H
And
just
from
a
technical
perspective,
I,
it's
I,
don't
know
of
a
way
to
do
it.
That
is
tightly
bound
because
it's
it's
bound
to
the
TLS
connection
between
the
client
and
that
TLS
termination,
so
everything
how
it
happens
behind
that
is
simply
moving
signals,
but
not
not
something
tighter
than
that
and
if
there's
a
practical
but.
M
Wait
the
verifications
happening
at
the
application
layer,
that's
correct,
and
so,
if
the
GLS
proxy
doesn't
know
the
currently
the
tokens
opaque
I
mean
not
okay,
if
it's
visible
and
so
I
think
the
Microsoft
solution
was
they're
encrypting
the
token.
So
then
the
proxy
wasn't
able
to
go
and
see
what
was
the
ekm.
In
the
token.
M
M
M
M
H
M
So
for
anybody
running
in
AWS,
right,
they're
having
to
trust
the
terminator,
if
they're
sitting
behind
it,
yeah-
which
they
do
now
on
lots
of
our
deployments,
don't,
but
they
give
it
their
private
key.
What's
that,
but
they
provide
it
with
their
private
key
right.
Well,
they
trust
them.
They
trust
the
TLS
terminated
to
manage
TLS,
but
they
don't
trust
the
Terminator
to
manage
the
token
or
manage
the
authentication
authorization.
M
So
so
in
AWS,
you
know,
API
calls
that
don't
see
before
which
gives
you
an
and
proof
of
possession,
okay,
which
you
know,
transit,
fine
through
a
TLS
proxy,
and
so
ideally,
we
would
like
to
use
something
was
more
standard,
but
it
doesn't
have
that
the
token
binding
and
access
token
look.
What
you're
proposing
doesn't
solve
our
problem
and
give
us
similar
security
characteristics
around
what
we
already
have
a
ciggy
for:
okay,
I'm,
not.
H
M
H
H
N
So
there
John,
Bradley
yubico,
so
I
did
attempt
to
extract
the
information
from
the
devil
the
other
day
about
what
Microsoft
is
doing
for
office
365
native
apps,
and
there
is
some
notion
that
there
is
an
additional
token
binding
ID,
which
is
added
to
the
token
binding
header
which
he's
generated
by
the
native
app
that
is
signing
over
some
piece
of
material,
which
is
the
goat.
She
aided
from
the
thing
behind
the
proxy
to
the
app
itself
and
I,
asked
the
devil
to
have.
N
His
minions,
provide
us
with
said
information,
but
it
is
potentially
a
chip.
It's
not
something
that
would
work
front
with
a
with
browsers
as
deployed.
It
may
be
something
that's
secretly
in
Microsoft's
library,
I,
don't
know.
Since
he's.
Looking
he's
looking
at
you're,
looking
at
me
like
like
I'm,
crazy,
which
is
probably
because
the
devil
is
full
of
lies,
so.
E
L
H
Q
Under
a
pop
of
Microsoft,
trying
to
speak
of
the
devil
or
and
a
half
so
I'm
not
not
entirely
familiar
with
what
was
just
sad
right
so,
like
I
know
what
the
implementation
of
token
binding
looks
like
in
Windows
is
I
worked
in
bad,
it's
just
an
implementation
of
the
standard
where
we
build
messages
where
we're
allowed
the
caller
to
specify
what
type
of
binding
they
want
to
do.
So,
basically,
that's
what
we
have
you
know
on
top
of
that,
how
a
specific
system
uses
that
I,
don't
really
know
you
know.
Q
It's
can't
comment
on
that.
I
would
be
surprised
if
there
was
a
solution
that
provided
the
end-to-end
token
binding
validation
of
the
type
that
was
just
discussed,
because
that
doesn't
make
a
lot
of
sense
to
me.
If
you
are,
if
you're
terminating
TLS
at
the
TLS
terminator.
That's
where
end-to-end
ends,
you
see
what
I
mean
the
terminator.
If
you
don't
trust
your
TLS
terminator,
you
know
it
can
inject
requests.
You
can,
you
know,
do
all
sorts
of
bad
things.
You
know
you
can.
Q
You
can
have
an
architecture
where
the
backend
server
actually
verifies
it
or
combining
by
having
the
TLS
Terminator
pass.
The
ETM
and
the
you
know
token
binding
message
to
the
backend,
but
it's
still
not
really,
you
know
and
to
enter
the
application,
because,
again,
you're
still
trusting
that
your
TLS
Terminator
is
passing
the
correct
information
to
you.
So
I'm.
B
Yes,
you
all
know
we
ran
into
some
issues
with
the
HTTP
signing,
but
and
people
have
entertained
other
ideas,
and
maybe
maybe
there's
there
different
layers
on
what
some
of
the
deployments
want
to
provide
in
terms
of
security
guarantees,
but
I
think
it's
definitely
in
scope
of
our
work.
We
just
have
to
come
up
with
ideas
on
how
to
best
solve
it
and
that
had
had
been
a
problem
in
the
past.
We
didn't
make
sort
of
rock-solid
decisions
and
then
move
that
forward.
H
R
M
Jacquard
Amazon,
we
have
a
what
I
would
consider
a
proprietary
mechanism
that
we
call
sig
v4,
which
is
how
API
calls
a
need
of
us
are
made,
and
so
that
works,
but
it's
non-standard,
so
we
would
prefer
I
would
prefer
moving
to
a
more
standard
model
that
worked
across
the
internet
as
opposed
to
us
having
a
model
that
works
really
well
for
us.
But.
M
M
B
G
At
the
when
I
was
writing
the
initial
HTTP
signing
thing.
I
did
look
at
the
AWS
solution
and
a
few
others
there's
a
I
believe
it's
cabbage
or
carriage
I
forget
his
last
name.
There's
another
specification
out
there
and
one
of
the
issues
with
a
lot
of
those
is
that
they
presume
that
the
HTTP
message
itself
doesn't
get
transformed,
and
that
was
a
problem
that
I
personally
ran
into
a
lot
of
with
OAuth
1
implementations,
with
parameters
getting
reordered
and
added
and
stuff
like
that.
So
that's
why
my
my
version
differs.
G
You
know
as
as
presented
and
do
your
signature
on
that
on
both
ends
and
my
understanding
with
the
AWS
side
is
that
there's
there's
just
a
lot
tighter
control
over.
You
know
where
you
get
access
to
at
the
application
layer,
the
HTTP
bits
and
so
yeah
I'm.
Definitely
I
was
aware
of
that.
It
is
related
in
the
sense
that
they
are
solving
a
lot
of
the
same
problems
in
similar
ways,
but
there
are
some
different
considerations
in
play.
B
But
I
hear
that
we
sort
of
have
an
action
item
for
Dicky
to
look
at
the
current,
actually
HTTP
signing
working
group
document
which
I
believe
it's
expired.
That's
why
you
you
couldn't
find
it
under
on
the
page
data
tracker
page,
so
I
think
that
would
be
a
useful
step
and
figure
out
whether
that's
actually
solves
the
issue
that
you're
having.
How
does
that
sound.
G
G
M
Well,
that's
the
feature
that
I
like
about
finding.
Is
it
you're
not
having
to
do
client
management
of
a
key
right?
So
that's
that's
one
of
the
downsides
of
sig
before
is
that
you're
having
to
go
and
manage
a
secret
over
with
the
client
token
binding
enables
you
to
get
many
of
the
characteristics
of
proof
of
possession
without
actually
having
to
do
key
management
and
the
client
about?
B
Okay,
I
wonder
like
what
would
be
a
reasonable
next
step
on
that
issue
is
not
it's
not
totally
obvious
to
me,
but
maybe
you
can
still
have
a
look
at
the
document
and
see,
but
you
you'd
be
big
because
you
want
you
want
to
you
want
o
confining.
You
don't
want
to
have
it
at
the
epic
public
up
to
the
application
you
don't
want
to.
You
want
to
have
a
standardized.
You
don't
want
to
have
to
manage
keys
in
the
client,
so.
H
M
I,
don't
know
whether
it's
possible,
but
I
mean
we.
We
were
we
like
the
idea
of
token
binding
right,
but,
and
we
like
the
idea
around
not
having
to
do
management
around
distribution
of
keys.
We
have
a
mechanism
that
works
now.
That
gives
us
a
lot
of
very
powerful
characteristics
that
enabled
our
customers
not
to
be
worried
when
there
was
compromises
on
the
TLS
staff,
so
we're
reluctant
to
not
continue
to
have
that,
and
you
know
so
I'm
just
phrasing
that
you
know
we're
interested
in
solution
like
that.