►
From YouTube: IETF101-OAUTH-20180319-1550
Description
OAUTH meeting session at IETF101
2018/03/19 1550
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
D
E
H
I
B
H
B
K
L
L
M
B
F
H
L
L
L
Okay,
let's
say
talk
about
status
here,
I'm,
so
device
slow
a.
We
will
talk
about
that
later
today
in
discovery.
Yeah
Michael
talk
about
that
a
the
jot
a
I
think
we
had
some
may
open
issues,
a
I
think
that
sent
a
an
email
response
and
closing
those
questions
so
I
occurred.
Do
you
think
we're
we're
done
with
that
or
satisfied
with
the.
O
O
J
L
You,
okay,
BCP,
will
drop
BCP,
we'll
talk
about
this
later.
Until
s
same
thing,
security
topic
and
talking
binding.
All
of
those
will
be
discussed
later.
Okay,
so,
let's
just
quickly
update
on
in
the
interim
meetings.
So
we
we
had
to
inter
meetings
to
discuss,
distributed,
earth
and
reciprocal
auth,
it
used
to
be
called
module
off,
M
distribute
earth
will
be
discussed
later,
a
Wednesday
and
they
for
with
regard
to
reciprocal
off
a
we
discussed,
this
would
occur
and
they
we
have
an
approval
to
move
forward
with
this.
I
So
we
had
an
hour
the
latest,
our
security
workshop
last
week
in
Trento.
Here's
a
picture
from
that
wonderful
place
there
we
had
there's
a
separate
workshop
webpage
and
I,
encourage
you
to
look
at
the
program
which
links
the
slides
as
well
as
position
papers
that
had
been
submitted
to
that
workshop.
I
We
covered
a
number
of
different
topics
like
in
the
previous
workshops.
We
talked
about
formal
methods
we
had
researchers
coming
along,
who
did
form
an
analysis,
shared
exp
experience.
We
talked
about
regulatory
activities
that
impact
o
us.
There
was
a
Dawson
spoke,
for
example,
about
the
financial
ABI
in
the
work
on
the
PSD
to
the
ideas
we
had
deployment
experience
related
talks,
new
ideas
also
Mike,
for
example,
did
absorb
presentation
on
log
of
or
log
out.
I
We
also
had
a
crypto
related
presentations,
so
overall
I
think
it
was
very
interesting
for
me
was
why
that
we
did
this
workshop
and
it's
a
good
to
get
the
researchers
into
the
same
room
as
standards.
People
to
have
an
exchange
and
I
was
advocating
for
them
an
increased
use
of
formal
methods
in
IDF
security
protocols
as
well
and
played
around
it.
Myself
or
one
of
the
hours
variants.
L
Okay
they're
on
the
agenda,
so
we
have
Brian
at
the
beginning
to
talk
about
MPLS
and
token
binding.
We
have
the
Torsten
to
talk
about
security.
Dennis
had
few
three
topics
to
talk
about
here
so
and
we're
hoping.
If
we
have
a
then
we
have
some
time.
Five
minutes
will
allow
Justin
to
talk
about
the
HTTP
signing,
if
not
we'll,
we'll
talk
about
that
on
Wednesday,
okay,
so
I'm
brian.
D
Q
Q
Be
sure
to
read
from
thank
you
that
is
London
from
some
years
ago
and
we
are
in
London.
Yeah
does
photos
in
here,
but
yeah,
let's
get
started
so
just
want
to
give
a
little
bit
of
context
since
I
know
everybody
reads
every
single
draft
before
they
come
in
here
when
I
give
it
a
little
bit
over
you
that
for
someone
that
maybe
hasn't
so
what
is
the
mpls
draft?
It's
two
things.
Two
primary
things.
Q
One
is
doing
mutual
TLS
client
authentication,
both
client
authentication
to
the
authorization
server
and
we've
got
two
main
methods
of
doing
this.
One
is
PK
I,
based
where
you
check
the
certificate
at
the
end.
Up
to
the
you
know,
to
a
change
route
and
the
other
is
a
self
sign
method
and
then
there's
also
a
mutual
TLS
sender
constrain
access
tokens
for
protected
resource
access.
Another
way
to
think
about
that
is
just
these
are
certificate
bound
access
tokens
side.
Q
So
why?
Why
are
we
working
on
this
mutual
TLS,
auth
client
authentication,
which
is
something
that
obviously
provides
better
security
characteristics
than
the
shared
secrets
in
the
normal
Oh
F
is
something
that's
been
done
in
practice
for
OAuth
from
a
lot
of
vendors
and
implementations
for
quite
a
while.
We've
never
actually
had
a
standard
to
support
it.
Mutual
TLS
sender,
constrained
resource
access
is
something
that
binds
access
tokens
to
the
client
certificate,
so
they
can't
be
played
or
replayed
by
any
other
entity
without
the
private
key.
Q
They
want
stronger
forms
of
security,
but
they
won't
also
be
able
to
use
OAuth,
and
this
draft,
even
in
its
draft
form,
is
currently
referenced
by
the
Open
ID
Foundation's
financial
API
working
group
fappy
in
their
reading
API
security
profile,
which
is
a
higher
sort
of
higher
security
profile
around
off,
as
well
as
being
referenced
in
the
UK
open
banking
API
security
profile.
So,
despite
being
a
draft
they're
already
being
referenced,
sorry,
you
can
jump
ahead.
Q
Ok,
so
how
does
this
actually
work?
The
mutual
TOS
client
authentication
is
obviously
to
the
authorization
server,
typically,
the
token
endpoint,
but
also
any
other
endpoint
at
the
authorization
server
that
might
require
fine
authentication
works.
The
same
way.
The
client,
let's
see
the
TLS
connection,
that
the
HT
request
is
made
over
is
established
with
mutual
TLS
client
certificate
authentication.
P
Q
There's
this
TLS
client
off
subject
the
end
which
specifies
the
expected
subject:
distinguished
name
of
the
client
certificate
and
then
there's
metadata,
also
supporting
the
self-signed
certificate
method
and
that's
an
authentication
method,
name,
unsurprisingly,
of
self
santi,
less
client
off
and
then
the
existing
Jenny
bouquet
S&J
DB
case
URI.
Really
an
or
metadata
parameters
can
be
used
to
carry
the
client
keys
and
certificates
or
hold
them.
And
just
maybe
it's
not
clear.
But
the
difference
between
those
two
methods
is
that
in
the
former
the
PKI
method,
the
client
presents
a
certificate.
The
authorization
server.
Q
Q
Okay.
So
how
does
mutual
TLS
sender
constrain
access
work
it's
hard
to
find
a
right
name
for
this
because
token
binding
kind
of
means
a
something
else
entirely
as
tourists
in
this
you
mentioned
to
me
a
few
times
or
misstated,
but
basically
this
is
binding.
The
access
token
to
a
client
certificate,
so
either
sender
constrain
access,
which
I
think
was
a
term
nak
came
up
with
or
certificate
bound
access
tokens.
The
wording
is
kind
of
used
a
little
bit
interchangeably
in
the
draft,
hopefully
in
a
clear
way.
Q
So
on
issuance
of
an
access
token,
the
authorization
server
associates
a
hash
of
the
certificate
with
or
into
the
access
token,
thus
binding.
The
access
token
to
the
certificate.
The
TLS
connection
from
the
client
to
the
actual
protected
resource
is
over
mutually
authenticated.
Tls
and
the
protected
resource
matches
the
certificate
obtained
from
the
TLS
layer
to
the
certificate,
hash
and
the
access
token,
and
obviously,
if
they
don't
match
it's
rejected.
If
they
do,
then
in
proof
of
the
corresponding
private
keys
have
been
proven
and
this
token
bound
or
certificate
bound
access.
Q
Token
has
been
used
successfully
in
order
to
carry
this
information
in
jot.
We've
got
a
new
confirmation
method,
which
is
the
x.509
certificate,
sha-256
thumbprint
confirmation
method,
x5t,
pound
s2,
five
six.
This
just
carries
the
sha-256
hash
the
certificate
itself
and
then
there's
a
confirmation
method
also
for
token
introspection.
That's
exactly
the
same,
looks
the
same
same
name
same
same
semantics:
it's
just
conveyed.
Q
In
the
token
token,
introspection
response,
rather
than
its
jot
itself
and
one
I
think
benefit
or
maybe
not
obvious
side
of
this-
is
that
the
the
token
binding
piece
of
it
that
binds
it
to
their
certificate.
It
doesn't
vary
based
on
the
client
authentication
method,
so
the
actual
access
token
is
bound
to
the
raw
certificate
itself,
and
the
resource
or
protected
resource
doesn't
have
to
have
any
knowledge
of
how
the
actual
client
authenticated
the
server.
Q
Q
I'm,
not
sure
how
I
got
those
out
of
order
in
the
first
place,
but
it
looked
really
weird
in
the
document.
Most
people
stopped
reading
when
they
get
to
IANA
and
the
security
considerations
here
are
actually
pretty
important,
so
it
ought
to
be
better
for
it
to
be
with
the
rest
of
the
text,
I
talked
a
little
bit
more
about
certificate.
Access
certificate
bound.
Excuse
me,
access
tokens
in
the
abstract.
That
part
was
not
not
really
conveyed
in
the
access
in
the
abstract.
Q
Very
much
I
thought
to
be
worthwhile
to
to
spell
that
out
more
so
someone
reading
the
beginning
of
the
document
could
know.
There's
sort
of
two
main
components
to
the
document
itself
did
something
similar
to
the
title.
I
was
just
called
MPLS
profiles
previously,
which
I
guess
is
accurate,
but
kind
of
meaningless.
Q
So
this
the
new
title
goes
on
to
basically
say
that's
for
client
authentication
and
certificate
bound
access
tokens
added
a
tiny
little
bit
more
text
in
the
security
considerations,
around
certificate,
spoofing
or
preventing
certificate
spoofing
based
on
you
know
a
constrained
set
of
cas
into
the
security
considerations.
I
was
suggested
by
someone
home
at
the
last
meeting.
I
did
add
an
explicit
note,
also
from
the
last
meeting.
Q
This
came
up
that
the
implicit
flow
is
not
supported
for
obtaining
certificate,
bound
access
tokens
and
finally,
added
an
appendix
section
describing
the
relationship
of
this
back
the
MTL
aspect
to
oauth
token
binding.
Since
there's
some
overlap
there
I
tried
to
explain
the
situation
and
why
they
both
exist
and
why
at
least
you
might
consider
one
or
the
other
and
those
are
all
the
changes
so
next
slide.
Q
R
P
G
Richer
I,
actually
don't
object
for
this.
Coming
last
call
you
didn't
give
me
any
other
option.
I
want
to
talk
anyway,
but
no
I
do
think.
This
is
ready
for
last
call
we
actually
just
over
the
last
two
and
a
half
weeks
or
so
have
gone
through
and
implemented
everything
in
this
draft,
so
both
authentication
methods
and
the
sender
constrained
access
tokens.
The
non
bound,
TLS
bound
access
tokens,
whatever
they're
called
right.
We
implemented
all
of
those
in
a
in.
G
S
Yes,
there's
another
implementation,
it's
the
Nimbus
library
and
they
connect
Ont
product.
We
used
it
at
yes
that
come
and
use
it
into
two
ways:
we
use
it
to
actually
secure
all
micro
service
based
architecture
and
for
our
directly
for
the
open,
le
connector
access
for
line
parties.
So
my
perspective,
that's
that's
ready
to
be
used
another
another
note.
S
Q
T
I
Okay,
go
ahead,
no
god!
Yes!
So
so
we
just
had
a
short
discussion.
I
think
we
we
will
start
the
working
group
called
last
coil
today,
even
because
it
will
give
us
a
opportunity
to
hassle
some
of
you
to
actually
do
that
during
this
week,
while
you're
here
next
week,
you
will
be
super
busy
catching
up
if
your
company
internal
work.
I
I
That's
what
we're
asking
for
last
time
so
and
would
obviously
work
with
eka
to
get
this
through
the
process
as
quickly
as
possible,
given
that
what
we
learned
at
the
workshop
that
there
is
a
dependency
from
some
of
the
bank
open
banking
initiatives
that
want
to
use
this
work,
so
definitely
a
new
field
where
OS
is
used
and
and
hasn't
traditionally
been
used.
So
so
we
are
spreading
out.
Oh
us,
in
all
sorts
of
new
domains,
which
is
excellent.
I
I
Q
G
I
A
P
C
C
I
Q
T
Q
I
Q
Is
what
it
is
all
right,
Oh
off
to
youto,
combining
that's
also
London
here
we
are
again
yeah
next
slide.
Please
so
just
want
to
give
a
little
bit
of
an
overview
of
what
tow
combining
is
for
those
of
you
that
may
not
be
familiar
and
having
followed
that
working
group,
it's
something
that
enables
a
long
live
binding
of
cookies
or
other
security
tokens
that
part
the
other
security
tokens
are
the
ones
that
are
interested
into
this
working
group
to
a
client
generated
public/private
key
pair.
Q
The
use
of
token
binding
is
negotiated
in
the
TLS
handshake
with
a
with
an
extension
and
then
assuming
it's
negotiated
on
all
subsequent
HTTP
requests
over
that
thiele
connection.
Possession
of
this
client
generator.
The
key
is
proven
by
signing
the
TLS
exported
key
material,
the
ekm
and
then
sending
that,
along
with
the
public
key,
basically
as
an
HTTP
header
and
every
request,
cookies
and
tokens
can
be
bound
to
that
key
I.
Q
Think
I
said
that
already
and
the
key,
at
least
in
the
web
browsing
case,
the
kiyah
scope
to
the
effective
top-level
domain
plus
one
so
there's
not
a
privacy
issue,
necessarily
at
their
scope,
basically
the
same
way
that
cookies
can
be
scoped,
so
they're
not
set
any
broader.
It's
not
like
a
super
checking
cookie
or
anything,
and
then
this
idea
of
federated
or
cross
domain
use
cases
like
OAuth,
where
the
resource
server
might
be
in
a
different
top-level
domain
than
the
authorization
server
are
supported.
Q
Via
this
thing
called
the
referred
token
binding
versus,
what's
normally
called,
provide
a
token
bonding,
which
is
a
way
for
in
in
that
HP
header,
to
send
actually
two
different
token
monies
to
keys
and
prove
possession
of
them
so
that
the
issue
token
can
be
bound
to
the
other
key
which
will
be
used
for
connections
to
some
other
service
like
the
resource
server.
Next
slide,
please
so
just
really
quickly
in
a
nutshell,
for
context
here.
What
is
this
document?
Q
It's
basically
a
way
to
provide
an
oauth,
2.0
proof
of
possession
mechanism
based
on
the
underlying
technology
of
tow,
combining
that's
the
defeat
you
know,
replay
or
play
of
tokens
by
unauthorized
entities,
including
a
resource
server,
replaying
it
or
a
lost
or
stolen
token
being
played
by
another.
You
know
personated
client.
All
these
things
are
prevented
to
the
extent
that
the
private
keys
are
protected.
Q
I
think
one
of
these
is
already
out
of
date
and
made
a
few,
maybe
just
two
really
minor
editorial
fixes.
So
if
nothing
really
substantial
has
changed
in
the
document,
but
it's
still
there
next
slide
and
so
we're
trying
to
look
ahead.
The
the
underlying
three
token
binding
drafts
should
be
going
to
RFC.
U
O
V
Q
And
then
you
know
beyond
that,
we
really
need
implementation,
experience
and
feedback
on
this
stuff
and
I
think
maybe
just
appreciate
this
stuff
should
be
really
easy.
Once
all
the
really
hard
parts
are
done
and
the
really
hard
parts
are
that
this
token
binding
itself
sort
of
crosses
over
layers
that
aren't
typically
crossed
over
by
your
average
developer.
Q
I
Get
it
and
get
an
idea
where
we
are
Biff
this,
so
you've
been
working
on
an
implementation
and
used.
So
you,
you
have
gained
a
lot
of
experience
in
that
regard,
but,
unlike
many
of
our
other
specifications,
which
had
lots
of
implementations,
also
product
implementations
and
even
deployments,
that
seems
to
be
a
little
bit
on
a
different
level.
Now
I
mike,
are
you
you
guys
have
for
the
Microsoft.
I
I
Q
P
P
Different
implementations
are
implementing
different
draft
numbers
and
therefore
the
one
that's
on
by
default
and
edge
is
not
talking
to
you
know
the
same
services.
That
chrome
is
because
they're
different
numbers-
and
so
once
you
know,
Eric
does-
is
write
up
and
we
have
one,
oh
that
unblocks
a
lot
of
developers
from
feeling
like
this
is
real.
We
will
do
the
library
work.
I
know
that
inside
Microsoft
you
know
some
things
are
happening,
but
some
things
are
waiting
till
we
have
one
out.
S
Hi
Anto
sniper,
vs,
comm
and
I
happen
to
be
the
editor
of
the
security
topics
document
the
security
dope
is
topics
document
is
basically
an
update
to
RFC
6890.
That's
the
security
threat
model
considerations
document
for
off
to
the
dole,
because
we
figured
it
was
time
to
together
and
capture
all
the
all
the
security
threats,
implementation
issues,
security,
relevant
implementation
issues
and
the
lessons
learned
over
the
course
of
the
last
couple
of
years.
S
So
this
is
how
the
document
looks
like
the
majority
of
the
after
sections
describe
different
threats,
implementation
issues
and
give
different
options
how
to
mitigate
on
this
threat.
So,
for
example,
there
isn't
the
innocent
section
on
access
token
or
leakage,
and
there
is
a
comprehensive
discussion.
What
options
exist
from
our
perspective
to
actually
cope
with
this
kind
of
threat
so,
for
example,
send
the
constraint
access
tokens
all
the
instructions
and
so
on,
and
then
in
the
end,
we
distilled
a
section
containing
recommendations
that
we
give
to
implementers.
S
For
example,
in
this
case
regarding
token
leakage,
the
working
group
decided
that
send
the
constraint
access
tokens
either
by
our
token,
binding
or
M
TLS,
would
be
the
way
we
would
recommend,
because
this
is
the
most
reliable
way
to
to
cope
of
this
kind
of
issue
next
slide,
please,
but
we.
Nevertheless,
we
gave
the
whole
discussion,
so
everyone
can
can
can
give
it
a
read
and
and
come
up
with
his
or
her
own
idea,
all
right.
So
this
is
a
selection
of
the
recommendations
we
we
are
giving
to
implementers.
S
S
We
published
a
new
revision,
actually
I
published
a
new
revision
yesterday
and
it's
complete
now
from
our
perspective,
so
we
completed
completely
reworked
the
section
on
code
leakage
and
completed
a
section
on
axis
or
f3
for
headers
and
so
on.
I
decided
to
remove
the
section
on
refresh
token
leakage,
just
because
there
is
nothing
new
to
report
right
so
refresh
token
leakage.
Prevention
is
already
covered
by
the
security
consideration
sections
of
our
C
67
49.
S
No
I
took
the
liberty
to
in
entering
a
distilled
version
of
that,
just
brief
description
of
the
thread
and
a
recommendation
how
to
cope
with
that,
because
the
the
open
redirection
draft
also
gives
additional
threats
that
we
are
already
covered
in
other
sections
of
the
document,
so
I
mean
I
would
hope.
We
will
have
another
review
round
now,
potentially
a
working
to
risk.
Also
people
can
can
check
it
and
give
us
feedback
on
that.
S
What
we
also
did
is
we
removed
all
the
text
around
this
being
a
working
document,
helping
the
the
the
working
group
to
keep
track
of
the
current
status
of
the
discussion
of
the
different
security
open
topics,
because
we
think
we
are
done
for
the
moment.
For
the
moment
I
mean
we
decided
to
make
it
a
PCP
to
be
able
to
update
it
to
update
it
too
frequently
and
I
hope,
I
hope
we
will
do
so
on
not
not
again
wait
for
how
long
five
years,
okay,
yeah
I,
think
so
yeah.
S
H
H
I
I
Five:
six:
seven:
eight!
If
we
wait
a
little
bit
long,
it
probably
that's
pretty
pretty
good
so
I
guess
we
should.
We
should
have
a
few
guys
reviewing
posting
or
doing
the
review
posting
something
to
the
list
before
we
started
working
here
and
following
that
one
and
there's
some
new
stuff
in
there
so
I
do
we
have
some
some
volunteers
to
review
this
document.
Tony,
William,
okay
and
if
not-
and
someone
knows,
Brian
pan-
you
aware
yeah.
P
W
W
W
So
the
classical
example
is
like
a
TV,
a
TV
app
like
the
YouTube
app
and
in
this
flow
the
user
actually
reviews
the
authorization
request
on
a
separate
device
and
they
can
approve
it
there,
like
a
mobile
phone
or
a
laptop,
so
the
TV
or
the
device
would
show
a
screen
just
like
this,
directing
the
user
to
go
to
an
authorization
URL
and
enter
a
code.
The
user
then
loads
up
that
URL
on
their
separate
device,
such
as
their
phone.
W
Typically
types
in
the
code,
approves
the
OAuth
request
and
then
the
device
can
get
its
tokens
there's
one
additional
optimization
which
which
we've
added
in
the
standard,
which
is
to
allow
for
a
QR
code
or
any
kind
of
non-textual
verification
technique.
This
is
presented
separately
to
the
and
of
manual
instructions,
allows
the
user
just
to
scan
the
qr-code
and
then
typically,
they
wouldn't
have
to
actually
enter
the
user
code,
but
they
might
confirm
that
it's
the
same
code
just
to
avoid
kind
of
phishing
risks.
W
W
Those
who
were
there
may
remember
a
discussion
we
were
debating
whether
or
not
to
have
a
kind
of
composed
a
URL
where
we
would
actually
add
the
verification,
URL
and
the
user
code
kind
of
in,
like
a
sort
of
structured
composed
way
that
was
rejected
in
the
end
and
we've
just
adopted
this
simpler
kind
of
option
where
the
authorization
server
can
just
provide
the
complete
verification
year.
All
for
that,
like
QR
code
optimized
option,
we
also
added
some
security
considerations
around
spying
that
was
at
Nats
request.
W
So
that's
just
covering
the
case
where
there
could
be
someone.
You
know
behind
you
watching
all
your
interactions.
You
know
given
this
is
on
a
TV.
They
could
be
like
in
the
back
of
the
room
or
something,
and
we
added
some
text
to
explicitly
require
that
the
device
code
is
actually
not
shown,
as
as
part
of
this,
just
in
case
that
wasn't
clear,
plus
the
text
regarding
the
minimum
poling
intervals.
W
So
we
don't
Dawson,
take
down
Justin's
server
again
and
then
I
just
posted
this
morning,
but
there
was
a
diff
posted
approximately
two
weeks
ago,
just
a
minor
clarification
around
the
entropy
guidelines
for
the
user
code.
So
this
is.
This
is
an
interesting
code
because,
because
it's
actually
part
of
the
user
experience
there,
the
length
is
kind
of
constrained
by
what
what
you
can
reasonably
expect
the
user
to
type
and
the
char
set.
Likewise.
W
So
we
just
added
a
little
bit
of
a
clarification
around
the
trade-offs
there
that
the
authorization
server
needs
to
take
your
account,
and
we
also
document
you
know
the
risks
of
a
low
entropy
code
there.
If
someone
were
to
be
able
to
kind
of
brute
force
that
user
code,
it
kind
of
puts
them
in
this
sort
of
reverse
takeover
situation
where,
like
normally,
if
you
brute
force,
standoff
you'll
gain
access
to
that
grant.
L
O
Yeah
I
guess
I'm
concerned
about
whether
or
not
there's
an
attack
pattern
here
and
so
I
I
guess
after
authors,
so
I
guess
I'm
not
sure
the
best
way
to
resolve
that
now
central
assimilating
John
message
in
the
middle
of
like
listening
to
this.
Do
you
want
to
discuss
it?
Should
we
have
a
side
meeting,
shall
I
read
it
like
tonight
and
come
back
to
you
what
we
must
they
do.
T
V
V
So
if
you
had
a
Roku
device
which
uses
this
kind
of
flow
for
binding
media
subscriptions
to
it,
so
if
Netflix
were
compromised,
ie
their
own
server
had
been
taken
over
by
a
malicious
person
that
server
when
it
receives
the
request
from
the
Roku.
When
the
person
clicks
on
the
Roku
player
clicks
on
the
Netflix
picture
and
the
Roku
would
then
you
start
off
the
flow
to
Netflix.
Netflix
would
then
go
yes,
but
now
I
can
go
to
Amazon
Prime
video
and
get
their
highly
prized
access
token
for
this
user
at
Amazon
Prime.
V
So
it
would
go
and
create
get
the
challenge,
get
the
user
code
etc.
Pass
that
back
to
the
device,
the
the
Amazon
1
back
to
the
device.
The
user
would
then
see
on
the
on
the
screen.
Please
type
in
an
amazon.com
slash,
Prime,
slash,
authenticate
or
whatever
the
URI
is,
and
they
would
go
there
and
they
would
put
in
their
Amazon
credentials
and
then
they
would
see
a
box
that
came
up.
V
Please
enter
the
code,
that's
being
shown
on
your
device
and
they
would
put
the
code
from
the
Roku
into
Amazon,
which
would
then
enable
enable
the
bad
Netflix
polling
to
then
get
the
appropriate
access
token.
So
essentially,
the
user
would
think
that
they're
logging
in
to
start
off
the
flow
thinking
that
they're
logging
into
Netflix
and
if
they
weren't
completely
on
the
ball,
they
may
wind
up
at
an
Amazon
screen
put
in
their
Amazon
credentials
at
Amazon,
so
Netflix
wouldn't
be
getting
their
Amazon
credentials.
V
X
J
P
So
I
have
John
work
on
that
text
that
you
got
14
minutes
ago.
I
added
the
point
that
for
this
to
happen
either
the
device
manufacturer
is
the
attacker,
in
which
case
you
probably
didn't,
want
to
buy
their
device,
but
that
or
they
are
trusting
an
authorization
server.
That
is
the
attacker
or
became
compromised.
Well,
you
know,
all
of
which
is
possible,
but
there's
reputational
things
where
you
know
you
would
get
a
bad
write
about
it
by
your
device.
P
Now
William
wrote
some
text
and
security
considerations
earlier
about
trying
to
inform
end-users
that
what
you
are
doing
now
is
authorizing
use
of
your
Roku
device.
The
reason
you
want
to
tell
them
that
is
if
software
has
men
in
the
middle
of
the
whole
thing
or
something
and
they
don't
actually
have
a
Roku
device,
maybe
that's
a
red
flag
and
we
made
an
offer
to
be
bub.
Two
of
the
security
consideration
subsections
to
discuss
this
confused
deputy
situation.
O
Yeah
I
mean
my
sense:
is
that
like
this
is
done
constantly
and
we
don't
know
how
to
fix
it
other
than
what
you
said
and
so
like
not
writing
it
down.
It's
not
helpful,
like
not
publish
the
document,
because
we
have.
This
problem
is
not
hopeful,
so
I
think
like
what
I
was
expecting
even
I
understand.
It
correctly
is
like
for
you
doing
for
the
security
concern
so
makes
it
clear
what's
going
on
and
then
we
could
move
forward.
O
W
W
All
right
now
for
something
new
well,
a
little
bit
less
move
you
if
you're
here
at
ITF,
no,
no
but
okay,
so
also
incremental
auth.
Let
me
just
give
a
bit
of
a
recap
in
case
you
haven't
heard
of
this
before
so.
The
problem
statement
that
incremental
authors
trying
to
solve
is
that
effectively
asking
for
the
kitchen
sink
of
scopes.
Upfront
is
a
bad
thing,
and
users
should
have
the
context
of
what
they're
authorizing
when
they
authorize
it.
W
So
a
good
example
here
is,
if
you
have
an
app
that
say,
combines
you
know
an
identity
related
scope,
such
as
with
O'grady
connect.
It
might
combine
like
a
calendar
scope
for
some
kind
of
calendar
integration,
and,
you
know,
say:
I'm
like
a
email
scope
for
some
email
integration,
the
user
shouldn't
be
presented
and
authorized
and
request
at
sign-in
time
asking
for
all
those
three
things
they
should
just
be
presented
with
the
the
thing
that
they're
doing
at
the
moment.
W
If
you
did
multiple
authorization
requests,
you
would
just
get
multiple
authorization
grants
that
you
would
have
to
maintain
several,
and
so
the
the
benefit
of
incremental
auth
is
that
emerges
them
into
that
one
single
authorization
grant
representing
all
the
scope.
That's
been
grounded
so
far,
so
typical
orientation
of
this
would
be
where
the
consent
screen
would
only
display
the
new
scopes.
W
So
if
the
user
has
already
granted
scope
a
and
the
app
would
ask
for
B,
it
would
typically
show
the
new
scopes
go
B,
or
at
least
it
would
show
that
scopes
a
differently
and
then
a
cigarette
fresh
token
is
issued
for
the
union
of
all
the
granted
scopes.
So
this
is
actually
possible
today
with
a
confidential
client.
W
W
Is
that
if
you've
already
done
one
authorization
grant
with
some
scope,
you
can
then
do
a
second
authorization
request
requesting
different
scope
and
then,
when
you're
going
to
when
you
go
to
exchange
the
authorization
code
for
the
tokens,
you
can
actually
pass
in
the
existing
grant
at
that
time
and
what
you
get
is
kind
of
emerged
authorization
grant.
That's
why
the
parameters
called
existing,
grant.
W
Here's
a
sequence
diagram
just
showing
the
the
first
request,
the
response,
the
top
half
is
very
typical
all
affair,
and
then
the
bottom
half
is
again
very
typical
or
just
with
that,
additional
existing
grant
scope,
the
existing
grant,
which
is
the
Refresh
token
from
the
first
part
being
passed
in
now.
It's
really
very
simple:
set
3,
it's
just
you,
take
the
grant
a
and
the
grant
B
that
we're
done
as
separate
authorization,
requests
and
unions
them
together.
Nothing
really
nothing
more
than
that.
W
So,
if
you
didn't
have
this
specification,
the
native
app
would
be
sitting
there
with
both
grants
separately.
They'd
have
to
maintain
those
to
refresh
tokens
that
have
to
refresh
the
to
refresh
tokens
and
just
keep
keep
track
of
things
with
this.
They
get
a
simplified
view
of
the
world
and
they
just
get
one.
W
W
So
here
the
user
has
performed
the
first
authorization
request,
the
user
granted
access
to
calendars.
We
do
a
token
exchange,
let's
introspect
that
token,
and
you
can
see
here
that
the
scope
was
created
to
calendar
within
to
a
second
authorization
request.
In
this
case
it
adds
the
blogger
scope.
User
has
allowed
that.
W
W
Okay
and
so
in
addition
to
the
public
clients,
the
specification
also
also
documents
some
best
practices
around
confidential
clients.
It
also
includes
this
new
parameter
for
confidential
clients,
as
I
mentioned,
it
is
possible
to
do
incremental
auth
with
confidential
clients
already,
but
perhaps
that
behavior
of
returning
more
scope
than
was
requested
is
is
not
always
expected,
so
this
extra
parameter
just
allows
the
the
user
to
actually
control
whether
or
not
the
request
will
contain
the
full
scope.
That's
already
been
granted
or
not
alright.
L
G
V
John
Bradley
I
think
it's
a
good
document.
We
should
move
forward
with
it,
there's
probably
additional
security
considerations
that
we
have
to
dig
into
like.
Was
that
refresh
token
actually
for
the
same
subject
our
resource
owner
as
the
new
one?
So
there
are
things
implementation
things
that
people
may
get
wrong
that
we
have
to
sort
of
think
through
some
of
the
the
new
issues.
V
It
would
be
better
with
token
binding,
obviously
so
that
the
Refresh
token
was
actually
bound
to
the
client,
so
there's
a
few
things
that
need
to
go
into
it,
but
other
than
that.
I
think
it's
functionality
that
we
did
have
can
largely
replicate
with
confidential
clients.
But
this
allows
us
to
have
public
clients
do
the
same
thing
which,
unfortunately,
some
of
the
OAuth
implementations
do
do
and
it
causes
incremental
auth.
V
Currently
with
public
clients
causes
all
sorts
of
interesting
side
effects,
because
you
wind
up
authorizing
a
client
on
one
device
for
something
and
all
of
your
devices.
All
this
with
the
same
client
ID
wind
up
inheriting
that
privilege,
which
is
also
unanticipated
but
I've,
seen
in
the
wild
quite
a
few
times
right.
W
L
I
I
B
P
W
W
Let
me
start
with
the
use
case,
so
this
document
is
designed
to
address
a
specific
use
case
and
that's
that's.
This
BYOD
phenomena
mean
enterprise
bring
your
own
device,
so
this
is
where
an
enterprise
wants
to
allow
its
its
workers
to
just
bring
their
own
devices.
You
know
Android
iPhone,
whatever
into
the
enterprise
and
use
their
personal
devices
with
corporate
with
corporate
resources.
W
At
the
same
time,
users
sometimes
will
be
hesitant
to
allow
kind
of
these
invasive
mobile
device
management
certificates
on
their
devices.
Mobile
device
management
is
sort
of
traditionally
how
the
enterprise
could
secure
those
devices
once
they're
brought
into
the
enterprise
environment,
but
it
has
a
significant
drawback
that
the
the
enterprise
can
typically
remote
wipe
that
device.
So
this
is
kind
of
a
very
uncomfortable
feeling,
because
you
know
you've
got
your
personal
data
on
there
like
your
photos
and
you
don't
necessarily
want
your
company
just
to
be
able
to
wipe
that,
and
secondly,
there
are
there.
W
W
W
W
The
device
posture
signals
are
simply
bits
of
information
they
get
sent
along
with
the
authorization
and
token
requests,
and
it
allows
the
authorization
server
to
make
informed
decisions
based
on
those
signals
as
to
what
the
user
can
access
of
the
corporate
resources.
The
spec
creates
and
ion
a
registry
for
the
common
signals
that
we're
defining,
which
are
then
sent
in
a
JSON
DC
area
like
this
example.
Here,
as
you
can
see
that
a
lot
of
the
data,
it's
just
bullying's
and
streams,
it's
kind
of
very
simplistic.
W
W
So,
for
example,
if
the
user
requires
a
lock
screen
and
the
signal
on
the
authorization
request
says
they
don't
have
a
lock
screen,
because
the
authorization
request
is
like
a
user
agent
flow
in
the
browser,
the
authorization
server
could
say,
display
an
error
and
say
hey.
You
need
to
go
set
up
a
lock
screen.
That's
in
on.
What's
called
the
device
posture
hint
then,
on
the
token
request,
the
same
dictionary
assent
again.
W
The
reason
it's
sent
on
the
token
request
is
that,
unlike
the
authorization
request,
this
one
can't
be
modified
by
the
user
in
the
user
agent.
So
it's
a
little
bit
more
safe
from
their
perspective,
and
then
it's
also
sent
that
that
same
jason
dictionary
is
sent
on
every
token
refresh
to
ensure
that
the
devices
remains
compliant
with
any
of
the
corporate
policies.
W
So,
from
from
an
app
adoption
point
of
view,
the
good
news
is
that
not
every
app
would
actually
need
to
implement
this
for
it
to
be
effective
uuugh
as
long
as
you're
actually
using
RFC
8252
news
style
authorization
where
you
can
actually
tie
all
of
the
devices
grants
to
a
single
session,
then
you
really
only
actually
need
one
to
buy
a
one
app
on
the
device
setting
this
these
signals.
For
it
to
be
effective,
it
can
apply
to
kind
of
every
app
or
can
apply
to
the
session
on
that
device.
So
that's
the
good
news.
W
As
far
as
adoption
is
concerned,
you
really
need
like
a
handful
of
apps
to
implement
this
of
the
enterprise
suite
for
it
to
be
effective
in
terms
of
what
protection
this
offers.
You
probably
noticed
earlier
that
that
these
words
kind
of
unsecured,
strings
and
bullying's
there's
no
kind
of
cryptographic
security
around
it.
So
what
good
is
that
right?
Well,
it's
this.
The
the
goal
here
is
to
protect
honest
users
who
may
be
hapless,
but
but
they're
generally
generally
honest.
W
So
this
is
the
user
that
that
is
not
trying
to
steal
corporate,
but
they
might
leave
their
phone
in
a
bar.
It
can
protect
against
that
use
case
because
the
user
is
not
lying
about.
Their
client
state
is
not
modifying
their
clients,
and
this
will
help
them
get
into
into
a
good
and
more
secure
state.
It's
not
designed
to
prevent
authorization
tokens
being
issued
to
dishonest
users,
someone
who's
actively
creating
like
a
spoof
client
and
trying
to
obtain
the
authorization
token.
That
is
not
the
goal
here.
W
However,
it
might
actually
possible
to
create
a
robust
unforgeable
system
if
you
combine
some
advanced
techniques,
such
as
token
binding
along
with
device
out
of
stations
like
safety
net.
This
is
supported
by
the
spec,
because
the
spec
is
just
defining
key
value
pairs
of
signals,
so
it
is
possible
to
encode
this
type
of
information
in
the
spec.
It
is
technically
out
of
scope,
we're
not
we're
not
trying
to
establish
the
exact
way
to
do
this
and
John
Bradley
has
all
the
details.
If
you're
interested
to
learn
more
about
that
baby.
I
So
I
guess
did
you
try
to
implement
this?
It
sounds
like
a
very
simplistic
implementation,
but
it
was
useful
information
that
you
included,
which
we
haven't
heard
about
last
time
of,
regarding
sort
of
like
what
What's
in
scope
of
the
document
what's
not
and
specifically
last
and
there's
a
little
bit
of
confusion
of
like
how
do
you
manage
to
get
these
attestation
information,
but
then
there's
nothing
said
about
it,
but
I
think
that
should
be
much
clearer
by
now
good.
W
I
V
I
I
V
Point
as
ekor
pointed
out,
we
have
this
problem
of
how
do
I
know
if
I'm
talking
to
a
fake
app.
So
this
is
the
first
thing
that
we've
actually
talked
about
that
may
actually
be
able
to
address,
am
I
talking
to
the
app
that
I
think
I'm
talking
to,
which
means
that
our
ad
should
actually
be
quite
keen
on
us
making
progress
with
this.
R
G
Am
yes,
you
should
read
the
title
of
the
slide
with
a
sigh
okay,
so
I
wasn't
planning
on
talking
about
this,
but
I
saw
an
interesting
draft
yesterday.
That
kind
of
brought
this
thing
back
around
and
also
there's
been
some
discussion
on
the
mailing
list
about
ja,
sind,
introspection
responses,
and
things
like
that.
So
anyway,
the
topic
of
HTTP
signing
we've
talked
about
it
before
and
there's
this
draft
that
I
wrote
years
ago,
it's
functional,
it's
been
implemented
by
several
different
people.
G
It
works
it's
flexible,
but
it's
also
expired
and
completely
unloved
by
this
working
group.
So
there's
also
this
other
draft.
The
cabbage
HB
signatures
cabbage
apparently
has
moved
on
from
this,
and
somebody
else
has
taken
over
editing
it,
but
it's
kind
of
resurrected
in
the
last
six
months.
I'd
actually
didn't
know
that
until
this
morning,
when
I
was
pulling
this
information
together,
but
there's
some
more
stuff
in
there,
it's
got
a
lot
of
problems
in
it
I.
G
You
know
humbly
say
that
it
has
more
problems
than
my
own
draft,
but
you
know
whatever,
but
it's
it's.
A
similar
kind
of
approach
tries
to
be
a
little
bit
more
Universal
and
therefore
runs
into
a
little
bit
more
Universal
problems.
We
looked
at
it
in
this
working
group
decided
back
then
it
wasn't
wasn't
really
what
we
were
looking
for
and
having
skimmed
the
new
version,
not
read
it
in
depth.
I
still,
don't
think
this
is
quite
what
we're
after
you
can
always
just
use
draw
for
everything.
G
We
already
made
the
mistake
of
soap
once,
let's
not
make
it
again
all
right.
The
new
draft
that
I
just
found
out
about
literally
last
night
at
the
RFC
lightning
talked
things.
Is
you
ask
an
HTTP
origin
signed
responses
now?
This
is
a
draft
that
adds
a
signature
header
to
the
HTTP
message.
This
is
not
something
that
is
bound
to
any
kind
of
like
access,
token
or
particular
style
of
API,
or
something
like
that.
This
is
something
that
allows
you
to
sign
an
HTTP
response.
G
G
It
is
not
the
client,
the
HTTP
client
signing
the
request
which,
if
we
were
to
apply
this
to
the
OAuth
space,
that's
the
part
that
we
really
want.
You
know
we
want
to
have
a
signature,
protection
and
key
proof
of
possession
around
the
client
that
is
making
the
request
to
the
API
in
the
first
place.
This
doesn't
do
that,
but
in
my
reading
of
it
and
I
sat
down
and
had
a
conversation
with
the
author
of
this
draft
earlier
today,
it
could
be
adapted
or
really
the
same
structure
be
reused
in
this
space.
G
Now
there
is
no
body
or
payload
protection.
This
this
is
all
like
headers
and
URLs
and
stuff
like
that,
but
there's
another
draft
which
I'll
talk
to
in
just
a
second
that
allows
you
to
do
that
kind
of
stuff.
It
is
tied
generally
to
certificates
in
PKI.
There
is
kind
of
this
little
additional
thing
on
the
side
that
says,
oh,
you
can
use
a
bear
key
if
you're
doing
elliptical
curves.
G
G
You
can
kind
of
chunk
it
up
and
incrementally
know
whether
or
not
you've
got
integrity
protection
over
the
body.
It's
an
alternative
to
like
the
HTTP,
like
full-body
message,
digest
thing
not
digest
authentication,
but
the
other
one
downside.
Of
course
is
that
none
of
this
supports
OAuth
because
they're
all
solving
their
own
things
and,
honestly,
that's
that's
kind
of
okay.
I
never
wanted
to
have
to
solve
HTTP
signing
in
the
OAuth
working
group,
but
it
was
if
we
were
going
to
be
doing
proof
of
possession
tokens
which
we
thought
we
were
a
few
years
ago.
G
We
were
gonna
have
to
come
up
with
some
way
to
do
that.
Other
people
turns
out,
have
this
HTTP
signing
problem
and
have
for
years?
That's
why
we
have
the
cabbage
document.
That's
why
we've
got
a
bunch
of
proprietary
implementations.
Aws
has
its
own
weird
fragile
thing.
I
see
Anna
nodding
for
that,
and
so
people
are
trying
to
crack
this
particularly
tough
nut.
G
I
think
these
two
drafts
have
some
interesting
promise
in
the
way
that
they're
approaching
the
problem
and
I
think
it
might
be
worth
while
for
us
to
look
at
that,
and
if
we
did,
what
we
would
really
need
to
do
is
adapt
the
sign
responses
so
that
they
can
cover
requests.
It's
all
HTTP
structures,
it's
all
based
on
structured,
headers
and
all
that
kind
of
stuff.
G
It
would
be
a
fairly
straightforward
to
define
a
request
header
that
would
be
analogous
to
the
response
header
and
how
those
two
play
nice
together
and
all
that,
how
that
gets
bound
to
the
the
keys
to
the
tokens
and
how
that
gets
represented
to
do
the
signing,
and
we
can
still
send
our
access
tokens
like
we
always
have,
because
now
we're
signing
a
header
and
we
can
sign
like
you
know
we
can
sign
the
access
token
header.
We
can
sign
the
the
date
header.
G
We
can
sign
a
bunch
of
other
things
that
give
us
the
types
of
security
properties
that
you
like,
in
addition
to
having
message
level
signature
protection
around
that
request.
That
proves
that
you
have
a
particular
key.
That
is
bound
to
that
token,
and
we
can
also
use
the
token
confirmation
methods
that
have
already
been
started
to
be
fleshed
out
in
job
and
thanks
to
Brian.
G
We
now
have
a
field
for
that
from
the
introspection
responses
due
to
the
MT
LS
work,
we
can
add
in
ways
to
say
like
from
the
authorization
server
to
the
resource
server,
hey
here's,
the
key
that
you're
supposed
to
be
looking
for
when
you're
looking
at
validating
this
message,
which
was
the
pop
model.
If
anybody
remembers
that
document
from
ages
ago,
that
was
kind
of
the
intended
model
of
this
all
along
so
I
figured.
G
I
Thank
You
Justin
for
making
as
a
way
of
this
work,
one
of
the
questions
I
have
on
what
the
problem
we
ran
into
packed
in
with
this
work
was
that
we
had
these
intermediaries
and
also
for
application
frameworks
that
munched
around
with
the
headers
and
and
the
payload.
Somehow
that
rendered
the
signature
invalid.
I
We
also
had,
as
we
focused
mostly
on
as
the
document
same
signing,
hdbuzz
signing
it
sort
of
literally
not
encryption
and
so
and
maybe
back
then
we
focused
on
symmetric
as
well
as
a
symmetric
keys,
and
our
question
for
me
is:
are
we
still
trying
to
accomplish
the
same
things?
Or
did
we
maybe
change
our
mind
in
the
meanwhile
that
we
saw
it's
from
your
torque?
I
Y
O
O
Mice
does
the
header
was
just
how
did
the
mice
adjust
had
to
do
a
signature,
as
our
call
that
allows
you
to
progressively
verify
the
data
as
it
comes
in
rather
than
it
verified
it
through
yet
right?
Otherwise,
it's
just
as
exciting
right,
I
think
you're
wrong
with
the
asking
graph
to
discard
that
the
askin
draft
does
cover
the
body.
I
can.
G
O
G
My
understanding
was
that
it
covers
the
body
by
outsourcing
it
to
either
the
mice
draft
or
the
body
digest
header
header,
yeah,
yeah,
so
yeah
it.
So
so
to
be
clear
this
this,
the
Gaskin
draft,
does
cover
the
body.
If
you
use
another
draft
that
covers
the
body
and
then
spits
out
a
header,
and
then
you
cover
that
header
using
this
okay.
So
this
is
basically
this.
This
does
the
the
verb,
URL
and
headers
okay
right
and
then
the
mice
draft
basically
does
a
progressive
form
of
a
signature
over
the
body.
I
U
G
G
To
be
a
presentation
on
the
ask
and
drive
tomorrow,
I
I,
don't
know
where
it's
going
and
I
can't
predict
where
it's
going.
But
people
are
trying
to
solve
this
as
well,
and
if
there's
a
general
HTTP
mechanism
that
we
can
then
say,
oh
instead
of
using
you
know
a
PKI
search
chain,
use
your
access
token
and
associated
key
to
generate
that
same
signature.
That
would
really
be
the
wind
that
we're
after
yeah.
O
So
there
was
some
question,
but
there
was
a
there's
this
meeting
today,
it's
or
some
of
that
stuff.
So
I,
don't
know,
what's
gonna
happen,
but
I
think
if
what
you
guys
want
is
a
digital
signature
over
the
system
that
is
just
tied
to
a
key
which
is
established
them
independent
fashion
that
is
not
tied
to
you
know
would
be
high
origins
then
probably
tell
me
she'd,
be
that
and
and
and
maybe
not
trusted
digital
signature
variant,
but
also
the
symmetric
key
variant
yeah.