►
From YouTube: IETF-OAUTH-20210510-1600
Description
OAUTH interim meeting
2021/05/10 1600
C
B
A
C
B
A
F
A
A
A
A
C
C
A
F
G
D
A
A
A
reminder
like
about
a
few
few
updates
about
the
the
work
in
the
idf
group
in
this
web
group.
So
the
security
bcp
passed,
a
workgroup
last
call
and
hannes
will
be
working
on
the
a
shepherd
right
up
there
soon,
hopefully,
and
the
authorization
server
issue
identifier
in
authorization.
Surplus
draft
is
we're
trying
to
kind
of
move
this
forward.
F
I
think
one
of
you
guys
needs
to
approve
the
screen
share
request
there
we
go
got
it
awesome,
all
right
and
hi
everybody
and
just
a
note
to
the
chairs.
Once
I
go
into
presentation
mode,
I
can't
see
the
chat,
so
just
you
know
feel
free
to
interrupt.
You
know
I'll,
monitor
you
all
right.
So
can
you
see
just
the
title
slide
now?
Yes,
all
right
perfect
can
never
tell
if
this
is
sharing
the
right
thing.
F
Okay,
so
hi
everybody
today
I
am
digging
up
an
old
old
topic
and
that
is
http
message,
signatures
and
and
how
we
can
use
them
with
oauth
2,
because
you
know,
since
we
started
looking
at
this
a
long
time
ago.
You
know
a
few
things
have
changed,
but
just
a
bit
of
history
for
those
who
most
of
you
probably
remember,
but
oauth
1.0,
all
of
the
messages
were
signed
and
they
were
generally
shared
keys.
F
It
did
eventually
the
concept
there
did
eventually
get
picked
up
into
a
more
general
proof
of
possession
architecture
and
key
distribution
set
of
documents
and
part
of
that
suite
was
the
signed
http
request,
suite,
which
I
was
the
editor
for
largely
because
I'm
the
one
who
who
made
the
mistake
of
volunteering
to
actually
try
and
solve
this,
because
you
know
how
hard
could
it
be
and
it
turns
out
really
hard.
If
you
go
look
at
the
now
long
since
expired,
signed,
http
request
draft
there.
F
F
So
the
cabbage
draft-
and
I
think,
yaskin
had
a
draft
at
that
point,
or
he
at
least
did
eventually
within
this
time
frame.
None
of
those
had
work
group
support.
There
was
limited
coverage
of
the
http
message
and,
most
importantly,
very
limited
flexibility
about
how
and
what
you
could
sign
and
how
to
actually
use
the
thing
it
had
a
very
specific
use
case.
All
of
them
had
a
very
specific
use
case
that
they
were
coming
from.
They
didn't
have
the
machines
of
a
working
group
to
actually
kind
of
push
that
into
general
functionality.
F
So
again
I
was
like
you
know
how
hard
could
it
be
to
actually
make
one
of
these
it
turns
out.
It
was
really
hard.
The
way
that
the
old
draft
works
is
that
you
kind
of
smush
all
your
headers
together
and
hash
that
mash
the
parts
of
the
query
together
and
hash
that
and
you
hash
the
body
and
you
throw
in
a
couple
of
you
repeat,
a
couple
of
extra
variables
from
the
http
message.
F
You
know
things
like
access
tokens
and
time
stamps
and
the
method
and
uri
and
maybe
some
other
stuff-
it's
extremely
drafty
and
hand
wavy,
but
you
kind
of
wrap
everything
there
up
into
a
jws,
and
then
you
send
that.
So
it
is
a
detached,
http
signature,
but
the
signature
itself
is
wrapped
entirely
in
a
jose
jws
object
with
all
of
the
bits
replicated
and
and
kind
of
stuffed
inside
of
the
jws
object,
and
a
lot
has
changed
since
that
work
was
picked
up
and
subsequently
kind
of
left
by
the
working
group.
F
Specifically
now
annabelle,
and
I
think
I
saw
her
on
the
call
right,
yeah
she's
here,
annabelle
and
I
have
picked
up
the
editor's
pen
for
a
new
draft
in
the
http
working
group-
and
this
is
this
is
important.
This
is
an
actual
part
of
the
http
working
group
that
takes
input
from
a
bunch
of
the
different
community
drafts.
F
So
you
figure
out
what
content
you're
signing
pull
that
out
format
it
in
a
very
specific
way
that
gives
you
your
signature
input
string.
Then
the
easy
part
is
kind
of
the
security
crypto
part
you
take
that
input.
String
of
the
normalized
http
message
run
that
through
a
crypto
function,
and
that
gives
you
a
blob
of
bytes
and
then
you
send
both
that
signature
output
and
the
parameters
that
you
use
to
create
it
as
structured,
http
headers.
Now
I
want
to
point
out:
there's
a
buried
bit
in
this
laptop.
F
D
F
Yeah,
I'm
I'm
using
them
interchangeably
there
I
mean,
I
know
that
there
are
some
subtle
differences
out
there.
The
thing
is
from
the
view
of
the
http
message:
group
http
is
now
defined
in
terms
of
semantic
objects
which
have
serializations
across
the
different
http
versions,
and
so
it's
it
is
more
canonicalization
and
functionally
the
way
most
developers
are
going
to
be
implementing
it,
they're
going
to
be
canonicalizing
strings,
but
it
does
really
get
into
the
semantic
normalization
kind
of
territory.
Yeah.
D
I
was
just
trying
to
and
see
like
how
the
differences
evolved
over
time,
because
in
oas
1.0
we
had
this
also
a
canonicalization
draft,
which
developers
got
a
little
bit
upset
about,
and
then
you
in
later
we
moved
from
that
away,
which
was
sort
of
this
completely
wrapping
it
up
in
json,
basically
replicating
all
the
parameters
which
people
liked
a
lot,
but
now
it
seems
that
we
are
going
back
to
where
we
started.
Is
that
fair
to
say
why
do
I
miss
that
point?.
F
So
the
oauth
draft
was
kind
of
the
worst
of
both
worlds,
in
that
it
did
have
some
canonicalization
requirements
to
it,
but
it
also
tried
to
use
this
encapsulating
signature
method
in
in
jose.
So
it's
it
was.
It
was
a
weird
chimera
of
the
two
yeah
and
as
far
as
the
general
construct
of
a
detached
http
message,
signature,
the
there
are
a
lot
of
people
who
don't
want
to
use
this
kind
of
mechanism
because
of
the
need
to
do
processing
on
the
http
message
itself.
F
You
know
they
would
just
rather
wrap
everything
up
in
an
object
and
send
it
and
to
them
I
say:
go
for
it
have
a
good
time.
There
are
huge
drawbacks
for
doing
that
as
well,
though,
and
with
this
draft,
and
especially
with
it
being
positioned
in
the
http
message
group,
the
http
working
group,
we
can,
I
think,
do
a
much
better
job
of
explaining.
What
that
trade-off.
Space
is
for
somebody
going
and
looking
at
this
draft
versus,
say
you
know
doing
everything
over
next.
C
Yeah
part
of
that,
I
think
it
comes
down
fundamentally
to
you
know.
How
are
you
structuring
your
messages,
your
your
api
over
http
and,
if
yeah,
if
you
have
an
api,
especially
if
you're
working
in
green
field-
and
you
just
want
to
like
put
everything
into
a
json
object
or
a
xml
object
and
send
that
as
your
body
and
yay
you're
done,
that
works
really
well
and
yeah.
If
you're
building
a
new
api,
you
do
that
it's
great
the
but
then
there's
this
whole
universe
of
stuff.
C
That's
been
built
on
http
and
puts
important
things
in
headers,
important
things
in
query,
strings,
important
things
in
the
body
and
all
over
the
place,
and
so
one
of
the
one
of
the
goals
with
http
message
signing
is
really
to
provide
a
message.
Level
kind
of
authenticity
check
that
is
flexible
enough
to
cope
with
the.
C
F
All
right,
yep
keep
cool
all
right.
So
a
point
that
I
wanted
to
make
on
this
slide
before
moving
on,
because
it's
it's
important
to
know
is
that
there
is
a
new
rfc.
It
was
just
published.
It
was
just
published
as
an
rfc
in
february
of
this
year,
called
structured.
Http
is
structured,
http,
message,
fields
or
field
values.
Technically
is
the
term,
but
as
we
would
all
know
them,
they
would
be
structured,
hdb
headers.
F
This
means
that
there's
now
a
standardized
way
to
do
things
like
dictionaries
and
lists
and
byte
arrays
and
all
of
that
kind
of
stuff
in
http
headers,
so
the
syntax
that
we're
going
to
be
using
in
a
lot
of
places
here
is
not
something
that
annabelle
and
I
invented,
which
was
how
we
used
to
have
to
deal
with
a
lot
of
things
in
in
http
headers.
This
is
this
is
all
part
of
that
spec
and
a
lot
of
the
http
group.
F
A
lot
of
new
extension
specs
are
moving
towards
using
these
definitions.
All
right.
So
I'm
going
to
walk
through
an
example
now
of
signing
an
http
message,
so
you
guys
can
get
a
feel
for
how
this
works
and
then
we're
going
to
talk
about
how
this
applies
to
oauth
and
some
of
the
some
of
the
questions
around
it,
including
the
questions
that
hana
started
to
raise
about.
You
know
why
do
you
detach
signatures
at
all?
F
So
this
is
our
http
message.
It's
a
simple
post
request.
I
will
point
out
that
the
message
signing
can
be
used
for
both
requests
and
responses.
I'm
going
to
focus
in
all
of
these
demonstrations
here
on
the
request
for
simplicity,
we're
going
to
sign
the
following
parts,
so
you
should
be
able
to
see
my
mouse
cursor
we're
going
to
sign
this
request
portion.
So
we've
got
a
post
and
we've
got
a
a
url.
F
Now
this
string
is
a
very,
very
simple
format.
Every
piece
of
covered
content
gets
its
own
line,
so
we've
got
the
request
target
here,
which
oh
I
realize
I
there's
a
typo
there.
So
none
of
these
request
signatures
will
actually
validate
because
there's
supposed
to
be
an
opening
quote
there,
but
we'll
pretend
that's
there.
The
at
request
target
means
that
you
know
I've
got
my
verb.
F
I've
got
the
url
that
I'm
going
to
and
the
host
header
with
that
with
the
header
value,
the
date
header
with
the
header
value
same
with
content
type
and
then
finally,
this
special
at
signature,
params
value,
which
has
the
list
of
all
of
the
covered
content
that
is
signed
so
request,
target
host
date
and
content
type
and
then
any
additional
parameters
and
variables
that
the
signer
needs
to
add
in
order
for
the
verifier
to
understand
it.
So
we've
got
the
created
timestamp
and
a
key
identifier
in
this
particular
example.
F
You
take
this
and
run
it
through
the
appropriate
key
signing
algorithm
or
the
the
crypto
algorithm,
and
you
end
up
with
a
blob
of
bytes,
and
this
is
here
in
base
64.,
no
big,
surprise
here,
then
you
add
these
to
the
http
message.
So
you've
already
got
your
http
message
and
you've
kind
of
run
it
through
this
utility.
That
says,
go
sign
these
parts
of
it
and
you
get
back
values
that
you
can
put
into
a
couple
of
new
headers.
F
So
there's
the
signature
input
header,
which
has
that
list
of
covered
content
which
again
a
typo
that
should
have
the
request
parameters.
Sorry,
it
was
this.
As
you
guys
all
know,
this
meeting
was
scheduled
very
quickly,
so
we've
got
the
signature
input
here
and
the
signature
value
itself.
Structured
headers,
gives
us
a
way
to
say.
F
Like
we've
got,
this,
we've
got
a
list
of
values
that
have
a
set
of
parameters,
that's
associated
with
that
list,
and
this
syntax
is
saying
that
we
have
a
a
sequence
of
bytes
that
is
encoded
in
base64..
What's
important
here
is
that
from
the
definition
of
the
specs
perspective,
this
is
a
byte
array.
This
is
not
a
string
that
has
been
encoded
in
a
particular
flavor
of
base64,
because
all
of
that
is
defined
by
http,
structured,
headers.
F
As
you
guys
can
hopefully
see
it
is
a
very
deterministic
and
very
straightforward
way
to
apply
a
signature
now
when
I'm
verifying
a
signature,
I'm
going
to
get
these
two
values
and
I'm
going
to
pluck
them
off
and
say:
oh,
these
are
the
bits
that
that
were
covered
in
the
signature
and
I've
got
a
time
stamp
of
when
this
was
created.
There's
also
an
expires
field.
If
you
want
to
use
it,
there's
a
nonce
field.
F
If
you
want
to
use
it-
and
you
can
extend
these
as
well-
and
I've
got
a
key
identifier-
that's
going
to
tell
me
as
the
verifier
okay,
which
key
should
I
test
this
against
and
probably
which,
which
algorithm
that
is
associated
with
that
key.
Although
there
is
also
an
algorithm
field,
if
you
need
runtime
agility
there,
and
then
I've
got
the
signature
bytes.
F
So
I'm
gonna
pluck
out
the
signature
bytes,
I'm
going
to
now
recreate
that
signature
base
string
using
the
same
algorithm
that
the
signer
did
on
only
the
parts
of
the
message
that
the
signer
says
that
they
signed
and
I'm
going
to
add.
As
my
last
line
there,
this
line,
which
is
specifically
the
bits
that
the
signer
said
that
they
signed
so
all
of
this
gets
covered
by
the
signature,
and
I
can
then
validate
it
based
on
the
key
all
right.
F
H
F
That
correct
yes,
yes,
that
is
absolutely
correct,
so
you
can,
you
can
sign
headers
and
for
the
most
part,
developers
will
be
able
to
get
away
with
doing
a
somewhat
lazy
thing
of
just
taking
the
string
and
signing
it
like
you
guys
all
know
me.
You
know
that
I
am
you
know,
first
and
foremost,
an
engineer
of
these
of
these
things.
You
know
all
the
the
pretty
semantics
aside.
I
we
need
to
be
able
to
hand
this
to
a
developer
and
have
them
get
it
right.
F
Put
here
so
yes,
absolutely
100
can
sign
any
header
with
with
any
valid
header
format
and
put
it
into
this
string.
There
is,
however,
an
additional
consideration
that,
if
you
do
have
a
structured
header,
the
signing
spec
allows
you
to
be
a
little
bit
more
precise
about
that.
You
can
require
the
structured
value
to
go
through
a
more
a
strict
normalization
process
or
you
could
sign
a
sub
piece
of
it.
You
know
there's
other
stuff
that
you
can
do
with
that.
F
F
So
you
take
the
header
name
lowercase
it,
because
headers
are
not
case
sensitive
in
http
and
then
you
serialize
it
as
a
structured
field.
String
value
with
optional
parameters,
I
think,
is
what
it
is.
I'd
have
to
check
the
adnf,
but
that's
why
it
gets
quotes
around
it.
That's
why
it's
lowercase,
and
all
of
that
you
do
not
just
take
the
header
value.
You
know
just
the
the
header
line
as
printed
out.
F
C
One
advantage
of
that
approach
is
it:
it
is
more
resilient
to
variations
across
http
versions.
As
far
as
how
these
things
get
represented
on
the
wire,
you
know
how
you
send
an
http,
2
header
versus
how
you
send
an
http,
1.1
header,
looks
kind
of
different,
so
just
saying
like
take
the
header
line
and
put
it
in
here
doesn't
necessarily
work
all
that.
Well,.
F
F
Then
it
would
show
up
down
here,
as
at
request
target
semicolon
verb
only
equals
true,
or
you
know,
whatever
the
appropriate
values
and
formats
are,
and
that's
the
string
that
ends
up
in
header
that
you
actually
send
to
the
verifier.
So
your
this
gives
us
a
way
to
pass
a
lot
of
information
between
the
signer
and
the
verifier.
C
F
Yeah
yeah
exactly
great
question,
though,
and-
and
I
will
I
I
will
take
half
a
second
here-
to
fully
credit
annabelle
for
the
structured
header
idea,
because
when
we
first
went
down
this,
I
thought
she
was
nuts
with
this
idea,
but
quite
frankly,
having
built
this
on
a
number
of
platforms.
Now
it's
really
nice.
F
You
get
a
lot
of
really
good
stuff
from
this,
and
I'm
excited
to
to
see
structured,
headers
and
other
stuff
in
addition
to
how
we're
able
to
use
it
here,
it
makes
dealing
with
it
makes
dealing
with
the
type
of
like
very
precise
definitions.
You
need
for
a
security
protocol,
much
easier.
It
gives
you
a
language
for
that.
C
F
I've
built
I've
built
out
this
the
signing
stuff
in
python
and
in
java
right
now,
and
I
didn't
actually
write
a
structured
field
like
a
library
for
either
of
those
which
was
pretty
awesome
that
those
those
are
already
starting
to
pop
up
and
they'll
start
to
just
be.
You
know
eventually
built
in
okay.
So
this
is
a
thing
that's
happening
in
the
http
working
group,
if
you're
interested
in
making
that
better
go
hang
out
in
the
http
working
group
annabelle-
and
I
are
pushing
this
forward
and
it's
you
know
it's
it's
going
well.
F
So
how
do
we
take
and
apply
this
whole
thing
to
oauth
2.?
So,
quite
frankly,
this
is
the
kind
of
draft
that
I
wish
that
we
had
had
way
back
in
the
day
when
I
wrote
the
oauth
signed,
http
draft,
that's
out
there
and
expired
right
now,
because,
like
the
features
that
we're
building
into
this
message,
draft
are
exactly
the
kinds
of
things
that
we're
missing
from
the
community
drafts
that
were
much
more
sort
of.
You
know,
point
solution
based.
F
What
we've
got
now,
I
think
we
can
actually
leverage.
So
my
proposal
is
that
we,
you
know,
we
base
the
oauth
message
signing
draft
on
this,
which
is
on
its
way
to
be
an
rfc,
so
we
create
a
new
token
type.
We
could
name
it
pop,
which
is
what
the
old
draft
does.
We
could
name
it
http
sig
if
we
wanted
to,
and
that
would
especially
help
it
be
separate
from
depop
but
more
on
relation
to
depop
in
just
just
a
minute.
F
I'm
thinking
about
that
and
we
set
up
requirements
for
how
http
message
signatures
get
used.
One
of
the
things
about
the
new
draft.
The
new
http
draft
is
that
it
enumerates
all
of
the
things
that
you
have
to
define
in
order
to
use
this
in
an
application,
including
defining
what
your
minimum
covered
content
is.
F
You
know
what
your
minimum
presentation
of
headers
like
so,
for
example,
we
would
say
you
have
to
just
use
the
signature
and
signature
input
and
authorization
headers
all
together
and
you're
required
to
cover
the
authorization
header.
Your
one
of
the
benefits
that
oauth
has.
Is
that
the
key
in
algorithm,
which
is
a
potential
place
for
confusion?
And,
potentially
you
know,
security
threats.
F
If
somebody
does
algorithm
substitution
or
key
substitution,
we've
got
this
whole
notion
of
a
client
in
oauth
which
can
have
registered
keys
or
they
can
have
generated
and
negotiated
keys
like
we
were
talking
about
in
the
oauth
key
distribution
draft
way
back
in
the
day.
So
maybe
we
can
dust
that
off
figure
out
how
to
get
get
that
going
and
things
that
and
all
of
this
stuff
can
be
communicated
down
to
the
rs
using
jotson
introspection.
F
Much
like
we're
already
doing
that
with
mtls
and
much
like
depop
is
communicating
how
to
do
it
there.
So
this
is
what
an
oauth
signed
request
might
look
like.
Quite
simply,
we've
got
the
authorization
header
which
contains
the
token
value,
and
we
sign
the
message
and
sign
the
authorization
header
that
that's
the
core.
That's
what
we
need
to
do
now.
We
might
say,
define
a
client
id
field
and
include
that
there
or
we
might
not
it.
F
F
F
But
this
is
something
that
we're
gonna
bring
up
in
the
context
of
the
core
http
message.
Signing
draft
is
there's
this
thing
called
the
specialty
type,
which
basically
is
one
of
those
flags
that
signals
like
this
is
the
thing
that
I
signed.
This
might
be
a
new
flag
for
that
that
we
could
add
there.
This
also
doesn't
directly
protect
the
content
body,
which
the
old
draft
said.
F
The
http
digest
draft
is
also
in
the
middle
of
getting
updated,
and
while
I've
got
some
some
issues
with
the
with
the
current
state
of
it
it
it
is
moving
along
well
and
okay.
So
big
question
and
I'm
glad
to
see
brian's
on
the
call
too
in
is
daniel.
I
missed
it,
but
anyway,
what
about
depop-
and
I
I
have
said
this
from
the
beginning
with
depop-
I
think
that
there
is
lots
of
space
for
these
things
to
coexist.
F
F
You
know
you
don't
even
sign
the
the
query,
parameters
and
paths,
and
things
like
that,
and-
and
I
think
that
those
limitations
are
what
give
it
focus,
and
I
think
that
depop
should
be
allowed
to
keep
that
focus
and
the
general
purpose
pop
draft
that
is
based
on
http
message.
Signing
is
where
we
should
be
absorbing
all
of
these
other
use
cases,
things
like
asymmetric
keys
or
as
distributed
keys
instead
of
client-generated
and
presented
keys.
F
Like
you
always
present
your
key,
you
know
the
simplicity
of
always
presenting
your
key
makes
a
lot
of
sense
for
the
space
depop
is
is
in,
and
it
makes
it
really
simple
to
always
do
the
same
thing
with
the
general
purpose.
Pop
thing.
Inside
of
oauth,
sometimes
the
client
might
negotiate
a
key
at
runtimes.
Sometimes
it
might
be
pre-registered
we're
going
to
need
more
flexible
language
for
that
kind
of
thing,
as
as
we
apply
apply
this
stuff.
F
Another
big
question
is
why
not-
and
this
gets
into
harnesses
saying
like
why
not
just
use
jose
and
wrap
everything
in
jose.
The
biggest
reason
here
is
that
jose
is
utterly
brilliant,
as
a
self-contained
cryptographic
object.
This
is
why
it
is
so
good.
Oh
yeah,
sorry,
honest,
I
I
know
you
weren't
proposing
to
use
jose
but
you're
the
question
of
you
know
what
gets
wrapped
what
gets
covered
in
the
the
questions
that
we
that
we
were
asking
for
the
old
draft
yep.
F
Sorry,
I
didn't
mean
to
misrepresent
there
my
bad,
but
there
is
a
question
of
of
why
not
just
use
jose.
So
this
is
why,
but
jose
is
really
great
at
self-contained,
which
is
why
this
is
really
really
good
for
things
like
tokens
for
things
like
assertions
and
messages,
things
that
you
want
to
be
self-contained.
F
An
http
message
object
whether
a
request
or
response
is
it's
not
self-contained.
You've
got
headers,
you've
got
urls,
you've
got
bodies,
you've
got
content
types
and
then
that's
not
even
getting
into
content
and
coding
versus
transfer
encoding.
I
think
it
is
there's
there's
lots
of
weird
stuff
that
happens
in
http
that
we
all
just
kind
of
deal
with
on
a
day-to-day
basis.
Http
message
signatures
is
designed
to
live
in
that
space.
C
Add
something
into
that
as
well.
This
goes
back
to
exactly
we're
saying
earlier
around
the.
If
you
have
an
api
and
you're
building
a
new
api
and
you
you
want
to
pack
everything
into
a
jot
and
that's
your
api
request
and
that's
you
stick
it
in
the
body.
You
don't
care
about
the
rest,
hp
request,
it's
just
there
to
get
it
from
point.
A
to
point
b,
cool
that
works.
That's
awesome
go
do
that.
C
F
Yeah
and-
and
we
could
get
into
architectural
arguments
about
why
one
way
or
the
other-
but
you
know
there
are
a
couple
of
really
really
really
important
features
of
http
message
signatures.
As
of
the
current
draft
that
are
apropos
here,
one
of
them
and
this
one
I
really
really
like
annabelle
and
I
came
up
with
a
way
to
allow
http
message,
signatures
to
use
jwa
and
jwk
for
algorithm
resolution.
F
F
The
other
thing
that
you
can
do,
which
is
really
really
neat
and
important
in
these
multi-tier
http
systems
that
we're
all
building
today,
is
that
there's
a
lot
of
advanced
http
stuff
that
we
can
now
support,
such
as
change
signatures,
which
is
to
say,
for
example,
I
send
a
message
and
it
gets
and
it
gets
dropped
onto
a
reverse
proxy.
The
reverse
proxy
is
in
the
perfect
position
to
validate
all
of
that
validate
the
signature,
because
you
know
it
can
look
up
the
key
it
has
that
original
message
object.
F
It
can
do
all
of
that,
and
then
it
needs
to
toss
that,
along
with
someone
else
well
message.
Signatures
gives
us
a
way
to
for
that
intermediary
to
sign
the
original
signature.
So
the
downstream
party
can
now
validate
the
intermediary
signature
and
know
that
that
incoming
message
went
through
the
known
intermediary,
and
this
is
something
that
it's
it's
a
really
really
amazing:
security
property
that
a
lot
of
other
either
message-based
systems
or
point-to-point
systems.
F
Don't
really
give
you
without
like
massive
encapsulation
and
and
other
kinds
of
stuff
that
makes
it
really
really
complex,
such
as,
for
example,
the
you
get.
A
jws
object
and
the
payload
is
another
jws
object
which
its
payload
might
be
a
jwe
object,
and
you
gotta
unspiral
all
of
that
these
they
they
live
together
using
again
that
structured
header
syntax.
F
So
that
brings
us
to
my
last
slide
and
my
suggestion
for
next
steps
is
that
we
basically
delete
the
content
of
the
current
expired
oauth
group
sign
http,
request
draft
and
tell
it
to
use
http
message
signatures
in
the
ways
that
I've
been
talking
about
here.
The
core
of
it
is
a
relatively
short
profile.
Here's
what
you
have
to
sign!
Here's,
how
you
add
the
token
into
it
that
kind
of
stuff.
F
But
that
brings
us
to
a
lot
of
really
important
questions
for
the
oauth
working
group.
How
do
we
do
key
management?
You
know
for
requests
to
the
auth
server.
We
can
tie
it
to
a
client,
but
does
the
resource
server
need
to
know
now
client
ids,
or
can
we
do
per
token
lookup
or
something
like
that?
You
know
how
do
you
discover
that
this
feature
is
available?
You
know
this.
F
A
Okay,
thanks
justin,
so
just
before
we
get
into
that.
So
I
pasted
that
that
link
again
to
to
the
chat,
please,
if
you
haven't
added
your
name
to
the
list,
go
and
add
your
name,
because
I
see
we
have
only
eight
people
added
themselves.
While
we
have
about
14
people
here,
so
please
go
ahead.
Add
your
name
any
comments,
questions
from
people.
I
think
you
can
join
the
queue
if
you
want
to
use
this
feature
or
add
your
name
to
to
the
chat
there.
We
can.
I
Kind
of
allow
you,
I
don't
know
anyway,
go
ahead.
Yeah
no
worries.
I
just
wanted
to
ask
a
clarifying
question
on
those
next
steps,
so
the
thinking
is
to
take
that
http.
This
document
and
profile
a
little
bit
add
some
oauth
stuff
in
the
front
and
back,
and
we
us.
We
basically
assume
the
constraints
of
what
that
draft
provides
us
in
terms
of
the
capabilities,
and
then
we
say
done
is
that
roughly
the
thinking.
F
Yeah,
with
with
the
caveats
of,
we
need
to
be
able
to
answer
these,
these
open
questions
at
the
bottom
and
that
may
be
within
the
same
document
or
it
might
be
within
a
suite
of
documents,
which
was
the
previous
approach,
because
we've
got
the
oauth
pop
architecture
and
the
oauth
key
distribution
drafts,
neither
of
which
progressed
either
so,
but
at
a
very
minimal
level.
Yes,
we
would
just
say
that
this
is
how
you
take
an
oauth
token
and
send
it
using
http
message:
signatures.
B
B
B
F
Thanks
yeah
I'll
I'll,
just
I
just
wanted
to
to
echo
that
yeah.
There
were
a
lot
of
issues
with
the
cabbage
draft
back
in
the
day,
and
frustration
with
that
and
seeing
so
many
different
splintered
versions
of
that
is
a
large
part
of
why
annabelle
and
I
stepped
in-
to
kind
of
pick
this
up
and
pitched
it
to
to
the
http
working
group,
which
has
been
very
very
receptive
of
this.
C
Yeah
yeah
they've
been
great
they've,
provided
a
lot
of
a
lot
of
good,
challenging
feedback
too
and
and
credit
to
them.
You
know
that
that
working
group
for
making
structured
field
values
happen
because
yeah,
that's
that's
huge.
That's
gonna!
It's
super
helpful
for
this
draft.
It's
going
to
be
super
helpful
for
a
whole
lot
of
things
moving
forward.
I
think.
F
A
I
D
Go
ahead,
it
keeps
asking
me
about
my
microphone,
so
I'm
always
unsure,
but
yeah
yeah,
also
as
I
posted
on
in
the
chat.
You
know
thanks
a
lot
for
for
the
work
just
in
an
annual.
This
was
sort
of
a
frustrating
topic
that
obviously
followed
us
for
for
many
years,
and
I
was
actually
not
expecting
you
guys
to
come
back
so
soon.
With
this,
it
looked
like
a
more
a
longer
endeavor
to
figure
this
out,
but
looks.
F
F
Yeah
so
as
annabelle
clarified
in
chat,
you
know
this
this.
This
draft
isn't
done
in
http.
It's
it's
still
got
a
ways
to
go,
but
we
really
think
that,
with
the
last
version
that
we
just
published,
we
kind
of
turned
a
corner
like
you
guys
all
know
that,
when
you're
working
on
a
on
a
spec,
you
kind
of
you
hit
a
point
where
it
feels
like
a
lot
of
the
background.
F
Churn,
has
kind
of
settled
down
and
sure,
there's
going
to
be
bike
shedding
of
terms-
and
you
know,
details
of
of
getting
this
stuff
right,
especially
with
the
header,
normalization
and
all
that
other
stuff,
but
the
basics
of
it.
We
feel
like
it
is
now
in
a
good
place
where
people
can
go,
try
out
implementing
it.
Try
profiling
it
like
this
is.
This
is
how
it
needs
to
be
exercised.
F
F
H
H
I
don't
know
if
you've
come
to
that,
but
that
that
might
be
worthwhile
knowing
about
as
it
may,
simplify
some
of
the
pain
and
the
the
the
whole
semantics
of
what
is
signed
and
all
that
I
going
back
a
few
slides.
You
don't
need
to
go
back,
but
the
question
about
whether
or
not
to
deal
with
partial
query
string
signatures.
H
I
believe
your
pain.
I
think
that
maybe
it's
less
of
an
issue
these
days
as
fewer
and
fewer
applications
are
using
parameter
of
form.
Encoded
parameters
that
could
be
embodied
could
be
in
in
the
query
string
and
as
as
the
world
moves
the
json
and
beyond
that.
My
sense
is
that's
not
worth
trying
to
to
make
a
special
case
or
exception
for
just
a
thought
and
then
just
logistically.
H
H
E
F
F
Of
the
questions
we
have
to
do
is
like
again,
one
of
one
of
dpop's
brilliances.
Is
that
it
just
kind
of
chucked
all
that
out
the
window
and
was
just
like
no
you're,
always
using
asymmetric
keys
and
you're,
always
presenting
them
and
just
deal
with
it
and
and
so
yeah
with
this
being
a
intentionally
a
wider
thing.
Those
are
other
questions
that
we
have
to
answer
either
in
this
document,
whatever
it
ends
up
being
or
in
a
companion
document,
but
it
has
to
be
answered.
H
H
A
Okay,
so
it
seems
that
there's
lots
of
interest
here
and
I
see
people
dropping
but
raise
of
hands
if
you
support
kind
of
working
on
this
as
a
new
document,
because
I'm
assuming
we,
we
don't
want
to
really
revive
that
old
document.
So,
let's
say
because
it
of
this
new
approach
a
raise
of
hand
if
you're
supporting
this
document,
please.
A
C
F
Right,
yeah,
that's!
This
is
why
I
wanted
to
have
this
meeting
instead
of
just
kind
of
sneakily
saying,
like
hey,
there's
a
new
version,
yeah
yeah.
I
think
we
don't
need
to
ask
the
question
right
right
so,
but
functionally
I
just
want
to
say
from
an
editor's
perspective.
The
only
thing
that
would
remain
would
be
the
url
like
this.
This
is
new
content.
A
A
C
A
A
F
No,
I'm
I'm
good
guys.
Please
take
a
look
at
the
message
signatures
draft
when
you
get
a
chance,
it's
got
a
lot
of
examples
and
stuff
it'll
give
you
a
feel
for
the
structure
that
we're
talking
about
and
how
we're
looking
to
use
it.
The
kinds
of
questions
we're
going
to
need
to
answer
all
right.
Thank.