►
From YouTube: IETF104-OAUTH-20190328-0900
Description
OAUTH meeting session at IETF104
2019/03/28 0900
https://datatracker.ietf.org/meeting/104/proceedings/
A
B
B
B
C
C
C
Okay,
okay,
so
a
we
will
probably
shuffle
this
agenda.
During
the
meeting
there
was
a
request
for
a
late
request
for
something
right:
five
to
ten
minutes,
but
to
see
so
it
will
start
with
the
with
harness
to
talk
about
the
author
workshop
update
and
then
Aaron
will
talk
about
that.
Browser-Based
app
harness,
maybe
take
lift
at
less
than
10
min
30
minutes
to
talk
about
peop
m
and
the
Torsen
will
talk
about
MPLS
and
I.
I
will
finish
it
with
that.
A
quick
talk
about
a
nested
day
chart.
D
So
some
of
you
attended
their
own
security
workshop
and
stood
out
last
week
and
others
didn't.
Unfortunately,
we
had
a
very
good
event.
I
will
give
you
a
short
summary
of
what
we
did
and
where
you
can
find
the
material
in
this
small.
So
this
is
obviously
the
webpage
I
post
I
posted
a
link
to
this
one
to
the
mailing
list.
We
had
record
participation.
We
actually
had
to
close
the
registration
in
some
point
in
time,
because
the
meeting
rooms
only
are
the
meeting
rooms
had
a
limit
and,
of
course,
having
discussions.
D
D
The
tutorials
focused
on
two
aspects,
formal
methods
or
the
use
of
formal
methods,
in
this
case
tamarine
for
protocol
verification
and
basically
was
a
hands-on
tutorials.
So
you
can
find
the
slides
there
and
I
I
believe
the
slide
also
contains
a
pointer
to
the
virtual
machine.
So
you
can
get
the
environment
set
up
and
running.
If
you,
if
you
go
into
this,
the
other
one
was
a
hands-on
tutorial
on
the
use
of
access
control
with
ours
in
in
in
a
sort
of
cloud
context.
D
D
We
also
had
then
the
unconference,
where
participants
could
pick
the
topic
that
they'd,
like
particularly
we
we
did
a
show
of
hands
on
who
is
interested
in
what
and
divided
up
the
groups.
So
you
can
those
obviously
worth
there
were
no
slides
for
those,
but
and
and
what
she
also
no
notes,
but
still
so
you
can
get
an
idea
about
people
cared
about
and
then
the
keynote
speak
speaker
dr.
John
Monaco
talked
about
cross-site
scripting
attacks
and
how
to
prevent
them,
and
it
was
a
very
detailed
arc.
D
I
would
say
the
slides
are
also
uploaded,
so
they
can
look
at
it.
Even
if
you
know
cross-site
scripting
attacks
going
through
there
order
different
mitigation
techniques
and
the
libraries
that
he
recommends
I
think
is
a
very
valuable
resource
that
did
the
recording
of
some
of
the
talks
and
I've
asked
him
to
send
me
the
recordings
and
so
that
we
can
upload
them,
but
that
hasn't
happened
yet
so
I
hope
this
will
be
available
at
some
point
in
time.
So
you
can
actually
get
a
good
idea.
What's
going
on.
B
F
Ahead,
Thanks
hi,
I'm,
Erin,
perky,
I'm,
sorry
I
couldn't
make
the
security
workshop
last
week,
but
I'm
glad
David
was
there
to
talk
about
this
draft
there.
I
am
yeah
I
want
to
give
a
quick
update
on
the
browser-based
Apps
recommendation
that
we've
been
working
on
and
kind
of
talk
about
where
we're
at
with
it,
and
then
also
there's
a
bunch
of
open
questions
that
I
have
on
it.
That
I
want
to
talk
about,
especially
based
on
some
of
the
recent
changes
to
the
security
DCP.
So.
G
F
Look
at
that,
so
the
high-level
overview
of
this
of
this
draft
is
that
it
provides
specific
recommendations
for
people
building,
browser-based
apps
and
the
definition
of
browser-based
apps
in
this
case
is
an
application
that
is
written
entirely
in
JavaScript
there's
running
in
a
browser
context
that
does
not
have
its
own
back-end.
Since
you
have
a
back-end
before
it,
then
you
kind
of
get
into
a
different
world,
and
you
can
do
you
know
real
real
ooofff
of
provision
secrets
and
things
like
that.
F
So
the
sort
of
quick
overview
of
the
points
of
the
spec
recommends
is
that
it
requires
the
browser-based
apps.
Do
the
authorization
code
flow
with
pixee
and
it
explicitly
disallows
returning
access
tokens
in
the
front
channel,
which
effectively
is
saying,
don't
do
the
implicit
flow,
and
there
is
a
point
in
there
that
says
that
it,
these
apps
have
to
use
the
state
parameter
for
CSRF
prevention
and
requiring
exact
match
of
redirect
URL
registration
and
that
browser-based
app
should
not
get
refresh
tokens.
F
So
all
these
things
were
things
we
talked
about
at
the
identity
workshop
in
October
and
kind
of
brainstorm.
Some
ideas
around
like
what
do
people
currently
recommend
for
these
kinds
of
apps,
and
this
was
listed-
we
came
up
with
and
I've.
You
know
digested
that
and
turn
it
into
this
into
this
document.
So
some
of
these
I
think
are
now
as
the
security
BCP
has
been
progressing.
Some
of
these
things
I
think
we
need
to
reevaluate.
F
So
some
of
the
high-level
questions
that
I
have
for
this
draft
should
so
I
had
originally
envisioned
this
app
would
be,
or
the
spec
would
be
talking
about,
specifically
pure
JavaScript
apps
running
in
a
browser
with
no
back-end
component
and
as
we've
been
talking
about
this
and
progressing
the
document,
you
know
some
people
have
chimed
in
and
said.
Well
there
is,
you
know
there
are
other
architectures.
You
are
billing
effectively
single
page
apps
that
do
have
a
back-end
component.
Even
if
it's
just
sort
of
to
manage
you
know,
proxying
api
calls
to
other
back-end.
F
H
F
F
F
Sure
yeah
this
is
so.
This
is
meant
to
be
recommendations
for
apps
running
in
a
browser
which
right
now
mostly
are
written
in
JavaScript.
That
is
probably
not
always
going
to
be
true,
so
this
is
not
a
JavaScript
recommendation.
This
is
a
browser-based
environment
recommendation,
so
yeah
I
would
say
that,
like
JavaScript
apps
that
are
running
in
non
browser-based
environments,
don't
fall
under
this
because
those
are
just
they
have
their
own
considerations
like
some
of
those
might
be
considered
native
apps
yeah.
Okay,
thanks
toast.
H
Little
test
would
come
to
remarks.
First
of
all,
we
shouldn't
really
narrow
that
to
only
JavaScript
apps.
You
already
mentioned
that
I
mean.
Basically,
we
are
talking
about
our
apps
that
are
running
in
a
user
agent
in
a
specific
specific
characteristics
of
that
environment,
because
you
don't
have
a
direct
access
to,
for
example,
certificates
can
do
empty
or
less
and
all
that
stuff
it
doesn't
matter
whether
this
javascript
or
any
other
language.
H
That's
that's,
that's
being
used
there
first
and
second
I'm,
not
quite
sure
whether
that
really
makes
sense
to
narrow
the
scope
down
that
much
as
you
have
done,
I
mean
I
already
commented
on
a
comment
on
your
draft.
I
personally
haven't
seen
a
pure
s.p.a
in
the
wild.
In
my
professional
career,
yeah
I
mean
I
might
be
the
only
one.
But
from
my
perspective
this
is
an
academic
concept
as
as
soon
as
you
go
multi-user
you
saw
them.
H
How
need
to
have
a
shared
state
among
your
instances
and
if
you
have
a
shared
state
among
you
among
your
instances,
I
I,
don't
think
you
will
directly
exposed
to
database
to
the
JavaScript
app.
So
we
will
have
come
some
kind
of
some
kind
of
back-end
component
if
I
take
a
look
under
standard
environment
such
as
spring,
in
combination
with
nodes,
yes,
or
something
like
that.
There
are
plenty
of
templates
that
you
just
instantiate
and
they
give
you
an
angular
front
end
and
a
spring
back
end
and
that's
a
default
architecture.
H
F
Course
so
thanks.
So
my
question
on
that
is
in
an
environment
where
you
have
a
single
page,
app
front-end
with
a
spring
back-end
or
something
like
that.
Are
there
enough
recommendations
in
the
existing
documents
that
cover
that
deployment
scenario
or
the
things
about
that
scenario
that
are
unique
that
should
be
described
by
this
document.
I
mean.
H
F
H
H
Okay,
I
misunderstood,
use
questions.
Sorry,
no!
It's
not
because
the
security
PCP
is
intended
to
be
generic
as
generic
as
possible,
and
we
haven't
included
any
recommendations
for,
for
example,
SPS
or
native
apps,
because
we're
native
apps
we
have
the
native
app
the
PCP
and
4s
paas
yeah.
We
have
this
SP
a
BCP
so,
for
example,
recommendations
on
the
use,
of
course,
although
we
have
discussed
about
that
so
then
you'll
discussed
about
that
with
neo
Madden
from
Fort
Rock
on
the
under
list.
H
J
Ludwick
sites
relating
a
comment
from
Justin
from
jabber,
we
should
mention
things
like
a
stay
with
proxy
backed
apps
and
generally
put
them
out
of
scope.
Specifically,
this
draft
should
only
deal
with
things
that
see
that
off
tokens
inside
the
browser,
but
we
can't
ignore
that
people
follow
other
patterns
and
we
want
to
steer
them
in
the
right
direction
and,
namely
those
should
usually
use
cookies
between
the
browser
and
the
backend
and
not
off
in
the
browser.
Thanks.
F
Okay,
so
that's
a
that's
the
completely
opposite
opinion
here,
so
that
that's
sort
of
what
I
wanted
to
discuss
so
Justin's
saying
we
should
this
document
should
only
cover
cases
where
the
browser
has
the
access
token
and
is
really
a
pure.
The
browser
is
the
one
doing
the
OAuth
flow,
so
that's
kind
of
where
we're
I'm
like
where,
where
where
should
we
fall
with
this.
K
So
John
Bradley
yubico,
if
I
understand
Justin
correctly
and
even
might
my
opinion,
the
I
mean
these
apps
in
the
browser,
aren't
want
just
one
thing
or
the
other.
They
may
have
a
back-end,
but
they
may
also
be
using
OAuth
tokens
in
the
browser.
So
just
because
the
app
has
a
back-end
doesn't
mean
that
if
it's
getting
and
using
weilding
auth
tokens
directly
that
this
BCP
shouldn't
apply
to
it,
so
this
should
apply
to
any
app
that's
using
OAuth
directly
with
OAuth
tokens
managing
those
OAuth
tokens
in
the
browser.
K
Yes,
a
different
pattern,
which
Torsten
is
legitimately
recommending
is
you
could
move
all
of
your
OAuth
to
your
back-end,
but
some
people
may
choose
not
to
do
that
for
a
number
of
reasons,
so
we
can
say
for
apps
that
choose
not
to
move
all
of
their
stuff
to
a
back-end,
all
of
their
OAuth
calls
to
a
back-end
server.
This
is
how
you
protect
the
oh-ah
functionality
that
you're
going
to
keep
in
the
single
page
app.
So
this
is
about
apps
that
do
OAuth
in
the
browser,
not
not
excluding
apps.
That
may
have
a
back-end
okay.
F
K
H
Tosun
again,
I
think
there
are
two
ways
to
or
two
kinds
of
Olaf
in
the
browser.
One
or
often
the
browser
means
you
have
an
application.
That's
heaven
that
hasn't
a
user
interface,
that's
running
in
the
browser
and
is
user
interface.
Amar
interacts
with
the
OAuth
authorization
server,
so
it
somehow
initiates
authorization
requests
and
it
receives
authorization
responses
how
those
responses
are
being
processed.
H
Doesn't
matter,
I
mean
in
the
native
PCP.
We
don't
exactly
describe
how
the
front
of
a
native
app
and
potentially
the
backend
are
interacting
with
each
other
and
what
the
boundary
is
between
them
for
good
reasons,
because
we
don't
care
it's
up
to
the
software
developer,
to
design
that,
and
that's
one
one.
One
way
you
can
look
into
that
yeah
an
SP
a
from
my
perspective
is
just
another
user
interface
for
an
application,
and
the
internal
application
architecture
is
a
completely
different
thing,
so
it
has
to
receive
an
authorization
request.
H
The
important
point-
and
that's
where
it
comes
to
the
second
view
on
Olaf
in
a
browser,
is
just
the
front
end.
That's
running
in
the
browser
also
process
the
authorization
response,
which
is
just
one
of
two
options
right:
the
user
interface
can
just
pass
the
code
or
whatever.
No
it's
it's
it's
supposed
to
be
the
code
to
the
backend
or
it
can
just
directly
call
the
authorization
server,
a
read,
email
access,
token.
Those
are
different
options
right
and,
from
my
perspective,
we
should
discuss
both
it's
both
Oh
off
in
the
browser
right
yeah
thanks.
F
J
Excites
again
relaying
just
in
from
jabber
Torsten
and
I,
don't
actually
disagree,
I
think
I'm
saying
talk
about
it
and
put
it
into
the
right
scope,
not
covering
it
and
not
mentioning
it
not
covering
it
and
not
mention
it
at
all
or
two
different
things.
I
think
we
should
mention
it
and
not
cover
it
like
what
John's
saying.
F
So
what
I'm
hearing
is
the
particular
architecture
of
your
browser
based
app
is
not
necessarily
the
important
distinction
here.
It's
whether
or
not
the
browser
and
the
job
and
the
JavaScript
or
whatever
code
is
running
in
the
browser,
is
at
all
actually
involved
in
the
Roth
flow,
either
initiating
it
or
redeeming
a
code
or
handling
an
access
token,
and
that
should
be
the
scope,
and
then
we
just
we
describe
the
different
architectures
within
that.
Okay,
that's
that's!
F
That
is
great,
I
would
and
any
other
points
on
that
so
I
do
want
to
get
to
some
of
the
other
questions
here.
I
think
that's
very
helpful,
though.
Thanks
for
the
input
there,
okay,
so
with
the
sort
of
the
high-level
scope
question
out
of
the
way
I
wanted
to
get
into
some
of
the
more
particular
details
of
this,
especially
as
they
relate
to
the
security
BCP,
as
that
has
been
evolving
as
well.
F
F
H
Well,
we
just
haven't
talked
about
it.
I've
talked
about
that,
so
we
haven't
really
come
to
a
conclusion
because
that
the
chairs,
first
one
a
send,
send
a
posting
to
the
list
to
get
get
a
failing
on
a
sense
of
the
working
group,
but
they
they
were
had
the
trouble
tremendous
positive
feedback.
So
we
will
be
gonna
update
security
BCP,
but
that's
not
in
there
yet.
But
if
your
fellow
follow
suit,
that's
perfect.
I
F
F
F
K
Yeah
further
to
that
state
will
continue
to
be
opaque
to
the
server
nothing.
It's
an
option
for
a
client
to
not
to
use
pixie
instead
of
state
every
application
currently
using
state.
The
two
percent
that
actually
correctly
use
state
for
CSRF
protection
will
continue
to
work
properly
and
the
rest
will
continue
to
be
broken.
M
H
Wasn't
chosen
again
my
proposal,
just
let
us
discuss
through
all
those
topics,
so
pixie
and
and
and
and
then
it
depicts
the
mode
and
so
on,
come
to
a
conclusion.
I'm
totally
agree
with
Tony.
We
first
have
to
do
our
analysis
and,
as
Philippe
pointed
out,
we
have
also
to
check
whether
the
chart
will
not
a
56
mode,
also
works
for
all
kinds
of
applications,
so
I
think
we
have
to
sort
it
out,
and
then
we
documented
in
the
PCP,
and
we
can.
H
D
D
The
best
current
practice
document
is
supposed
to
illustrate
the
best
current
practice:
it's
not
less
Lia
what
we
do
today
there
may
be
actually
a
disconnect
between
what
we
recommend
going
forward
as
sort
of
a
kind
of
a
missionary,
at
least
to
a
certain
extent,
not
like
this,
a
fine
line
between
sort
of
trying
to
steer
the
community
in
the
right
direction
versus
being
overly
ambitious,
unrealistic.
Potentially.
So
we
to
keep
that
in
mind
this
part.
F
So
that's
something
I
would
like
everybody
else
to
keep
in
mind
as
we're
working
through
this
and
I
think
we
should
probably
have
more
these
discussions
on
the
list
offline
since
they're
kind
of
bigger
questions,
but
that's
what
I'm
looking
for
of
like
in
the
security
PCP.
Is
it
saying
anything
that
is
like
too
hard
to
you
to
do
in
a
browser
that
we
need
to
address
differently
or
is
it?
Is
it
saying
stuff
that
that
we
should
make
sure
you
do
in
a
browser
the
where
the
security
PC
teammates?
F
F
There
was
a
there
was
a
in
the
original
discussion
of
this
back
in
October
when
we
were
white
boarding
it
out
at
iiw,
I
took
picture
the
whiteboard,
and
then
it
was
there
and
I
was
trying
to
figure
if
this
came
from.
But
there
was
an
idea
that
there
should
be
an
option
for
browser-based
apps
to
do
hostname.
F
Don't
remember
why
that's
there,
but
now
it's
in
the
document
and
I
want
to
see
if
anybody
has
any
recollection
of
or
any
experience
with,
the
deployment
scenario,
where
they're
doing
a
browser-based,
app
environment
and
matching
only
on
the
hostname
of
the
reader
at
URL
to
sort
of
allow
like
a
pseudo
wildcard
redirect
URL.
That
seemed
that
throws
up
red
flags
to
me
because
everything
else
about
OAuth
says
you
should
do
exactly
direct
URL
matching.
F
But
there
was
something
about
the
browser-based
environment
and
JavaScript
environment
that
suggested
this
was
an
option
and
I
would
love
to
remove
that.
If
that
that
sort
of
exception
here,
if
there
isn't
a
good
reason
to
have
it,
says
anybody
off
top
of
their
head,
have
any
scenario
where
you
would
want
to
allow
a
sort
of
wild
card
match
on
the
radar
to
go
with
matches.
Only
the
host
name
and
about.
N
N
That's
still
possible
doing
everything
in
the
browser
I
mean
usually
the
way
we
we
tell
people
to
do.
That
is
have
a
single
redirect
URL
endpoint,
that
extracts
from
state
where
you're
supposed
to
go
back
to
that's
so
possible
in
the
browser,
but
it
does
mean
having
to
push
more
of
that
logic.
You
know
into
JavaScript,
and
so
we
have
to
think
about
how
does
that
work?
What
libraries
are
available
to
support
that
in
a
secure
fashion,.
N
Just
doesn't
assume
I
mean
we
have
to
change
our
guidance
here,
but
there's
probably
room
for
giving
some
examples
or
some
some
guidance
on.
How
do
you
address
these
issues?
Maybe
this
is
something
that
should
really
be
in
the
security
BCP
I
don't
know,
but
that
I
think
this
is
an
area
where
the
specs
have
been
a
little
bit
weak
and
as
far
as
pointing
people
in
the
right
direction,.
J
K
I'm
gonna
raise
Justin
and
they're
definitely
wrong,
but
I
agree
with
Annabel.
We
have
to
give
I
mean
again
we
get
back
to
state
and
people
misusing
it
or
not,
understanding
what
it's
for
so
providing
advice
either
in
the
BCP,
the
security
BCP
or
this
BCP
about
actually
not
just
whacking
on
query
parameters
because
they're
convenient,
which
is
the
way
that
people
traditionally
maintain
state
inoue
but
put
put
it
in
the
in
the
state,
parameter
and
also
discuss
integrity,
protecting
the
state
parameter
because
there
are
possible
attacks.
K
K
N
Annabelle
back
them
again,
I
will
go
step
further
and
say
we
should
actually
think
about
revisiting
like
a
sign
or
state
as
a
job
kind
of
specification.
Instead
of
just
punching.
This
problem
to
the
client
actually
give
them
a
potential
solution
that
covers
as
much
of
the
basis,
as
can
be
generalized.
K
L
K
D
L
K
F
Thank
you
thanks.
Okay,
I,
quick,
quick
ones
so,
like
I
can
mentioned
earlier.
One
question
is:
if
we're
gonna
require
pixie,
is
s
256
reasonable
to
require
in
a
browser,
and
are
there
good
enough,
JavaScript
libraries
for
it
and/or
is?
Is
there
like
a
browser
library
that
can
do
these
these
hashes
now
or
do
we
need
to
allow
plane
in
in
the
browser-based
app
scenario
for
a
while?
Even
if
it's
not
necessarily
the
best
practice,
does
anybody
have
experience
on
that
front?.
M
Plus
one
to
us-
or
it
is
a
flip
spoken
of
zero
web
crypto-
is
there
widely
supported?
The
only
problem
is
that
it
is
promise
based
even
for
chars,
even
for
hashes.
So
if
you're
gonna
do
anything
like
a
pop
up
mode,
where
you
want
to
open
a
new
window
to
do
the
authorization,
then
sin,
then
you
might
run
into
issues
where
you
can't
open
the
the
actual
window
after
the
promise
has
been
resolved.
Interesting.
M
N
Yeah
I
think
there's
workarounds
for
that
there
are
a
lot
of
other
problems
that
you
run
into
trying
to
deploy
a
pop-up,
based
speaking
from
experience,
trying
to
deploy
a
pop-up
based
both
experience
that
I
don't
think
it's
I,
don't
think
it
makes
sense
for
us
to
restrict
our
guidance
based
on
that
particular
use
case.
Great.
F
F
Okay,
the
last
point
I
want
to
talk
about
was
about
passwords.
I
know,
there's
been
some
more
talk
about
that
lately
as
well.
The
right
now,
the
browser,
the
browser
app
spec,
does
specifically
say
that
you
should
either
do
auth
code
and
pixie
or
use
the
password
grant
for
JavaScript,
apps
and
I
would,
for
many
reasons
like
to
avoid
recommending
the
password
grant
at
all,
so
I'm
wondering
what
we
can
do
on
that
front.
So
any.
K
F
H
H
Toast
Ligon,
as
you
have
seen,
this
is
one
of
the
of
the
open
issues
we
will
be
working
on
in
security
PCP.
So
if
this,
if
the
SP
a
BCP
just
follows
the
recommendation
of
the
security
BCP,
I
think
once
we
discourage
use
of
the
password
grant,
you
no
longer
need
to
to
really
mention
that
unless
you
really
want
to,
but
I
don't
see
a
real
need
for
that.
N
Anabelle
back
when
again
this
correct,
this
might
be
able
to
go
further
than
the
security
BCP.
In
that
the
use
case
that
was
mentioned,
the
rationale
behind
password
the
password
grant
is
wanting
to
avoid
redirects
and
whatnot.
There
are
other
ways
to
do
that,
if
you're
already
in
a
browser
environment
that
normally
we
would
recommend
against
things
like
embedded
iframes,
that
if
you
are
going
to
accept
this
curity
world
of
collecting
passwords
on
this
other
set
the
site,
then
the
concerns
around
embedding
an
iframe
there.
N
Embedding
your
your
sign-in
experience
in
an
iframe
on
that
page.
Don't
really
register
like
if
you're
accepting
one
you're
gonna
accept
the
other.
So
it's
really
at
that
point
no
reason
to
need
to
have
the
password
grant.
So,
even
if,
even
if
the
security
BCP
says
not
recommended,
we
might
consider
a
must
not
here.
F
D
F
F
F
F
F
Around
passwords,
it
sounds
like
the
the
consensus
here
is
to
not
allow
passwords
in
JavaScript
apps,
and
we
should
probably
continue
that
discussion
on
the
list
for
a
little
bit,
but
the
direction
we're
going
to
move
there
is
hopefully
to
explicitly
disallow
passwords
house
we
grant
from
JavaScript
apps,
even
if
the
security
BCP
doesn't
necessarily
go
that
far
with
that
recommendation
that
it
like
every
anything
else,
I
forgot
great.
Thank
you.
D
D
Too,
to
summarize
so
we
had
the
BOP
talked
usage
for
HTTP
specified
in
OS
working
group,
but
the
coop
based
version
or
potentially
for
other
IOT
related
security
protocols
in
age
working
group.
We
had
a
lot
of
back
and
forth,
which
luckily
came
to
an
end
in
terms
of
aligning
it
thanks
a
lot
big
for
that.
So,
but
of
course
they
can
be
combined.
Both
of
them
can
be
combined
this
world.
D
D
So
we
had
in
in
this
document
OS
working
group
document
we
separated
out
with
an
earlier
version
we
separated
out
the
functionality
of
requesting
and
obtaining
that
pop
based
information
and
in
everything
related
to
the
DoCoMo's
in
this
document.
But
the
resource
indicator
aspect
were
separated
out
into
a
separate
document
that
you
I'm
sure
you
recall
the
discussion.
The
document
is
currently
in
the
is
G,
so
that's
that's
great
Luke
has
written
another
document,
the
azores
parameters,
which
describe
the
parameter
encoding
for
in
coop.
D
For
the
parameters
that
are
also
listed
in
here-
so
that's
that's
pretty
good.
There's
one
thing
I
wanted
to
point
out,
which
is
also
in
the
latest
version
included
in
the
reference
that
we
actually
have
in
absolutely
awry
in
the
resource
indicator
on
sort
of
in
the
resource
barometer
and
a
logical
name
in
the
audience
barometer
which
are
separated
out
in
two
different
documents.
D
So
I
included
their
preference,
because
that
was
created
some
coefficient
and
Elizabeth
when
I
posted
the
version
right
before
the
IDF
meeting,
which
was
really
only
an
update
to
take
some
of
the
most
recent
developments
into
account
and
I
then
got
this
review.
So
a
couple
of
copy
and
paste
errors
which
we
fixed
and
a
couple
of
additional
notes.
We
added
so
this
was
fixed
with
version
or
seven.
D
H
Just
in
just
one
question:
why
we're
working
we're
working
on
the
depop
draft
that
you're
gonna
gonna
get
to
know
in
this
session?
I
realize
that
deep
up
just
indicates
the
public
key
or
sense
the
public
key
that
it
wants
to
bind
to
token
to
to
the
ass
without
any
proof
of
possession.
That's
correct!
H
D
H
P
H
Unlike
we
identify
that
it's
is
a
need
for
deep
op
yeah.
My
question
is:
have
you
analyzed
the
security
implications,
because
someone
could
potentially
inject
the
public
key
or
something
like
that
and
and
just
make
the
access
token
to
be
bound
to
a
completely
different
key
pair?
So
have
you
analyzed
the
security
implications?
I
mean
we
could
also
simplify
depop.
If
it
turns
out
yeah
there's
an
even
out.
We
didn't.
J
Ludwig
cites
as
himself
in
ace
will
require
public
keys
or
yeah
public
keys
that
proof
of
procession
for
a
public
key
that
the
client
requests
the
yes
to
include.
In
a
token
and
honestly,
I
would
like
to
hear
a
very
good
scenario
for
where
we
would
want
not
to
do
that
and
off,
because
why
should
we
let
someone
inject
the
public
key?
In
a
token
when
we
don't
know
whether
he's
in
control
of
it
or
not?
Well,
how
do
we?
How
do
we
do
that
in
ace
in
ace?
J
J
K
Torsten
and
and
the
rest
of
us
feel
strongly
that,
in
order
to
register
a
key
to
be
used
as
proof
of
possession,
you
must
demonstrate
that
you
actually
control
the
private
key
is
part
of
that
message.
Exchange
so
did
that
and
as
Torsten
points
out
that
isn't
actually
a
requirement
at
pop
key
distribution.
Q
Then
Caidic
first
john,
thank
you
for
saying
that,
but
totally
agree.
I
came
up
to
the
mic
because
of
this
comment
about
the
public
key
that
you're,
using
in
the
DTLS
handshake
being
expected
to
be
the
key
that
is
in
the
token,
and
that
seems
kind
of
questionable
from
the
cryptographic
standpoint
in
terms
of
using
the
same
key
in
different
scenarios.
D
Well,
but
also
later
from
the
communication
to
the
resource
server,
the
even
if,
if
MPLS,
when
we
find
the
token,
we
have
the
key
that
we
use
in
in
TLS,
it's
the
one
that
is
bound
to
the
token.
So
in
that
sense,
that
would
follow
a
very
much
a
similar
pattern
used
already
in
other
documents.
But
probably
we
have
no
I.
Don't
think
that
we.
H
I'm
toasting
yeah,
that's
the
way
the
M
TLS
works,
and
we
also
had
a
discussion
in
Bangkok
whether
we
would
like
to
add
in
other
parameter
and
allow
the
client
to
request
token
binding
to
a
different
public
key,
and
we
decided
to
not
go
that
way
because
I,
don't
typically
used
to
say
it.
It
opens
a
can
of
worms
and
the
convinced
ants.
So
we
are
relying
on
the
under
under
on
the
proof
of
possession,
that's
being
provided
by
the
client
authentication.
I.
Think
that
would
make
sense
for
pop
P.
K
Okay,
so
John
Bradley
again,
so
the
so
I
understand
Benjamin's,
concern
and
agree
with
it.
So
if
your
so,
it
depends
on
the
proof
method
that
you're
using
to
the
resource.
If
the
proof
method
is
perhaps
signing
an
object
but
you're
proving
possession
over
mutual
TLS,
then
those
are
kind
of
two
different
uses
of
the
key
and
would
be
considered
different.
K
In
my
mind,
to
the
in
the
mutual
TLS
draft
were
using
mutual
TLS
client
authentication
to
establish
the
key
and
to
prove
the
key,
so
in
that's
kind
of
a
special
case
where
you're
guaranteed
not
to
have
different
different
uses
of
the
same
same
key.
But
in
a
more
generalized
case,
if
I
was
wanting
to
do
TLS
to
the
token
endpoint,
but
have
a
different
signing
key
then
arguably
I
may
want
to
have
different
protections,
because
there
are
different
security
concerns
around
I
protect
a
TLS
key
versus
a
signing
key.
D
J
N
J
D
K
Whether
you
prove
that,
where
it
gets
gray,
is
if
you're
using
TLS
to
prove
possession
of
the
private
key
that
you
then
intend
to
use
at
some
other
application,
layer,
etc
that
you
Annabelle
and
other
people's
minds.
That's
where
it
gets
a
bit
slippery
using
what
a
proof
from
one
layer
at
a
different
layer.
So
that's
what
we
need
to
look
at.
It's
not
that
we
don't
want
it
and
we
don't
I,
think
everyone
thinks
that
yes,
providing
a
proof
is
important,
perhaps
required
it's.
P
R
Dave
Robin
I
understand
the
security
implications
of
saying
that
I
want
you
to
sign
it
with
that
guy's
public
key,
but
I.
Don't
control
that
public
key.
However,
that
is
a
legitimate
scenario
of
where
that
thing
is
deeply
embedded
device
and
I
am
a
sophisticated
device
and
I'm
getting
access
tokens
on
his
behalf,
but
I
don't
actually
control
any
of
the
credentials
that
he
has
I.
Don't
control
these
private
key
I.
Need
you
to
make
a
token
and
give
it
to
him.
R
I
need
to
give
it
to
it,
because
I
have
a
back
channel
to
him
and
you
don't
so,
there's
no
introspection
possibility
anyway.
It's
just
it's
a
scenario,
but
I
don't
want
to
completely
discount
that
I
have
some
sort
of
big
sophisticated
thing.
That's
that's
getting
access
tokens
on
behalf
of
deeply
embedded
products
and
jamming
them
down
in
there
and
I
can't
prove
that
I
have
is
private
key,
but
I
need
you
to
bind
it
to
his
public
key.
H
Toast
just
as
a
reflection,
if
you've
got
it,
if
you
got
a
back-channel
sorry,
if
you've
got
a
back
channel
to
this,
not
so
sophisticated
device,
it
could
also
create
a
proof
of
possession
for
you
for
actually
sending
the
authorization
request.
So
it's
not
really
precluded
if
just
as
an
idea
right.
What
I
would
like
to
say
is
that
as
an
observation
in
M,
TLS
and
also
token
binding,
we
always
enforce
the
client
to
really
demonstrate
proof
of
possession
before
the
binder.
H
K2
meter
feels
like
a
design
pattern
or
design
principle,
and
my
feeling
is.
We
should
follow
that
principle,
except
we
a
really
good
reason
to
have
more
flexibility.
I
was
arguing,
draw
boards
yeah,
let's,
let's
build
into
this
flexibility
into
em
TLS,
because
that
would
allow
in
exactly
this
kind
of
scenario,
that
someone
gets
a
token
for
someone
else.
But
you
really
need
to
understand
the
security
implications
so.
J
Quick
comment
on
your
statement
there:
it
might
be
that
the
back
channel
is
not
readily
available.
You
might
I
mean
if
you
want
to
do
a
proof
of
possession,
you
need
to
kind
of
knowns
from
the
AAS
and
if
your
back
channel
involves
going
to
the
device
and
plugging
into
it
or
something,
then
that's
not
a
good
option.
Just
clarification.
M
N
Anabelle
again,
I
kind
of
to
that
point.
I
think
we
want
to
consider
what
use
cases
we're
trying
to
optimize
for
here.
I
think
the
the
the
one
just
described
is
that
there's
a
you
know
a
valid
use
case
there,
but
it's
also
nuanced
enough
and
has
enough
unique
characteristics
that
it
may
be
worth
treating
that
separately
in
tackling
that
that
scenario
separately
from
the
more
general
case
where
this
we
can
make
some
sort
narrower
assumptions,
I.
R
D
C
H
Good
morning
again,
Joslin
yes,
come
get
the
pleasure
an
honor
to
present
the
current
status
of
MPLS
on
behalf
of
Brian
Kemp
Oh
Brian
you're
supposed
to
enjoy
your
holiday
right
now,
all
right
once
what
has?
What
is
what
is
MTL
is
all
about.
I
mean
we've
heard
about
MPLS
in
Indy,
and
the
comment
in
the
last
couple
of
minutes.
I'm
TLS
is
a
mechanism
that
utilizes
TLS
client
authentication
for
two
different
use
cases.
H
One
is
the
authentication
of
the
client
or
boards
das
and
the
second
one
is
to
use
the
key
materia
to
bind
the
issued
tokens
to
the
private
key,
that's
being
used
for
the
TLS
connection
on
the
client
side.
So,
basically
it's
an
alternative
to
token
binding
and
something
we
will
see
later
on
all
right.
What
happened
since
Bangkok?
H
There
were
also
new
meta
data
edit.
So
now
it's
possible
for
a
client
to
register
more
than
the
subject
DN
to
being
identified
based
on
the
data
in
the
certificate.
So
there
are
a
couple
of
new
options.
One
of
them
is
the
email
address.
One
is
the
IP
address.
One
is
the
URI
that's
based
on
a
request
being
done
by
a
representative
of
a.
H
Thanks
a
lot
for
that
because,
as
he
pointed
out
when
you
want
to
use
MPLS
in
a
browser-based
application,
it
will
be
experiencing
the
sometimes
really
awkward
user
experience
that
the
user
applies
when
the
Wendy,
when
the
TLS
enable
end
point
asks
the
user
to
present
certificates,
our
recommendation
for
MTL
is
to
set
up
the
token
endpoint,
for
example,
in
a
mode
that
optionally
supports
TLS,
client
authentication.
So
the
client
may
decide
whether
it's
gonna
use,
client
authentication
as
a
method
or
any
other
method.
The
problem
is
in
user
agents
or
in
in
that
environment.
H
The
the
server
anyway
sends
a
first
message
and
asks
the
user
for
the
certificates
and
in
native
apps
and
other
apps.
This
is
just
suppressed,
whereas
in
a
browser,
this
typically
will
pop
up
a
dialog
asking
the
user
in
some
circumstances.
What
certificate
to
use
for
that
particular
connection
and
it's
really
bad,
because
the
certificates
we're
gonna
use
for
EM
TLS
are
device
application,
bound
certificates
that
have
nothing
to
do
with
the
user
identity.
So
the
user
is
not
really
aware
of
the
existence
of
those
certificates
and
that's
okay.
H
So
since
there
is
no
way
to
control
that
from
within
the
app
the
solution
being
proposed
and
also
documented
right
now
in
the
draft
is
that
the
AAS
can
maintain
one
set
of
TLS
and
points
that
are
configured
to
support
client
authentication.
So
they
are
empty,
LS,
ready
and
another
set
of
endpoints
that
do
not
require
any
kind
of
a
TLS,
client
authentication.
H
The
questions
being
discussed
on
the
list
was
more
how
we
actually
represent
this
kind
of
metadata,
and
there
were
two
options
being
proposed.
One
was
a
completely
alternative,
AAS
metadata
file
and
the
other
one
was
to
include
a
section
into
the
stone
of
metadata
file,
called
I,
think
TLS,
endpoint,
aliases
and
just
add
those
endpoints
to
that
section
that
are
relevant
for
MPLS.
So,
for
example,
the
token
endpoint
potentially
introspection
and
revocation
Oh.
H
Then
there
is
a
new
privacy
conservation
section
discussing
the
implications
of
the
way
certificates
are
being
handled
in
a
TLS
up
to
version
1.2,
because
in
that
case
the
public
key
certificate
is
sent
in
the
clear.
So
the
implications
regarding
privacy
is
now
also
discussed
in
the
document,
and
there
is
some
more
text
about
hash
algorithm
agility
in
the
security
conservation
section.
N
Firstly,
I
think
the
example
yeah
that
one
I
believe
that
violates
RFC
84
14,
the
authorization
server
metadata
spec,
because
that
spec
says
regarding
where
was
it
I
had
it
up
here
regarding
the
token
endpoint
off
methods
supported
that
it
is
optional,
a
JSON
array
containing
a
list
of
client
authentication
methods
supported
by
this
token
endpoint
in
the
context
of
the
spec.
That
means
the
token
endpoint
listed
in
the
token
endpoint
property
we
are.
N
H
Might
be
right,
I
think
you
should
be
waiting.
Til
Mike
arrives
again,
so
you
can
comment
on
that.
More
deeply.
I
think
the
assumption
is
that
the
MTA,
less
aware,
client
first
looks
up
the
authentication
method
see
there
is
a
TLS
client
authentication
support
and
then
looks
for
the
M,
TLS
and
pound
aliases
I
think
we
could
cope
with
the
issue
just
raised
by
just
having
a
copy
of
there
or
a
redundant
token
end
point
of
methods
supported
in
DRM
TLS.
H
Let's
call
it
metadata
and
have
those
elements
added
there
to
this
to
this
particular
economy.
I
think
that
that
should
be
feasible,
because
in
the
end
it's
it's
the
same
way
as
the
alternative
made
today.
That
would
work
right
what
you
would
look
for
the
alternative
metadata
and
then,
if
that
does
not
access,
you
will
fall,
would
fall
back.
So
it's
it's
now.
The
logic
is
quite
the
same.
I
think
when.
N
It
was
that
first
step
that
led
me
down
the
path
of
going
hey.
Let's
just
make
this
a
separate
document,
because
that
way,
we
we
don't
have
to
worry
about
other
issues
like
this
that
may
come
up
in
the
future,
as
there
are
further
iterations
on
what
goes
into
the
authorization
server
metadata
as
like,
every
single
new
spec
that
comes
along
practically
as
introducing
new
properties
there,
which
gets
to
one
of
the
other
concerns
I
had
which
is
around.
N
Are
we
requiring
now
that
every
spec
that
introduces
a
new
endpoint
property
also
has
to
define
that
under
MPLS
endpoint
aliases?
It
looks
like
the
language
in
MPLS
right
now
is
kind
Fuzzy's
around
that
and
is
sort
of
saying.
Well
anything,
that's
an
end
point
property
can
also
go
under
em.
Tls,
end
point,
aliases
and
maybe
that's
come
out-
adds
enough
flexibility
there
that
we
don't
need
to
expect
people
to
be
too
explicit,
but
again,
I
just
want
to
make
sure
we're
being
intentional
about
that.
N
H
H
Mike
welcome
back
Annabelle
just
raised
the
issue
that
the
syntax
has
shown
in
the
example
violates
on
the
is
metadata
RC,
since
the
TLS
of
client
off
method
is
contained
in
the
top
management
of
methods
supported.
Although
the
token
end
point
in
the
same
in
the
same
context,
does
not
support
an
TLS.
F
N
Can
restate
my
objection?
So
if
you
look
at
the
text,
484
14,
it
says
that
the
token
and
point
Oz
method
supported
is
a
list
of
Awesome
edits.
It's
supported
on
the
token
endpoint.
That's
plainly
no
longer
the
case
here,
because
now
it's
a
list
of
token
of
auth
methods
supported
on
one
of
these
two
token
endpoints,
so
that
that
is
a
change
in
the
semantics
of
that
property
right.
We
should
make
sure
we're
working
group
are
comfortable
with
that
change
or,
if
we're
not,
then
we
need
to
think
through.
N
How
else
do
we
do
that?
It's
as
a
further
example
of
where
this
potentially
goes
wrong
is
like
in
this
context.
We
understand
really.
This
only
applies
to
TLS
client
offs,
but
outside
of
the
context
of
this
room.
Somebody
looking
at
this
is:
do
they
understand
that?
Do
they
realize
that
okay,
TLS
client
auth
is
supported
on
this
endpoint
mm-hmm
and
everything
else
is
supported
over
on
that
endpoint
or
is
there
a
question
of
okay
client,
also
supported
here,
client
secrets
supported
there.
N
O
O
O
K
C
C
P
C
L
Give
Daniel
fat
with
yes
calm
first
time
here
and
yesterday,
I
uploaded
my
first
draft
demonstrating
proof
of
possession
at
the
application
layer.
So
this
was
an
idea
that
came
up
at
the
all
security
workshop
last
week
and
struck
that
the
problem
is
we
heard
about
this
before
so
the
all
security
BCP
to
recommend
recommends
to
send
a
constraint
tokens
which
absolutely
makes
sense,
but
orth
lacks
a
suitable
mechanism
in
an
SP,
a
or
let's
say
in
a
browser-based,
app
or
whatever.
You
want
to
call
it.
L
L
L
L
But
signatures
are
used
only
for
the
proof
of
possession
for
the
public
key
itself
or
the
product
itself,
and
also
for
replay
detection,
whereas
the
message
for
message
integrity.
We
have
to
rely
on
to
your
les
to
give
you
a
brief
idea
of
what
the
current
approach
looks
like
in
the
auth
flow.
We
have
in
step,
C
the
token
requests
and
to
the
stockmen
requests.
We
attach
deep
Alpine
binding
that
is
assigned
jawed
that
contains
a
public
key
and
also
information
about
the
request.
Enricher
disused,
namely
the
method
and
the
path.
L
Then,
when
the
client
wants
to
use
that
access
token,
that
sensor
so-called
Depot
proof,
which
is
a
JWT
which
is
again
signed
by
the
same
public
key
and
again
contains
information
about
the
end
point
where
it
is
used.
A
new
request
for
it
is
used
and
the
resource
server
can
now
check
that
if
the
access
token
is
JWT,
then
in
the
access
token,
you
probably
would
have
the
public
key
signed
by
the
authorization
server
so
that
the
resource
server
can
just
check
the
topic
key.
L
Otherwise,
if
you
use
token
its
introspection,
then
the
resource
server
would
go
to
the
authorization
server
and
in
the
intro
introspection
response
received
the
public
key,
which
was
presented
by
the
client
earlier.
We
can
also
use
especially
for
public
lines,
the
same
mechanism
if
you
want
to
get
a
fresh
refresh
token,
if
you
want
to
use
the
Refresh
token
to
get
a
fresh
access
token
there,
you
would
obviously
also
be
able
to
attach
a
new
proof
and
maybe
also
even
find
a
new
public
key
and
rotate
that
in
the
process.
L
L
K
John
Bradley
yubico.
So
by
way
of
sort
of
explanation
of
the
origin
of
this,
we
sat
through
some
long
explanations
about
xsrf
attacks
on
single
page
applications,
and
at
the
end
of
that,
we
decided
that
we
should
just
completely
eliminate
browsers
because
they're
an
attack,
vector
I,
agree
short
of
that.
K
The
finding
the
you
know,
binding
tokens
to
the
browser
instance,
doesn't
solve
all
problems,
because
an
attacker
can
still
take
over
your
JavaScript
act
and
wield
the
tokens
inside
of
the
user
agent,
but
not
allowing
the
the
attacker
to
exfiltrate
those
tokens
cuts
down
a
bunch
of
things
that
forcing
them
to
use
them
inside
the
same
user.
Agent
gives
you
more
options:
more
ability
to
detect
something
horrible
has
happened.
K
So
in
order
to
come
up
with
a
way
of
not
exfiltrating.
The
observation
was
made
that,
yes,
we
do
have
web
crypto
now
and
you
can
create
keys
that
are
non
exportable
in
the
browser.
So
this
was
a
mechanism
of
essentially
we
have
Justin's
HTTP
signing
draft.
We
had
Nats
j-pop
draft.
This
is
cutting
all
of
the
stuff
that
wasn't
absolutely
required
out
of
the
proof
mechanisms.
K
Now
we
can
private
we're
probably
going
to
have
a
long
discussion
about
yes,
I
want
to
add
back
signing
header
signing
the
header
signing
the
body
and
various
other
things,
and
those
are
all
debates
that
that
we
can
have
going
forward.
This
is
the
sort
of
minimal
subset
that
one
would
need
to
meet
the
basic
use
case,
there's
nothing
that
would
stop
us
from
adding
back
all
those
canonicalization
options
in
the
access
to
in
the
proof
for
the
access
token.
K
But
this
also
we're
also
focusing
on
not
forcing
people
to
do
pre
flights
by
requiring
use
of
a
header.
So
there's
a
bunch
of
things
when
you're
doing
cores
that
have
to
be
taken
into
account,
so
you
can
double
the
amount
of
calls
that
a
single
page
application
has
to
make
we're
trying
to
avoid
doing
that.
So
this
is
targeted,
but
people
will
undoubtedly
argue
that
we
should
add
back
a
whole
bunch
of
other
stuff.
So
ok.
I
O
Mike
Jones
Microsoft
I
think
it
would
be
useful
to
explain
to
the
room
because
most
people
weren't
in
Stuttgart
last
week,
there's
a
whole
bunch
of
different
kinds
of
Roth
applications.
There's
native
applications,
there's
single
page
applications,
there's
web
applications
etc,
which
of
those
is
this
mechanism
applicable
to
so.