►
From YouTube: OAUTH WG Interim Meeting, 2021-04-12
Description
OAUTH WG Interim Meeting, 2021-04-12
A
Okay:
let's
go
welcome
everyone,
so
this
is
the
not
well
as
a
reminder.
This
applies
here
too
so
and
before
we
get
going
so
first
some
announcement,
the
isg,
has
approved
two
documents
from
the
ietf
from
this
group.
So
congratulations
to
nat,
john
and
mike
for
finally
getting
approval
for
the
jar
document.
A
Just
for
your
your
information,
the
work
that
the
draft
the
work
group
draft
was
submitted
in
2014
and
the
individual
draft
was
submitted
in
2010,
so
this
document
has
been
in
the
work
for
a
very
very
long
time.
So
congratulations
to
the
another
document
that
was
approved
is
the
job
for
a
profile
for
extra
token,
so
vittorio
and
congratulations
on
that
document
too.
Yours
wasn't
as
bad
as
as
the
jar
document,
so.
A
C
C
A
C
Okay,
can
everybody
see
my
screen?
Yes,
but
yes,
we
can
excellent.
Okay,
thanks
everybody
for
joining
today,
we're
going
to
speak
about
the
auth
to
security
best
current
practice.
This
has
been
in
the
making,
not
for
quite
as
long
as
the
draft.
I
think
work
on
this
started
2015
or
2016,
and
this
is
joint
work
by
torsten,
john
andre
and
me
just
a
quick
recap.
C
C
C
C
C
A
C
C
C
This
enables
a
client
to
identify
from
essentially
from
where
the
authorization
response
is
coming
and
the
nice
or
the
advantage
of
this
solution
is
that
it's
completely
based
on
existing
auth
features.
It's
it
just
means
that
you
have
yeah
use
separate,
redirect
uis
and
register
them
and
so
on
for
each
issuer.
C
C
This
has
been
discussed
since
mix-up
attacks
were
first
discovered,
it's
something
that
for
which
we've
already
formally
proven
the
security.
So
it's
a
it's
a
good
mechanism
and
it's
easy
to
automate
in
libraries,
because
it's
very
simple
to
just
check
this
parameter
and
the
authorization
response
when
you
know
that
it
should
be
there.
So
you
have
the
metadata
flag,
you
can
look
at
it
and
then
process
this
response
parameter.
C
C
Current
or
the
new
recommendation
in
the
security
bcp
is
as
follows.
First
of
all,
a
mitigation
against
mix-up
is
required.
When
the
client
interacts
with
multiple
authorization
servers,
then
we
recommend
to
use
a
mix-up
defense
by
identifying
the
issuer,
which
means
that
you
should
use
the
new
parameter,
the
iss
authorization
response
parameter
by
default,
so
to
say,
but
if
you
have
the
same
information
already,
because
you're
using
automatic
connect
or
jam
or
maybe
other
features
that
already
provide
an
iss
claim
in
the
response.
C
C
We
also
have
some
experience
with
this
in
practice
already,
of
course,
many
people
are
already
following
the
recommendations
we
have,
although
it's
only
a
draft
in
more
specific,
it
is
also
the
foundation
for
or
for
the
security
part
of
oauth21
and
in
the
openid
fabi
working
group.
We
have
the
new
pro
5
rp20,
already
aligned
with
the
security
bcp,
telling
you
very
precisely
how
one
instance
of
this
could
look
like.
C
We
also
have
a
couple
of
future
topics
that
might
at
one
point
go
into
the
same
bcp
or
go
into
different
bcps
or
rfcs.
For
example,
you've
maybe
seen
the
discussion
that
we
had
on
the
mailing
list.
Regarding
specifics
of
mobile
environments,
I
feel
that
there's
a
lot
of
yeah
a
lot
to
learn
in
that
area
or
a
lot
to
that.
C
We
still
need
to
write
down,
for
example,
how
to
do
secure
app
to
app
redirections
on
android,
ios
and
so
on,
but
this
goes
way
beyond
the
scope
of
the
security
pcb,
so
I
wouldn't
recommend
to
put
that
into
the
security
bcp,
especially
because
it's
not
new
attacks
that
we
are
seeing
there.
It's
essentially
variants
of
existing
attacks,
so
I
would
propose
to
update
pcp
212
or
rfc
80
to
52,
which
is
for
native
apps.
C
A
First,
I'm
gonna
post
that
link
to
the
chat
here.
If
you
haven't
added
your
name,
please
to
the
list,
go
ahead
and
add
that
because
I
see
we
have
18
people
here,
but
what
I
see
on
on
that
page
there
we
have
less
number
people
here.
So
please
add
your
name
to
the
list
and
now
let's
go
and
open
it
for
questions.
I
think
philip
is
in
the
queue.
D
D
The
second
point,
where
the
as
must
reject
non-https
redirect
uri
there
is
an
exception
for
native
url
native
client
urls,
pointing
to
the
same
device
now
in
the
draft.
Also
in
your
presentation,
it
mentions
with
localhost
uri
or
custom
scheme
now,
bcb212
actually
says
using
localhost
is
not
recommended
and
in
general
proposes
to
use
loopback
uri
rather
than
localhost.
So
I'm
not
sure
if
the
draft
is
using
localhost
as
the
actual
hostname
or
if
it's
ruling
out
the
possibility
to
use
loopback
addresses
in
favor
of
using
something
which
212
says
is
not
recommended.
C
F
Yeah,
so
I
guess
the
only
point
I
was
going
to
make
is
that
we
probably
shouldn't
recommend
or
mention
I
don't
know.
I
worry
about
the
the
whole
custom
scheme
thing
because
the
212
specifically
says
don't
use
it's.
It's
best
practice
to
not
use
custom
schemes
and
instead
you
use
claimed
uris
yeah.
We
refer
to
pcp212.
C
F
F
And
leave
the
customs,
I
don't
know,
I
I
see
your
dilemma.
You
know
you
specifically
kind
of
have
to
mention
custom
schemes
because
that's
the
non-http
part
the
claimed
uris
are
going
to
be
https
right,
but
by
by
pointing
those
out,
I'm
afraid
it's
going
to
point
people
to
using
that
mechanism
versus
the
other,
which
is
problematic,
yeah.
C
A
A
D
B
B
Two
of
the
three
parties
involved
in
the
protocol
make
a
load
to
mount
an
attack
against
the
third
one.
With
such
a
sentence,
you
are
thinking
there
is
a
client.
There
is
an
nas.
There
is
an
rrs
that
this
sentence
is
not
considering
the
case
where
you
have,
for
example,
two
clients
collaborating
against
an
rs,
and
it
is
supposed
to
be
addressed
in
the
new
document,
which
is
updated,
auto
attacker
model
in
section
3
of
the
current
document.
B
But
it
is
not
the
case,
because
this
document
is
considering
different
kind
of
attackers
a1,
which
are
web
attackers.
It's
obviously
considering
a2
networks,
attackers,
it's
considering
the
s3
attackers
that
can
re-modify
the
content
and
so
on,
attacker
4
secondary,
but
not
modify
and
attack
of
five
that
can
acquire
an
access
token
issued
by
a.s.
B
None
of
this
attacker
are
considering.
We
can
be
considered
as
collaborating
client
voluntary,
collaborating
together
against
the
rs,
so
the
model
is
not
sufficient.
Today,
it
doesn't
cover
that
case
and
it's
not
a
single
sentence
at
the
end
of
the
paragraph
which
says
attacker
can
collaborate
to
reach
a
common
goal
that
allows
to
consider
that
the
client
collaboration
attack
is
covered.
B
So
there
is
an
encouraging
message.
I
received
lastly
from
danielle
this
afternoon
where
he
says
that
he
makes
sure
that
it
understands
correctly.
Well,
I
have
been
talking
about
that
topic
about
for
four
years
and,
as
I
mentioned
in
an
earlier
email,
I
mentioned
that
the
first
time
in
the
zurich
oauth
working
the
the
workshop.
B
C
C
And
the
in
the
security
vcp
yeah,
so
this
is
definitely
covered,
and
this
is
not
the
the
main
problem
here.
What
I'm
seeing?
I
would
very
much
welcome
input
from
others
here,
but
my
impression
is
that
this
attack
is
trying
to
undermine
something
that
is
not
really
by
by
the
structure
of
oauth
something
people
would
expect.
C
F
F
You
know
in
the
in
the
core
oauth
rfc,
and
so
I
don't
know
that
we
need
something
stated
again
right,
because
the
fact
that
it's
a
bearer
token
is
what
allows
bob
to
get
the
token
pass
it
to
alice
and
alice,
presents
it
right.
You
know
the
d-pop
and
other
things
that
daniel
have
presented
are
ways
to
create.
You
know
you
know
proof
of
possession
or
center
constraint
tokens,
but
for
me
this
is
just
a
bearer
token
attack
and
it's
just
a
function
of
the
fact
that
in
oauth
the
tokens
are
bearer
tokens.
F
So
I
I
don't
so
so
to
me
it's
kind
of
outside
the
scope
of
oauth.
Specifically,
it
is
a
valid
attack
right.
If
that
is
something
that
is
of
concern
and
in
that
context
right,
then,
you
know
people
should
be
looking
beyond
bearer
tokens
to
any
of
the
center
constrained
mechanisms
that
exist,
mtls,
depop,
otherwise,.
B
B
B
C
B
C
Attack
so
they
are
attackers,
so,
even
though
they
are
based
on
a
normal
client,
behavior
normal
client
code-
and
maybe
they
are
just
one
of
them-
is
just
running
normal
client
code.
They
still
collude
to
to
reach
a
common
goal
and
this
goal
is
to
undermine
some
security
property
of
the
resource
server.
That's
what
you're
trying
to
say
that
has
nothing
to
do
with
the.
B
Definition
of
what
the
web
attacker
is
today,
basically
three
elements,
and
if
you
consider
only
these
three
elements,
you
can
not
see
the
attack
and
if
you
have
attacker
against
these
three
elements,
you
cannot
see
the
attack.
You
have
to
imagine
that
each
element
may
be
replicated
in
a
number
of
ways
and
when
two
clients
are
collaborating,
they
can
collaborate
against
the
arrests
and
they
are
attacking
the
rs.
There
is
no
web
attacker
in
this
area.
B
E
Well,
the
I'm
not
sure
whether
dennis
is
trying
to
say
that
the
language
doesn't
quite
describe
what
he
does,
but
it
seems
like
it
does,
but
there
he
thinks
it's
an
attack
on
the
rs.
That
alice
is
impersonating
bob,
but
from
the
rs
point
of
view
it
doesn't
really
matter
it's
bob's
resource
and
if
bob
wants
to
go
and
give
it
to
alice,
then
he's
given
it
to
alice
to
work
right.
How
is
that
any
different
than
bob
just
using
a
number
of
different
clients
to
access
his
own
resource?
B
G
Yeah,
just
to
follow
up
a
little
bit
from
what
george
was
saying.
This
isn't
just
limited
to
bearer
tokens,
because
if
bob
is
willing
to
share
his
access
token
bob
is
that's.
The
key
point
bob
is
willing
to
share
his
access.
Token.
Bob
is
probably
also
willing
to
share
his
private
keys
to
make
that
presentation.
It
adds
an
extra
step,
but
it
doesn't
actually
prevent
anything.
G
But,
more
importantly,
what
it
also
doesn't
prevent
at
all
is
bob
just
going
in
doing
things
for
alice
like
this.
As
far
as
the
resource
server
is
concerned,
dick's
100,
correct
here.
This
is
bob
doing
everything
it
doesn't
matter
to
the
resource
server
like
the
person
running
the
software
on
the
other
side,
because
the
identification
and
authorization
artifacts
in
play
here
are
abstracted
from
the
entities
in
the
real
world,
and
so
this
so-called
attack
as
dennis
is
describing.
G
It
is
completely
equivalent
to
bob
taking
his
existing
software,
calling
alice
and
saying
all
right
which
api
calls.
You
want
me
to
make
all
right,
I'm
gonna
go
make
those,
and
I
will
just
email
you.
The
results
of
all
those
api
calls
bob's
allowed
to
do
that
and,
as
far
as
the
rs
is
concerned,
this
is
exactly
the
same
as
a
different
piece
of
software,
with
the
access
to
all
of
the
same
authorization.
B
Can
they
respond?
Yes,
go
ahead.
Two
points.
First,
bob
is
never
sharing.
His
key
bob
is
making
some
cryptographic
computation
at
some
point
of
time
only
to
help
alice
so
alice
never
knows
the
privacy
of
bob.
That's
a
key
point.
Second
point:
some
people
spoke
about
impersonation,
of
course,
and
these
are
the
key
issues
if
it
would
be
able
to
identify
in
the
access
token
that
bob
is
calling,
then
the
attack
would
fail.
B
So
the
important
point
to
have
success
with
this
attack
is
that
the
access
token
does
not
contain
any
identifier
able
to
identify
that
it
is
bob,
and
then
the
attack
makes
succeed,
because
no
one
will
know
that
bob
has
helped
alice
and
that's
a
key
point
now.
As
soon
as
the
rs
is
able
to
relate
the
token
to
bob
and
not
to
alice,
then
the
attack
will
fail
and
another
point:
the
communication
is
done
by
alice.
B
G
Yeah
go
ahead,
justin
yeah!
No!
No,
and
no
so
oh,
my
gosh,
okay,
so
alice
is
making
the
call
with
bob's
token
material,
so
any
auditing
system
would
tell
bob
hey.
These
are
the
calls
that
your
account
is
making
like
this
is
not
you
know.
This
is
not
alice,
acting
as
alice
and
doing
something
with
an
attribute
of
bob's
on
a
session
that
she
has.
This
is
alice,
acting
as
bob
impersonating
bob
and
being
bob.
For
all
intents
and
purposes.
G
This
is
not
alice
pasting,
bob's,
birth
date
onto
her
driver's
license
in
order
to
go,
buy
alcohol.
This
is
alice,
taking
bob's
driver's
license
and
the
store
being
able
to
say
hey
bob.
Your
driver's
license
showed
up
here.
You
know,
and
so
I
I
think,
there's
a
lot
of
conflation
of
different
layers
of
security.
That's
happening
in
the
description
of
this
attack,
most
of
which
are
not
relevant
to
the
layers
of
security
that
are
addressed
by
this
level
of
protocol.
B
I
feel
we
don't
understand
ourselves.
I
just
mentioned
that
in
the
claims
content
in
an
access
token,
there
is
no
way
to
identify
that
the
access
token
is
coming
for
bob
or
is
for
bob
whatsoever,
so
it
is
not
for
alice
as
well.
It
is
just
for
anybody,
so
if
there
is
no
way
to
identify
who
the
access
token
was
only
given
to
then
the
attack
must
succeed.
This
is
what
I
said
that
if
there
is
a
sub-claim
or
some
equivalent
of
a
sub-plane,
then
the
attack
would
be
defeated.
G
I'm
sorry
that
is
incorrect,
because
an
access
token
given
to
bob
that
says
hi.
This
is
bob's
access,
token,
which
you
can
do
today
through
lots
of
different
means,
can
still
be
given
to
alice
and
alice
can
present
it
and
that
token
will
say
hi.
This
is
bob
and
the
resource
server
will
say:
hi
bob
yeah.
B
G
G
H
H
C
However,
that
does
not
mean
that
this
should
be
considered
an
attack,
and
this
needs
to
be
something
we
need
to
talk
about
in
security
bcp,
because
the
goal
that
you
can
achieve
with
this
attack
is
not
something
that
oauth
is
trying
to
protect
against.
So
if
we
have
these
collaborating
parties,
then
it
is
really
obvious
that
they
can
do
such
things
and,
as
justin
said,
this
is
really
something
that
can
apply
to
a
lot
of
yeah
a
lot
of
concepts.
C
So
we
we
already
have
things
covered
like
an
access
token
getting
to
an
attacker
by
accident
and
yeah.
Essentially,
this
goes
into
a
similar
direction.
It
is
not
giving
out
the
access
token,
but
giving
somebody
else
access
using
your
own
token
and
it's
not
by
accident.
It
is
on
purpose,
but
really
this
is
nothing
that
first
of
all,
you
can,
as
we
have
just
seen,
really
defend
against
with
the
things
we
have,
and
second,
it's
not
really
something
you
would
expect
somebody
needing
to
defend
themselves
against.
H
Thanks
daniel
yeah,
that's
a
that's
a
good
question
or
a
good
aspect
to
distinguish
between
the
daca
model
and
which
attacks
we
we
care
about.
So
a
question
to
you,
then,
is
why:
why
do
you
care
about
that
specific
attack?
Is
that
something
that
you
encountered
in
in
like
practical
deployments,
or
how
did
you
run
into
this
issue.
B
So
what
I
am
simply
saying
is
that
if
you
have
some
identifier
that
indicates
that
the
access
token
belongs
to
bob.
That's
fine.
There
is
no
more
attack
possible
if
the
rs
is
checking
that,
indeed,
this
release
to
the
bob
account
open,
for
example,
using
the
sub
identifier
of
bob.
But
if
this
is
not
present
in
the
access
token,
then
you
have
a
problem
now.
H
A
H
Yeah
I
was
yeah.
I
was
in
the
way
of
this
of
this
new
working
iso
on
this,
so
I
I'm
curious
as
to
whether
you
would
then
what
your
plan
is
to
contribute
to
that
work
and
contribute
overs,
plus
some
new,
let's
say
claims
that
you
could
register
and-
and
maybe
that
could
actually
be
a
possible
approach.
I
don't
know
if
iso
wants
to
develop
something
entirely
new
or
not
or
whether
they
are
interested
in
in
sort
of
reusing
and
extending
on
top
of
ours.
I
So
given
that
that
is,
the
main
concern
is
handling
claims
about
users
being
over
18
and
things
like
that.
It's
just
not
an
oauth
problem,
so
it's
not
something
that
even
makes
sense
to
address
in
in
the
spec.
I
don't
think-
and
I
agree
that
justin's
justin's
point
in
the
chat
of
solving
that
by
including
more
information
about
users
sounds
like
a
privacy
violation.
G
All
very,
very
good
points
erin.
Thank
you.
I
just
wanted
to
raise
that.
I
think
there
might
be
a
way
to
address
this
topic
in
the
bcp,
but
in
a
different
way,
because
what
I
believe
and
what
I'm
hearing
from
others
is
that
this
isn't
describing
an
attack
on
oauth,
at
least
as
any
of
us
consider
it.
It
is,
however,
describing
some
fallout
of
the
nature
of
the
protocol.
G
Whoever
can
present
the
information
is
the
presenter
of
the
information
basically
and
to
me
it
seems
like
the
security
bcp
would
be
a
good
place
to
discuss
that
kind
of
thing.
We
already
have
text
in
there
about,
if
you're,
presenting
a
bearer
token,
then
you're
you're,
using
the
bearer
token
and
the
same,
would
be
true
of
depop
keys
or
mtls
certs
or
any
other
proof
of
possession
mechanisms
or
or
anything
like
whoever
has
the
what
we
can,
or
you
know
even
client
secrets
and
things
like
that.
G
Whoever
has
the
secret
material
can
act
as
the
party
for
the
secret
material.
So
if
you
share
that
with
someone
else,
they
are
by
definition,
able
to
impersonate
you,
because
these
secrets
are
what
differentiate
you
from
everyone
else
and
yes,
including
pre-computed
calculations
of
presentations
under
that
umbrella.
A
G
No,
no.
What
I'm
saying
is
that,
in
our
discussion
of
the
nature
of
the
protocol
in
the
bcp
this
this
isn't
a
use
case.
This
isn't
an
attack.
This
is
just
kind
of
how
things
work
and
what
what
kind
of
made
me
think
of
this
is
is
every
time
daniel
said
well,
this
is
obvious,
and
I
agree
that
savia's,
but
part
of
the
job
of
spec
writers
is
to
write
down
all
the
obvious
things
for
the
people
who
don't
think
that
it's
obvious,
sometimes
okay,
right,
like.
G
C
The
problem
that
I
see
is
that
I
do
not
think
that
this
covers
what
dennis
has
on
his
my
earnest
mind,
and
I
do
not
think
that
this
will
be
the
end
to
the
discussion,
although
obviously,
I
think
justin,
dick
aaron
george
made
very
good
points
here
from
various
angles.
Why
this
yeah
is
is
not
really
an
attack
in
the
scope
of
the
or
security
recipe.
C
A
A
H
A
A
Okay,
okay,
thank
you
guys,
okay,
so
I
think
there's
clear
kind
of
support
of
making
sure
or
not
adding
this
to
to
the
list
of
things
to
address
in
them
in
this
document.
So
this
this
topic
is
closed
right
now.
So
let
me
ask
you
a
different
question
about
a
go
for
a
working
group
class.
Call
again,
I'm
going
to
start
if
you
support
starting
a
work
group
last
call,
please
add
yourself
to
the
rest
plus.
A
A
Okay
and
if
you're
against
starting
a
work
group
last
call,
please
add
yourself
now:
okay,
okay,
I
think
there's
clear
support
for
moving
forward
with
the
document,
as
is
with
the
with
some
changes
that
we
discussed
earlier
about
the
philips
point.
So
otherwise,
I
think
the
document
is
ready
to
go
to
work.
Group
last
call
a
and
we'll
take
it
from
there
after
so
then,
after
you
update
that
document,
it
will
represent
auto
reflect
that
change.
We
will
start
our
group
last
call
that's
it.
H
I
I
just
wanted
to
bring
up
the
last
point,
thanks
to
all
who
responded
so
quickly
to
my
call
for
the
bar
feedback
on
implementations
and
also
ibr
disclosure.
So
if
there's
any
last
thing
that
people
want
to
sort
of
add
regarding
implementations,
they
have
for
bar
posted
to
the
list
and
I'm
going
to
add
it
to
my
shepherd.
Write
up
my
plan
is
to
send
that
off
or
finalize
it
today
or
tomorrow.
So
so,
please
hurry
up.