►
From YouTube: IETF97-OAUTH-20161116-1520
Description
OAUTH meeting session at IETF97
2016/11/16 1520
A
B
So,
let's,
let's
start
Brian,
we
have
a
note
taker,
not
yet
Wes,
Wes
Mike,
dhoni
wit.
Did
you
see
Mike.
C
D
Did
toe
combining
we
were
finishing
with
token
exchange
I
think
there
were
a
couple
sort
of
hanging
pieces
of
that
at
the
end,
one
was
a
request
from
torsten
in
particular,
but
I
think
it's
a
more
general
thing
that
need
to
further
explain
the
relationship
between
resources,
the
resource
parameter,
the
audience
parameter
and
the
scope
parameter
and
I've
talked
with
them.
A
little
bit
off.
I
think
I
know
what
to
do.
D
If
you
have
thoughts
about
that
chat
with
me,
but
that's
what
I'm
thinking
right
now
arm
there
was
a
hope
to
get
it
to
working
group
last
call
at
least
from
me,
but
it
sounds
like
people
are
interested
in
holding
off
a
little
bit
for
some
implementation.
Experience
I
think
that's.
B
Right,
I,
don't
I,
don't
remember
who
such
as
did
that,
but
just
to
get
an
idea
I'm
talking
about.
Can
you
it
yeah?
Okay,
thanks
Mike
me:
can
you
take
notes
like.
E
F
B
D
B
So
do
we
so
who
I'm
so
talking
about
the
doc
needs
change
when
who
is
currently
implementing
token
exchange
for
planning
to
do
that?
Raise
your
hand
finding
one
two,
three
four
five:
five,
that's
good
so
like
if
we
are
able
to
collect
the
feedback
from
those
five
folks
or
five
groups,
that
would
already
I
think
push
us
forward.
Quite
a
bit
God
could
maybe
I
should
maybe
we
should
write
down
what
who
those
five
people
are
I
saw.
Justin
I
saw
you
brian
mike
vick
and
Tony.
G
B
D
D
You
tell
my
wife
that,
and
my
kids,
probably
in
in
December,
sometime
okay,.
I
D
That's
I
think
that's
course.
J
J
We
had
some
discussions
in
Berlin
about
that
would
be
a
great
idea
to
have
a
comprehensive
list
of
all
the
topics
that
are
right
now
floating
around
on
a
really
soft
implementation
issues,
our
new
security
threats
and
so
on
arm,
and
we
sat
down
and
try
to
start
work
on
those
draft,
and
the
motivation
basically
is
because
arm
Oh
of
itself
was
published
in
2012
and
got
massive
traction
since
then,
and
what
we
have
seen
in
the
wild
is
that
there
are
some
practical
issues
with
implementing
it
correctly,
typically
basic
stuff
like
I
access,
RF
or
openly
directors
and
so
on,
and
we
thought
it
would
be
a
good
idea
to
give
recommendations
to
developers
how
to
do
it
right.
J
That's
the
first
motivation
second
motivation
arm
my
feeling
is
technology
or
the
underlying
of
Technology
Oh
off
changed
a
bit.
For
example,
the
wave
fragments
are
handled
in
when
redirects
occur
and
user
agents
arm,
and
we
should.
We
should
analyze
that
and
then
find
out
what
the
body
consequences
are,
for
example,
on
the
implicit
grant.
Well,
there
are
also
changes
that
will
support
us
in
getting
off
security.
Tighten
up.
For
example,
the
claims
URLs,
which
are
supported
by
some
of
the
major
mobile
operating
systems.
J
It
turned
this
back
to
me
and
last
but
not
least,
are
when
we
published
off
originally
arm
the
typical
setup.
Looked
very
simple:
there
was
a
single
client
connecting
to
a
single
a
s
and
interacting
with
a
single
resource
/,
and
this
is
changed
significantly
significantly.
So,
for
example,
in
in
through
Paul
you
login
or
federated
login
scenarios,
clients
typically
connect
to
more.
Oh
thank
you.
That's
cool,
so
I'm
in
full
control
again.
J
So
if
you,
for
example,
take
a
look
into
federated
identity
scenarios,
they
are
a
client
typically
connected
to
more
than
one
IDP
and
they
typically
have
today
in
blind
all
of
our
open
ID
connect,
and
this
opens
arm
and
attack
angle
for
things
like
mix
up
attack
and
so
on
things
we
we
didn't
really
consider
when
writing
the
60
original
security
threat
model,
but
more
is
going
on
or
coming
up
more
dynamical
scenarios
are
being
used
in
conjunction
with
OAuth
and
I.
Think
those
reasons
or
those
different
different
motivations
drove
us
to
to
writing
this.
J
J
All
the
all
the
holes
that
we
see
today
and
I
would
also
like
to
capture
the
status
of
discussion,
and,
if
you
take
a
look
on
to
the
drafts
by
the
way,
has
some
one
of
you
already
read
the
draft
you're
my
hero
I
mean
you
are
co
awful,
so
yeah,
right,
okay,
so
I
read
it
as
well.
So
thank
you
very
much
your
heroes.
J
So
if
you
could
take
a
look
on
to
the
draft-
and
you
will
see
that
before
example
for
the
different
medications
that
we
already
described,
we
discuss
the
pros
and
cons
for
those
different
medications.
So
what
I
would
like
to
to
come
up
with
is
a
document
that
facilitates
the
discussion
process
within
the
working
group
and
we
do
not
plan
to
document
all
the
threats
and
all
the
countermeasures
in
this
document,
but
to
have
a
kind
of
an
umbrella
document
and
to
refer
to
all
the
drafts
that
other
people
already
have
written
down.
J
J
So
the
long
term
goal.
From
my
perspective
and
the
perspective
of
my
my
co-authors,
is
we
come
up
with
ideas?
What
all
of
extensions
we
really
need
to
define,
for
example,
for
code
injection
prevention
and
we've
write
down
a
comprehensive
list
of
items,
actions
or
things
a
developer
needs
to
implement
in
order
to
implement
all
of
in
a
secure
fashion.
The
bullet
I
gave
are
just
examples,
so
this
is
not
the
real
list.
J
What
just
to
get
to
give
you
an
impression,
so
that
could
be
a
PCP
and
either
return
this
document
in
the
PCP
or
write
a
new
by
CP
I.
Don't
I
don't
care
about
that
right.
So,
but
that's
that's
the
long-term
goal
so
that
we
come
up
with
a
real,
comprehensive
description.
If
you
want
to
do
it
right,
do
it
that
way?
J
J
We
first
have
a
section
describing
the
different
means
to
steal
credentials
of
the
leak
credentials
and
off
credentials,
meaning
access
tokens,
authorization,
codes,
refresh
tokens
and
we've
got
a
section
describing
the
different
threats
regarding
injections,
the
code
injection
access
hook
and
injection
all
this
stuff
xrf,
and
we
also
have
a
section
about
open,
redirect,
errs
and
all
the
sections
that
have
a
TBD
in
the
title
are,
as
the
name
suggests,
to
be
determined.
So
we
focused
in
the
first
version.
J
Oops,
okay.
So
from
my
perspective,
if
the
working
group
decides
to
adopt
this
document
and
to
use
it,
the
way
we
are
proposing
the
next
will
believe
is
that
next
step
will
be
to
complete
the
description
of
all
the
different
threads
and
the
mitigations
and
to
really
have
a
discussion
in
the
working
group
about
the
mitigations.
Their
assessment
from
client
side
perspective,
server,
perspective,
cost
perspective
complexity
perspective.
J
All
that
all
those
different
aspects
that
needs
to
be
into
so
taking
into
account
when
meeting
the
decision
to
what
are
we
gonna
recommend
and
then
we
should
document
that
and
start
work
on
on
on
on
PCP.
So
that's,
basically
the
idea
and
from
tactical
perspective,
I
would
like
to
to
get
your
feedback
on
under
your
single
magazine
makes
sense
what
we
proposing
and
what
are
the
next
topics
you
would
like
us
to
cover
and
us
meaning
the
working
group.
K
So
we've
had
a
lot
of
discussion
at
Microsoft
lately
about
this
particular
topic,
and
you
said
that
and
I'm
just
not
quite
sure
what
your
intent
is
here
right,
there's
over
12
documents
that
are
in
the
list
today
that
have
been
standardized.
Our
developers
can't
piece
the
12
together
and
understand
what
to
do
and
what
not
to
do,
I
think
understand
and
so
I
don't
know
what
you'd
run.
K
What
you're
trying
to
mitigate
are
you
trying
to
combine
them
all
together
and
find
out
the
mitigations,
be
issues
and
mitigations
between
all
the
specs
when
they're
used
together
or
you're
just
talking
about
OAuth,
so
I'm
a
little
little
confused
on
you
know,
what's
your
total
goal
is
and
I'm
also,
you
know
carrying
on
the
message
from
from
Microsoft
that
this
is
it's
somewhat
getting
out
of
hand
for
our
developers,
all
the
all
the
specs
that
are
that
are
here
and
how
and
so
what
happens?
Is
they
wind
up
creating
their
own?
K
K
J
It
but
it
sounds
all
I
answered
a
question
yeah
because
it
was
erected.
K
J
Its
broad
enough,
surprisingly
I
would
agree
with
you
I
think
it's
not
enough
what
what
we
trying
to
focus
on.
First,
all
the
obvious
problems
and
the
obvious
problems
are
the
threats
we
have
been
discussing
for
a
year
or
now
and
didn't
come
to
a
conclusion.
Yeah.
K
J
Less
so,
first,
first
of
all,
one
of
the
reasons
why
we
need
this
document
is
from
my
perspective,
because
we
didn't
really
evolved
and
enhance
the
securities
fraud
model.
The
overall
security
threat
model
why
we
were
adopting
auto
specifications,
namely
our
dynamic
registration
for
example,
which
which
changed
the
capabilities
of
all
of
a
lot.
Didn't
we
didn't
do
that
now
we
somehow
try
to
to
to
fill
those
or
fill
this
hole
and
I
also
feel
that
our
documents,
like
the
RBC,
p
or
native
apps,
address
a
real
need,
so
I
think
beside
the
specs.
K
Little
bit
more
guidance,
but
you
know
these
add-ons
aren't
making
a
lot
of
sense.
I
mean
pixie
was
just
a
patch
I,
don't
think
it
was.
You
know
well
thought
out
and
in
something
that
you
know
we
could
have
avoided
earlier,
and
so
we
have
these
little
patches
that
are
been
placed
around
here.
So
I
think.
J
That's
a
question
folder
for
the
working
open
general.
My
personal
opinion
on
that
speaking
as
torsten
I
think
we,
like
an
architecture
overview
on
a
vision
and
that's
why
we
have
this
pesci,
a
landscape,
yeah,
that's
it
and
may
I.
I
would,
I
would
say
we
need.
We
need
more
bcp
documents
for
different
kinds
of
applications.
I
the
other
day,
I
talk
to
one
of
our
architects
and
we
were
talking
about
how
to
implement
multi-tenancy
resource
service,
the
resource
service
that
have
relationships
with
different
autorisation
service.
J
This
is,
from
my
perspective
and
very
interesting
topic
that
could
be
solved
different
in
different
ways.
I
think
this
is
another
example
where
we
really
need
a
PCP
or
your
question
take
over
over
dinner
on
Monday,
who
actually
does
refresh
crop
rotation,
but
why?
Because
it's
not
documented
in
the
RC.
L
Benkei
duck
I
also
support
this
work,
I'm
really
happy
you're
doing
it,
I'm
going
to
say
Kathleen's
name
to
get
her
attention,
but
if
this
is
a
supposed
to
be
used
to
living
document,
this
particular
thing
I
feel
like
you
should
just
go
ahead
and
do
it
and
not
even
bother
asking
for
a
working
group
adoption,
because
if
it's
not
going
to
be
published,
I
mean
you
only
care
about
working
reproduction
by
the
time
you
want
to
make
a
bcp.
Why
don't
you
just
do
the
word?
No,
not
necessarily
don't.
B
So
you
can
still
have
a
document
sort
of
the
fact
that
it's
a
working
group
document
and
services
as
a
Dawson
said
a
point
for
discussion,
which
then
points
to
the
documents
that
mitigate
specific
solutions
and
infer
the
PCB
documents.
You
could
still
have
a
lot
of
value
and
gives
people
an
indication
like
what
we
are
we
working
on,
rather
than
having
an
independent
individual
submission.
That
is
one
of.
J
Many
so
just
to
say
that
clearly,
I'm
not
interested
in
having
a
draft
that
just
expresses
Maya,
John
and
Andres
opinion
I
want
to
gather
the
opinion
of
all
the
working
group
members
and
to
come
up
with
a
conclusion.
What's
the
right
mitigation.
Otherwise,
we
want
come
to
a
conclusion,
because
what
I
have
been
observing
is
we
didn't
come
to
any
conclusion
for
any
of
the
of
the
open
security
issues
in
one
year.
L
M
J
J
N
John
Bradley
I
support
having
best
current
practices,
I
think
it's
a
dot
if
we
decide
to
start
this
work,
I
think
that's
a
document
management
issue
that
in
some
cases
it
may
make
sense
to
have
modular
things
like
native
apps,
single
page
applications
that
developers
who
are
interested
in
how
do
I
use
OAuth
to
do
a
specific
thing
may
find
more
approachable,
but
we
have
to
do
the
work
anyways.
We
we
can
later
decide
how
we
divided
up,
whether
it's
one
large
monolithic
document,
yeah
everybody's,
going
to
no
matter
what
we
do.
N
N
Some
large
organizations
and
governments
etc.
If
it
doesn't
have
an
RFC
number,
it
doesn't
really
exist.
So
you
know
yes,
we
can
have
a
living
document
that
that
keeps
us
all
happy,
but
unless
we
snapshot
from
time
to
time
when
I'm
talking
to
just
on
government-
and
they
say
well,
what's
you
know
what's
the
standard
we
you
know?
Is
it
an
iso
standard
know
it's
an
ietf
standard?
Oh
well,
I
guess.
But
if
it's
an
individual
submission
you
know
they
just
don't
take
it
as
seriously.
B
I
have
one
question
on
what
Dhoni
was
proposal
and
proposing
and
what
you,
because
a
python
is
a
sort
of
this
architecture
and
I
am
not
quite
sure
how
that
looks
like
so,
for
example,
the
best
current
practice
for
the
native
apps.
In
some
sense,
this
is
an
architecture
because
it
talks
about
the
specific
aspect,
the
specific
deployment
very
end.
B
Then
it
makes
dice
a
couple
of
specifications
together,
sort
of
epic
architecture,
something
that
is
or
a
single
architecture
is
very
difficult
to
create
in
in
OS,
because
all
along
it
was
used
in
in
very
different
context.
So
I'm
curious
on
how
that
would
look
like,
and
maybe
you
guys
can
earn
enlightening.
John.
N
Again,
I
think
maybe
we
could
have
a
stab
at
an
overall
architecture
but
from
a
developer
point
of
view,
I
think
that
the
architecture
to
do
some
particular
task
is
more
approachable,
but
somebody
who's
doing
a
native
app
doesn't
necessarily
need
to
know
about
token
exchange
and
various
other
things
you
know.
So
if
we
can
focus
the
the
BCPS
to
be
more
task,
oriented
I
think
that
that's
going
to
be
more
helpful
and
I
also
think
that,
along
with
bcp
like
we
did
with
native
apps,
we
also
at
least
in
the
open
ID
foundation.
N
We
created
actual
open
source
libraries
that
developers
could
look
at
the
code
and
figure
out
how
to
do
it
as
examples
it's
not
just.
You
know.
This
is
the
high
level
architecture,
because
developers
again
relate
more
to
actual
code
examples
or
things
that
they
can
incorporate
each
other
their
operation.
B
For
those
who
had
read
it
it
points
to,
for
example,
pixie
and
it
this
discusses
other
aspects
and
so
I'm
borrowing,
whether
we
are
like
what
we
do,
whether
we
are
so
far
off
what
you
guys
are
actually
talking
about.
We
just
need
to
sort
of
continue
along
that
line,
at
least
from
the
act
I'm
talking
about
really
about
the
architecture
stuff.
N
B
Start
with
one,
and
then
it
was
well-received
so
right
we
add
another
one
and
I
think
that's
I'm.
To
me,
it
sounds
like
from
a
from
a
type
of
approach
to
the
work
seems
to
be
more
manageable,
rather
than
sort
of
trying
to
work
out
the
architecture
which
sir
no.
N
And
the
good
thing
about
that
is
that
we,
actually
you
know,
William
and
I-
have
gotten
a
lot
of
feedback
from
the
development
community.
It
hasn't
been
just
us
telling
them.
You
know
this
is
the
way
to
do
it.
Well,
mostly,
it's
that,
but
you
know
they
do
actually
give
us
feedback
on.
Well,
have
you
thought
of
this
in
this
particular
environment?
Did
you
know
that
Windows
acts
in
this
particularly
bizarre
way,
et
cetera
so
having
that
feedback
from
the
developers,
because
there
is
an
open
source
project-
is
helpful?
Okay,
so.
J
Toastin
from
my
perspective,
after
listening
to
discuss,
I
think
it
in
the
end,
it
would
make
sense
to
have
BCPs
for
different
kinds
of
things
as
their
a
dick
call
it
so
for
different
kinds
of
kinds
of
clients,
but
also
for
different
scenarios
and
different
all
kinds
of
resource
and
authorization
service.
The
question
is
how
to
approach
that
and
and
which
tpc,
which
PCP
is
the
right
down
and
I.
J
Think
if
we
write
BCPs
for
this,
those
different
arm,
clients
types
that
we
should
also
incorporate
the
security
stuff,
but
I
also
think
that
the
securities
fraud
model
and
the
analysis
and
the
mitigations
are
cross-cutting
concerns.
So
I
think
it
makes
a
lot
of
sense
to
to
to
to
work
this
way,
and
then
we
need
to
decide
which
BCPs
to
to
write
in
afterwards.
That
would
be
my
proposal.
J
Or
less
yeah
iiiii,
I'm
rather
reluctant
to
call
it
the
bcp,
but
I
can
live
us
out
early
yeah,
it's
just
an
informational
draft
run
so
discussion.
J
J
J
If
people
could
tell
us
which
types
of
client
and
which
scenarios
they
carry
the
most,
so
would
you
like
us
to
take
a
look,
especially
into
JavaScript
apps
or
a
single
page,
apps
or
whatever,
because
in
the
end,
redirect
URI
validation,
for
example,
works
completely
different
for
those
different
client
types
and
we
need
to
anyhow,
I
distinguish
those
in
the
draft,
so
what
I
would
like
to
suggest
will
oppose
the
message
to
the
list
or
so,
and
people
can
can
can
can
propose
which,
which
scenarios,
which
kind
of
applications,
clients
and
back-end
system
they
want
us
too,
to
consider
and
but
will
be
also
an
indication
where
we
need
pc
ps4.
B
Let's
have
William
say
something:
hi.
P
Yeah
I
actually
think
this
should
be
a
DCP
and
that
it
probably
should
obsolete
RFC
6890
if
possible,
and
what
what
I
like
about
the
bcp
model
is
that
it
does
allow
that
kind
of
snapshotting
that
that
people
been
talking
about
so,
which
I
think
is
a
valuable
thing
now
and
people.
You
know
last
cool
to
give
that
stable
identifier
for
all
the
security
issues,
so
I'm
definitely
supported
over
security.
Bcp.
J
B
Let's
so
I
will
ask
who
is
are
in
favor
against
adoption
of
the
document
that
toss
was
just
talking
about
and
introducing
to
us.
So
please
raise
your
hand
if
you're
in
favor
of
adopting
that
document.
As
a
working
group
item
I
see
about
yeah
two,
four,
six,
eight,
nine,
nothing
beyond
certain
hands,
husa
again
against
I'm
adopting
this
document
is
working
to
bite
them.
F
B
F
Yeah:
okay,
okay,
good
thanks
good
thanks,
Oh.
F
Q
Do
Oh,
does
it
work
yeah?
It
works,
awesome,
okay,
so
I
want
to
talk
about
what
is
currently
listed
as
the
OAuth
age
should
be
signing
draft.
Q
The
whole
motivation
behind
the
entire
pop
architecture
was
to
have
something
that
was
roughly
in
parity
with
bearer
tokens,
so
you
need
a
way
to
get
a
token
need
a
way
to
use
the
token
need
various
ways
to
validate
the
token
as
it's
being
presented
at
the
protected
resource
and
so
getting
a
token
is
really
pretty
much
the
same,
except
that
you
get
a
key
associated
with
that.
We've
got
a
different
document.
That's
working
on
how
to
do
that.
Whether
or
not
the
client
presents
the
key
or
has
the
key
issued
by
the
EAS.
Q
We're
not
talking
about
that
here.
Right
now,
validating
a
token
we
toss
our
hands
up
in
the
air
and
say
it's
up
to
you:
go
figure
it
out,
but
obviously
we've
got
introspection
jot
and
a
bunch
of
other
things
that
will
need
to
be
adapted
for
use
in
the
pop
world.
What's
interesting
in
this
conversation
is
the
middle
one
is
how
do
you
use
one
of
these
pop
tokens?
So
you
go
through
all
this
work
to
associate
a
key
with
the
token
and
how
do
you
get
it
over
to
the
protected
resource?
Q
Okay,
this
is
how
you
kind
of
do
the
whole
thing
and
the
signing
bits
for
the
HTTP
request.
Message
are
really
optional
additions.
On
top
of
that,
however,
that
seems
to
really
confuse
use
a
lot
of
people
so
I'm
going
to
break
down
today
exactly
how
these
things
all
fit
together.
First
off
we've
got
signing
and
it's
basically
you
take
a
JSON
object.
You
put
your
access
token
inside
of
it
you
put
currently
it's
in
there
as
a
timestamp.
Q
It
could
be
a
nonce
I,
really
don't
care
just
some
way
to
have
a
non-repeatable
transactional
kind
of
thing
of
some
type
in
there,
whatever
wrap
that
in
a
JSON
web,
stick
signature
and
sign
it
with
the
key
associated
with
the
token
really
not
hard
since
we're
using
josé
there's
a
crypto
agility
re
in
there.
If
you
want
to
do
elliptical,
curves
or
shared
secrets-
or
you
know
the
Jose
quantum
cryptography
draft
that
somebody's
going
to
write
some
day,
I
don't
care,
you
know
it's
jose.
It's
a
jws!
Q
It's
not
a
JWT,
incidentally,
because
this
is
not
really
an
assertion.
It's
not
carrying
sort
of
application
level.
Information
that
a
jot
normally
would,
but
we
are
using
the
jws
general-purpose
structure
for
carrying
this
stuff
over
presenting
the
token
is
really
in
parallel
with
6750,
so
chuck
it
in
a
header
chuck
it
in
a
form
body
checking
in
query
parameter.
We
did
all
three
with
pretty
much
the
same
caveats
and
limitations.
Q
That
6750
has
because
that
honestly
hasn't
really
changed
all
that
much
in
the
last
four
years,
except
for
the
fact
that
the
middle
one
is
I
would
honestly
be
willing
to
drop
the
form
parameter
because
back
when
we
wrote
Oh
off
to
form
encoded
in
JSON
out
was
sort
of
the
the
rule
of
the
day
for
writing
an
API
these
days.
That's
just
not
true.
It's
JSON
and
both
JSON
out
so
I'd
be
happy
to
drop
that
one
I,
don't
think
we
really
lose
anything
for
having
it
in
or
out
of
there.
Q
The
other
two
I
do
think
are
important
because
they
have
very
specific
use
cases
and
yes,
I
do
even
mean
the
query
parameter.
But
that's
not
what
I'm
here
to
argue
today
when
I'm
here
to
argue
today
is
the
third
bit
is,
and
that's
actually
the
HTTP
message
signing.
This
is
something
that
ofone
did
that
OAuth
2
doesn't
now
there's
very
good
reasons
that
OAuth
2
dozen
part
of
that
is
that
a
lot
of
developers
got
this
wrong
in
both
one,
and
we
know
this.
Q
Q
Well,
what
we're
going
to
do
is
we're
going
to
use
that
to
create
a
detached
signature
of
the
HTTP
message
now,
unlike
existing
HTTP
signature
methods
that
are
out
there,
so
AWS
has
their
own
proprietary
one.
There
been
a
few
others
that
are
floating
around
this
one
does
not
assume
that
the
HTTP
message
remains
unscathed
throughout
the
process.
Instead,
it
very
much
admits
that
lots
of
things
can
go
wrong
in
the
middle
of
it.
What
that
means
is
that
this
is
not
a.
Q
This
is
not
just
take
the
HTTP
request
exactly
as
is
and
create
a
signature,
then
take
it
exactly
as
is
and
re-sign
it
on
the
other
side.
No,
instead
that
this
is
designed
for
a
world
where
things
get
manipulated
in
the
middle
headers,
get
injected
query
parameters
get
mucked
around
all
kinds
of
stuff,
like
that.
Q
That's
not
going
to
get
screwed
up
on
the
way
through,
and
it's
up
to
the
application
on
the
far
side
to
make
sure
that
the
stuff
that
comes
in
and
decide
is
the
stuff
that
it
cares
about
and
the
stuff
that
makes
sense
for
it
to
be
able
to
do
its
job.
Yes,
this
is
a
compromised
position
and
I
think
that
this
is
actually
a
reasonable
compromise.
Q
Given
the
complexity
of
the
HTTP
protocol
and
the
complexity
of
HTTP
deployments
in
all
of
the
different
ways
that
they
can
get
screwed
up
on
the
way
through
any
given
process,
anybody,
that's
done
a
reverse
proxy
or
any
type
of
HTTP
application
framework
will
know
the
pain
that
this
can
cause.
If
you
have
something
that
assumes
sort
of
you
know,
static,
pristine
preservation
of
the
HTTP
messages
on
either
end
IE
anybody
that's
tried
to
write
an
oauth
one
client
in
any
of
those
situations.
Now,
anyway,
this
is
not
fully
comprehensive.
Q
There
are
some
corner
cases
that
it
doesn't
cover
and
we've
enumerated
those
and
just
said
that,
if
you
have
you
know,
if
you
have
stuff
that
fits
in
these
cases,
don't
sign
that
bit.
You
can't
sign
it
so,
instead
of
making
this
try
to
bend
over
backwards
to
fit
every
last
weird
corner
case
of
HTTP,
of
which
there
are
a
lot,
we
just
said
this:
doesn't
this
doesn't
do
that
part?
It
doesn't
go
that
far
and
that's
that's
ok,
so
you
sign
what
makes
sense.
That's
really
kind
of
the
the
gist
of
this
whole
thing.
Q
The
key
point
here
is
that
this
is
all
optional.
This
is
all
optional
in
today's
draft
spec,
you
add
these
components
in
to
the
base
signature.
The
base
signatures
over
the
access
token,
which
is
being
presented,
as
is
uninterpreted
by
the
client,
still
opaque
to
the
client
just
like
a
bearer
token,
and
that
nonce
timestamp
transactional
identifier,
whatever
we
end
up
wanting
to
call
it.
This
is
all
in
addition
to
that.
Q
Q
We
put
the
HTTP
signing
in
a
separate
document,
how
it
was
in
the
first
place,
and
we
put
the
core
signing
bits
in
their
own
document
and
we
move
the
two
forward
together
and
if
somebody
wants
to
raise
a
stink
and
say
that
the
HTTP
signing
is
experimental,
I'm,
actually,
okay
with
that,
because
it
kind
of
is
because
signing
HTTP
is
really
really
hard
as
it
turns
out,
and
we
have
not
yet
had
a
single,
comprehensive
solution
that
I
have
seen
now
remember.
This
is,
in
fact,
in
a
detached
signature.
Q
This
is
not
taking
the
entire
HTTP
message
and
sort
of
you
know,
encapsulating
it
inside
the
jws.
Nor
is
it
assuming
that
the
HTTP
message
keeps
some
pristine
format
outside
of
the
jdub.
So
it's
not
the
Mike.
Can
you
remind
me
what
the
the
external
jws
is
called?
Okay,
you
wrote
it.
You
wrote
it
whatever
Mike's
last
draft
and
Jose
was
it's
not
that
either
thanks
anyway,
so
my
suggestion
is
that
we
move
both
of
these
both
of
these
forward.
Q
If
we
want
to
mark
the
HTTP
signing
and
and
and
have
them
cross-reference,
each
other
so
have
the
course
pack
say
and
hey
if
you
want
to
add
protection
for
the
HTTP
message,
components,
here's
a
way
to
do
that
and
have
the
HTTP
signing
thing
say:
well,
okay,
we're
going
to
tell
you
how
to
hash
the
message:
how
to
do
all
the
verification
you're
going
to
have
to
put
it
somewhere.
You
might
want
to
put
it
into
a
no
op
op
signed
request.
Q
Q
So
I
think
that
there
has
been
some
chatter
about
alternate
presentation
mechanisms,
because
it
seems
that
some
people
forget
that
if
we're
going
to
be
doing
all
this
work
with
our
pop,
we
need
to
be
able
to
send
the
token
from
the
client
to
the
resource
server
in
some
fashion.
But
I
haven't
seen
any
concrete
proposals.
That
said,
even
if
there
were
additional
concrete
proposals,
that's
fine.
We
have
6750
and
whatever
the
kitten
one
is.
Did
the
kitten
know
offing?
Do
you
remember
safley.
Q
Gssapi
thing:
whatever
number
that
one
is:
we've
got
both
of
those
and
they
don't
fight
because
they're
doing
different
kinds
of
things.
You
can
get
the
token
in
the
same
way
and
use
it
in
different
ways,
depending
on
what
kind
of
API
you're
talking
to,
and
everybody
gets
along
just
fine
same
kind
of
things
happening
here,
so
that
was
always
the
intent.
That's
why
token
presentation
was
pulled
out
as
a
separate
document
in
the
early
days,
early
ish
days
of
OAuth
2
to
allow
that
kind
of
protocol
flexibility,
we're
inheriting
that
and
embracing
that
here.
Q
So
if
you've
got
a
different
way
to
present
pop
token
go
for
it,
I
haven't
seen
any
yet,
but
if
somebody
comes
up
with
one
that
doesn't
mean
that
this
one's
not
useful,
also
side,
note
I've
actually
implemented
this.
Both
server
and
client
side
and
a
couple
of
other
people
have
done.
I've
done
their
versions
of
it
as
well.
So
this
is.
This
is
a
thing
that
does
exist.
It's
not
a
thing
that
has
a
universal
applicability,
but
we
know
that
so
bearer
tokens
get
the
job
done
in
a
lot
of
cases
and
that's
fine.
L
Q
Yeah,
we
don't
actually
address
discovery
because
discovery
is
kind
of
a
black
magic
voodoo
box
in
the
OAuth
world
and
it
is
and
so
how
the
client
knows
even
which
server
to
talk
to
oooff
doesn't
care,
and
we
we
inherited
that
attitude.
So
we
could.
We
do
say
that
I
forget
the
exact
word,
but
we
do
say
something
like
the
API
must
document
or
something
like
that
which
things
that
expects
to
be
signed.
But
we
don't
say
what
that
means
yeah.
We
do.
B
On
Monday,
we
had
this
discussion
about
metadata
and
never
smell
a
date
that,
for
example,
also
about
the
resource
so
where
this
could
potentially
belong
to
I.
But
but
I
don't
think
it's
there,
because
the
work
is
still
at
the
yeah.
Q
We
definitely
do
have
security
considerations
about
that.
Thanks
to
Phil.
We've
also
got
some
security
considerations
about
things
like
argument
order
and
a
couple
of
other
things
that
aren't
necessarily
strictly
preserved
by
the
by
the
hashing
process.
So
it
basically
like
if
these
things
really
matter
to
you,
this
isn't
going
to
give
you
that
information.
You've
gotta
have
some
other
way
to
make
sure
that
that
works
so
yeah
we
did.
Q
We
definitely
do
say
that,
because
that
was
actually
the
root
of
a
really
big
problem
in
open
ID
to
real
world
exploit
with
opa
90
to
where
providers
were
taking
in
taking
in
messages
validating
the
signature
and
then
just
assuming
that
everything
that
came
in
was
signed,
which
isn't
the
case,
and
this
is
really
kind
of
its
taking
the
same
approach.
It's
you
list
what
you
signed,
and
you
sign
that,
and
this
is
kind
of
doing
the
same
thing
so
that
this
was
not
fully
invented
out
of
whole
cloth.
Q
B
So
at
the
last
at
the
buena
idea
for
meeting,
which
has
been
unfortunately
wasn't
present
from
did
we
had,
and
at
that
time
we
also
adopted
the
dough
combining
work.
Sort
of
is
a
little
bit
of
bad
at
that
you
got
thoughts.
This
work
and
sort
of
the
perception
was
that
since
we're
working
on
tow
combining,
we
don't
need
this
anymore,
but
I
don't
hear
the
same
type
of
feeling
now
anymore,
so
I,
I
guess
I'm
letting
I'm
leaving
the
question
about
document
management,
the
side.
B
I
think
I
would
like
to
get
a
sense
of
the
room,
what
they
think
about
moving
this
work
forward.
This
is,
and
so
basically
please
raise
your
hand
if
you
think
we
should
try
to
finish
this
work
in
in
the
East
working
group.
This
meaning
HTTP
signing
raise
your
hand
up
in.
H
H
B
That
that
was
could
be
so
1
I'll.
Let
me
try
it
once
more.
It's
late
for
me,
raise
your
hand
if
you
think
we
should
continue
this
work
in
this
working
group
see
two
three
four
five,
six
six
and
please
raise
your
hand
if
you
think
that
we
should
stop
this
work.
You.
Q
So,
as
the
document
editor,
apart
from
doing
the
split,
the
documents
been
done
for
ages,
there's
not
really
been
additional
feedback.
There's
a
handful
of
implementations.
It's
just
the
working
group
has
not
said
kick
it
out
the
door
and
go
from
my
perspective,
so.
M
Concern
is
the
worry
that
if
we
have
this-
and
we
haven't
really
thought
it
all
the
way
through
and
it
isn't
all
the
way
baked
it's
yet
another
spec
for
people
trying
to
figure
out
what
to
do
with
I
wanted
to
do
and
potentially
leads
the
more
sort
of
incompatibility
of
people
trying
to
make
things
work
together.
Torsten.
S
Rich
Saul's
is
a
stranger.
Why
would
splitting
if
it's
been
stuck
for
a
year?
Why
would
splitting
it
unstick
it?
Because.
Q
D
Was
gonna
say
more
or
less
they
should
be
signing
has
been
the
sticking
point
for
a
lot
of
people
I
think
so
maybe
there's
more
hope
for
it
with
just
the
presentation.
Ii
sort
of
a
sidebar
question
is:
is
there
any
mechanism
in
the
presentation,
though,
that
that
keeps
a
token
from
being
presented
by
the
resource
server
to
another
resource
server?
Yes,.
B
Q
Q
D
D
Q
Q
N
So
this
is
John
Bradley,
so
the
token
presentment,
without
actually
having
an
audience
or
destination,
as
part
of
that,
doesn't
actually
move
the
ball
very
much
further
ahead.
So,
if
we're
going
to
split
the
document,
we
should
consider
some
basic
things
so
that
we
actually
meet
the
a
worthwhile
security
goal
by
having
the
presentment
method.
You.
B
Mean
something
like
that:
the
resource
indication,
oh.
N
Q
N
N
H
N
Q
Q
N
But
go
ahead
so
maybe
it's
having
enough
security
considerations
to
understand
that
this
alone,
without
properly
audience.
Restricting
the
actual
token
you
need
to
use
the
HDD
be
signing
to
sign
parts
of
that
yeah.
So
we
just
need
to
make
sure
that
it
actually
is
meaningful
and
actionable,
and
people
don't
wind
up
thinking
that
they
get
security,
that
they
don't
that's
and
that's
an
absolutely
fair
observation.
G
Mike
Jones
I
was
busy
taking
notes
and
didn't
repeat
my
position
at
the
time
that
I'm
already
on
record
for
that
I.
Don't
think
we
need
to
do
this,
it's
not
that
it's
terrible
work
per
se,
but
we're
already
doing
so
many
things
that
I
think
it's
been
starved
for
attention
because
we're
doing
other
things
that
people
consider
higher
priority
and
I
haven't
seen
any
ground
swell
of
people
saying
we're
going
to
implement
this.
G
Q
B
Guess
we
need
to
ask
a
saline
said:
put
it
to
the
list,
it
was
again
a
difficult
discussion,
like
we
had
on
a
mailing
list.
I
hope
we
can
make
some
progress
on
this
topic.
T
B
B
Anyway,
but
anyway
doesn't
matter,
we
put
that
we
need
to
discuss
this
on
the
list,
so
we
have
five
minutes
left
I'm
a
beach
on.
You
could
come
over
here
and
talk
a
little
bit
about
potential
future.
Was
he
I.
N
John
Bradley
ping,
so
we
wanted
to
talk
a
bit
about
some
of
the
new
work
so
on
the
resource
indicator,
which
we've
gone
around
about
several
times:
Brian
and
a
Ryan
reposted.
Our
original
draft,
so
I
will
point
out
that
this
is
essentially
the
same
mechanism
that
as
your
ad
uses
and
when
Tony
gets
a
pal
point
that
out
again
when
he
objects
to
it
as
a
matter
of
principle.
So
there
is
implementation
experience.
N
He's
objecting
you're
confused,
it's
normal
the,
so
we
should
consider
actually
adopting
that,
as
as
working
group
document
I
don't
know,
have
you
with
sort
of
stuck
as
as
an
individual
submission
I.
Don't
so
the
chairs
can
consider
whether
or
not
to
to
adopt
that
there
are
other
BCPs
that
we
just
talked
around.
N
William
I've
had
a
bunch
of
inquiries
from
Microsoft
in
other
places,
around
single
page
applications
and
what
the
best
practices
are
for
that
I'm,
seeing
like
lots
of
Fortune
100
companies
that
have
now
all
decided
that
single
page
applications
are
cool
but
have
no
idea
how
they're
doing
Oh
off
with
single
page
applications,
and
that
is
leading
to
some
interesting
interpretations.
We
can
tell
that
he's
make
that
face
every
time
he
thinks
of
it
and.
B
N
N
N
You
know
what
happens
when
your
RS
gets
a
token
and
you
actually
want
to
do
something
with
it
to
talk
to
another
Rs.
So
I
think
we
have
a
bunch
of
sort
of
server-to-server
documents,
sort
of
user
not
present.
So
there's
probably
another
DCP
that
what
what
happens
when
you
have
this
sort
of
circumstance,
so
that
people
can
actually
see
how
those
various
documents
work
together.
There's
also
let.
B
J
N
J
Toasting
again
so
I'm
what
support
what
you
said:
hanas
I,
think
if
we
make
an
enquiry,
let
people
give
feedback
on
where
they
see
a
real
lead
for
PC
piece,
because
we
we
have
not
that
plenty
of
capacity
and
I
think
we
should
focus
on
the
most
relevant
arm
bc.
Piece,
the
more
the
most
relevant
bc
piece.
K
N
B
We
are,
we
ran
out
of
time,
okay,
but
I'm
going
to
what
I'm
going
to
do
is.
I
would
boost
a
message
to
the
list
to
sort
of
ask
for
the
type
of
needs
for
pcbs
that
people
have
and
then
we
have
to
figure
out
on
how
which
one
of
those
actually
we
can
work
on
first
and
which.