►
From YouTube: OAUTH WG Interim Meeting, 2021-03-15
Description
OAUTH WG Interim Meeting, 2021-03-15
A
Okay,
welcome
everyone
to
the
first
meeting
of
the
first
oath
intern
meeting
so.
A
Again,
let's
go
to
that
while
not
well
here.
So
obviously
this
applies
here.
So
if
you're
not
familiar
with
that,
not
well,
please
make
sure
it
to
get
familiar
with
this,
because
this
is
applicable
to
everything
that
we
do
at
the
itef,
including
this
entire
meeting
is
so.
This
is
going
to
be
the
first
of
seven
term
meetings
that
will
be
starting
today
and
every
monday
until
april
26th.
A
So
today
the
first
one
is
d-pop
and
brian
will
they
will
walk
us
through
this
and,
and
there
are,
you
can
see
the
list
of
upcoming
meetings
and
the
topics
and
if
you
have
any
other
topic
that
you
want
to
discuss,
please
let
us
know-
and
we
will
try
to
accommodate
that
any
questions
about
any
comments
about
this.
This
list
of
interim
meetings.
A
Okay,
good
so
I'll
then
hand
it
to
brian,
so
he
could.
A
Go
through
his
presentation,
I
did
I
share,
or
I
wasn't
sharing,
was
that
what
did
you
see
my
slide
guys.
C
For
the
meeting
minutes
could
do
you
want
to
post
a
list
of
future
meetings
in
there
so
that
when
we
shared
with
the
rest
of
the
group,
everyone
sort
of
has
this
as
a
for
the
records
yeah
yeah?
Absolutely
we
can
do.
B
I
don't
know
to
use
preview.
Okay
are
my
slides
showing
up
for
people?
Okay,
yes,
all
right!
Well
I'll
get
started,
then
I'm
sorry
not
to
see
you
all
in
prague
last
week,
but
doing
this
from
the
basements
of
our
home
online
we'll
have
to
have
to
survive
so,
as
fat
mentioned
here
to
talk
about
the
depop
draft
and
yeah
without
I
will
get
started.
Maybe
sorry,
apparently
I
don't
know
how
to
use
preview
there
we
go
so
just
real
quickly.
B
What
I
want
to
cover
today
is
a
review
overview
of
the
draft
and
its
contents.
It
will
be
probably
a
review
for
many,
but
I
find
it's
helpful
to
kind
of
level
set
and
recover
kind
of
the
the
working
aspects
of
how
things
work
to
help
facilitate
the
discussion
later
on,
and
then
I
want
to
basically
look
at
consider
a
path
forward
for
a
couple
of
open
issues
that
have
been
sort
of
lingering
over
the
the
draft
and
the
email,
archives
and
so
forth
for
a
little
bit.
B
So
that's
really
it
over
just
how
everything
works.
What
it
looks
like
and
then
talk
about
really
just
these
two
major
issues,
not
major
two
outstanding
issues:
I'd
like
to
try
to
come
to
agreement
on
a
path
forward
and
get
a
new
draft
published.
So
with
that
said
here
we
go.
So
reviewing
is
what
we're
doing
here
deepak,
what
is
it
what
it
isn't?
Basically,
it
is
a
pragmatic
application
level
sender,
constraining
of
access
and
refresh
tokens.
B
It
works
by
binding
a
key
pair
controlled
by
the
client
in
a
trust
on
first
use
style
way.
It
is
not
an
http
signature
scheme
on
its
own.
It's
not
a
client
to
authorization,
server,
authentication
mechanism,
as
we
traditionally
think
about
those,
and
it's
certainly
not
perfect
or
an
infallible
solution.
It's
sort
of
a
best
effort
at
providing
some
application
level
sender
constraining
quick
overview
of
how
it
works.
B
Basically,
we
introduced
this
new
construct
called
a
depop
proof,
which
is
a
jot
sent
as
an
http
header,
and
it's
sent
basically
on
every
request
to
both
the
authorization
server
and
the
resource
server,
every
direct
request
and
it
attempts
to
demonstrate
a
reasonable
level
of
proof
of
possession.
In
the
context
of
that
particular
request
itself.
B
Api
requests
the
as
uses
the
proof
to
bind
the
tokens
with
it,
which
it
issues
to
that
key
and
rs
uses
the
proof
to
verify
the
binding
in
those
tokens
and
access
tokens.
B
Here's
what
it
looks
like
the
proof
again
is
sent
as
a
as
a
header
with,
unsurprisingly,
the
name
depop,
and
it
is
just
a
jot.
This
gives
a
look
into
the
inside
of
one
of
those
jots.
It's
explicitly
typed.
It
only
supports
asymmetric
signature.
B
Excuse
me,
algorithms,
because
this
is
heavily
reliant
on
the
you
know,
the
properties
of
asymmetric
key
pairs
where
the
public
key
can
be
shared.
But
you
need
to
prove
possession
of
the
private
key
which
you
keep
private.
B
The
public
key
itself
is
included
in
the
header
of
the
jot,
and
this
is
the
public
key
which,
by
we're
proving
possession
or
the
client,
is
demonstrating
possession
of
this
public
key
by
signing
this
jot
itself
within
the
body
of
the
request.
There's
a
few
things
that
basically
minimally
bind
this
depop
proof
to
the
http
request
that
it's
being
sent
on
there's
a
unique
identifier
which
can
be
used
for
some
limited
replay
protection
and
checking.
B
There's
the
method
of
the
hd
request
and
there's
the
overall
uri
that
the
request
is
being
sent
to
with
query
parameters,
fragments
other
things
removed,
just
the
the
path
scheme
and
authority
and
then
there's
a
time
stamp
of
when
this
particular
proof
was
issued.
And
that
allows
for
these
to
be
only
valid
only
received
by
the
receiving
party
for
a
limited
time,
relatively
small,
limited
time
relative
to
the
the
creation
time
of
the
proof.
And
it
is
a
job
and
we
specifically
do
say
that
other
stuff
could
go
in
here.
B
There
is
some
work
or
look
at
this
in
in
some
other
contexts
that
are
adding
pieces
to
make
it
more
like
an
http
signature
scheme
potentially,
but
the
the
primary
goals
of
depop
itself
are
just
to
to
use
limited
signature
over
use.
A
signature
over
a
limited
amount
of
the
http
request,
not
the
whole
thing
to
prove
possession
of
the
key
not
to
ensure
integrity
of
the
overall
request,
but
there's
sort
of
built-in
extensibility
here
that
would
allow
for
that
kind
of
profiling.
B
In
downstream
protocols,
when
you're,
making
an
access,
token
request,
the
depop
header,
the
depop
proof,
is
sent
in
the
depop
header
of
the
request
and
otherwise
the
the
x
yeah.
The
access
token
request.
The
token
endpoint
looks
pretty
similar
and
that
allows
the
authorization
server,
assuming
everything
checks
out
to
bind
the
access
token
that
is
issued
there
to
the
public
key.
B
That
was
in
the
proof
that
that
binding
can
be
indicated
back
to
the
client
with
the
token
type
of
depop
telling
the
client
that,
indeed
that
that
token
was
bound
to
the
depop
public
key
and
the
proof
that
it
sent
on
refreshing
an
access
token.
It
works
much
the
same
way.
The
depop
proof
jot
is
sent
in
http
header,
along
with
the
normal
content
of
the
refresh
token
request.
B
The
authorization
server
has
metadata
that
it
can
use
to
advertise
support
for
both
deepak
and
general,
as
well
as
specific
algorithms
that
it
supports.
So
this
depop
signing
out
value
supported
is
a
json
array
containing
a
list
of
the
jws
algorithm,
supported
by
the
authorization
server
for
the
depop
proofs.
That
it
will
accept
and
probably
es
256
is
a
good
choice
here,
but
this
allows
for
some
dynamicism
in
the
algorithm,
supported
and
some
negotiation
between
client
and
server
by
publishing
this
value
and
depop
bound
access
token,
which
is
issued.
B
The
draft
basically
covers
two
scenarios:
one
is
or
doesn't
cover
it
codifies
and
describes
how
this
would
look
in
the
context
of
a
jot
self-contained
access,
token
or
any
access
token.
That
would
be
dereferenced
and
introspected
and
then
describes
how
that
payload
would
look
for
the
confirmation
in
json
on
the
access,
token
or
introspection
response
and
the
current
draft
states,
basically
that
the
confirmation
claim
the
cnf
claim
carries
the
shah,
256
jwk
thumb
print
of
the
depop
public
key
to
which
the
access
token
was
bound
using
this
jkt
member
of
the
cnf
claim.
B
So
really
all
it's
doing
is
taking
a
hash
with
a
deep
public
key
and
embedding
it
in
the
access
token,
but
but
for
introspection
and
jot
access
tokens.
We
describe
sort
of
the
syntax
and
semantics
of
what
that
looks
like
in
the
token
itself,
or
by
by
reference
later
on
protected
resource
requests
are
made
with
the
access
token
that
was
issued
here,
we're
showing
a
reference
style
access
token,
but
one
that
is
is
bound
to
the
public
key
and
presumably
would
be
figured
out
via
introspection
mentioned
in
the
previous
slide.
B
But
that
token,
then,
is
bound
to
the
key
in
the
proof
which
is
also
sent
via
the
normal
mechanism.
Here
the
depop
header
and
the
depot
proof
being
sent
in
there
and
then
the
the
protected
resource
would
then
check
both
the
validity
of
the
proof.
Does
the
signature
match
up
to
the
re
to
the
the
key
that
was
in
there?
Does
it?
Is
it
properly
bound
to
this
particular
request
and
if
so,
then
check
the
binding
between
the
access
token
and
the
public
key
within
the
proof.
B
There's
a
couple
of
challenges
defined
that
allow
for
a
little
bit
of
negotiation
and
error
handling
one
would
be
response
to
a
protected
resource
request
without
a
token.
B
So
if
a
request
was
made
without
a
token,
this
would
be
a
normal
401
indicating
how
access
could
be
achieved
in
this
basically
saying
the
develop
authenticate
the
depop
scheme,
the
realm
per
is
like
the
realm
in
any
other
challenge
as
such,
and
additionally,
we
defined
the
alex
parameter
here,
which
is
a
way
for
the
protected
resource
to
advertise
to
clients
which
deepak
signing
algorithms.
B
It
supports
in
this
case
we're
showing
es256
ps256,
basically
saying
it
can
be
olympic
curve
or
pss
rsa
style,
and
then
a
response
to
a
protected
resource
would
with
a
token
but
one
that
is
invalid.
These
are
very
similar
by
the
way
to
the
the
bearer
error
responses,
but
with
the
addition
of
the
the
algs
to
indicate
support,
for
which
obs
there
are
similar.
We've
got
the
scheme
the
realm
and
then
the
error
messages
which
describe
both
human
readably
and
hopefully,
more
programmatically.
B
So
that's
a
quick
ugly,
very
dirty
look
at
the
details
of
depop,
so
I
wanted
to
give
a
little
bit
of
a
status
update
here
and
just
all
the
changes
that
have
been
published
in
the
new
drop
since
the
last
interim,
which
you'll
notice
is
nothing's
actually
been
published.
Since
then,
you
might
be
wondering
why
and
basically
coming
out
of
the
last
interim.
B
There
were
three
main
topics
that
at
least
as
an
editor
here
I
perceived
as
needing
to
be
looked
at
or
wanting
the
working
group
to
try
to
drive
to
some
kind
of
consensus
on
and
up
in.
The
left
here
are
meetings
from
the
excuse
me
minutes
from
the
last
meeting.
You
can
see
basically
a
lot
of
take
it
to
the
list.
Take
it
to
the
list,
take
it
to
the
list.
Let's
go
discuss
this
on
the
list,
so
I
did
fire
off
three
follow-up
questions
from
that.
B
Taking
these
items
to
the
list
and
unfortunately,
consensus
has
been
somewhat
elusive.
Trying
to
to
achieve
there,
and
not
so
much
because
it's
been
real
contentious
but
there's
been
a
lot
of
sort
of
yeah.
We
could
do
that
or
really
it's
not
that
important.
These
are
issues
which
the
the
cost
benefit
isn't
totally
clear.
It's
not
not
real
clear
to
anyone.
What
which
way
we
should
go
on
these
myself
included.
So
there's
been
a
lot
of
back
and
forth
on
the
list.
B
There
were
a
few
changes
actually
made
to
the
draft,
largely
editorial
and
not
enough.
I
thought
to
warrant
a
new
publication
just
yet
so
I
was
hoping
to
get
through
these
items
get
to
some
kind
of
resolution,
either
with
changes
or
not
before
publishing
the
next
draft.
B
There
was
one
of
the
three
items
where
basically,
in
my
judgment,
the
the
list
consensus
was.
This
is
not
a
good
idea.
We
don't
need
to
do
anything
with
it,
and
that
was
the
question
of
whether
to
use
or
profile
somehow
separately
d-pop
as
a
specific
client
authentication
mechanism.
B
There
was
those
pretty
pretty
strong
or
pretty
clear,
vocal
support
of
not
doing
that
at
all.
So
that's
been
kind
of
dropped
off
the
list
and
there
remain
these
two
other
issues
which
I
don't
even
necessarily
have
good
names
for,
but
this
issue
of
sort
of
the
freshness
of
the
depop
signature
and
what
the
signature
signature
itself
covers,
as
well
as
the
nature
of
how
we
represent
the
confirmation
style
and
the
access
token
right.
B
B
The
first
one
is
this
freshness
and
signature
coverage.
I
say
for
lack
of
a
better
for
name,
because
I
don't
really
know
what
to
call
it.
B
So
because
there's
no
sort
of
server
contribution
to
the
proof
itself,
there's
no
real
strong
guarantee
of
liveliness
or
timeliness
of
the
proof
itself,
so
the
stolen
artifacts
can
later
be
used,
together
with
the
stolen
access
tokens
to
protect
to
access
protected
resources
or
even
to
acquire
new
access
tokens
completely
independent
of
the
client
application
itself.
D
Brian,
this
is
mike.
Could
I
speak
for
just
a
moment
in
charge,
because
I
have
to
leave
in
10
minutes.
I
did
some
investigation
into
what
microsoft
is
actually
doing.
D
Application
level
will
pop
for
office
and
other
things,
which
again
is
internal,
but
we
would
like
to
be
able
to
move
to
a
depop.
I
learned
that
we
are
having
a
server
nonce
included
in
the
signature.
Now
it's
the
old
oauth
http
signing
draft,
but
we're
adding
a
nonce
to
it
and
the
way
we
get
that
nonce
is
sending
an
unauthenticated
request
and
getting
the
www
authenticate
header
response
back
that
has
announced
in
it
and
in
terms
of
your
slide
about
other
stuff
could
go
here.
B
That's
certainly
yes
for
your
own
sort
of
usage.
That
would
be
a
possibility.
I'm
curious
does.
Does
that,
then,
is
that
nonce
renegotiated
for
every
single
request.
D
Okay,
good
question:
I
was
going
to
add
one
other
piece
of
information,
which
is
the
way
that
works
is
the
nonce
can
be
reused
but-
and
you
could
call
this
a
hack
or
not,
but
if,
in
the
200,
okay
response
from
the
authentication,
you
get
back
a
new
nonce
you're
expected
to
use
that
the
next
time
it
does
mean
that
there's
one
mandatory
additional
round
trip
to
get
the
first
nodes,
but
there's
no
additional
round
trips
for
subsequent
lenses.
D
Again,
I'm
not
saying
this
is
the
way
it
would
have
to
be,
but
I'm
giving
you
a
data
point
that
microsoft
felt
that
the
liveness
of
the
tokens
was
a
big
enough
security
deal
that
they
didn't
want
malware
to
be
able
to
mint
50
tokens
that
were
good
indefinitely
far
into
the
future,
and
so
at
least
I
think
if
microsoft
was
to
move
this,
we
would
want
the
ability
to
have
a
server
contribution,
even
though
we
admit
it
introduces
an
at
least
one
extra
round
trip
and
again
I'm
gonna
have
to
drop
in
five
minutes.
D
B
D
I
I
can
find
out,
I
think
it's
in
the
body,
but
I'm
guessing.
This
was
a
late
friday
conversation
with
our
engineering
architect,.
B
Yeah,
thank
you
for
watching.
I
discuss
this
briefly
on
friday
as
this
his
discussions
with
internal
implementations,
sort
of
overlapped
with
this
general
question,
so
we
were
trying
to
get
some
clarity
on
on
how
some
of
those
things
were
being
done.
I
I
think
I
saw
a
question
here
so.
F
No,
I
I
was
just
since
mike
brought
it
up.
I
just
wanted
to
talk
about
the
oauth
pop
draft
and
the
old
one
and
http
message
signing,
but
I
can
wait
till
the
end
of
brian's
presentation.
I
don't
need
to
jump
in
now,
so
just
if
I
can
just
hang
in
the
queue
till
then.
F
I
mean
the
short
version
is
that
that
draft
was
always
intended
to
be
much
more
of
a
general
flexible
solution,
whereas
I've
always
seen
people
it's
a
more
sort
of
point
solution,
so
my
gut
says
that
that's
probably
the
direction
that
that
extensions
like
this.
A
lot
of
extensions
like
this
should
go
in,
even
though
I
think
it's
important
to
ask
these
questions
of
you
know.
Are
there
any
sort
of
easy
bits
to
cover
in
depop
that
will
actually
have
a
positive
impact
without
making
it
too
complex,
yeah.
B
I
agree
fair
all
right.
Let
me
let
me
try
to
re-pick
up
here.
Basically,
so
this
slide
does
talk.
A
lot
about
site.
Scripting
is
a
vector
of
of
like
executing
code
in
the
client
context,
but
where
you
could
potentially
use
the
apis
that
have
access
to
the
key
without
actually
stealing
the
key
itself,
and
so
I
think
cross-site
scripting
is
the
the
most
likely
candidate
for
that
sort
of
thing.
B
But,
as
mike
mentioned,
the
potential
for
for
some
kind
of
malware
on
the
client
would
be
another
potential
way
that
that
kind
of
access
to
mint
tokens
meant
proofs
use
the
key
but
not
actually
steal.
B
The
key
might
might
be
a
vector
for
that,
and
so
the
the
current
situation
is
that
that
we
have
this
issued
at,
which
is
meant
to
be
a
time
stamp
of
when
the
the
token
was
itself
issued,
and
this
is
helpful
on
the
server
side
for
preventing
you
know,
reuse
or
limiting
the
the
time
during
which
a
token
would
be
accepted.
B
B
B
I
say
it's
not
because
of
that
as
well,
but
that,
including
a
token
might
be
one
way
to
sort
of
pseudo-
include
some
level
of
server
contribution,
because
it's
something
that
that's
issued
by
the
the
authorization
server
so
including
that
in
the
proof,
somehow
would
limit
potentially
the
scope
of
of
use
of
the
proof
in
a
way
that
doesn't
rely
on
an
individual,
knobs
or
challenge.
B
As
as
mike
described
being
done
in
microsoft,
I
will
say
that
not
having
a
challenge
response
type
protocol
for
the
proof
itself
was
was
an
intentional
design
choice
aimed
at
trying
to
keep
simplicity
and
less
overhead
for
the
the
overall
protocol
itself.
That
doesn't
mean
that
choice
was
the
right
one,
but
it
was
intentional
trying
to
keep
things
simple
and
trying
to
keep
them
relatively
efficient,
at
least
in
terms
of
round
trips,
with
the
with
the
various
servers
so
coming
back
to
some
potential
options.
Ideas
of
ways
forward.
B
The
first
one
is:
is
that
it's
okay,
as
is
it's
sufficiently
all
right
as
it
is,
leave
it.
It
is
there's
some
discussion
in
the
draft
right
now
about
the
possibility
of
this
happening
and
describing
key
rotation
as
a
recommended
means
to
reduce
the
impact
of
such
a
attack.
So
if
pre-computed
proofs
were
made,
you
know
using
a
particular
key,
but
that
client
rotates
keys
over
time
and
in
a
lot
of
ways.
Depop
keys
can
be
not
not
fully
ephemeral,
but
they
can
be
relatively
short-lived.
B
You
could
create
and
use
new
keys,
largely
you
know,
for
for
the
scope
of
a
single
authorization
and
then
start
with
a
new
one,
so
that
key
rotation
is
while
not
built
directly
into
the
protocol.
One
way
to
really
limit
the
impact
of
the
kind
of
attack
we're
talking
about
here
and
all
this
kind
of
builds
on.
The
fact
that
any
attack
vector
that
allows
for
this
kind
of
pre-computation
of
proof
and
use
later
offline
or
away
from
the
client
itself
certainly
allows
for
a
direct
use
already.
B
So
there's,
I
think
some
question,
then,
whether
there's
really
worth
the
the
effort
and
the
complexity
introduced
in
the
specification
to
to
sort
of
close
off
the
offline
attack
scenario.
While
the
online
attack
scenario
is
still
possible
and
one
that
that
can't
necessarily-
or
at
least
I
am
not
aware
of
any
way
to
directly
close
that
off.
If
you
have
access
to
the
the
key
to
create
things,
and
you
can
execute
that
functionality
on
the
client,
you
can
go
ahead
and
make
requests
and
carry
out
whatever
attack.
It
is
directly
from
the
client.
B
So
there's
really
nothing.
We
can
do
in
the
protocol
itself
to
mitigate
that
and,
if
that's
a
possibility,
then
again
I'm
repeating
myself,
but
is
it
really
worthwhile
to
try
to
close
off
one
variant
of
that
same
attack
when
the
full
access
is
available?
Another
way,
I
don't
know,
I
I
kind
of
think
it
gets
hard
to
move
that
way,
but
so
some
other
potential
ideas
are
one
that's
come
up.
Quite
a
few
times
is
incorporate
some
aspect
of
the
access.
B
Token,
probably
a
hash
into
the
proof
itself,
potentially
with
with
other
tokens
or
codes
as
well,
but
this
would
give
sort
of
a
semi-limited
aspect
of
freshness
to
the
proof,
because
it's
only
good
for
the
duration
of
that
particular
access
token
itself
or
to
try
to
go
all
the
way.
I
guess
and
allow
the
server
to
somehow
provide
some
sort
of
non-slight
contribution
to
the
proof
itself.
B
As
I
said
previously,
this
is
you
know
the
the
protocol
itself
was
designed
intentionally
to
try
to
avoid
a
challenge
response
in
this
kind
of
area,
so
it
feels
a
little
bit
awkward
within
the
current
design,
particularly
there's
differences
in
what
sort
of
mechanisms
are
allowed
for
the
as
and
the
rs
to
convey
additional
details
in
the
response
mike
mentioned
previously
that
he
thinks
maybe
the
you
know,
the
new
nonce
is
carried
in
the
body
of
of
a
response,
but
that
becomes
really
problematic
for
apis
and
resource
servers,
where
the
the
body
of
requests
and
responses
are
completely.
B
You
know
application
level
design
for
whatever
that
api
is
so
we
have
to
find
some
other
way
to
stop
a
nods
into
into
a
challenge
in
a
way
that
that
fits
with
sort
of
all
the
protocol
layers
and
then,
as
sort
of
previously
mentioned,
the
challenge
for
call.
It
certainly
feels
untenable
to
me,
so
we
need
to
devise
some
kind
of
schema
to
amortize
the
cost
of
the
challenge
response
over
multiple
requests.
But
then
that
leads
me
to
ask:
how
does
that
work
exactly?
B
Is
it
not
really
a
nonce,
because
that
means
used
only
once,
but
maybe
some
sort
of
temporally
relevant
server
contribution
that
could
be
used
for
some
period
of
time
defined
by
the
authorization
server
or
resource
server?
B
Sometimes
hacks
are
clever,
sometimes
they're
really
hacky,
but
that
during
the
course
of
normal
operations,
you
could
continue
to
sort
of
update
the
the
server
contribution
through
successful
requests.
Maybe
in
some
additional
header
I
don't
know,
I
honestly
haven't
thought
about
it.
Much
in
that
way
seems
nice
for
a
single
client,
but
also
sort
of
problematic
for
a
client.
B
That's
making
multiple
requests
through
different
threads
to
to
the
same
resource,
server,
keeping
track
of
those
challenges
and
correlating
them
between
requests
seems,
I
don't
know,
potentially
problematic,
but
maybe
I'm
not
thinking
about
well
enough
and
certainly
I'm
sure,
there's
other
solutions
or
approaches
that
I
haven't
thought
of
just
because
that's
the
nature
of
things,
but
also
because
mike
already
discussed
one
that
I
hadn't
really
thought
through
previously.
B
Proposal
for
path
forward
coming
into
this,
but
it
is
just
that
is
sort
of
let
this.
What
I've
jokingly
tried
to
call
cross-site
scripting
nihilism
go
ahead
and
prevail,
and
I
think
the
last
comment
on
the
list
about
this
sort
of
sums
it
up
pretty
well,
if,
if
this
is
already
game
over,
if
if
cross-site
scripting
is
already
facilitating
full
access,
it's
probably
not
necessarily
worth
it
to
trying
to
patch
one
particular
scenario
with
a
hash.
B
So
this
would
mean
no
protocol
changes,
but
some
editorial
changes
and
actually
daniel's
already
written
some
of
these
up
and
and
put
them
into
the
editor's
copy
of
the
repo
which
you
don't
need
to
read
here
on
the
right.
But
additional
editorial
changes
describing
the
potential
for
the
attack
and
some
mitigations
in
the
form
of
key
rotation,
or
you
know,
general
suggestions
that
that,
even
with
this
protocol
in
place,
everything
in
your
power
needs
to
be
done
to
prevent
cross-site,
scripting
and
other
similar
types
of
attacks.
B
So
yeah
that
I
guess
that's
that
was
my
feeling
or
recommendation
working
on
these
slides
last
week.
I'm
not
sure
that
necessarily
represents
how
we're
feeling
from
a
consensus
of
working
group
here,
but
but
that's
where
we're
at
so
maybe
table
that
for
the
moment,
while
we
talk
about
the
other
one,
so
do
you
want
a
table?
Do
you
want
to
take
what's
happening
well
or
we
can
dig
into
it
now.
G
B
B
B
One
could
think
of
that
as
adding
a
lot
more
context
and
entropy
to
the
request,
which
would
make
precomputation
a
lot
harder.
But
ultimately,
if
the
goal
of
an
attacker
was
to
pre-comp
precompute,
some
sort
of
content
to
carry
out
an
attack
later,
the
content
of
the
attack
would
be
the
the
message
body
of
the
api
requests
themselves.
B
And
so
they
would
be
in
a
position
to
pre-compute
that
as
well.
B
So
I
don't
actually
think
the
kinds
of
measures
in
something
like
a
ship
or
or
full
hdb
signatures
by
themselves
provide
anything
with
respect
to
this
particular
problem
and,
at
the
same
time
introduce
a
lot
of
complexity
which
I'm
strongly
trying
to
avoid
at
this
layer,
which
is
keeping
this
particular
document
about
the
proof,
possession
itself
and
not
trying
to
not
trying
to
and
actively
trying
to
keep
a
strong
separation
of
layers
and
keep
this
from
becoming
a
larger
hp
signature
type
of
scheme,
because
it
it
doesn't
seem
like
it.
B
E
F
Plus
one
to
everything
the
brain's
saying
there,
you
know
the
the
problem.
I
said
this
in
the
chat
here,
but
the
problem
with
http
message
signing
is:
is
not
the
actual
signing
the
bits,
it's
figuring
out
the
bit
to
sign,
yeah
and
so
saying
things
like.
Oh
just
add
a
body.
F
Hash
is
great
until
you
realize
that
people
can
make
http
get
requests
that
don't
have
a
body
and
so
that
same
get
request
is
going
to
be
the
same
all
the
time
my
personal
preference
for
depop
would
be
to
and
brian,
and
I
have
talked
about.
This
would
be
to
have
just
a
very
simple,
very
statically
defined
access,
token
hash
as
an
additional
header,
with
some
discussion
about
that,
because
I
think
that
that's
a
that's
an
easy,
simple
ad
to
this,
that
that
doesn't
get
into
the
normalization
of
http
messages
right.
D
F
The
right
so
personally,
I
think
that
that's
a
that's,
a
very
small
jump
and
I
mean
even
like
just
make
it
recommended.
You
know,
make
it
a
instead
of
a
must
on
calls
to
the
rs
or
something
I
don't
know,
but
the
rest
of
the
the
rest
of
the
depop
structure
stays
the
same,
and
that's
that's
important,
like
the
simplicity
and
the
parallelism
of
doing
the
same
thing
when
you
talk
to
the
eas
versus
the
rs
based
on
the
information
you
have,
I
think,
is
a
really
good
thing.
F
I
think
the
inclusion
of
the
access
token
does
fulfill
some
notion
of
server
knots.
Although
it's
not
it's
not
perfect.
You
know,
and
on
top
of
that
I
am
working
with
annabelle
bachmann
on
a
on
a
general
purpose.
Http
message,
signature,
spec
so
and
I'm
actually
meeting
with
her
later
this
afternoon
and
it's
our
goal
to
progress
that
to
rfc
sometime,
hopefully
this
year,
but
we'll
see
sorry
yeah.
No,
no!
F
That's
I!
I
don't
disagree
with
the
with
the
chuckles,
but
but
no
so
we're
we're
actually
making
more
more
progress
recently.
I
actually
hope
to
have
another
draft
of
that
out.
At
the
end
of
this
week
that
addresses
some
things.
So
when
that
is,
has
gone
through
like
one
or
two
more
immediate
pushes,
I
would
actually
like
the
oauth
working
group
to
pick
up
the
general
purpose.
F
Oauth
pop
draft
based
on
that
and,
as
I
have
said
all
along,
I
think
that
there
is
a
perfectly
reasonable
space
between
d-pop
to
allow
both
d-pop
and
the
http
message.
Signing
pop
exist
together
because
depop
solves
a
small
solution
in
a
very
elegant
way,
without
a
lot
of
complexity.
F
Hard
to
get
right,
but
it
pays
off
for
those
who
want
to
be
able
to
use
it
and
because
of
all
of
the
problems
that
it
does
solve,
that
depot's
not
trying
to
solve.
Ultimately,
it's
all
a
decision
trade-off
space,
and
so
I
like
to
see
us
have
things
within
that
space.
G
G
That
is
why,
if
you
want
to
protect
the
access
token
access
token
making
sense,
if
you
want
to
protect
a
request
that
requests
hash
or
digest
makes
sense,
you
cannot
solve
the
problem
of
a
future
projection
of
the
request,
because
some
attacker
that
has
access
to
the
key
now
and
compute
something
for
the
future.
The
only
way
to
protect
us
like
mike
said
before
is
having
a
round
trip
to
the
server
it's
about.
Theoretically,
keeping
it
simple
like
you
want,
but
also
keeping
it
open
enough
for
reuse
for
other
purpose
access.
G
Token
hash
grant.
I
can
protect
the
access
token
by
putting
the
access
token
edge
there.
I
can
protect
another
request
by
putting
the
word
request
digest
there.
You
can
put
that
in
recommendation,
but
that
is
not
a
replacement
of
the
http
signature,
of
course,
but
I
find
the
solution
that
brian
drafted
elegant
to
limit
attack
space.
It
won't
solve
all
problem,
but
it
shall
be
considered.
A
C
Yeah,
I
it's
great
to
hear
that
there's
good
progress
with
the
hdb
signing
as
justin
just
mentioned,
and
initially
when
the
work
on
debuff
was
kicked
off.
It
was
supposed
to
be
a
really
quick
solution
that
people
can
deploy
right
away,
but
now,
like
sometime
in
it,
almost
appears
that,
like
the
depop
that
the
http
signing
the
chestnut
is
working
on
might
might
be
faster
in
getting
finalized.
So
am
I
am
I
seeing
this
wrong
based
on
what
justin
just
said.
F
I
was
muted,
while
I
was
laughing,
is
faster
than
d-pop.
We
are
doing
everything
wrong
like
a
general-purpose
hp.
Signing
has
lots
of
corner
cases
that
that
we're
shaking
like,
and
I
I
think
like
depop,
should-
should
remain
simple
and
extensible.
F
I
think
in
an
ideal
world
we
would
have
had
hp
message
signing
a
decade
ago
and
I
think,
with
the
the
standards
like
the
hdp
group
and
the
security
community
are
finally
in
a
space
where
we
can
actually
make
that
happen,
but
but
I
think
that
there
is
still
very
much
value
in
deep
talk,
especially
because
depop
also
serves
the
or
answers
the
question
of.
F
How
do
I
associate
the
key
right,
because
that's
something
http
message
signing
doesn't
get
and
so
default
has
a
very
simple,
consistent
way
to
do
that
within
the
space
of
all
too,
and
I
think
that
there's
a
lot
of
value
in
that,
so
you
know
if,
if
the,
if
consensus
is
to
just
take
d-pop
as
it
is
and
publish
it
with
that,
I'm
actually.
Okay
with
that,
like
I
said,
I'd
like
to
see
a
hash
of
the
access
token,
I
think
it
would.
F
I
think
it
would
help,
but
if
we
don't
see
it
here,
we'll
probably
just
very
quickly
see
extensions
like
shim
and
and
other
specs
that
are
using
it
say
like
okay,
here's
how
you
hash
the
access
token
put
it
there
register
it,
go
on
with
your
day.
B
Yeah,
I
think
just
to
add
to
that.
I
do
think
that
should
be
signature.
Stuff
is
coming
along
better
than
maybe
anticipated
in
the
http
working
group,
but
I
would
be
shocked
if
it's
actually
faster
than
this,
particularly
because
it
is
hard
as
as
justin
mentioned,
when
you
get
around
all
the
edge
cases,
and
even
once
that's
done
or
close
enough
to
be
done.
B
Largely
oauth
will
need
some
profile
thereof
or
some
instructions
about
how
to
use
the
hpv
signature
and
bind
that
against
the
access
token
and
do
those
things
so
there's
there's
additional
work
that
will
need
to
be
done
worthwhile
work,
but
I
don't
think
that
the
timelines
are
such
as
you
sort
of
asked
that
they
might
play
out
honestly.
I
think
this
could
be
done
significantly
and.
A
A
B
So
go
ahead,
I
was
just
gonna
say
you
know.
I
think
this.
This
discussion
belies
some
of
some
of
what
I've
been
struggling
with
about
a
path
forward
with
this.
Is
it's
not
there's
a
lot
of
different
opinions
about
what
could
and
should
be
done?
B
Interestingly
enough,
none
of
them
are
super
strong,
like
justin's,
advocating
for
for
doing
the
hash
here,
and
I
certainly
like,
even
though
I've
got
a
proposal
not
to
do
it
in
the
next
slide,
I'm
I'm
pretty
minimal
to
that
too,
as
it,
it
feels
like
potentially
a
relatively
simple
way
to
address
some
of
this
and
has
some
benefit
as
well,
because
it
does
give
it's
not
a
full
sort
of
liveness
server
contribution,
but
it
emulates
a
lot
of
that
functionality
and
covers
things
for
a
future
beyond
when
this
sort
of
online
offline
attack
might
be
carried
out.
B
A
full
challenge
response
doesn't
do
anything
to
the
online
attack
anyway.
Nor
would
the
hash
of
an
access
token,
but
it
does
prevent
really
further
out
precomputation,
and
in
that
sense
it
might
be
a
good
sort
of
middle
ground
trade-off
in
terms
of
protection
and
simplicity.
So
but
we
seem
to
be,
we
maybe
seem
to
be
stuck
in
this
well
yeah.
Maybe
maybe
we
should
do
this
and
I
I
don't
know
to
be
honest,
I
could
certainly
go
for
a
hash.
I
could
go
with
this.
B
I
don't
want
to
be
in
this.
I
don't
it's
definitely
at
least
partly
my
fault.
I'd
rather
not
be
having
the
same
conversation
again
in
six
months.
I'd
love
to
to
come
to
some
kind
of
consensus
here
and
try
to
move
things
forward,
because,
despite
these
outstanding
couple
of
things,
I
do
think
we
are
really
close
to
being
able
to
publish
something
that
that's
usable
and
and
implementable.
Right
now,.
A
Okay,
I'm
gonna
cut
the
line
after
dennis
here,
so
dennis.
I
Thank
you.
Well,
I
sent
three
mails
on
december.
The
second
and
I
proposed
some
text
and
obviously,
since
my
comments
were
made
on
the
version
two
and
there
is
no
version,
three
none
of
my
comments
has
been
incorporated
would
like
to
insist
on
a
very
important
comment:
ryan
mentioned
that
he
wanted
a
clean
layering
and
he
went
as
deep
up
to
work
with
basically
only
keys
well,
if
we
want
to
make
the
pop
more
secure
than
it
is
really
possible.
I
There
is
a
case
of
the
collaboration
attack
where
you
have
a
illegitimate
client
that
is
given
by
a
legitimate
client,
both
an
access
token
and
a
debuff
proof
token,
and
basically,
if
you
give
this
token
and
if
it
incorporate
the
name
of
the
person
on
a
notifier
of
the
person
who
gave
you
the
token,
this
may
limit
the
attack
or
this
will
limit
to
impersonation
attack.
Only
so
I
would
say
that
normally
an
access
token
should
include
either
a
sub-claim
or
other
claims
allowing
to
unambiguously
identify
the
user
to
the
rs.
I
A
A
Okay,
so,
like
I
guess
I
don't
know,
I
want
to
try
to
get
the
feeling
of
that
of
the
room
here
or
or
the
the
people
on
in
in
here.
So
yeah
we're
trying
to
to
make
a
decision.
Do
we
wanna,
like
maybe
I'll
I'll,
ask
a
question
first
about
if
you
are
in
favor
of
not
doing
anything
like
exactly
what
what
the
what
the
slide
is
talking
about
right
now,
just
leave
the
document
as
is
or
you
want
to.
You
want
to
incorporate
either
that
mechanism.
A
That
kind
of
helps
with
that
replay
attack,
whether
it's
a
nonce
or
something
else,
that's
a
different
story.
We
can
discuss
it
later
on,
so
so
I'll
I'll,
ask
the
question
and
see
how
many
people
are
in
favor
of
living
it
as
a
as
as
is
as
presented
in
this
slide.
So
if
you
are
in
favor
of
leaving
the
the
document,
as
is,
please
add
a
plus
one
to
the
chat
there.
J
A
J
Okay,
so
don't
change
the
protocol.
Add
the
caveats
in
security
considerations
or
whatever
correct.
A
A
Yeah,
okay,
yeah.
I
was
just
waiting
for
people
to
leave
there.
I
think,
if
I
count
it
correctly,
I
have
eight
in
favor
of
leaving
it,
as
is
now.
If
you
are
in
in
favor
of
changing
this
and
including
a
replay
protection,
it
doesn't
matter
what
mechanism
for
we'll
discuss
the
mechanism
later
on.
Please
plus
one
now.
I
B
D
F
With
this
going
both
ways,
I
I
do
have
a
preference
for
a
very
simple
access
token
and
I
think
brian
and
I
are
in
the
same
boat.
So
I
I
hate
volunteering
myself
to
write
texts,
but
brian,
maybe
you
and
I
can
can
write
a
really
simple
access,
token
pr,
because
I
I
don't
think
it
would
actually
take
much.
I
I'd
be
happy
to
work
with
you
on
that.
B
Thank
you.
The
the
actual
text
is
less
of
my
concern,
although
I
could
always
use
help
writing
anything.
It's
just
it's
trying
to
get
to
consensus
there
and,
like
I
said
it's
weird,
because
there's
not
super
strong
feelings,
either
way,
but
I
think
it's
important
to
move
forward.
G
I
I
francis
I,
I
think
we
should
really
split
it
in
the
general
protocol.
That's
very
powerful.
The
way
it
is
now
and
an
extension
part
that
can
give
adopters
the
possibility
to
either
add
access
to
cash
or
something
else.
Those
extra
security
measures
should
be
put
in
a
separated
block,
if
not,
if
we
just
lock
it
with
the
access
token,
by
reducing
the
extent
of
the
use
of
this
protocol,.
A
E
J
A
B
Okay,
so
the
other
one
is
it's.
It's
been
suggested
that
on
resource
access
having
the
jdbk
and
the
header
of
the
proof
itself
makes
it
much
too
easy
to
just
use
that
key
to
validate
the
signature
and
maybe
miss
checking
the
binding
to
the
access
token,
which
might
lead
to
just
sort
of
careless
accepting
of
that
and
not
actually
getting
any
of
the
value
of
this
protocol.
B
This
is
compared
to
the
out
none
world
of
the
jot,
which
I
try
to
humorously
say
is
the
worst
hyperbole
in
the
history
of
time
here,
but
I
don't
think
it's
quite
that
bad,
but
I
do
think.
Potentially
it
is
a
problem
that
current
situation
is,
we've
got
the
full
jbk
and
the
proof
the
hash
of
the
jwk
is
and
the
access
token's
confirmation,
and
potentially
this
is
a
problem,
although
there's
only
one
person
really
strongly
advocating
for
this,
I
think
it's
a
pretty
reasonable
point.
B
We've
got
two
options.
One
is
leave
it
as
it
is.
The
other
is
to
move
the
full
job
full
day
became
the
access,
token
confirmation
and
emit
it
from
the
proof
on
resource
access,
and
this
is
less
error
prone
and
also
avoids
the
need
to
actually
define
the
hash
function
for
the
confirmation.
B
So
my
proposal
on
this
one
is
to
remove
that
foot
gun
put
the
full
job
jwk
and
the
access
token
confirmation
and
admit
it
or
make
it
optional
on
the
proof
in
resource
access
real
quickly.
I
tried
to
show
a
diff
of
what
that
would
look
like.
Basically,
the
proof
would
take
that
jbk
out
of
that
line,
move
it
over
to
the
confirmation
you
see
here
in
the
access
token
and
then
the
jkt,
with
the
hash
of
the
proof
or
the
public
key
and
the
proof
would
be
removed
entirely.
B
I
I
think
this
makes
sense
from
a
security
point
of
view,
and
is
it
real?
It
is
a
change,
but
is
a
relatively
small
change
and
it
actually
once
done
means
there's
less
bits
being
conveyed
all
over
the
wire.
It's
hard
to
really
say:
what's
more
and
more
efficient
with
various
caching
schemes,
but
in
general,
there's
less
stuff.
Being
carried
across
the
two
artifacts
here,
so
it's
a
it's
a
net
win
in
that
sense
as
well
and
does
make
the
particular
security
mistake
much
much
more
difficult,
almost
impossible
to
do
here.
A
K
Yeah,
just
just
one
point
that
when
whenever
we
would
put
these
jw
case
in
the
xs
token,
this
might
be
a
stretch
if
we
actually
or
if
anybody
actually
uses
rs
rsa
for
designing
the
access.
Token
jaw
just
becomes
massive,
because
your
whole
modulus
and
everything
is,
is
then
part
of
the
access
token,
and
you
may
run
into
limits
if
part
of
the
query
or
something
so.
B
Anyway,
you
should
be
and
it's
moving
it
from
one
place
to
the
other,
and
it's
potentially,
then,
if
you
were
using
rsa
in
the
old
style,
you
might
have
problems
with
the
size
of
the
proof.
So
I'm
not
it's
really
just
moving.
A
F
Hey,
I
see
the
point
here,
but
I
personally
don't
like
it
because
it
breaks
the
parallelism,
which
was
one
of
the
as
brian
pointed
out,
yeah
yeah,
and
that
is
one
of
the
nice
and
very
elegant
things
about
depop
and
adds
a
lot
to
its
simplicity.
This
is
coming
from
someone
who
has
implemented
this,
both
client
and
server
side
on
a
couple
of
different
platforms
and
language
stacks.
Now
that
parallelism
buys
you
a
lot.
B
No
okay,
you
know
just
to
throw
this
last
slide
up
here.
Probably
won't
see
you
all
in
san
francisco,
but
it
would
be
nice.