►
From YouTube: OAUTH WG Interim Meeting, 2020-08-03
Description
OAUTH WG Interim Meeting, 2020-08-03
A
Welcome
to
the
first
oauth
inter
meeting,
so
this
is
the
not
well
and
make
sure
you
understand
what
this
means.
This
applies
here
too,
so
a
quick
update
so
that
the
jot
response
for
token
introspection
document.
This
is
the
document
that
we
pulled
back
to
the
working
group
and
we
had
to
get
feedback
from
the
working
group
on
that
recent
changes
because
of
isg
feedback.
A
So
we've
we've
done
that
it
seems
that
the
word
group
is
is
is
okay
with
the
changes
and
we
are
and-
and
we
sent
it
back
so
to
the
isg.
So
I
think
we're
good
with
this.
So
so
that's
one.
The
second
one
is
oauth.
2.1
is
now
a
working
group
document.
We
went
through
the
option
process
for
two
weeks
and
and
lots
of
support
for
the
document.
No
objection.
A
B
So
this
is
roman,
if
I
could
jump
in
on
the
iesg
documents.
Would
that
be
okay,
yep
yeah
yeah?
So
with
regards
to
the
first
one?
Yes,
that's
in
my
queue,
I'm
gonna
squint
at
it
quickly.
I
expect
that
to
go
relatively
easily,
given
that
we've
been
through
this
once
before
and
I'll
bring
it
back
to
the
iesg.
A
You
thanks
for
update
roman
appreciate
it
any
any
questions
about
those
okay,
let's
move
on
then
so
today
we
will
be
talking
about
oauth
2.1
next
week,
we'll
be
talking
about
par.
Now
we
still
have
a
a
bunch
of
other
working
group
documents,
and
I
was
wondering
if,
if
people
have
made
some
progress
on
on
those
documents-
and
we
need
to
discuss
those,
so
any
of
the
authors
of
these
documents
want
to
present
any
of
those
documents.
Let
me
know,
and
we
will
schedule
meetings
so
those
any.
C
Documents,
okay,
so
hi.
This
is
justin.
There's
been
some
discussion
on
clarifications
to
rar
and
those
have
not
yet
been
sort
of
fully
folded
into
the
document.
Yet,
there's
a
there's
a
pull
request
with
some
discussion
on
it.
I
think
it
might
be
a
good
idea
to
have
have
an
update
on
rar
in
a
bit.
I
don't
see
torsten
on
the
call
today,
so
I
definitely
would
want
to
coordinate
with
them,
but
but
yeah.
I
I
think
we
should
do
one
on
rawr
in
the
future.
C
A
A
C
I
guess
next
steps,
so
this
was
recently
adopted,
I
think
last
week,
so
it
is
now
working
group
documents
and
we're
back
to
version
zero
zero.
There
were
no
actual
changes
between
the
last
document
that
everybody
saw
and
this
version
so
there's
no,
don't
worry
if
you
haven't
actually
read
this
version
yet
because
it's
not
any
different
than
the
last
individual
draft.
D
C
The
idea
in
oauth
2.1
is
to
consolidate
the
sort
of
best
practices
and
current
state
of
the
art
of
oauth2
and
roll
those
up
into
a
new
document.
Updating
the
core
rfc
doing
things
like
capturing
the
best
practices,
as
is
documented
in
a
handful
of
other
drafts
that
have
been
published
since
the
original
rfc
as
well
as
now.
In
the
original
author
rfc,
there
were
a
lot
of
things
that
were
left
undefined
or
future
extension
points
that
now
do
have
extensions
at
various
levels
of
stability.
C
C
C
Whoever
is
making
a
lot
of
noise,
can
you
please
mute,
I'm
not
sure
who,
that
is.
I
can't
see
someone's
making
breathing
noises
and
dishes
thanks.
So
oauth2.1
is
consolidating
6749
the
core,
the
native
apps
best
current
practice,
rolling
in
pixie
support
as
well.
There's
a
placeholder
for
the
browser-based
apps
best
current
practice,
because
that's
not
yet
an
rfc,
but
it
will
eventually
roll
that
in
as
well
and
the
security
best
current
practice
as
well
is
rolled
up
into
there
and
bearer
tokens
as
well.
C
C
There
is,
however,
one
exception
carved
out
for
specifically
clients
that
are
used:
openid
connect,
clients
that
are
using
the
nonce
to
prevent
authorization
code
injection.
There
is
a
carve
out
for
that.
Just
so
that
these
this
draft
does
not
break.
You
know
quote:
unquote:
break
open
id
connect
clients,
however,
it
is
still
highly
recommended
that
pixie
is
used
because
it
is
a
safer
way
to
prevent
all
those
attacks.
C
Redirect
you
are
matching
to
drop
any
wild
card
matching,
don't
so
dropping
query,
string,
usage
of
bearer
tokens
there's
some
additional
requirements
around
refresh
tokens
which
again
are
from
the
security
bcp
and
probably
most
significantly,
the
two
grant
types
from
the
core
are
no
longer
here,
which
are
the
implicit
and
password
grants,
and
these
are
again
not.
This
is
not
anything
that
oauth
2.1
is
deciding.
This
is
based
on
the
security
best.
Current
practice
also
saying
do
not
use
those
those
grants
in
oauth,
2.
C
So
one
of
the
other
big
changes
in
oauth
2.1
is
in
a
I
shouldn't,
say,
changes,
but
there's
a
new
term
introduced
in
oauth
2.1,
which
is
called
a
credentialed
client,
so
oauth
2
defines
public
and
confidential
clients
and
then
throughout
the
document
there
is
a
sprinkling
of
exceptions
to
these
definitions
used
with
throughout
the
document.
So
the
idea
is
that
we're
going
to
actually
give
those
exceptions,
a
name
and
that's
credentialed.
So
a
credentialed
client
is
a
client
that
has
credentials
but
whose
identity
is
not
confirmed.
C
So,
for
example,
probably
the
most
straightforward
way
to
imagine.
This
is
a
client
that
uses
dynamic,
client
registration
and
then
gets
a
client
secret
through
that
dynamic
client
registration
and
specifically
where
the
dynamic
client
registration
was
not
authenticated
itself.
So,
if
you
imagine
a
mobile
app
shipped
in
the
apple
app
store,
it
obviously
cannot
be
shipped
with
a
client
secret
included.
C
So
the
first
thing
you
can
do
when
it
wakes
up
is
use
dynamic,
client
registration
to
get
a
client
secret.
However,
that
api
call
to
the
registration
endpoint
is
an
authenticated
api
call,
so
its
identity
isn't
actually
confirmed,
and
yet
it
has
a
client
secret,
which
it
still
can't
use
in
many
ways
that
are
mentioned
in
the
draft
to
you
know
prevent
certain
attacks.
So
this
is
that
sort
of
halfway
between
public
client
and
confidential
client.
It's
not
a
confidential
client
because
it
doesn't
have
it's
not
it's.
C
Now
we
can
just
call
the
credentialed
client
so
the
what's
next,
for
this
there's
still
some
editorial
cleanup
that
needs
to
happen.
I'm
sure
there's
a
lot
of
copy
editing
to
do.
I
think
it's
a
good
idea
to
also
take
this
opportunity
to
clean
up
the
the
language
used
in
the
draft,
and
you
know
look
for
anything
that
is
anything
in
oauth2.
That
was
not
necessarily
clear
and
we
have
a
chance
to
update
it
now
to
make
it
easier
to
read.
C
I
do
need
to
add
examples
of
credentialed
clients,
because
the
other
client
types
already
have
examples
in
here.
So
that's
been
one
of
the
pieces
of
feedback
we've
received.
Is
people
don't
quite
understand,
credentialed
client,
just
reading
this
short
description
and,
of
course,
getting
feedback
from
the
group,
so
that
is
what
we
are
here
to
do
right
now.
So
that
is
the
status
and
I'm
happy
to
open
it
up
for
questions
or
questions
or.
D
D
A
B
A
A
A
A
E
E
C
E
C
Yeah
so
I'd
like
to
see
more
discussion
in
this
well
one
I
I'm
I'll
volunteer
to
review
the
spec
text.
I've
I've
read
through
it,
but
not
deeply
enough
to
have
a
full
set
of
comments.
Yeah
awesome
thanks
granted.
This
is
the
dash
zero
zero.
So
you
know
we've
got
a
ways
to
go
yet.
I
would
like
to
see
more
discussion
in
this
with
about
non-bearer
token
types.
D
C
C
I
don't
think
it
quite
does,
but
it
gets
close
in
some
in
some
places.
So
it's
just
something
that
I'll
be
on
the
lookout
for
in
my
review,
and
I
request
the
editors
keep
an
eye
towards
that
going
going
forward.
Hey
yeah!
That's
no!
That's
a
great
point.
Can
I
ask
if
there
was
a
particular
instance
that
you
are
referencing
or
just
sort
of
general
comment?
C
C
The
one
reference
that
is
actually
normative
is
the
exception
that
allows
openid
connect
clients
to
not
use
pixie.
That
was
that
might
have
been
quite
a
bit
of
discussion
that
got
that
got
into
that.
But
we've
tried
to
reword
that
in
this
draft
compared
to
some
of
the
earlier
iterations
of
it,
to
make
it
very
specific
that
this
is
not
trying
to
say
you
should
be
doing
open,
openly
connect
things.
It's
saying.
If
you
are
doing
opening
connect
things,
then
you
don't
need
to
do
pixie
right
now.
C
I
remember
that
discussion
on
the
list
and
I'm
trying
to
find
it
in
the
documents
yeah,
I'm
I'm
fine
with
the
reference
to
I'm
fine
with
the
reference
to
the
knots
thing
being
included
here.
I
yeah,
unfortunately
just
scanning
through
the
document.
In
the
background
right
now,
I
can't
find
the
line,
but
still
the
general,
the
general
sentiment
and
suggestion
still
applies.
C
E
Some
time
ago
we
had
a
discussion
about
the
fact
that
the
deprecation
of
the
implicit
flaw
has
implications
on
some
of
the
open
id
connect
flows,
in
particular
I'm
thinking
of
a
case
in
which
there
is
a
response,
type
id
token
and
their
response
mode
is
a
form
post,
which
is
a
scenario
which
doesn't
have
any
of
the
drawbacks
that
we
have
and
the
reason
for
which
implicit
was
deprecated
and
the
problem
I'm.
Having
is
that,
as
I
predicted,
whenever
people
see
that
flow,
they
say.
E
Okay,
that
flow
is
gonna
go
away
anyway,
because
implicit
is
deprecated
which
instead
isn't
the
case.
Let's
say
that
that
particular
deprecation
is
for
all
the
various
considerations
we
had
about
having
talking
in
the
referral
header
or
like
all
the
various
issues
that
we
have
in
tokens
in
the
url
in
general.
E
So
I
don't
know
if
it's
the
place
in
this
spec
to
make
a
clarification
in
there
that
that
particular
way
of
issuing
tokens
from
there,
for
example,
endpoint,
is
not
affected
by
the
various
security
reasons
that
made
us
deprecate,
and
I
bring
this
up
again.
I
know
that
we
already
discussed
this
and
we
got
to
a
position
in
which
we
were
okay,
but
unfortunately
it
doesn't
seem
to
have
worked.
E
Let's
say
that
people
do
keep
getting
this
wrong
and
I
bring
this
up
because,
given
that
in
the
nonce,
we
actually
called
out
a
particular
scenario
that
occurs
in
open
id,
I'm
wondering
if
there
is
something
that
we
can
do
in
here
to
preempt
and
clarify
that
point
so
that
I
don't
have
to
spend
the
next
five
years.
Every
time
someone
says
here,
implicit
is
deprecated
to
explain
that
that
deprecation
doesn't
really
affect
the
form
of
post.
A
C
That
makes
sense.
Can
I
go
ahead
just
clear
one,
one
thing
real
quick
before
I
get
to
the
queue
so
while
effectively
this
means
the
implicit
flow
is
deprecated.
What's
actually
happening
in
this
draft
is
that
it's
not
being
defined,
which
is
different,
so
the
security
bcp
actually
says
things
like:
don't
use
the
password
grant?
It's
just
not
in
this
draft.
So
well.
I
totally
get
your
point.
C
C
C
From
the
perspective
of
the
developer,
though,
I
think
victorious
got
a
really
good
point
that
people
are
going
to
look
at
this
document
and
see
that
this
is
one
of
the
things
that
is,
you
know,
potentially
extensible,
defining
new
grant
types
and
therefore
wonder
kind
of
okay,
so
this
is
defined
here.
Does
that
what
does
that
mean
about
using
it
and
stuff
like
that?
D
I
don't
know
if
that's
in
this
draft
or
in
a
blog
post
we
make
or
something,
but
I
agree
that
developers
are
being
caused-
confusion
about
implicit
with
form
post
being
in
the
same
category
as
implicit
in
the
fragment,
not
at
all
the
same
yeah.
So
I
don't
know
what
we
want
to
do,
but
we
need
to
do
something.
A
C
I
would
can
I
respond
to
these
couple
a
couple
things.
I
think
I
think
justin's
point
is
good,
that
there
could
be
some
more
discussion
of
this
and
I
think
one
of
the
things
that
could
be
clarified
in
this
without
stepping
too
far
into
either
openid
connect
or
redefining
implicit.
Is
that
also
as
a
guidance
for
future
extensions?
C
Is
that
the
actual
problem
with
the
implicit
flow
is
that
the
access
tokens
are
issued
from
the
authorization
endpoint
rather
than
the
token
endpoint,
and
that's
that
then
doesn't
discount
response
type
id
token,
because
that's
not
an
access
token
right.
So
if,
if
oauth
actually
makes
a
statement
that
says,
don't
issue
access
tokens
from
the
authorization
endpoint,
then
that's
the
thing
that
that's
the
goal.
There
would
be
to
clarify
that.
C
That's
the
reason
the
implicit
flow
is
being
emitted
is
that
the
implicit
flows,
access
tokens
come
from
the
authorization
endpoint,
and
maybe
that's
a
way
to
make
it
more
clear
that
response
type
id
token,
with
whatever
response
modes
are
totally.
You
know
a
different
issue
because
they're
not
access
tokens
that
don't
have
the
same
threat
model.
C
C
C
I
see
it
as
a
security
issue
because
the
the
lack
of
confirmation
of
of
delivery,
if
you
you
can
confirm
it,
was
delivered
to
the
right
client,
then
there's
higher
assurance
overall
in
like
the
policies
of
that
token
or
the
lifetime
of
it
or
the
lifetime
of
chain.
You
know
tokens
around
it
like
the
refresh
tokens
or
other
access
tokens.
If
you
can't
confirm
was
received,
you
don't
get
that
assurance
and
you
can't
make
the
same
decisions
because
you're
working
with
less
information.
D
Sure,
but
again
this
doesn't
facilitate
an
attack.
We
can
take
this
on
list
if
you
want,
but
the
the
high
order
bit
here
is.
I
support
the
torio's
point,
and
maybe
you
can
put
this
on.
You
know
that
we
need
to
make
an
affirmative
statement
that
implicit
with
foreign
posts
does
not
have
the
same
security
problems
as
implicit.
C
Do
we
expect
an
oauth,
2.1
client
to
be
able
to
talk
to
a
2.0
server?
Do
we
expect
a
2.0
client
to
be
able
to
talk
to
a
2.1
server
or
under
which
circumstances?
Obviously,
oauth
does
not
guarantee
compatibility
between
oauth,
2.0
and
oauth
2.0,
so
we're
already
constrained
by
that
space.
But
you
know
in
a
very
real
sense-
and
this
gets
back
to
some
of
the
the
questions
that
vittorio
and
mike
are
raising
here.
C
Are
we
guiding
people
towards
better
off
servers
or
better
clients
or
both,
and
what
does
that
mean
when
talking
to
legacy
systems
the
bit
of
text-
and
I-
and
I
understand
that
this
is
that
this
is
imported
from
the
pixie
draft,
but
the
bit
of
text
that
really
makes
me
really
brings.
This
up
is,
in
section
4112
the
discussion
of
the
plane
transformation.
C
I
remember
when
we
decided
to
keep
that
in
the
pixie
document,
because
google
had
already
done
that
and
then
somebody
came
up
with
a
much
better
way,
much
more
secure
way
to
do
it.
So
you
know,
in
addition
to
having
pixie,
could
we
is?
Would
it
be
reasonable
to
deprecate
this
also
or
to
re-evaluate
what
compatibility
with,
for
example,
pixie
means
here.
C
C
Because
if
this
document's
going
to
leave
it
out,
then
it
should
have
already
been
left
out
taken
out
by
another
document
that
predates
this
one
right.
So
the
security
bcp
is
the
obvious
place
for
that
where
that's
where
a
lot
of
these
similar
restrictions
are
coming
from
similar
constraints,
and
if
it's
not
a
good
idea
to
use
this
anymore,
we
should
make
that
clear
in
the
security
bcp
that
it's
also
not
okay
for
oauth
2
clients
to
be
using.
C
It,
okay,
that's
reasonable.
I
I
the
specifics
of
pixie
aside.
I
do
think
that
we
need
to
have
more
explicit
discussion
about
what
compatibility
means,
or
even
whatever
aim
is
between
2-1
and
2.0.
This
has
been
brought
up
on
the
list
a
couple
of
times
and
back
when
we
could
all
sit
in
the
same
room
together.
I
remember
this
was
this
was
another
very.
F
Justin
it's
dickheart
here,
just
maybe
you
can
drive
more
clarification
on
that
I
mean
we
are
trying
to
frame
2.1
as
being
the
best
practices
of
oauth
2.0
and
the
combination
of
all
existing
documents.
So
it's
compatible
with
what's
out
there
today,
it's
just
put
together
in
one
document.
What
what
are
you
suggesting
we
change
or
or
is?
Do
you
think
that
it
is
incompatible
in
some
way.
C
Oh,
it's
not
compatible
because
it
it
says,
don't
use
the
implicit
flow,
it
says,
or
it
doesn't
say
how
to
use
the
implicit
flow.
There's
a
bunch
of
things
that
are
defined
and
you
can
do
in
the
world
of
oauth
2.0
that
we
now
our
best
practices.
Documents
say,
don't
do,
but
that
makes
people
who
are
implementing
just
raw
oauth
2.0,
strictly
incompatible
with
oauth
2.1,
which
includes
all
the
best
practices.
That
say,
don't
do
the
bad
things.
F
C
F
A
A
G
Yeah
there's
an
obsolete
clause
in
the
document
that
I
read,
but
I'm
trying
to
discern
the
difference
between
the
you
know:
there's
a
difference
between
obsolete
and
deprecate,
and
so
I'm
trying
to
understand
what
the
meaning
of
the
obsolete
was.
Was
that
that
it's,
you
know
completely
gone
or
in
the
deprecate
case?
Is
it
still
in
use
and
future
may
go
away?
G
C
I'm
not
quite
sure
I
understand
the
the
process
implications
here,
but
the
the
the
goal,
at
least
from
from
my
end,
is
people,
should
look
at
67
49
and
be
able
to
see.
Oh,
I
don't
need
to
read
this.
I
should
go
read
this
other
thing
instead,
because
it's
a
better
starting
point.
What
that
what
that
means,
as
far
as
the
words
to
use
I'm
not
totally
sure,
but
we
can
just.
B
Yeah
hi
this
this
is
roman.
Let
me
jump
in
kind
of
with
from
a
process
perspective
on
on
that,
so
we
didn't
actually
include
the
right
metadata
yet
in
the
2.1
document,
but
generally
speaking,
what
obsolete
means
is
obsolete
relative
to
something
else.
Is
that
the
whatever
is
that
document
that's
doing?
The
obsoleting
is
considered
the
thing
that
the
ietf
is
recommending.
B
It
doesn't
necessarily
make
any
statement
that
the
thing
that
preceded
it
is
going
away,
but
this
is
this
document
that
is
doing
the
obsoleting
is
the
thing
we're
saying
that
you
know
is
the
is
the
thing
that
we're
working
on,
and
I
dare
say
the
thing
that
we're
recommending.
I
think
a
really
strong
example
of
this
is
we
have
tls
version
1.3
and
tls
version
1.2
technically
1.3
is
obsoleting
version
1.2,
but
I
think
no
one
would
say
that
tls
1.2
is
going
away.
A
G
A
H
B
Again,
roman
jumping
in
here
on
top
of
everyone,
I
think
that's
something
we
would
need
to
be
very
precise
with
with
regards
to
the
metadata
when
we
say
what
we're
obsolete,
because
right
now
only
in
words
we're
just
saying
it
obsoletes,
but
with
the
metadata
as
it
relates
to
the
rfc
series.
We
actually
have
not
done
anything
and
we
would
need
more
precision
there
because
likely.
A
B
B
B
I
I
would,
I
would
agree
with
you,
I
mean
that's
a
lot
of
ietf
rfc
series,
arcane
kind
of
stuff.
I
believe
there
was
a
suggestion
I
forgot,
who
made
it
kind
of
earlier
that
we're
going
to
need
to
tune
the
language
in
the
abstract
to
make
some
very
clear.
You
know
real
natural
language
kind
of
statements
about
what
is
the
relationship
to
this
to
the
bcp
to
2.0,
and
I
would
strongly
endorse
that.
I
think
we
need
that
level
of
clarity
here.
Yeah
good
point.
A
A
Okay,
well,
that
was
a
really
good
discussion
and
interesting,
and
I
guess,
if
no
other
topics
to
discuss,
I
think
we
will
end
it
here
and
hope
to
see
you
all
next
week
for
a
another
day
meeting
next
week,
yeah
same
time,
okay,
I
ask
a
question
before
we
go
ahead.
Mike
hold
on
guys
hold
on,
don't
drop,
go
ahead
mike.
D
A
A
Oh
did
roman
draw,
I
guess
he
did
drop,
so
we
did
talk
about
this
mike
now
that
that
document
is
still
with
isg.
If
I
remember
correctly,
let
me
check
it
very
quickly
here.
I
don't
think
we
pulled
it
into
the
working
group
back
back
into
the
wagon
group,
so
it
is
with
the
isg.
Let
me
see
yeah
it's
it's.
It's
is
evaluation
so
and
enrollment
go,
but
we
probably
need.