►
From YouTube: IETF105-OAUTH-20190723-1520
Description
OAUTH meeting session at IETF105
2019/07/23 1520
https://datatracker.ietf.org/meeting/105/proceedings/
A
Okay,
welcome
everyone
to
the
first
session
of
faith
and
we
have
two
sessions
a
one
today
and
the
other
one
is
Friday
morning.
Friday
morning
we
have
two
hours,
and
now
we
have
an
hour
and
a
half.
So
let's
get
going
I
think
that
is
that
note
well
bye-bye
now,
hopefully,
you're
familiar
with
this,
so
in
the
blue
sheets
are
out
there
already
we're.
Looking
for
EM
javis
pride,
many
taker
volunteers.
B
D
A
E
A
You,
okay,
let's
get
going
so
our
agenda
and
we
have
ten
minutes
for
a
chairs,
update
and
then
Daniel
will
talk
about
the
office
workshop
for
five
minutes
in
a
dick
will
entertain
us
say
about
reciprocal
or
off
after
that.
Daniel
will
then
talk
about
security,
BCP
and
then
Justin
will
will
entertain
us
this
time
of
what's
really
a
lot
transactional
authorization
and
hopefully
we'll
have
enough
time
for
Anibal
if,
if
we
can't
get
that
we'll
have
to
just
squeeze
it
into
Friday,
we'll
see
okay,
okay,
so
let's
get
started
with
that
without
date.
A
Thanks
for
to
Roman,
we
had
made
lots
of
progress
recently,
hey
thank
you
and,
and
to
that
authors
too,
and
so
it
the
first
one
we're
gonna
talk
about
this
in
later,
a
I
think
on
Friday,
that
which
is
the
the
access
talking
dot
in
the
profile
for
that
Vittoria.
We'll
talk
about
this
on
Friday
in
that
browser
based
app,
we'll
discuss
this
on
Friday
a
device
flow
I
think
it's
say
in
the
editor
queue,
and
there
are
some
editorial
changes.
It's
hopefully
will
be
done
soon.
A
A
F
G
I
J
I
K
Campbell
thing
at
one
point:
the
same
issue
was
raised
with
respect
to
effectively
the
same
document
and
the
open,
ID
baby
connect,
working
and
I
understanding
was
that
it
had
been
decided
there
that
that
document
on
morado,
sir
the
most
commonly
used
cleanse
those
that
were
most
likely
subject
to
collusion
in
the
ANA
registry
for
OAuth
parameter
names.
Did
that
did
that
ever
happen,
or
is
that
being
considered
as
part
of
the
solution?
It
did
it?
L
C
H
H
C
L
F
A
C
C
That
is
being
used
for
authentication
by
the
client
to
the
authorization
server
and
we
tabled
that
issue
and
a
co-worker
of
mine
did
a
formal
analysis
of
it
in
which
concluded
that
it's
fine
from
that
point
of
view
and
I,
he
posted
it
to
the
list,
but
there
was
no
follow-up
discussion
on
this
afterwards.
So
maybe
this
is
also
a
topic
that
a
few
of
us,
Daniel
and
and
and
I,
and
maybe
who
someone
else
who
who
is
into
that
topic
should
discuss
to
me.
C
We
can
come
up
with
a
story
specifically
in
the
context
of
people,
because
it
touches
on
that
aspect
as
well
and
if,
if
you
guys
think
we
should
nevertheless
sort
of
have
a
separate
mechanism
to
prove
possession
of
the
private
key
from
the
client
to
the
authorization
server
in
the
specification
which
is
currently
not
they
are
currently.
It's
only
from
it
would
be
done
from
the
client
to
the
resource
server.
Then
we
need
to
do
that
as
soon
as
possible,
because
this
is
a
document.
C
That's
fits
into
the
ace
work
where
we
tried
to
make
alignment-
and
you
may
remember
all
these
discussions
that
we
had
with
the
ACE
group,
and
so
this
is
sort
of
the
HTTP
part
of
the
counterpart
of
what
they
have
been
doing
in
coop.
So
we
need
to
figure
this
out.
I
understand
that
this
is
maybe
a
little
bit
beyond
what
most
people
want
to
look
at
form
an
analysis
of
specifications
but
I
think
it's
a
good
good
thing
that
we
do
that.
F
A
A
G
H
G
G
G
Now.
The
question
is:
where
do
we
want
to
hold
the
next
event,
and
so,
as
you
can
see,
the
last
ones
were
in
Korea,
Germany
and
Zurich
in
Switzerland
train
to
Italy,
an
intricate
in
Germany
and
I
would
like
to
find
a
location
and
a
time
for
the
next
event.
Where
can
we
do
that?
Well,
I
heard
two
proposals
regarding
that:
first
one
is
Stein
enorm.
He
proposes
to
do
something
in
Norway.
There
are
multiple
locations
possible,
for
example,
Oslo
at
run
time.
G
G
Yeah-
and
we
can
also
do
that
and
stood
that
at
the
group
of
course,
as
they
said
they
would
at
least
fill
in
if
nobody
else
would
do
that
they
could
host
the
event
as
well.
When
would
we
do
that?
Well,
if
we
have
it
in
Europe,
then
maybe
not,
we
don't
attach
it
to
the
ITF
event
107,
which
in
Vancouver,
but
we
might
do
that
and
may,
where
the
EIC
is
Munich
or
close
to
the
ITF
108
event,
which
is
in
Madrid
Spain
I
do
an
assent.
G
G
N
J
N
H
C
N
F
G
H
D
Lower
everybody,
so
the
last
time
I
talked
about
this
Hans
was
confused
as
to
how
it
worked
so
I
put
together,
you
were
I
was
giving
you
the
benefit
of
the
doubt
about
other
things,
but
it
wasn't
clear
at
times.
I
get
confused
thinking
about
it
like
who's
doing
what
and
where
is
it
going
because
it's
you
you're
you're,
switching
back
and
forth
quite
a
bit
and
so
I
added
to
the
draft
ASCII
art
diagram,
which
I've
got
in
Nice
art
here,
is
that
big
enough
people
can
kind
of
see
that
people
in
the
back?
D
That's
beyond
my
graphical
capabilities,
but
also
the
ASCII
art,
then,
is
in
the
text
version
also,
as
opposed
to
not
and
I
already
grew
it.
So
this
was
easy
to
do
in
keynote.
So
this
is
just
your
standard.
Oh
awesome
how
you
go
and
you
get
an
authorization
request
to
the
resource
owner.
You
get
some
kind
of
grant
back
and
then
make
a
call
with
that
grant,
and
then
this
is
the
one
place
where
things
change,
which
is
the
authorization
server
says.
D
Hey
I
would
like
to
go
and
get
a
token
as
well
optionally
and
can
go
and
put
in
a
request
of
which
scopes
it
would
like
to
have
at
that
point,
the
plans
really
starting
to
change
to
be
the
resource
owner
and
it's
saying:
okay.
Well,
here's
what
the
reciprocal!
This
is,
what
the
other
guy
wanted
if
he
asked
it.
Otherwise
it's
potentially
pre-configured
what
the
other,
what
party
he
wanted
and
then
the
resource
runner
calls
the
Aussie
server.
D
D
Can
I
can
I
start
again?
Thank
you
Mike,
so
that
it
hands
over
the
grant
and
party.
B
knows
the
context,
because
it's
getting
back
its
access
token,
and
so
that's
why
we
can
sort
of
do
this
behind
the
scenes,
because
you've
got
context
there
before
the
resource
owner
sends
out
over
there's
likely
some
interaction
because
from
a
user
experience
point
of
view,
if
you've,
if
you're
going
through
the
browser
you're
back
over
at
the
party
that
started
off
making
the
request
and
then
you
can
ask
the
user.
D
Is
it
okay
for
the
other
party
to
acts?
Do
these
things
with
you,
and
so
you
would
be
getting
consent
from
the
user
at
this
point
before
you
make
this
call
over,
and
so
you
make
the
call
over
the
other
side
knows
which
user
it
is
because
the
access
token
and
ends
a
grant
over
and
the
client
then
goes
and
does
the
reverse
of
essentially
what
was
see
there
and
oops
oops
I
was
I
pushed
the
wrong
button
back
and
then
it
gets
back.
It's
access
token.
D
D
D
A
A
A
P
P
Why
we're
try
to
do
this
right,
but
I
think
before
we
get
to
the
actual
flow,
which
is
great
by
the
way
you
know
kudos
today,
but
I
think
that
we're
really
helpful
to
have
a
use
case
as
something
that
the
reader
to
use
the
flow
to
read
against
and
I
know.
I
did
say
this
at
one
time,
but
I
I
know
there's
nothing
to
be
done
here,
but
I
hate
the
word
reciprocal,
because
we
have
a
mutual
draft,
and
now
we
have
a
reciprocal
draft
and
the
mutual
draft
is
all
gone
right
and.
P
I
D
The
use
cases
I
think
of
there's
one
resource
owner,
but
I'm
thinking,
there's
situations
where
there
may
be
more
than
one
but
I'm,
not
sure
so,
I
don't
know
I,
don't
know
yeah.
Let
me
let
me
think
about
that's
a
good
comment.
Yeah
yeah
and
then
I'd
have
to
change
your
diagram
and
just
say
resource
owner
instead
of
a
and
B
yeah.
That's
a
good
comment,
as
was
the
the
suggestion
to
add
a
use
case.
I
will
do
that.
Thank
you.
R
G
G
G
The
important
thing
here
is
that
we
have
a
updated
and
more
comprehensive
threat
model
than
before.
We
have
described
many
attacks
that
were
discovered
recently
over
the
last
years.
Let's
say,
and
we
have
concrete
actionable
recommendations
for
implementers
of
oauth2
to
defend
against
these
attacks.
G
What
did
we
do
since
the
last
ITF?
Well,
I
have
not
been
to
many
changes.
One
changes
that
we
now
discourage
the
use
of
the
resource
owner
password
credentials,
grant
we
say
it
must
not
be
used.
I
think
the
reason
is
pretty
clear.
This
grant
type
exposes
credentials
to
the
client,
it's
essentially
a
plant
men
in
the
middle
attack.
G
It
increases
the
attack
surface,
that
users
exposed
to
our
users
credentials
and
it's
not
are
not
easily
adaptable
to
many
modern
authentication
mechanisms
like
two-factor
authentication,
web
authentication,
web
crypto
and
the
mighty
self
authentication
that
you
have.
For
example,
at
Google
we
say
the
resource
on
a
password
credentials
grant
must
not
be
used.
G
He
noticed
that
in
some
rare
cases
a
client
may
be
able
to
impersonate
a
resource
owner
that
can
happen
if
there's
a
confusion
between
this
cell
claim,
that
is
used
for
a
client
in
the
client
credentials
grant
and
the
sub
claim
that
is
used
for
a
resource
owner
in
the
authorization
code
grant.
This
may
happen
if,
for
example,
the
client
uses
dynamic
registration
and
the
client
itself
can
influence
its
sub
value
that
is
later
used
by
the
AES
for
that
client.
E
H
G
That's
right,
yeah
I,
think
I
think
it
should
be
a
fit,
but
we
can't
talk
about
them:
yeah,
ok,
yeah
and
then
the
yes,
so
the
subtle
value
might
be
influencing
them
confused
for
a
set
value
of
a
resource
owner.
So
the
recommendation
is
clear:
the
client
should
not
be
able
to
select
or
influence
the
set
value
that
is
later
used
for
the
client.
G
The
next
batch
of
changes
is
around
pixie.
We
encourage
the
use
of
the
pixie
mode
sha-256
instead
of
the
plane
mode.
This
is
because
the
authorization
request
might
leak
to
an
attacker
or
parts
of
it
might
lead
to
an
attacker
or
whatever.
So
it's
a
really
good
idea.
If
the
pixie
challenge
is
a
hash
of
the
verifier,
not
the
verifier
itself,
therefore,
we
say
that
the
client
should
use
a
pixel
Coachella
or
should
use
pixie
code
challenge
methods
that
do
not
expose
the
pixie
verify
and
the
authorization
request
which
currently
is
the
sha-256
mode.
G
Essentially,
we
also
say
that
authorization
service
must
support
big
zoo,
because
pix
is
super,
useful,
optimization
service
should
publish
pizzas
abroad.
We
go
back
to
that
point
in
a
moment
and
we
say
that,
under
certain
conditions
that
we
define
in
the
BCP
pixie
may
replace
state
for
CSF
protection
and
if
pixie
is
used
instead
of
State
for
CSF
protection,
then
you're
free
to
use
state
to
carry
application
state
or
whatever
you
want.
G
G
So
the
question
is
kindly
we
say
the
AAS
should
use
metadata
to
announced
support
for
pixie,
but
we
could
also
say
the
AAS
must
use
metadata
to
announce
the
support
for
pixie
and
because
we
also
say
that
every
a
s
must
support
pixie.
This
would
mean
that
the
metadata
our
C
essentially
becomes
a
mandatory
to
implement
for,
or
authorization
service.
N
I
think
that
maybe
mandating
the
use
of
metadata,
no
matter
how
tempting
it
may
be
for
some
of
us
might
be
a
step
too
far,
I
think
it's
probably
okay
to
say:
if
das
doesn't
advertise
Pixy
units
metadata
or
have
a
metadata,
you
can't
assume
that
the
server
does
pixie.
So
it's
not
safe
to
rely
on
it.
Yeah.
S
Victoria
rzf,
looking
actively
our
physicians,
have
a
sidewalk
with
I.
Don't
think
about.
These
would
be
reason
enough
to
catch
your
to
actually
adopt
metadata,
mostly
because
most
of
them
are
already
use
the
open
and
he
committed
for
the
information
that
we
needed
to
publish
such
as
signing
keys.
If
value
suppose
it
claims
and
signal.
So
if
you
wanted
to
meet
what
they
already
have,
if
you
find
a
way.
Q
G
S
C
G
Okay,
and
the
next
topic
is
an
attack
that
is
possible
on
the
earth,
under
certain
circumstances
that
we
discussed
them
stood
guard
briefly,
and
that
I'd
like
to
discuss
a
bit
more
here
because
I'd
like
to
write
something
on
this
attack
in
the
BCP,
because
we
know
of
this
attack.
We
need
to
write
something
and
yeah.
The
question
is
what
we
write.
G
G
The
attacker
starts
a
session
with
a
client
and
gets
the
authorization
request.
Your
eye
from
the
client,
so
the
attacker
just
starts
okay,
says
just
start
a
new
session
get
the
authorization
your
I.
Now
the
attacker
forwards
that
authorization
UI
to
the
victim,
unmodified
and
a
victim
will
open
that
your
eye
and
see
the
authorization
/
authentication
dialog
at
yes.
Why
would
the
victim
now
authorize
/
authenticate?
Well,
maybe
because
the
victim
was
expecting
something
like
that,
but
maybe
for
a
different
map,
so
the
victim
might
be
tricked
into
authorizing
the
client.
G
So
what
can
we
do
against
that?
As
it
turns
out?
None
of
the
existing
defenses
involve
help
against
that
we
could
use
token
binding
yeah,
but
there's
the
lack
of
support,
famously
in
some
browsers
we
could
use
the
form
post
response
mode,
which
would
be
a
relatively
big
change,
depending
on
what
your
implementation
looks
like
it's
also
not
suitable
for
apps.
We
could
check
the
origin
or
referer
header
at
bas,
so
that
the
hess
would
see
that
the
authorization
request
comes
from
a
different
religion.
G
Unfortunately,
the
authorization
request
is
a
get
request
and
the
fetch
specification
says
that
there's
no
original
error
in
such
a
request,
yeah
and
that's
essentially
the
end
of
the
things
that
we
could
do.
I
discussed
this
with
John
yesterday
and
we
came
up
with
a
new
mechanism,
a
relatively
simple
mechanism
which
could
defend
against
this
attack
and
I
called
this
mechanism
eyeball,
which
may
or
may
not
resemble
the
Scandinavian
furniture.
G
But
it
stands
for
integrity,
verification,
faltered
and
authorization
requests.
The
idea
is,
as
I
said,
relatively
simple:
das
needs
to
check
that
the
authorization
request
actually
comes
from
the
client
itself,
not
from
the
attacker.
So
the
attacker
didn't
forward
anything
to
the
users
browser.
How
would
it
do
that.
G
The
idea
is
that
the
client
in
its
metadata
publish
a
so-called
I
value
or
I
the
client,
then
before
redirecting
the
user
through
the
authorization
server
Stross,
the
authorization
request
URI
in
the
web
storage
of
the
user's
browser
in
its
on
its
own
origin.
Of
course,
now
the
users
being
redirected
to
the
a
s
and
the
a
s
then
opens
an
iframe
from
the
I
value
RI
and
sends
a
post
message
to
that
iframe.
G
That
post
message
would
just
contain
the
authorization
request
URI,
as
it's
seen
by
the
a
s
the
I
would
check
the
local
storage
of
the
of
the
client,
because
it's
running
on
the
clients
origin
would
then
see.
Okay,
there's
an
entry
of
that
URI
and
would
then
answer
okay,
and
if
it
doesn't
answer
okay,
das
doesn't
continue
with
the
authorization
flow.
G
So
what
we're
doing
is
we're
ensuring
the
integrity
and
origin
of
all
the
data
in
the
authorization
request.
Your
I
and
while
this
seems
like
a
big
change,
I
think
it's
actually
not
such
a
big
change
because,
for
example,
if
you
don't
have
JavaScript
enabled
you
can
safely
fall
back
to
a
mode
which
doesn't
provide,
provide
the
protection
by
Iowa
but
still
works.
G
We
can
we
have
integrity,
/,
origin
checks
for
not
only
the
pixi
data
or
yeah
anything,
so
we
have
the
full
authorization
request.
Uri
that
is
checked
so
state
nonce
request
your
I,
if
you're
using
that
and
also
the
redirect
URI
so
is,
and
we're
also
getting
rid
of
many
or
most
of
the
attacks.
Targeting
the
redirect
URI-
and
this
is.
This
mechanism
protects
against
at
least
three
attacks
that
I
know
of
the
pixie
trolls
and
challenge
attack
attacks
using
a
manipulator
redirect
URI
and
at
least
one
very
end
of
the
AAS
mix
at
attack.
G
G
So
sorry,
is
that
a
separate
draft,
or
is
it
both
of
this?
That's
a
separate
raft
so
in
the
security
disappear?
We
would
probably
make
this
informal
reference,
because
we
would
not
say
you
have
to
implement
that,
but
we,
this
is
one
way
to
do
it.
You
could
also
use
token
binding
if
you
know
the
browser
supports,
you
could
also
use
the
forum
post
mode
if
you
are
willing
to
change
your
implementation
or
you
could
opt
for
not
doing
anything
like
this.
If
this
is
not
in
your
attacker
model,.
N
N
N
J
I
understand,
Chrome
and
Firefox
also
are
supposed
to
be
blocking
local
storage
when
third-party
cookies
are
disabled.
So
this
is
not
just
a
Safari
issue.
Given
me
increased
attention
on
things
like
third
party
cookie
settings,
this
strikes
me
as
any
solution
that
has
a
very
short
effective
lifetime.
Yes,.
G
O
It
you
may
need
at
least
no
sorry
later,
wasn't
it.
It
looks
like
you,
you're,
like
a
bunch
of
stuff
like
you're,
a
cookie
or,
and
a
lot
of
other
stuff
relate
to
do.
It
is
being
sandbox,
that's
how
it
appears
to
the
browser
right.
So
you
it
looks
like
you
have
a
cookie
or
in
your
hammer
as
locals,
or
is
sometimes,
but
if
nothing
ever
persists.
So
you
know
it's
like
an
empty.
It's
an
empty
object,
always
so.
O
T
F
Proxy
wait
to
the
mic.
Philip
says:
WebKit's
IPT
2.0
is
famous
for
blocking
cross-origin
access
to
local
storage,
so
disabling
javascript
isn't
the
only
case
it
is
in
the
only
case
of
fallback
would
have
to
run
for
our
set.
That's
what
so
disable
javascript
isn't
the
only
case
a
fallback
would
have
to
run
for
yeah.
Let's.
G
K
N
N
G
G
Anyway,
so
we
need
to
wrap
this
session
up,
so
what
I
will
do
is
I
will
describe
this
attack
or
my
planners
to
describe
this
attack
in
the
OAuth
PCP
security
PCP
and
also
discussed
some
of
the
mitigations
which
might
or
might
not
include
this
mitigation.
But
we
need
to
talk
about
the
attack
because
we
know
of
the
attacks.
Are
we
shouldn't
yeah,
just
leave
it
out
from
the
BCP,
but
other
than
that.
G
S
One
thing
about:
they
must
not
use
wrong
ice
apartment,
but
I
think
it
would
be
nice
if
we'd
have
some
kind
of
answer
for
some
of
those
scenarios
where
people
have
absolutely
no
alternative,
like
missing
area
where
I
stumbled
upon
very
often
in
the
last
few
years,
when
we
were
trying
not
to
make
visible,
was
a
secret
connection
strings.
That
imagine
that
you
already
are
a.
S
S
Use
of
physical
servers
as
they
are
an
authorizer,
it's
very
so
those
guys
will
be
in
non-compliance.
So
if
it's
anything
at
all
that
we
can
do
for
both
scenarios
that
we
deem
wins
matter
than
then
we
should
hint
that
otherwise,
we'll
just
tell
people
you
guys
are
orphaned.
We
put
all
your
way
from
the
house
of
a
father.
You
cannot
use
ourself.
G
S
S
C
C
C
G
C
N
N
N
F
H
T
H
E
Thank
you
all
right.
Well,
there's
is
another
yet
yeah,
it's
not
there
yet.
So,
if
it
did
now
there
we
go
except
the
clicker
is
not
working
yeah
there
we
go.
Okay,
we're
good
sorry,
I've
got
about
18
minutes
for
68
slides,
so
we're
gonna
do
what
we
can
I'm
going
to
talk
about
who's,
who
I
don't
shut
up
dick.
My
name
is
Justin
richer,
I'm
gonna
talk.
What.
E
E
So
over
the
last
year
or
so,
I've
started
to
do
an
experiment
of
trying
to
see
what
it
could
look
like
if
we
kind
of
started
with
a
new
base,
so
something
that
was
not
specifically
OAuth
2
compatible,
and
that
has
led
me
to
the
XYZ
project
so
named
because
on
a
lark
I
bought
the
domain
Oh
XYZ,
and
that
seemed
like
a
reasonable
place
to
host
this.
So
that
is
a
website
you
can
go
to
and
follow
along
during.
The
talk.
I
want
to
reiterate
here
that
this
is
not
an
extension
to
OAuth
2.
E
E
It's
it's
a
wonderful
innovation!
That's
been
used
in
the
OAuth
and
open
ID
worlds,
because
the
user
is
there
in
the
browser
is
an
incredibly
flexible
platform,
but
on
the
downside,
there's
a
whole
lot
of
stuff
that
can
go
wrong
when
you're
pushing
information
through
the
front
channel.
Now
this
is
all
reasonable
to
work
with,
except
for
the
fact
that
OAuth
2
puts
lots
of
things
through
the
front
channel
right,
there's
a
lot
of
stuff
that
goes
on,
and
this
causes
a
lot
of
problems.
E
So
many
problems
that
we've
got
a
whole
list
and
an
ever-growing
list
of
specs
to
close
holes
in
the
front
channel,
so
we're
basically
closing
holes
that
we
created
in
the
first
place.
So
my
proposal
started
with
the
idea
of
let's
not
use
the
front
channel
unless
we
absolutely
have
to.
Let's
only
use
it
for
very
specific
things
and,
as
I
started
to
work
on
that,
I
tried
to
take
a
step
back
of.
E
How
could
we
do
that
with
an
OAuth
like
protocol
and
I
kind
of
stumbled
into
the
idea
of
using
a
transaction
as
the
key
thing
now,
o
auth
has
always
been
transactional.
It's
all
about
the
client.
Getting
a
token
and
then
getting
it
authorized
from
using
a
token
and
Center
and
so
forth.
What
I
decided
to
do
with
this
project
was
make
that
transaction
sort
of
the
singular
key
element.
So
this
is
the
intent
registration
pattern.
E
First
off
there's
this
notion
of
what
I
want:
Torsten
loader
steps
got
a
really
great
blog
post
that
talks
about
structured
scopes
and
the
kinds
of
things
we
want
to
see
there
you
on
a
garden
path
about
the
actual
things
in
here,
because
as
far
as
I'm
concerned,
there's
a
whole
lot
of
debate
that
needs
to
happen.
The
important
thing
here
is
that
those
are
rich
objects.
There
are
adjacent
objects
that
can
describe
in
greater
detail
what
the
client
is
asking
for.
E
I
think
this
is
a
place
where
we
need
to
be
flexible.
The
thing
that
I
have
SPECT
right
now
is
just
take
that
post
body
use
the
detached
jws
put
it
in
the
header.
Call
it
a
day.
We
could
use
cabbage
signatures,
we
can
use
em,
TLS
binding,
there's
a
lot
of
different
things.
We
could
do
and
I
think
there's
a
lot
of
good
innovation.
We
can
do
there
next
up.
The
client
can
say
a
little
bit
about
itself,
so
this
is
more.
The
user
facing
information,
its
display
name,
its
URI
and
stuff,
like
that.
E
This
isn't
really
functional
information
about
the
client,
because
I
found
that
in
implementing
this
over
the
years,
so
Ott's
model
of
the
client
as
an
entity
being
a
hanging
point
for
a
lot
of
things
like
what
rights
of
access,
what
types
of
functions
you
can
do
and
stuff
like
that
ends
up
being
a
little
a
little
bit
weird.
So
in
this
case
this
is
the
client
just
saying:
here's
how
I
describe
myself?
How
you
recognize
me?
What
I
can
do?
E
Those
are
all
different
things
they
may
be
strongly
associated
with
each
other,
but
they
are
really
different.
Subsets
of
information.
This
got
brought
up.
Vittorio
actually
raised
this
a
little
bit.
I
think
we
really
need
to
have
a
separate
way
to
say
this.
Is
the
information
I
know
about
the
user?
This
could
be
an
assertion.
This
could
be
a
set
of
verifiable
credentials
that
I'm
posting
this
could
be
a
user
name
password.
This
could
be
any
number
of
things
that
I've
collected
to
know
about
the
user.
E
E
There
are
two
parts
to
it
and
it's
basically,
how
can
I
get
the
user
there
and
how
can
I
get
the
user
back
in
this
particular
example,
I'm
saying
I
can
send
the
user
to
an
arbitrary
URL
and
when
I
get
them
back,
I'm
going
to
be
doing
a
redirect
to
a
URI
that
I
host
the
canonical
auth
code
flow.
So
at
this
point
the
AAS
has
all
of
this
information
and
it
can
decide
what
to
do
with
it.
E
It
may
very
well
decide
that
it
has
everything
it
needs
to
do
to
issue
an
access
token,
because
that's
the
client
credentials
flow.
That's
a
lot
of
the
token
exchange
flows.
That's
all
the
resource
owner
to
flow
there's
a
lot
of
cases
in
OAuth,
where
we're
already
doing
this,
but
we're
doing
different
specialized
things
in
order
to
do
that
or
the
auth
server
can
look
at
all
of
that
and
say
hey.
This
isn't
good
enough
and
I
need
to
talk
to
the
user.
E
I
need
to
talk
to
the
user
myself,
so
I
am
going
to
send
you
to
a
an
arbitrary
URL
that
I
host.
This
URL
needs
to
be
unique
for
the
given
transaction
request.
So
this
is
not
a
an
authorization
endpoint
URL
that
the
client
adds
stuff
to.
This
is
something
that
is
generated
and
handed
to
the
client
just
in
response
to
this
request,
because
each
step
in
this
process
needs
to
point
to
the
next.
E
This
closes
the
mix-up
attack
and
a
lot
of
other
things
that
happen
in
the
OAuth
discovery
space,
because
the
client
starts
at
one
URL.
It
gets
pointed
to
every
next
step
that
actually
proposed
this
in
the
OAuth
world
like
ten
years
ago,
or
something
like
that.
We
decided
not
to
listen,
I,
don't
know
why
the
client
then
sends
the
user
over
to
that
URL,
and
it
does
not
add
any
query
parameters.
It
does
not
have
a
client
ID,
it
does
not
add
a
state.
It
doesn't
do
anything
like
that.
E
That
tells
us
what
client
we're
talking
to
what
keys
have
been
verified,
what's
being,
or
maybe
even
information
about
what
user
we're
expecting,
which
can
close
a
lot
of
the
the
attacker
problems,
including
the
the
pixie
based
attack
that
we
were
hearing
about
before.
If
the
client
knows
something
about
what
use
the
user
is
user,
does
everything
that
you
would
expect
here
and
then
they
get
sent
back
right?
E
Now
I've
got
a
separate
state,
parameter
that
the
client
had
pre
registered
with
that
transaction
request
and
an
interaction
handle
that
comes
back
to
the
client
and
then
the
client
needs
to
validate
that
state
value
and
send
that
back
to
the
authorization
server
now
something
that
I
kind
of
glossed
over
before
was
that
when
I
got
back,
the
interaction
URL
I
was
given.
What's
called
a
transaction
handle
that
transaction
handle
is
now
used
by
the
client.
E
E
I
can
keep
talking
about
this
notion
of
handles
and
so
far
we've
seen
how
that
they
can
be
used
for
the
for
continuing
the
transaction.
These
can
be
used
actually
all
throughout
the
system,
so
it
might
seem
a
little
funny
to
people
that,
like
we're
doing
kind
of
a
dynamic
registration
thing,
every
time
we're
always
sending
client
information,
we're
always
sending
key
information
stuff
like
that.
E
That's
kind
of
silly
right,
I
agree
because
the
server
can
issue
in
response
to
either
an
initial
transaction
or
an
out-of-band
interaction
with
the
developer,
a
client
handle
and
key
handle
that
the
client
can
use
in
lieu
of
the
the
actual
JSON
document,
and
the
transaction
request
then
looks
more
like
this.
So,
instead
of
sending
an
object,
I
send
in
this
case
a
string
because
it
was
a
bearer
type
handle.
E
It
might
be,
a
hash
of
a
string
or
any
number
of
cryptic,
ethically
bound
operations
that
we
could
do
with
these
things
and
I
send
those
over
and
the
auth
server
looks
it
up
and
says:
oh
I
know
which
client
this
is
referring
to.
This
is
effectively
replacing
a
client
secret,
but
not
giving
up
that
key
binding
right.
E
The
access
token
itself
can
also
come
back
with
the
transaction
handle,
and
why
would
we
want
to
do
that?
Well,
in
olt
we
decided
that
access
tokens
can
now
expire,
and
so
we
had
to
invent
this
weird
thing
called
a
refresh
token,
which
was
kind
of
a
bearer
token,
but
kind
of
not,
and
only
in
some
circumstances
and
stuff,
like
that.
Well,
I
got
to
thinking
that
what
is
a
refresh
token
except
saying
that
I
want
to
continue
this
transaction.
E
What,
if
I've
got
a
really
trusted,
client
and
I
want,
and
the
a/s
decides
that
you
know
what
you've
done
all
of
these
claims.
Maybe
it's
not
the
resource
owner,
but
it's
a
third
party
requesting
party
kind
of
thing.
Looma
has
this
notion
called
the
persistent
claims
token
we
can
use
the
user
handle
in
this
protocol
to
do
the
same
kind
of
thing.
That's
that's
a
different
rabbit
hole,
we're
gonna
go
quick
and
next
up
is
scopes.
E
A
lot
of
the
a
lot
of
the
discussion
around
Torsten,
x',
structured
scope
example,
is
that
the
simple
scopes
are
all
are
still
really
really
useful,
but
I
got
to
thinking
what
is
a
scope
except
a
shorthand
way
to
say:
I
want
this
actually
rather
complicated
slice
of
API.
Well,
if
we
just
extend
this
notion
of
a
handle
representing
an
object
with
the
client
would
otherwise
send.
We
can
now
have
an
API
decide
that
if
you
want
this
particular
set
of
API
rights,
use
this
magical
string,
which
also
happens
to
be
human,
readable
and
typable.
E
In
other
words,
it's
an
OAuth
scope.
One
of
the
coolest
things
about
this,
though,
is
that
you
can
combine
the
string
based
scope
with
the
object
based
sort
of
more
detailed
requests,
which
is
something
that
developers
have
asked
for
four
years
in
the
OAuth
space,
and
there
are
clear
semantics
of
how
those
things
stick
together,
because
each
of
those
simple
strings
unpacks
to
one
of
those
objects
and
that's
something
that
you
need
to
be
able
to
deal
with
any
way
inside
your
API
very,
very
quickly.
This
works
for
the
device
flow
as
well
I'm.
E
Basically
going
to
say,
I
cannot
send
the
user
to
an
arbitrary
URL,
so
I'm
gonna
instead
send
them
to
a
static
URL
that
maybe
has
been
configured
on
a
webpage
or
is
in
the
little
sticker
that
came
on
my
box,
but
I
can
chirp
out
a
user
code
and
send
to
the
user.
So,
okay,
that's
great
I'm
gonna.
Tell
the
user
go
here,
enter
that
code.
User
shows
up.
E
Meanwhile,
the
device
can
go
and
poke
the
server
and
say
that
I
want
to
be
able
to
continue
this
transaction.
Are
we
ready
yet
and
the
server
anytime
it
gets
poked
with
one
of
these
transaction
continue
messages
can
basically
say
yeah
we're
not
done
yet.
You
know
we're
still
waiting
for
somebody
to
go
click
a
button
or
something
like
that
hold
off
wait,
30
seconds
and
by
the
way.
Next
time
you
talk
to
me.
Here's
a
brand
new
transaction
handle
this
has
to
get
rotated
every
single
time
through.
E
This
was
something
that
we
found
in
the
to
protocol.
This
closes
a
whole
bunch
of
problems
when
you
rotate
this
kind
of
thing
same
thing.
By
the
way,
with
the
refresh
token
analog
every
time
you
would
continue
in
transaction
there,
you
rotate
the
handle
any
time
you
come
back
from
an
interaction.
If
it's
not
ready
yet
or
you
can
do
more
things,
you
rotate
the
handle
so
and
since
we
had
this
discussion
with
the
device
flow,
what
about
a
combined
URL?
E
Well,
what
is
a
combined
URL
except
saying
that
I
can
send
the
user
to
an
arbitrary
URL,
except
that
now
I'm
saying
I
can
send
them
there
by
painting
a
QR
code
instead
of
by
you
know,
sort
of
artificially
mashing
these
things
together,
you
should
be
able
to
use
these
things
side-by-side
with
each
other.
There
are
two
different
ways
that
I
can
get
the
user
over
to
the
server
to
to
interact
all
right.
What
about
identity
and
just
wrote
a
Aaron
correct?
E
You
just
wrote
a
great
blog
post
about
this
I
think
that
we
can
pass
identity
assertions
back
just
like
we're
doing
with
OAuth.
Today
we
can
protect
an
identity
API,
just
like
we're
doing
with
open
ID
connect
to
know
off
today,
and
we
can
also
send
identity
assertions
like
I
said
at
the
beginning
in
ways
that
it
really
hard
to
do
with
OAuth
2.
E
We
can
also
bind
tokens
and
very
deep
Popish
kind
of
ways
and
OAuth
M
TLS
kind
of
ways,
because
we
have
a
mechanism
for
the
client
to
be
able
to
present
improve
keys
already
to
the
authorization
server.
We
can
extend
that
and
say
that
this
access,
token
that's
coming
back,
is
no
longer
a
bearer
access.
Token
is
bound
to
a
specific
key
that
I
can
then
reference,
and
you
have
to
use
the
same
proofing
mechanisms
to
do
that.
A
lot
of
the
concepts
of
OAuth
2.
E
Are
there
they've
just
been
you
see
a
lot
of
like
underscore
handle
going
on
here,
because
there's
there's
really
a
lot
of
abstraction
that
you
can
gain
from
this
by
stepping
back
from
the
sort
of
syntactic
details
of
both
to
itself
and
trying
to
look
at
things
a
little
bit
differently.
If
you
really
want
to
get
down
to
it.
This
came
from
a
conversation
I
had
with
Chuck
Mortimer
over
at
Salesforce.
E
You
could
send
in
your
client,
ID
or
client
secret
as
your
client
handle
and
use
it
as
your
key
handle.
You
can
send
in
your
scopes
as
resource
handles.
I
mean
a
lot
of
this
does
kind
of
collapse
into
the
same
same
types
of
concepts,
but
in
ways
that
allow
you
to
also
do
it
in
a
more
rich
and
robust
way
without
losing
the
simple
expressivity,
huge
bunch
of
pros
and
cons.
I
think
there
are
a
lot
of
pros
to
this.
E
I
started
working
on
this
in
earnest,
maybe
about
a
year
ago
trying
to
hack
apart
or
off
and
see
how
it
could
be
a
little
bit
different
it
out
of
the
box.
Does
a
wider
set
of
use
cases,
I
mean
them,
and
the
more
legacy
use
cases
that
I
throw
at
it.
The
more
I
find
that
stuff
actually
fits
uses
some
multi
modal
JSON.
In
order
to
make
everything
you
know
fairly
clean
and-
and
you
know,
expressive,
I
can
do
static
and
dynamic
things.
E
There's
a
few
moving
parts
which
is
generally
better
for
security
cons
biggest
one.
It
is
not
backwards
compatible.
This
is
not
a
off
it's
just
not.
We
can
do
a
lot
of
the
things
that
this
protocol
does
with
OAuth
2
as
a
base,
we're
already
seeing
it
with
happy
resource
object,
registration,
we're
seeing
it
with
deep
hop.
A
lot
of
the
bits
and
pieces
are
ideas
that
are
pulled
from
these
other
things,
but
it's
drastically
simplified
when
we
start
with
a
different
syntactical
and,
more
importantly,
a
semantic
model
base
to
build
off
of
alright.
E
It
is
a
huge,
huge
drawback
that
it
is
not
a
lot
too
compatible,
but
I
do
think
that
these
things
can
be
deployed
side
by
side
with
similar
or
related
backing
systems.
So
you
can
have
one
registration
system
and
you
know
a
transaction
endpoint
and
an
OAuth
token
endpoint,
that
kind
of
live
side
by
side.
A
downside
is
multi
modal
JSON
because
that's
kind
of
tricky
to
parse
and
some
in
some
cases,
but
I
will
say:
I
have
implemented
this
in
Java,
which
is
one
of
the
most
annoyingly
strongly
typed
languages
out
there.
E
So
if
it's
possible
in
Java
I
think
it's
possible
in
almost
anything
and
my
codes
up
on
github,
it's
linked
from
the
site.
So
it's
you
know
you
can
do
it.
We
don't
know
how
this
scales
yet
there's
a
lot
of
questions
about
statefulness
and
statelessness
and
quite
frankly
we
don't
know
what's
broken
yet,
but
with
that
I'm
gonna,
ask
that.
E
N
I
think
you
put
a
lot
of
work
into
this.
It
incorporates
a
lot
of
the
extensions
that
we've
done
it
a
lot.
A
wife
will
not
live
forever.
Much
like
WS
bed
may
not
live
forever
on
Cano
B
I
think
it
may
be
useful
to
adopt
this
as
perhaps
experimental
at
this
point
and
work
on
it,
get
the
experience
so
that
at
some
point
in
the
future
right,
you
know,
I,
don't
think
that
we
necessarily
want
a
signal
people
that
you
know
this
is
necessarily
maturer.
Yet,
oh,
it's
not
I'll.
N
It
in
as
experimental
and
say
this
is
stuff
that
we're
looking
at
for
the
future.
We
want
to
develop
it
so
that
by
the
time
a
watt
starts,
people
start
hitting
real
boundaries
with
a
lot
that
they
can't
do.
Maybe
we
will
have
something
that
can
be
deployed,
so
I
think
it's
something
that's
worth
the
work,
we're
tracking.
Okay.
Thank
you.
U
U
E
Right,
thank
you.
Yeah
I
mean
the
idea
of
it.
Being
a
kind
of
a
state
machine
is
absolutely
not
new
to
this,
but
it's
more.
It
forces
its
explicit.
It
forces
it
to
the
foreground
because
I
mean
I've
written
like
a
half
dozen,
oh
I'll
server
implementations
at
this
point
in
my
life
and
that's
what
you
do
anyway,.
U
U
F
J
About
Batman,
Amazon,
yeah
I
think
this
is
great
work
and
something
we
definitely
want
to
dive
into
I
want
to
call
attention
to
the
fact
that
none
of
this
overall
idea
of
handles
and
and
we're
closing
what
not
is
specific
to
authorization
and
I
think
there's
sort
of
an
underlying
protocol
here
that
has
is
more
broadly
applicable
and
worth
breaking
out
as
its
own
thing.
All
right.
So.
P
J
E
Thank
you
for
that
example,
and
the
that
kind
of
thinking
is
exactly
why,
in
the
straw,
man
that
I've
written
so
far,
I've
called
it
the
interaction
URI
and
not
the
authorization
URI.
Because
if
you
actually
look
at
the
uma
to
specifications,
the
requesting
party
gets
sent
to
interact
and
provide
a
bunch
of
claims
and
umas
very,
very
hand
wavy
about
what
that
means.
It
could
very
well
be
entering
credit
card
information
there
and
so
yeah.
E
J
Similar
pattern
internally
for
look
at
using
it
between
like
authorization,
services
and
the
authentication
stack,
those
are
separate
and
then
essentially
within
the
authentication,
stack
breaking
up
parts
of
the
authentication
process
into
independent
workflows
that
operate
separate
from
one
another
and
have
their
own
trust
boundaries
around
them
right.
So.
D
D
So
a
few
questions,
few
comments
darling
is
this
working
group
started
off
working
on
OAuth,
1
and
then
moved
to
when
I
was
working
on
Goa
we
tried
to
keep
a
number
of
the
semantics
and
thinking
that
we
didn't
break
the
it
wasn't.
An
extension
of
OAuth,
1
sort
of
like
I.
Think
for
the
same
reasons,
you're
saying
it
needs
to
break
I
would
agree
with
those
I
wish.
We
were
smarter
back
then
and
was
abused
more
of
a
back-channel
handle.
D
The
reason
we
didn't
is
we
were
sort
of
following
on
what
we
thought
did
work
in
O'laughlin
yeah
and
taking
the
parts
that
didn't
work
out
so
I
myself,
I'm.
A
big
advocate
of
that
I
think
that
the
challenge
is
going
to
be.
People
got
a
lot
of
stuff
deployed
right,
yeah.
One
advantage
of
it
is
that
the
model
about
how
I'm
a
API
calls
doesn't
change,
which
is
where
most
of
all
the
code
is.
D
Yes,
it's
just
changing
how
you
go
about
getting
those
right,
I
wrote
this
comment
on
the
list
and
I
think
for
us
to
get
traction
of
people
being
interested
in
working.
This
ended
up
being
like
some
Perl
6,
forever
project
that
who
knows
what
it
solves,
which
I
worry
about
them
with
the
let's
capture
in
the
use
cases.
What
we're
doing
one
thing
is
addressing
issues
with
OAuth,
2
and
I.
Think
even,
more
importantly,
would
be
one
of
the
use
cases.
D
This
solves
that
we
can't
easily
solve
with
that
a
lot
too,
because
that
will
drive
adoption
of
people
using
it
and
they'll
say.
Oh
and
it'll
also
do
everything.
I
must
and
was
about
to
so
I'll
just
use
that
all
the
way
right,
I
think
that
solving
new
use
cases
will
enable
us
to
bring
a
bunch
of
energy
I'm
working
on
it,
as
opposed
to
fixing
something
that
could
be
better
but
already
works.
Yeah.
E
I
I
couldn't
agree
more
and
what
has
been
driving.
My
implementation
of
this
is
is
a
set
of
use
cases
which
would
be
happy
to
talk
with
you
offline
about
spaces
where
os/2
doesn't
work
because
of
the
nature
of
kind
of
where
the
user
and
clients
sit
in
the
process
don't
fit
with
OAuth
twos
model.
Wait.