►
From YouTube: IETF100-OAUTH-20171114-1550
Description
OAUTH meeting session at IETF100
2017/11/14 1550
https://datatracker.ietf.org/meeting/100/proceedings/
C
D
E
B
B
The
first
one
is
that
device
flow,
so
this
say
was
they
updated
just
recently,
so
the
plan
is
to
run
it
one
more
time
with
the
workgroup
last
call
and
then
they
hopefully
will
ship
it
a
so
that's
the
plan
for
this
one.
Yes
right.
Oh
yes,
okay,
yeah!
We
will
discuss
that
too
right.
The
discovery,
a
draft
say
Mike,
we'll
talk
about
that
in
a
second
to
em
and
that
chart
chart
request
here.
So
do.
G
This
is
Stephen.
Hosed
me,
the
status
is
so
this
this
actually
got
through.
Is
she
before
I
was
ad
and
I
and
I
have
to
figure
out?
Why,
like
it's,
still
stalled,
I?
Think
what
so
my
understanding
what
happened
is
that
is
that
there
are
a
bunch
of
comments
and
they
got
cleared
by
B
and
they
and
they
got
cleared
by
fake,
clear
by
fixing
the
doctor
document
and
then
I.
Finally,
women
look
to
the
document
to
see
like
how
the
changes
were.
G
H
G
G
G
B
Okay,
so
the
rest
of
them
a
will
be
presented
today,
with
the
exception
of
that
token
exchange,
so
that
token
exchange
is
a
we're
currently
in
a
working
on
the
write
up
for
that,
so
a
hopefully
we'll
ship
it
a
very
soon
to
to
occur
for
one
more
document
to
review.
So
that's
that's
a
that's!
The
update.
F
So
next,
for
next
year
we
have
already
prepared
another
our
security
workshop.
Here
you
see
the
sign
up
page
monitors
on
our
next
slide.
This
is,
as
you
recall,
we
have
done
the
previous
workshop
specifically
to
reach
out
to
some
of
the
researchers
who
investigate
sort
of
implementation
and
sort
of
formal
method
analysis
they
can
to
apply
them
to
our
protocol.
F
So
I
think
this
is
really
useful
effort,
but
I
also
encourage
folks
in
this
community
to
participate
and
to
share
on
what
they
are
doing
now,
so
that
research
has
actually
become
a
way
of
what
items
they
should
be
looking
at
and
what
status
the
documents
have.
So
it
least
in
the
past
workshops,
I
thought
them
extremely
useful
to
find
out
some
or
to
get
a
pry
a
broad
overview
on
what
these
different
techniques
are,
that
people
apply
to
analyze,
protocols,
things,
which
is
why
we
try
to
organize
another
one.
F
The
date
has
been
chosen
as
the
week
before
the
next
IETF
meeting
in
in
the
next
IDF
meetings
in
London
this
one.
This
workshop
is
in
Trento
in
Italy,
supposedly
a
nice
place
here.
You
can
also
find
the
link
in
the
scope
is
like
with
the
other
workshops,
so
we
are
trying
to
see
or
receive
position
papers
related
to
OS
of
MIDI
connect
and
OS
related
topics
such
as,
for
example,
the
IOT
stuff
that
uses
OS
and
so
on.
F
B
E
I
I
You
go
alright
mutual
TLS
profile
for
a
lot
a
lot.
What
we
do
here
so
we're
gonna
talk
about
the
mutual
TLS
profile
for
get
into
it
next
slide.
You
know
I'll
hear
me
alright!
Is
that
better?
Okay?
So
sorry,
there's
better
alright.
So
what
is
it?
What
is
the
mutual
TLS
profile
for
auth?
It's
sort
of
two
main
things:
one
is
defining
a
mutual
TLS
client,
authentication
mode,
the
authorization
server
and
there's
two
distinct
methods
or
modes
of
this.
I
And
then
you
have
the
actual
full
certificate
configured
as
a
credential
for
the
client
and
just
compare
those
two
after
the
fact,
and
the
other
other
part
of
the
draft
is
defining
a
mutual
TLS
sender
constrained
access
tokens
for
protected
resource
access,
which
another
way
of
saying
that
is
just
certificate
bound
access,
token,
so
actually
binding,
oo-oo
thaks
s
tokens
to
certificates,
so
they
can't
be
used
by
anybody
else.
Next
slide,
please.
I
Why
are
we
doing
this?
A
couple
things
one?
Is
that
a
mutual
TLS
client
authentication,
which
is
obviously
provides
better
security
characteristics
than
the
shared
secret
method
we
have
in
OAuth?
Normally,
it's
something
that's
been
done
by
a
number
of
different
implementations
in
practice,
but
we've
never
for
years
now,
we've
never
written
it
down
as
an
actual
standard
and
there's
been
some
pressure
from
some
other
communities
to
to
have
it
written
down,
so
they
can
references
it
as
an
actual
standard
in
a
common
interoperable
way
of
doing
it.
I
I
There
are
banks
now
that
that
need
these
four
server-to-server
type
api
cases,
mostly
being
driven
out
by
new
regulations
around
open,
banking
and
and
so
forth.
This
spec
is,
in
its
draft
form,
is
currently
referenced
by
fappy,
the
open,
ID
foundation,
financial
api
working
group
in
their
readwrite
security
profile,
as
one
suitable
holder,
a
key
mechanism
necessary
for
financial
level
transactions
with
OAuth,
and
it's
also
referenced
in
the
I
left
out.
The
UK
part
here.
I
Next,
please
so.
The
first
part
how
mutual
to
us,
client
authentication,
works.
Basically,
the
TLS
connection
from
the
client,
the
token
endpoint
or
any
other
direct
connection
to
the
authorization
server
is
established
with
mutuality,
less
authentication.
In
the
request.
The
client
includes
the
con
ID.
I
So
we
have
the
token
endpoint
authentication
methods,
as
you
can
list,
for
a
server
support
and
client
authentication
methods,
we're
defining
a
new
one
here,
TLS
client
off,
to
refer
to
the
PKI
method
and
then
there's
a
new
client
metadata
parameter
that
specifies
the
expected
subject
to
sting
which
name
of
the
client
certificate.
This
is
how,
when
presenting
this
mutual
TLS
over
this
method,
the
client
presents
the
certificate.
The
TLS
layer
verifies
the
search
chain
and
then
looks
for
the
expected
subject.
Ii
end
in
the
cert
would
now
be
a
good
time.
Life.
Sorry.
J
So
a
quick
question
so,
when
we've
deployed
on
similar
methods
in
in
eduroam
right
one
of
the
things
that
you
actually
run
into,
if
you
do
PK
I
base
this,
you
have
sort
of
just
just
looking
at
the
subject.
The
end
may
not
been
sufficient
for
doing
good
access
control.
You
might
actually
want
to
have
a
combination
of
subject
and
issuer
because
you
may
want
to
do
constraints
based
on
you
know.
J
You
don't
want
sort
of
somebody
else
to
stamp
on
you
stomp
on
your
name
right
and
if
you
know
public
PKI
is
gonna,
allow
that
if
you
just
do
subject
yeah,
so
I
would
suggest
that
you
think
a
little
bit
about
what
you
actually
want
to
achieve
now.
This
may
be
enough
for
the
people
who
want
to
implement
stuff
like
this,
so
it
probably
should
be
optional
or
something,
but
if
I
were
to
deploy
something
like
this
I
would
definitely
want
something
more
constrained
in
my
PKI
method
than
just
subject
distinguish.
I
Routes
that
you
have,
which
is
one
option
in
a
any
previous
version
of
this
draft,
we
also
had
a
parameter
that
allowed
you
to
constrain
down
based
on
an
issuer
DN,
so
a
constrained
issuer
for
the
client.
There
was
some
feedback
from
implementers
that
getting
sufficient
access
to
that
to
actually
deploy.
It
was
difficult
and
my
following
up
from
the
implement
or
feedback
the
reason
I'd
originally
introduced
it
is.
I
We
had
a
similar
type
piece
of
functionality
as
a
product
feature
in
our
server
and
while
it
I
agree
with
you
that
it's
a
potentially
common
and
desirable
additional
constraint
to
put
around
it,
the
idea
at
least
the
thinking
was
that
it
wasn't
necessarily
appropriate
to
be
something
that
the
client
asserted
about
itself
in
client
registration,
metadata,
but
more
something
that
the
server
could
implement
additional
constraints
as
it
sees
necessary,
but
not
something
that
that
should
live
in
the
standard
itself.
So.
J
Possibly
I'm
at
least
I
would
suggest
that
getting
some
sort
of
security
considerations
text
in
there
it
says
here's
some
of
the
stuff
that
you
can
get
wrong
when
you
do
certificate
validation
and
don't
assume
that
you
know
your
subject,
use
that
your
subject.
Name
is,
you
know,
unique
or
can
be
only
be
issued
by
a
single
issuer
in
your
trust.
J
I
So
yeah
in
in
that
that
is
what
is
in
the
current
draft,
we
can
look
at
some
additional
considerations,
there's
already
some
considerations
there,
but
not
particularly
around
that.
So
it's
worth
mentioning
and
then
there's
some
some
metadata
provided
in
support
of
the
other
method,
the
other
mode,
which
is
the
self
signed
certificate
mode.
There's
an
authentication
method,
name
for
this
as
well,
and
then
it
doesn't
define
anything
new,
but
references
back
to
the
jws,
uri
or
JW
KS
client
registration
parameters
from
RFC
75
91
that
already
exists.
I
These
are
ways
to
specify
a
set
of
public
keys
for
individual
client,
and
so
the
self
signed
certificate
mode
just
makes
use
of
these
existing
client
registration
possibilities
to
specify
public
keys
and
just
references.
Those
next,
please
the
other
side
of
it.
How
the
actual
sender
constrain
access
works
is
on
issuance
of
an
access
token.
The
authorization
server
associated
a
hash
of
the
certificate,
with
the
access
token
itself,
basically
binding
the
access
token
to
that
certificate.
On
TLS
connections
from
the
client
to
the
resource.
I
Server
mutual
TLS
is
needed
there
and
then
the
protected
resource
matches
the
certificate
it
received
from
the
client
against
the
hash
of
the
certificate
in
the
access
token
and
those
need
to
match.
Otherwise,
it's
a
it's
an
error.
That's
the
the
binding
between
the
two.
In
order
to
facilitate
communicating
that
information,
we
added
a
new
JWT
confirmation
method,
which
is
the
x.509
certificate,
256
thumbprint
confirmation
method.
I
So
this
is
a
new
confirmation
method
on
RFC
7800,
which
is
just
the
the
shot
2p6
hash
of
the
certificate
included
in
the
CNF
clam
and
then
parallel
of
that
there's
a
new
confirmation
method
for
token
introspection,
which
is
exactly
the
same
data
as
the
JWT
confirmation
method.
But
it's
returned
in
the
introspection
response
and
checked
by
the
protected
resource
in
the
same
way
so
either
way
it's
the
job
of
the
protected
to
get
the
certificate
presented
by
the
client
and
compared
to
the
hash
of
the
certificate.
In
the
access
token.
I
Maybe
one
important
detail
about
this
is
by
using
the
hash
of
the
access
token,
the
the
actual
binding
of
the
I'm,
sorry
by
using
the
house
or
the
certificate.
In
the
access
token,
the
actual
binding
of
this
certificate
of
the
actor
to
the
token
doesn't
vary
based
on
the
client
authentication
method,
so
that,
regardless
of
the
mode
that
was
used
on
the
authorization
server,
the
presentation
and
validation
method
is
the
same
at
the
resource
server
and
then
there's
just
examples
down
here
at
the
bottom
of
the
JW
confirmation
method.
It
took
an
introspection.
K
Richer,
so
just
just
to
be
clear
here:
the
certificate
that's
being
hashed
is
the
one
that's
presented
to
the
token
endpoint
right.
Yes,
so
this
is
unable
to
be
used
with
anything
that
doesn't
call
the
token
end
point
specifically
implicit
flow
or
derivatives
thereof.
That's
correct,
okay,
so
implicit
clients
are
just
can't
use
certificate.
Bound
tokens
is
that
al
is
that
it
that.
K
L
John
Bradley,
so
the
the
experience
of
mutual
TLS
for
users
in
the
browser
is
known
to
be
suboptimal.
To
put
it
highly
optimistically,
encouraging
people
to
get
users
to
provision
soft
certificates
into
their
browsers
to
be
able
to
do
this
would
be
a
nightmare.
We
believe
that
token
binding
and
the
fetch
extensions
in
the
browser
are
going
to
provide
a
much
more
manageable
way
for
doing
proof
of
possession
and
tokens
through
implicit
flow.
K
I
I
M
Yes,
calm
leave
one
question:
there
is
a
coming
back
to
your
question
regarding
the
scoping,
the
the
DTN
of
the
sort
or
the
certificate
of
an
issue.
Oh
we've
got
some
text
within
the
security
considerations
about
x.509
certificate
spoofing.
Have
you
taken
a
look
under
that
yeah?
It's
just
a
question
yeah,
because
I
think
that
that's
that's
somehow
the
text
you
are
looking
for
so
yeah.
I
Okay,
I
mean
yeah
I
forgotten,
that's
in
there.
It
may
not
be
everything
you
want,
but
it's
a
start.
So
if
you
have
some
take
a
look-
and
let
us
know
if
if
there
could
be
better
or
more
thanks
for
reminding
me
Torsten
all
right,
so
just
a
little
bit
of
history
on
the
document,
I
presented
draft
two
in
Prague
and
I,
maybe
had
a
little
bit
premature
call
for
a
working
group
house
call
at
that
point,
but
it
led
to
some
excellent
discussion
and
some
I
think
really
worthwhile
changes
at
the
draft.
I
Since
then,
so
there's
been
three
drafts
published
since
then,
and
we
made
a
few
changes
which
all
summarized
here
went
from
kind
of
leaving
the
trust
model
completely
wide
open
and
saying
you
just
have
to
do
something:
two
defining
clearly
defining
these
two
methods
of
client
authentication,
the
PKI
method
in
the
self-signed
certificate
method.
It's
kind
of
one
of
the
other
and
I
think
it's
a
nice
improvement
to
nail
down
what
they
are.
I
wanted
to
leave
it
open
to
allow
for
either.
But
really
these
are
the
only
two
kind
of
reasonable
possibilities.
I
I
Let's
see
clarified
that
that
this,
the
client
authentication
is
an
exclusive
to
the
token
endpoint
and
it
can
be
used
for
other
endpoints
such
as
that
require
client
authentication
such
as
revocation
and
introspection
endpoints.
Some
of
that
I
think
was
just
legacy
a
little
copy-paste
that
in
the
original
world
of
OAuth
the
only
place
the
client
could
directly
authenticates.
Who
was
the
token
endpoint?
So
a
lot
of
the
wording
sort
of
carried
over
for
that.
I
I
This
was
the
one
that
was
at
one
point
intended
to
allow
for
the
constraint
of
the
issuer
on
a
particular
client,
but,
like
I
said
it,
it
sort
of
fell
in
the
wrong
place,
allowing
the
client
itself
to
specify
this
didn't
make
necessarily
make
sense,
and
it
introduced
a
lot
of
support
requirements
that
might
have
been
difficult
for
certain
implementations
to
to
accommodate.
So
it
didn't
didn't
feel
entirely
appropriate.
I
The
about
just
reading
through
the
doc
reorganized
it
to
try
to
more
clearly
distinguish
between
the
different
moving
parts
specifically
distinguish
between
the
client,
authentication
method
and
certificate
bound
access,
tokens
they're
very
similar,
but
they're
they're,
distinct
in
the
document,
so
split
them
out
better
and
then
more
clearly
delineate
between
the
two
client
authentication
methods,
the
changes
since
Prague,
and
there
have
been
so
I
actually
built.
I
didn't
build
I
paid
someone
to
build
a
bike
shed
in
my
yard.
I
I
She
told
me
they
were
wrong
and
told
me
what
colors
to
choose
and
that's
what
we
went
with
its
really
pretty
straightforward,
but
the
only
commentary
that
there's
been
some
commentary
on
the
latest
draft
one
implementer
said
it
looks
good
another
one
came
back
and
I
had
a
bunch
of
editorial
stuff,
but
the
only
sort
of
substantive
comment
was
around
the
name
of
the
client
and
server
metadata
parameter
used
to
indicate
support
for
bound
access
tokens,
that
is,
it
was
described
as
unnatural.
The
current
name
is
mutual
TLS
sender,
constraint
access
tokens.
I
He
proposed
certificate
bound
access
tokens
as
being
a
little
bit
more
natural.
That
sounds
nice,
but
you
could
also
go
with
mutual
TLS
certificate,
constrained
access,
tokens,
Mitchell,
TLS
certificate,
bound
access,
tokens,
M,
TLS
certificate,
bound
access,
tokens,
M,
TLS,
bound
access,
tokens,
TLS,
client,
bound
access,
tokens,
etc,
etc,
etc.
There's
a
lot
of
potential
options
here:
I'm,
not
sure
that
one
is
demonstratively
demonstrably
better
than
the
other
and
opinions
are
like.
I
You
know,
fill
in
the
well-known
saying
if
you
like,
but
it
was
raised,
I'd
really
like
to
get
to
some
I,
don't
know:
I!
Guess
if
there's
there's
really
strong
opinions,
please
bring
them
to
the
list,
and
maybe
we
can
drive
to
skin
some
consensus.
But
this
stuff
is
meant
to
be
machine.
Readable
humans
will
look
at
it
and
I'd
sort
of
like
to
just
leave
it,
as
is
even
if
it's
not
ideal.
N
I
And
they're,
like
they're,
supposed
to
go,
live
in
January,
which
is
which
has
its
own
issues
but
but
for
the
sake
of
just
changing
a
name
based
on
aesthetics,
I
I'd
prefer
to
avoid
it
so
yeah,
so
I'm
I'm
leaving
at
this.
If
you
have
super
strong
opinions,
please
raise
them,
otherwise
I
think
I
think
leaving.
F
I
The
words
and
the
title
and
the
document
identifier
to
be
a
if
I
can
be
really
frank.
I've
referred
to
this
document
at
times,
as
sort
of
like
a
poor
man's
token
binding.
It
provides
many
of
the
same
benefits,
at
least
with
respect
to
binding
the
access
token
that
you
would
get
from
token
bonding,
but
in
a
way
that
is
deployable
now,
because
the
mutual
TLS
functionality
that
it
relies
on
exists
and
can
be
deployed,
I
have
I,
have
working
prototypes.
All
this
either
in
product
or
extensions
and
product
in
the
lab.
F
Microphone
if
it
on
I
could
write.
H
No
gag
I.
F
Wanted
to
add,
because
I
would
have
phrased
it
differently
and
I
think
we
should
clarify
that
in
the
document
to
explain
the
relationship,
I
would
have
actually
said.
The
token
binding
is
about
this.
The
raw
use
of
raw
public
keys
and
this
document
is
the
use
of
certificates.
However,
unfortunately,
as
this
slide
shows,
you
have
also
a
self
signed
certificate
mode
India,
which
makes
it
awfully
similar
to
to
the
DOE,
compiling
and
so
like.
F
I
What
I've
seen
them
doing
they're
looking
for
more
traditional
client
certificates
in
a
in
a
PKI
type
mode,
and
they
have,
to
the
best
of
my
knowledge,
their
own
sort
of
PKI
for
their
deployment
of
it.
The
the
self
sign
mode
sort
of
opportunistic,
in
that
we
didn't
want
to
force
a
single
trust
model
on
there
and
that
it's
it's
useful.
It
provides
the
ability
to
do
some
of
this
binding
that
is
innocent,
similar
to
tow,
combining,
but
using
existing
deployable
technologies.
F
C
L
There
is
a
component
of
this
that
you
can't
do
with
token
binding,
because
it's
using
the
mutual
TLS
certificates,
the
the
other
thing
is
that
this
introduces
a
level
of
certificate
and
key
management
that
really
isn't
scalable
to
mobile
devices
and
and
and
web
browsers,
etc.
This
is
really
more,
you
know
if
you
have
a
server
to
server
sort
of
environment
this
you
can
do
now,
but
it
isn't
scalable
to
every
device
on
the
planet
without
having
another.
You
know
key
management
overlay,
so
this
is
sort
of
for
certain
use
cases.
L
This
is
not
a
bad
compromise,
but
for
the
broader,
broader
use
cases
token
binding
is
going
to
work
better
token.
Binding
also
has
other
privacy
protections
that
are
known
to
not
exist
with
mutual
TLS,
and
that's
one
of
the
reasons
why
we
did
token
binding
that
if
you,
the
server
has
a
certificate,
it's
gonna
present
the
same
certificate
everywhere.
So
these
are,
you
know,
generally
targeted
towards
server
to
server
implementations,
the
privacy
of
the
server.
It's
known,
it's
got
a
client
ID,
it's
not
really
a
secret,
so
correlation
isn't
an
issue.
M
This
is
Dawson.
We
come
back
to
to
the
first
slide
where
you
said
what
this
is
all
about
and
why
we
do
that.
You
stated
that
this
is
going
to
replace
shared
secret
for
authentication
and
I.
Think
that's
the
main.
The
main
reason
why
we
have
to
sell
certificates
in
there
right
it's
a
very,
very
reasonable
way
to
replace
shared
secret
for
authenticating
clients,
and
you
don't
need
a
PKI
for
that.
It's.
M
Communication,
that's
that's.
The
main
reason
why
we
included
the
cell
science
stuff
because
everyone
is
got
is
going
is
getting
afraid
if
we,
if
we
mention
certificate
based
authentication,
because
everyone
has
in
it
had
the
P
key
I
typically
required
with
that,
but
that's
not
needed
for
client
authentication
right,
because
you
have
a
pre-established
trust
relationship
between
the
the
provider
of
the
client
and
the
authorization
server.
So
that's
the
main
reason
there
is
no
tight
bind
binding
between
the
subsets
and
and
the
undertow
combining.
G
G
I
guess,
as
ad
I'd
like
to
request
that
you
do
make
clear
on
somewhere
in
between
these
two
documents,
where
the
applicability
situation
for
each
of
these
is
so
that
when
you
know
people
read
them
at
the
isg
and
also
when
people
consume
those
RFC's,
they
can
understand
when
they
see
one
technology.
First,
the
other
that'd
be
very
helpful.
O
Okay,
their
card
amazon.
You
know
as
much
as
I
like
mutual
TLS
client
authentication.
I
just
want
to
point
out
that
in
the
major
cloud
provider,
vendors,
their
load
balancers
that
do
TLS
termination,
none
of
them
support
mutual
TLS
client
off
for
passing
it
down.
So
anybody
deploying
this
would
have
to
you
know,
run
their
own
load,
balancer
and
stuff.
It's
going
to
be
a
barrier
for
people
to
deploy
it
in
scale
for
a
bank
or
something
like
that.
They're,
probably
not
gonna,
be
sitting
behind
it,
but.
K
Justin
to
follow
up
on
dicks
comment.
One
of
the
things
a
bit
of
perspective
to
keep
in
mind
for
this
work
is
that
in
a
lot
of
spaces,
the
financial
industry
in
in
particular,
they're
already
doing
mutual
TLS
and
then
nothing
else.
On
top
of
that.
So,
from
their
perspective,
it's
how
do
we
add
ooofff
to
mutual
TLS
and
not?
How
do
we
add
mutual
TLS
to
OAuth?
So
where
today's
systems
are,
you
present
the
right
certificate
and
therefore
you
can
do
whatever
you
want,
because
you
got
a
certificate
you're
in
the
door.
K
We
don't
care,
adding
ooofff
to
that
allows
them
to
have
constrained
in
time,
limited
tokens-
and
you
know
scopes
and
all
of
this
other
kind
of
stuff
that
oweth
just
kind
of
brings
to
the
party,
while
still
having
the
the
strong
sender
constraints
that
a
mutual
TLS
gives
you
so
while
you're
absolutely
right.
It
really
doesn't
make
sense
in
a
lot
of
cases
where
you
have.
You
know
large
scale,
load,
balancers
and
stuff
like
that,
I,
don't
think!
That's
me
crackling
yeah!
K
It
does
make
sense
in
cases
where
you're
already
doing
em
TLS
and
you
want
to
add
other
stuff
to
it
more
OAuth,
II
stuff.
So
I
think
that's
the
perspective
that
people
need
to
keep
in
mind
for
this,
which
is
again
as
John
was
saying,
a
different
perspective
from
the
people
who
would
be
looking
at
token
binding
as
a
solution
by
and
large.
K
J
Got
a
I
guess,
stupid
question
about
the
subject.
Deals
again:
I
looked
at
the
text,
it's
sort
of
okay
actually,
but
if
you're
doing
I
mean
it's
better
than
nothing
I
mean,
but
if
you
let's
say
you're
doing
what
John
sorry
for
Justin
describes,
the
banks
are
doing.
Aren't
you
doing
I
have
an
STS
somewhere
in
your
architecture
and
issuing
those
certificates
so
dynamically
and
wouldn't
subject
the
M
be
changing
all
the
time?
Do
you
really
want
that
in
metadata?
F
I
F
Sorry
we
cut
the
line
already
because
otherwise
we
cannot
run
completely
out
of
time,
but
please
post
your
comment
to
the
list.
Nevertheless,
I
think
you
got
very
good
feedback.
I
see
a
little
bit
of
clarification.
Also
that
comments
Justin
raised
life
will
double
check.
The
document
who
is
going
to
review
the
document
and
Rick
give
us
a
few
names
just
in
will.
E
F
I
H
I
The
the
idea
is
providing
an
oauth2
based
proof
of
possession
mechanism
based
on
token
binding
work.
That's
happening
in
another
working
group
here
that
can
defeat
replay
of
lost
or
stolen
tokens,
really
all
the
tokens
primarily
access
tokens,
but
also
Refresh
tokens,
authorization
codes
and,
and
some
of
the
other
tokens
that
are
are
used
within
the
context
of
OAuth.
I
That
turns
out
there's
a
lot
of
them
next,
so
just
a
real,
quick
refresher
for
what
we
had
in
draft
4,
which
was
prior
to
the
most
recent
set
of
changes
to
combining
of
access
tokens,
was
defined
using
referred
token,
bonding
ID,
as
well
as
a
representation
in
jadibooti
access
tokens.
How
to
actually
include
that
using
similar
to
the
last
draft,
a
confirmation
method
type
which
was
a
the
hash
of
the
token
binding
ID
inside
of
a
RFC
7800
confirmation
method.
I
We
also
talked
about
token
binding,
refresh
tokens
using
the
provided
token
binding
ID
very
similar
to
what
you
do
to
buying
cookies,
and
then
there
were
two
modes
to
allow
for
token
binding
of
authorization,
codes
built
on
top
of
pixie,
one
for
native
app
clients
and
one
for
web
server.
Clients
they're
just
different
in
the
nature
of
how
they
interact
so
they're
two
different
ways
of
doing
that.
I
I
Dependency
status
included
Dallas
here,
because
that
was
when
the
token
binding
working
group
got
officially
formed
and
you
can
see
John
up
there
and
lathe
sharing
that
first
meeting,
the
three
main
token
binding
working
group
documents,
negotiation,
the
protocol
and
HTTP
are
all
very
close
to
RFC
publication.
I
did
say
something
similar
in
Prague
and
oh.
I
Yeah
so
I
was
gonna,
say
things
move
so
fast
in
the
IETF
that
this
status
has
changed
since
I
submitted
these
slides
of
the
chairs,
and
today
they
have
moved
from
submitted
to
IESA
ESG
publication
to
I
ATF
wide
last
call
at
least
two
of
them,
and
the
third
one
I
think
is
either
out
or
close
behind
it.
So
we
are
actually
moving
forward
here.
I
Current
status
of
this
document
is
draft.
5
was
published
on
October
26,
with
changes
in
editions
that
were
were
discussed
in
Prague
on
the
mailing
list
too,
but
largely
agreed
upon
in
the
presentation
in
Prague,
and
you
scroll
up
just
a
little
bit
or
change
the
and
just
for
those
of
you
sort
of
following
along
at
home.
The
open,
ID
connect
token
bound
authentication,
draft
o
2,
which
is
very
closely
related
to
this,
and
also
itself
defines
the
structure
of
the
confirmation
method
to
carry
the
token
binding
ID
that
was
updated
with
similar
similar
changes.
I
That
was
a
little
bit
of
implementation
detail,
but
it's
potentially
infeasible
for
some
clients
that
are
implemented
as
distributed
web
based
clients
on
different
nodes
to
actually
do
token
binding
in
in
an
in
a
reasonable
way
and
noted
that
refresh
tokens
are
already
indirectly
bound
to
the
clients
credentials.
So
most
refresh
tokens
are
are
in
effect
already
bound
to
whatever
the
client
is
using
for
authentication
of
the
token
endpoint,
so
both
explain
sort
of
why
it
might
be
difficult
to
buy
and
refresh
tokens
as
well
as
why.
I
The
the
protections
you
would
get
are
already
in
place,
adjusted
the
language
a
little
bit
around
boarding
authorizations
in
the
phasing
and
to
combining
section
to
be
just
a
little
bit
more
general
and
not
only
about
downgrades
or
some
really
specific
discussion
about
detecting
downgrade
attacks
when
in
when
in
case
they
might
actually
be
just
miss
configurations
or
other
potential
issues.
The
the
suggested
outcome
is
actually
the
same,
but
the
language
is
just
a
little
more
generalized
and
removed
a
reference
and
usage
of
to
the
the
oauth2
protected
resource.
I
I
So
these
are
parallel
to
the
the
the
two
that
exist
now
for
JA
client
authentication,
but
with
token
bound
and
I'm.
The
the
private
key
variant
for
asymmetric
versions
and
the
client
secret
took
a
mountain
JWT
for
the
the
one
using
the
client
secret
and
then
also
defined
a
new
grant
type
to
again
explicitly
say
that
this
is
a
token
bound
jock
for
for
authorization
grant
versus
the
the
bearer
version.
I
So
that's
it
for
that.
So
next
slide
and
looking
ahead,
the
London,
the
token
binding
documents
are
going
to
progress
to
RFC
status
and
I.
Think
it's
for
real.
This
time.
I
I
think
that'll
happen
before
we're
in
London
still
looking
to
get
implementation,
experience
and
feedback
here,
I
will
go
so
far
as
to
say:
I've
been
working
a
little
bit
on
the
client
side
of
doing
some
of
this
in
the
early
stages
and
it's
kind
of
a
pain
in
the
ass,
so
I
think
it'll
be
good
as
things
get
standardized
and
and
maybe
API
is
in
support,
develop.
Hopefully
that'll
that'll
get
easier.
H
F
I
F
C
So
our
current
draft
is
those
seven
that
incorporated
clarifications
which
Eric
requested
about
some
defaults
and
statements
about
when
you
must
use
TLS,
which
we'd
forgotten
to
include
so
all
good
stuff.
We
requested
publication.
We
got
back
the
usual
reviews
from
upstairs
sector
and
Jen
art
two
of
the
three
said
good
to
go.
C
Another
requested
an
RFC
number
update,
which
is
correct
and
then
actually
had
a
very
interesting
interaction
with
mark
Nottingham
in
his
role
as
designated
expert
for
registering
the
well-known
value,
and
he
pointed
out
a
few
ways
in
which
the
context
that
most
of
us
who
are
familiar
with
the
space
already
understood
about
when
and
why
you
would
use
this
where
it
wasn't
actually
in
the
document.
And
so
that's
you
know
you
get
fresh
eyes
on
something,
and
that's
always
good.
C
So
there's
a
few
things
which
I
plan
to
add
with
the
co-editors
just
clarifying
the
context
of
like
when
you
use
an
issuer
versus
the
well-known
path
and
all
good.
So
within
a
couple
of
days,
I
plan
to
get
o
it
out.
That
mainly
includes
the
clarifications
which
mark
usefully
suggested
and
at
that
point
I
think
we'll
be
ready
for
the
telecheck,
assuming
eric
concurs
yeah.
G
That
seems
fine,
just
FYI
we're
now
looking
pretty
far
out
and
they
tell
us
how
to
agenda
so
I
think
it's
probably
gonna
better
than
a
half
before
it
shows
up,
but.
C
P
C
Yep,
so
this
is
largely
another
status
update,
but
this
one
has
a
call
for
action
at
the
end,
as
you
know,
Kathleen
and
others
requested
that
a
best
current
practices
document
be
written
for
the
use
of
the
JSON
web
token,
and
several
of
us
put
together
a
first
draft
next
slide.
Please
there
we
go
your
own
Scheffer
decart
and
I,
with
some
input
from
many
of
the
rest
of
you,
wrote
the
first
draft.
We
updated
the
0-0
individual
draft
a1
to
include
some
things
about
how
to
better
identify
conflicts.
C
C
What
I
won't
do
here
is
repeat
my
presentation
from
last
time
where
we
talked
about
what
we're
trying
to
achieve,
how
we're
trying
to
achieve
it,
the
structure
of
the
document
etc.
All
of
that's
in
the
record,
from
ITF
99
and
if
you'd
like
to
refresh
yourselves
on.
Why
and
what
and
how
that's
already
recorded
next.
C
This
is
my
last
slide
about
the
jot
BCP.
This
is
the
call
for
action,
I
think
to
progress
this.
We
need
some
people
to
put
eyes
on
it
and
put
pen
to
paper
about
what
they
saw
and
I'm
hoping
we
can
find
victims
or
volunteers
depending
upon
your
nomenclature
to
do
so
and
Bryan's
at
the
microphone
yeah.
I
Ryan
Campbell,
with
with
ping
I
so
I
did
there
was
there
has
been
some
stuff
on
the
list,
including
I,
asked
about
whether
and
if
other
ways
of
disambiguating
was
considered
or
useful,
which
sort
of
I
don't
have
a
strong
preference.
But
it
there
was
at
least
a
request
to
add,
was
a
more
consideration
or
more
clarify
where
in
fact
on,
if
you
had
a
nested
jot
where
you
would
need
to
look
for
the
type
that
was
or
the
the
type
for
disambiguation
and
so
I,
don't
think.
That's
happened
and
I
did
I.
I
I
will
try
to
find
it
and
look
for
it
and
then
I.
It's
it's
not
easily
addressed,
but
I
had
a
question
about
whether
and
if
the
the
document
should
cover
use
of
compression
in
jots,
which
sort
of
didn't
end
up
anywhere
but
I,
guess
it's
not
entirely
fair
to
say,
there's
been
been
no
discussion
on
it.
There
has
been
okay.
C
C
C
F
D
L
He's
probably
sleeping
so
we
went
over
the
device
flow
at
the
last
meeting
and
got
some
feedback
which
we've
now
incorporated
into
the
draft.
So
if
we
go
through
here
looking
at
the
changes,
it's
not
large
sections.
So
there
was
the
big
discussion
at
the
last
IETF
was
around
including
the
code
as
part
of
the
the
verification
URI.
So
we
split
that
out
so
there's
now
a
verification
URI
complete
that
includes
the
the
user
code,
which
is
separate
from
the
other
components.
We've
added
that,
in
the
examples
added.
F
Yeah
one
question:
I
saw
net
that
you
had
some
some
comments
and
one
of
them
was
a
question
about
the
type
of
devices
that
we
envision
and
I
I,
wonder
whether
we
or
what
all
of
your
comments
have
been
addressed,
you
think
so
or
you
look
at
it.
Okay,.
L
F
L
Okay,
so
that's
it
for
that
draft
and
just
so
that
everybody
knows.
The
other
draft
that
William
and
I
were
working
on
is
now
actually
an
RFC
yay
app
off
BCP,
as
done,
which
means
that
we
now
have
to
start
the
next
version,
because
the
darn
operating
system,
vendors
have
updated
things.
I
guess
that's
that's
life
in
the
world
of
BCPs.
L
L
Cool
okay,
don't
hold
it
upside
down.
So
one
of
the
problems
that
we
have
with
OAuth
is
that
in
general,
the
authorization
server
has
no
freaking
idea
what
application
it's
is
actually
making.
The
is
the
client
really
the
client
that
you
that
it
claims
to
be
so,
especially
for
native
applications,
given
that
they
don't
actually
have
client
secrets.
Knowing
that
you're
talking
to
the
right
application
is
a
significant
problem.
I
I
believe
Google
has
seen
instances
of
fake
applications
a
lot
of
times.
L
So
we
started
looking
at
rather
than
EMM
s,
which
sort
of
take
a
top-down
approach.
How
do
we
start
looking
at
managing
applications
from
the
bottom
up
so
having
applications
pass
attestation,
z'
and
statements
about
what
what
their
operating
environment
is
to
the
token
endpoint
to
the
authorization
endpoint
as
as
a
hint
and
further
from
the
authorization
server
to
the
identity
provider,
so
that,
if
you're
talking
to?
L
If
you
have
an
app
that's
going
to
a
SAS
provider,
you
may
have
device
posture
information
that
gets
presented
to
the
SAS
provider,
who
then
passes
that,
along
to
wherever
it's
doing
federated
identity
from
so
that
the
identity
provider
has
some
ability
to
say,
hmmm
wait
a
minute
that
device
doesn't
have
a
screen
lock
or
I.
Don't
like
that
particular
application
instance
to
talk
to
that
third
party
API,
so
try
to
move
some
of
the
decision-making
closer
to
the
people
that
are
actually
have
a
handle
on
it.
Getting
SAS
providers
to
make
those
policy
decisions.
L
Well,
we
have
skin
for
pushing
policy
down
to
the
SAS
providers.
It's
not
an
easy
fit
to
make
them
responsible
for
for
making
all
of
those
decisions.
So
in
this
model
the
Kent's
get
passed
up
all
the
way
to
the
identity
provider,
but
the
actual
confirmation
of
whether
or
not
the
application
is
the
app
it
says
it
is
and
the
other
things
that
can
be
directly
attested
need
to
happen
on
the
direct
communication
to
the
token
endpoint,
so
policy
decisions
are
made
and
then
enforced
at
the
sass
provider.
L
So
that's
essentially
what
we're
up
to
in
this
this
app,
so
we're
adding
a
couple
of
parameters
and
dictionaries
for
the
JSON
object.
So
we
have
you
know,
device
vendor
device
os,
whether
or
not
it
has
screen
lock
root
privileges.
These
are
all
things
that
the
app
already
has
access
to.
So
it's
not
new
privileges
for
the
app
but
things
that,
if
you
configure,
if
you
can
determine
whether
or
not
it's
your
app,
then
the
app
itself
can
say
whether
or
not
there's
a
screen,
lock,
etc.
L
You
don't
necessarily
need
to
rely
on
an
EMM
for
that.
So
the
first
step
is:
are
you
the
app
I
think
you
are?
And
if
you
are
my
app
and
you're
running
in
a
non
rooted
environment,
then
perhaps
I
can
trust.
Some
of
the
other
things
that
you
say
about
yourself,
Tony
has
the
look
on
his
face
like
he
had
bad
fish
Shawn.
F
L
How
do
you
so
they're
passed
on
a
direct
connection,
so
the
ultimate
verification
happens
to
the
token
endpoint.
So
that's
a
direct
TLS
connection
to
the
token
endpoint,
from
the
application
and
for
certain
kinds
of
attestation
types.
We
want
to
use
the
token
binding
so
that
you
so
that
you
can't
have
it
have
the
attestations
replayed
so.
L
But
that's
you
know
right
now:
it's
an
Indian,
it's
not
a
working
group
document.
So
that's
where
we
want
to
progress
it
to
so
that
we
can
start
getting
other
people's
feedback.
L
Q
L
R
Yes,
they
were,
as
it
relates
to
the
these
little
signed
bundles.
You
said
you
know,
the
attestation
is.
H
R
R
R
L
So
the
in
general,
the
application
that
asks
for
the
attestation
has
its
identity
in
that
and
there's
a
nonce
that
can
be
sought.
That
generally
goes
in
that
gets
signed
over.
So
one
of
the
ways
that
we
want
to
prevent
those
tokens
from
being
reused
is
by
using
the
token
binding
ID
which
again
binds
it
to
that
particular
device.
L
Yes,
Tony,
you
could
send
a
challenge
to
the
device
and
have
that,
but
again
you
can
man
in
the
middle
of
the
challenge
because
of
other
things.
So
there
are
advantages
to
sending
a
challenge
in
having
it
signed
versus
using
the
token
binding
ID
may
want
to
do
both,
but
right
at
the
moment,
o
auth
doesn't
provide
a
challenge
from
the
token
endpoint.
So
these
are
things
that
we'll
have
to
you
know
this
is
the
first
couple
of
drafts,
so
these
are
things
that
we
can
get
some
implementation
experience
for.
P
F
E
F
Think
we
would
have
to
find
some
some
people
to,
but
just
to
get
a
sense
of
what
like
a
sense
of
the
room
on
whether
you
find
in
general,
the
topic.
Despite
on
what
the
current
status
is,
do
you
find
it
useful
to
have
sort
of
an
attestation
mechanism
for
ours?
Is
that
something
you
find
use
worthwhile
to
spend
some
time
on
in
the
future?
Raise
your
hand
if
you
do
three.
F
N
H
L
In
in
principle,
they
parts
of
it
could
be
similar,
but
this
allows
so
this
allows
the
information
to
be
passed
from
from
the
a
s
up
to
the
authorization
at
the
authentication
server.
It
allows
for
additional
parameter
a
dictionary
to
provide
it
pass
additional
parameters.
So
this
is
more
the
application
space,
as
opposed
to
the
TLS
layer
where,
where
the
token
binding
attestations
might
live.
F
So,
what's
the
status
of
the
dough
combining
at
their
station
document,
it's.
N
F
N
L
Not
constraining
what
you
know
what
the
a
s
is
necessarily
going
to
do
with
that.
But
if
you
had
an
attestation
about
what
the
developer
key
and
the
app
ID
of
the
app
that's
claiming
to
be
a
particular
client
ID,
then
the
a
s
would
then
have
the
ability
to
say
wait
a
minute:
that's
not
the
developer
key
that
belongs
to
that
client
ID
or
some
such
policy
decisions.
L
So
the
first
step
is
figuring
out
whether
or
not
the
app
is
lying
to
you
about
its
identity
and
then,
after
that,
potentially
some
of
this
other
information
might
be
useful.
But
you
know
the
app
developer
probably
has
some
relationship
with
the
AAS,
so
we
don't
want
to
be
overly
specific,
but
you
know
having
a
per
M
standard
parameter
to
pass.
This
information
along
is
I,
think
a
good
good
part
of
it.
We
also
have
to
look
at
you
know
if
the
I.
L
Authenticate
server
makes
a
policy
decision
based
on
some
of
the
information
it
can
always
lie,
because
the
app
can
lie
on
the
redirect
to
the
authentication
server
unless
we're
also
doing
something
with
token
binding
attestations.
So
there
also
has
to
be
a
of
feeding
that
Paulette
those
policies,
decisions
back
down
to
the
SAS
provider.
L
Q
Lucy
Lynch
I
have
not
read
the
document,
but
but
I'm
listening
to
your
explanations
here,
I'm
having
a
hard
time
pulling
apart,
the
reliability
of
the
individual
at
access
stations
as
they're
passed,
and
then
the
idea
of
profiling,
multiple
access,
attestations
into
some
kind
of
policy
that
you
then
apply.
There's
a
gap
in
how
that
works.
Q
L
Well,
more
assurance
from
who
is
that
is
the
problem,
so
the
operating
system
generally
tends
or
the
lower
levels.
Something
is
creating
these
attestations.
The
application
is
going
to
bundle
them
together
and
send
them
over
a
TIA.
An
authenticated,
TLS
connection
does
adding
an
extra
layer
of
signature
around.
That
necessarily
add
anything.
That's
something.
Q
L
H
L
And
how
how
does
it
even
have
a
key
to
sign,
etc?
So
you
know
the
I
mean
it's
it's
something
that
we
can
look
at.
There
may
be
a
reason
you
know
to
sign
it
for
sign
the
bundle
in
the
front
channel
but
again
signing
the
bundle
in
the
front
channel.
You
then
have
a
bunch
of
key
management
issues
and
is
the
question
is:
are
we
really
getting
any
real
value
out
of
that
extra
signature
and.
F
I
think
I
think
what
Lucy
is
hinting
to
is.
She
would
like
to
understand
the
framework
the
architecture
peda
like:
where
does
the
information
come
from
and
and
does
that
piece
provide
any
additional
guarantees
besides,
actually
the
entity
that
is
potentially
lying,
providing
the
information
by
itself?
Obviously,
that
wouldn't
provided
a
lot
of
additional
information,
so.
L
C
L
L
M
F
M
That's
okay,
that's
understood
and
I.
Think
the
analogy
to
the
in
native
apps
PCP
is
reasonable.
Another
question:
are
there
existing
prototypes
or
implementations
of
that
whole
combination
at
the
station
on
the
operating
system
level
and
oh
of
implementation?
It
uses
this
postures
to
to
make
informed,
also
authentication
decisions.
We've.
F
L
L
R
No
I,
don't
know
who
that
would
be.
But
my
main
question
is
sorry.
This
is
Dave
Robin
again,
regardless
of
whether
it's
in
ur
signed
or
outer
signed
or
all
those
other
discussions.
We've
had
that
I
just
realized,
I'm,
not
sure
what
the
signature
is.
You
have
an
attestation
that
is
signed
by
the
operating
system.
Yeah.
How
does
the
AAS
I
know
what,
with
what
keying
material
with
what
agreement?
How
does
you've
got
a
signature?
Well
again,
what.
L
R
H
R
C
L
About
safety
net,
which
is
on
most
Android
devices
right,
so
that
requires
secure
boot
and
various
Google
Google
certification
programs.
What
I
can't
remember
the
name
of
you
have
to
have
Play
services
and
so
on
and
so
forth.
So
there
is
a
process
that
happens
on
the
Android
phone,
which
involves
some
split
key
signing
that
goes
off
to
Google
servers
which
check
the
phone,
which
then
okay
create
look
at
the
at
the
signing,
key
of
the
individual
application
and
various
other
other
things
and
produce
an
attestation
now.
Is
it
a
perfect
attestation?
L
No
that's
why
they've
just
introduced
Android
attestation,
which
involves
even
more
TPM
hardware,
etc.
So
the
actual
access
tations
depends
on
the
operating
system.
You
have
everything
from
total
crap
on
iOS
to
two
different
versions
of
of
things:
on
Android
and
I.
Don't
know
how
many
versions
of
attestations
on
on
Windows
and
in
Android
by
the
way,
not
DBM
so
again,
we're
gonna
have
to
the
actual
amount
of
trust
that
you
have
and
what
information
you
get
signed
by.
L
Who
is
going
to
have
operating
system
dependencies
and
we're
going
to
have
large
appendices
to
try
and
explain
what
you
make
of
these
things?
So
in
you
know,
if
you
look
at
at
phyto
attestations,
some
of
those
issues
are
also
discussed
over
there
for
the
various
app
types
of
attestations
that
you
might
get
from
hardware
platforms.
F
Okay,
thanks
John,
it
seems
that
we
sort
of
got
through
our
material
faster
and
we
fought
and
cutting
the
line
and
with
the
initial
presentation,
actually
wasn't
necessary.
I,
don't
like
the
gentleman
who
I
bumped
off
the
queue
is
actually
still
here
you
see,
or
did
he
leave
already.