►
From YouTube: OAUTH WG Interim Meeting, 2020-04-27
Description
OAUTH WG Interim Meeting, 2020-04-27
A
A
A
C
C
I'll
jump
right
in
then
so
hi
everybody
I'm
here
in
Karachi
from
from
octa
I'm
here
to
talk
about
a
walk
2.1.
This
is
an
effort
that
we
started
at
the
last
IETF
106,
and
it's
been
a
couple
of
updates
since
then,
but
mostly
I
want
to
get
everybody
up
to
speed
on
this
effort.
So
I
deal
with
two
point.
C
All
we've
anybody's
been
using.
So
the
idea
with
OAuth
2.1
is
to
start
from
beginning
start
for
in
67
49
play
these
RFC
is
out
of
order
and
what
you
get
at
the
end
of
them
is
what's
then
captured
in
this
new
document,
so
what's
subscribed
across
all
these
RFC's
and
best
practices,
you
essentially
end
up
with
two
grant
types
that
are
defined
authorization
code
along
with
pixie,
as
well
as
the
client
credulous
grant
type
security.
Western
practice
is
taking
out
the
password
flow.
C
It's
also
taking
out
the
implicit
flow
and
the
author's
it
also
requires.
Well,
very,
nearly
it
requires
pixie
on
the
authorization
code
flow,
so
it
also
defines
a
couple
of
other
behaviors,
such
as
exact,
redirect
URI
matching
by
the
authorization
server
it.
The
security
PCP
removes
the
use
of
air
tokens
and
query
strings.
It
has
some
tighter
requirements
around
refresh
tokens
and
and
then
yeah.
C
These
two
legacy
grants
are
emitted
from
from
the
draft,
so
2.1
is
basically
the
collection
of
the
the
current
state
of
the
art
of
both
two
in
the
most
secure
way
way
possible.
It
is
explicitly
not
meant
to
define
any
new
behavior,
which
was
one
of
the
original
design
goals
we
went
into
it
with
so,
rather
than
trying
to
be
more
like
proactive
or
pushing
things
forward
in
terms
of
some
of
the
other
new
extensions
that
are
coming
out,
we
wanted
to
focus
on
just
creating
a
new
starting
point
for
that
kind
of
work.
C
So
this
was
the
a
couple
of
weeks
ago.
I
think
it
was
early
March.
We
published
the
first
the
first
draft
and
sent
an
email
to
the
list
sharing
that
which
was
which
we
created
since
the
original
brainstorming
of
this
in
November.
Since
that
first
draft
we've
had
some
feedback
on
the
list
and
thanks
to
Brian
for
a
nice
detailed
review
on
that,
I
have
gone
ahead
and
made
a
couple
of
the
changes.
C
That's
a
couple
changes
that's
been
discussed
on
the
list
since
then,
so
mainly
there's.
There
was
a
section
around
HTTP
redirects
and
the
secure
dbcp
that
I
guess
we
just
forgot
to
bring
in
in
the
first
place.
So
that's
now
been
added.
There
was
a
bunch
of
editorial
typo
fixes
that
have
been
made
as
well
there's
also
now,
some
of
the
references
have
been
fixed
since
things
like
HTTP
have
also
evolved
since
2012.
So
a
lot
of
the
references
that
were
in
the
original
documents
are.
C
Are
now
updated
to
the
more
modern
equivalents
of
those
references,
so
there's
a
couple
of
open
questions
that
I
have
just
to
start
off
with
that
we
we
can
discuss
and
there's
a
couple
of
other
details
on
the
list
that
we
could.
That
probably
need
some
further
discussion
as
well.
There's
a
couple
of
new
and
new
things
that
have
you
know
come
out
since
2012
things
like
dynamic,
client,
registration
and
authorization
server
metadata.
Well,
we
don't
want
to
require
those
in
the
core.
C
It's
probably
still
a
good
idea
to
at
least
references
reference
them
as
optional
ways
to
do
those
things
so
client
registration
like
there
is
a
client
registration
section
in
I,
want
to
now
know
in
the
core
RFC.
It
mainly
just
says
this
is
out
of
out
of
scope
of
the
draft,
so
we
could
at
least
reference
that
there
are.
C
Some
RFC's
talked
about
different
ways
to
do
these
as
optional
there's
another
interesting
one,
which
is
whether
redirect
URI
should
require
TLS,
of
course,
except
for
local
host
or
non
HDTV
ones,
and
that
it
was
originally
not
required
because
in
2010
and
2012
it
was
a
much
more
of
a
hurdle
of
a
burden
to
deploy
TLS.
So
that's
so
that's
my
good.
It
has
also
changed
in
the
environment
since
then,
however,
that
would
be
a
change
from
from
the
core
there's
another
there's.
Another
comment
on
the
list
about
sorry:
go
ahead:
I.
D
Sorry
this
is
Justin
richer,
the
dynamic
client
registration
and
a/s
metadata,
in
addition
to
defining
their
respective
protocols.
They
also
effectively
define
a
de-facto
object
model
for
clients
and
authorization
servers
respectively,
and
so
at
least
referencing.
Those
under
that
context,
in
addition
to
the
functionality
that
they
provide,
I
I
believe,
would
be
a
good
thing
for
the
group.
C
Yeah,
that's
a
great
point
Vegas,
so
yeah
I'm
not
sure
exactly
what
that
would
look
like
in
the
draft,
but
that
probably
is
a
good
idea
to
at
least
make
people
aware
of
them,
since
one
of
the
one
of
the
goals
of
this
document
is
to
give
people
a
clearer
starting
point
getting
into
the
OAuth
space.
So
having
places
to
go
to,
as
you
know,
clear
launching
off
points
to
go
find
the
information
looking
for
is
is
definitely
beneficial,
so
I'm.
Definitely
in
favor
of
that.
A
E
You
a
lot
of
said
speaking
first
of
all,
I
support
what
Justin
just
said
regarding
a
client
registration,
a
is
made
of
data
because
it
provides
the
conceptual
model,
we're
talking
about
relationships
and
representation
of
about
clients
and
services
regarding
this
shoot
for
TLS
and
redirect
URIs
are
C
67
49
already
required
TLS
for
redirect
you
eyes
in
case
the
flow
is
being
used
for
identity,
providing
identity,
Federation
use
cases
I,
don't
see
any
reason
not
to
require
TLS
on
redirect
your
eyes.
In
the
current
version
of
a
LOF.
C
E
E
C
C
C
So
there's
another
sort
of
tricky
one
that
came
up
and
some
of
the
discussions
around
the
definition
of
confidential
clients
and
there's
a
couple
of
different
sentences
across
the
spread
of
documents
that
kind
of
approach
the
definition
differently.
So
the
the
sentence
at
the
top
is
yeah
requirement
for
authorization
servers
to
consider
the
confidence
in
the
clients
identity
when
deciding
whether
it
can
use
things
like
the
client
credentials
grant
type,
which
is
a
statement
about
the
clients
identity
rather
than
just
whether
or
not
it
can
authenticate
so
I
guess.
C
My
question
here
is
kind
of
going
back
to
the
original
original
definition
of
confidential
clients.
What
was
the
actual
intended
definition
of
that
is
it?
Is
it
the
identity
assurance
of
a
client
or
is
it
the
ability
for
a
client?
Well,
the
main
difference
here
is,
if
you
imagine,
a
situation
that
uses
dynamic,
client
registration
and
it's
like
an
iPhone
app,
that's
downloaded
a
would
first
wake
up
and
go
register
which
would
give
it
a
client
secret
which
it
can
use
to
authenticate.
As
that
instance.
C
However,
there
is
no
assurance
of
that
clients
identity,
because
anybody
can
make
that
registration
request
and
the
registration
request
will
be
unauthenticated.
So
that's
the
sort
of
situation,
that's
a
difference
between
the
identity
assurance
and
ability
to
authenticate
and
I,
see
dick
on
the
character.
B
F
F
D
The
in
67
49
doesn't
do
best
at
differentiating
those
two,
whereas
the
dynamic
registration
specs.
We
had
a
little
bit
more
experience
to
articulate
that
a
little
bit
better
wherein
they
effectively
allowing
you
to
turn
what
would
normally
be
a
public
client
into
the
confidential
client,
because
you're
now
changing
a
secret
that
would
have
been
issued
at
configuration
time
into
something
that,
by
necessity
of
the
nature
of
the
client
into
something
that
is
issued,
vouch
and
protected
at
runtime
and
George
is
absolutely
right
in
that.
When
you're.
D
E
Speaking
yeah
I
have
to
agree
with
Justin
as
well.
So
for
my
perspective,
we
need
to
distinguish
the
fact
that
there
is
an
authentication
the
client
can
authenticate
and
what
policy
yes
may
associate
are,
with
a
certain,
very
certain
client
when
rc6
m.49
was
published.
Basically,
our
model
was
if
the
client
has
a
secret,
and
typically
the
application
has
not
has
gone
through
some
wetting
process.
So
we
know
what
application.
That
is
what
partner
that
is,
and
we
can
associate
a
certain
policy
and
certain
authorization
permissions
with
that
client.
E
It
has
gone
with
dynamic
line
registration,
so
we
clearly
need
to
distinguish
camera.
Can
we
recognize
a
certain
client
using
a
secret?
That's
one:
that's
authentication
insurance
and
what
policy
can
we
associate?
How
how
many
trust
can
be
put
on
that
on
that
client,
which
is
identity,
assurance
I?
Think
we
need
to
do
to
to
really
differentiate.
That
I
mean
the
text.
E
You
should
see
this
on
the
screen,
I
think
written
by
myself,
I
try
to
somehow
get
across
that
just
having
a
secret,
not
enough,
because,
depending
on
the
way,
the
client
secret
is
being
provisioned.
It
firend
she
ate
when
meeting
access
control
decisions,
so
we
needed
to
sent
it.
We
need
to
distinguish
both
different,
both
effects.
I
think
in.
G
Yeah
I
was
just
gonna
say
that
the
description
of
the
different
types
of
clients
is
one
of
the
things
that
causes
ongoing
confusion
for
developers
and
when
we
publish
60-49,
as
Justin
said,
we
tried
to
clean
up
those
distinctions
in
dynamic,
client
registration.
Yes,
you
can't
hide
a
secret
in
a
taxi
file,
but
you
can
obtain
one
dynamically
from
one.
A
A
C
Okay,
great,
so
thanks
for
all
that
that
helps
clear
things
up.
Sorry
is
he
saying
it
is
a
question
of
uniqueness,
more
than
authentication
or
assurance,
so
yeah
I
think
I
think
this
makes
sense
and
I
like
the
idea
of
making
the
idea
of
the
clients,
identity,
separate
and
call
more
explicitly
so
I
will
try
to
work
on
that.
C
So
I
will
try
to
make
sure
that
the
the
caught
the
confidential
client
definition
is
strictly
around
whether
it
can
maintain
a
secret
and
use
a
secret,
whether
whether,
regardless
of
how
it
got
that
secret
and
then
save
the
identity,
discussion
for
a
different
part
of
the
spec,
so
I
think
they'll
be
great,
and
thanks
for
the
suggestions
for
looking
at
the
name
of
client
registration
for
some
language
they're
great.
So
that's
really
the
only
things
I
wanted
to
discuss
right
now
on
this
call.
C
No,
that
was
all
I
really
wanted
to
say,
really
is
just
like.
What's
next
I
think,
there's
obviously
still
some
editorial
work
to
clean
up
the
language,
make
sure
that
it's
not
too
much
of
a
patchwork
and
does
flow
a
little
better,
because
it
is,
it
is
mostly
text
copied
from
all
of
the
existing
RFC's.
So
there's
some
work
there
and
then
then
do
we
want
to
actually
bring
this
into
the
working
group
to
make
it
a
working
group
item.
C
B
On
that
topic,
when
the
the
meeting
that
kicked
off
us
creating
this
document
was,
there
seemed
to
be
a
lot
of
confusion
and
apprehension
about
what
was
in
or
what
wasn't
in
this
document,
and
so
maybe
we
can
open
up
the
questions
to
be
around.
Do
people
have
concerns
about
the
contents
of
what
is
in
or
concerns
about
what
is
not
in
this
document.
G
F
B
Fully
agree
with
that
Mike
and
I
think
in
the
latest
draft
I,
don't
know
if
you
took
it
out
Aaron,
but
you
had
in
the
draft.
I
didn't
notice
it
until
later
was
that
there's
AI
ni
Anna
considerations,
but
there
isn't
any
ionic
considerations
because
all
of
those
things
are
registered.
So
we
should
definitely
include
references
to
the
various
registries
around
o,
auth
and
Mike.
If
you
have
suggestions
for
how
to
reference
other
documents,
definitely
open
to
that.
So
you
know
we
don't
want
to.
B
G
C
So
let
me
address
that
one
so,
just
like
sixteen
eleven
forty
nine
only
to
find
a
few
response
type,
and
then
there
were
many
extensions
that
were
created
to
do
things
better.
C
C
How
I
think
that
might
the
the
one
thing
that
might
change
in
terms
of
some
of
the
extensions
is
that
the,
for
example,
response
type
code
ID
token
is
a
would
then
be
a
completely
new
extension
from
the
framework,
rather
than
an
extension
of
the
authorization
code
grant,
because
if
it's
not
doing
pixie,
it's
not
extending
the
authorization
code
grant
that's
described
in
2.1
its
extending
the
entire
framework,
so
the
mechanism
is
still
unchanged
in
open,
econnect
extension.
It's
just
extending
it
from
a
different
point.
G
A
E
Problem
as
long
as
all
the
people
taking
care
of
me
speaking
so
just
as
an
impulse
I
think
we
as
a
working
group,
need
to
decide
what
we
want
to
achieve
with
oauth2
that
one
and
one
we
want
to
establish
a
new,
a
new
basis
or
going
forward.
E
We
just
wanna
hash
things
together
that
pre-existed
I
mean
insecurity
BCP.
We
came
up
with
new
guidelines
and
made
sure
that
I'll
put
as
possible
combinations,
for
example,
for
seasoned
ref
and
code
free
protection,
we're
being
mentioned,
whereas
in
the
O
of
2.1
draft
we
explicitly
say,
code
plus
pixie
is
required
to
be
supported
by
the
AAS.
My
perspective
creates
a
new,
clean
and
simple
basis,
and
I
would
like
to
start
from
that
and
not
weakening
the
language.
D
Mean
covered
it
plus,
what
all
of
us,
the
goal
of
this
document
should
be
to
read
a
new
baseline,
not
to
explain
all
the
things
that
you
can
buy
on
the
oauth2
menu,
and
also
anybody
who
is
doing
off
to
notto
can
still
do
to
dotto
I
think,
that's
the
you
know
we're
publishing
a
2.1,
and
then
everybody
is
going
to
turn
off
there.
A
lawsuit,
ATO,
stuff
out
of
fear
is
is
ridiculous.
A
H
This
is
rhomin.
Sorry
I
was
having
difficulty
finding
the
mute
button.
I
mean
this,
isn't
an
observation
on
this.
The
wording
in
this
specific
draft,
but
again
as
we're
talking
about
next
version
of
OAuth
2.0,
calling
it
a
lot
two
point.
One
I
would
just
God
ever
able
to
think
about
what
we're
actually
charter
to
do
and
what
we're
trying
to
trying
to
kind
of
do
in
the
current
charter
box
is
to
improve
security
and
interoperability.
So
that's
the
eye
on
the
prize
for
me,
unless
we've
recharter.
A
E
I'm
going
to
present
to
you
is
the
latest
latest
version
of
the
WT
is
respectful
response.
Draft
UT
response
draft
already
was
in
is
G
is
already
formally
is,
is
in
is
G
review.
E
E
As
I
said,
we
did
it
change
recently,
I
have
to
admit
I
I
forgot
to
publish
I,
had
to
draft
and
was
realized,
I
think
Saturday.
We
hadn't
published
it
and
that's
why
I
published
oh
nine
on
weekend.
What
we
did
is
we
are
previously.
We
had
all
the
data
about
the
introspected
token
and
the
metadata
of
the
jot
representing
the
introspection
response
in
the
same
job
and
that's
caught
this
caused
some
discussion
in
the
is
G
review
and
also
on
the
list
and
yeah.
E
In
the
end,
we
decided
our
also
based
on
suggestions
from
some
working
room
members,
including
just
an
attacker
to
move
the
data
of
the
introspected
tokens
into
a
new
top-level
claim
that
we
called
token
underscore
introspection
and
it
allows
us
to
separate
the
claims
from
the
carrier
chart
that
represents
the
introspect
response
from
the
actual
data
of
the
introspected
tokens.
So
if
we
take
a
look
on
the
next
slide,.
E
E
You
can
see
well,
we
did
it.
Change
is,
on
the
left
hand,
side,
you
see
the
header
of
the
token,
which
remains
unchanged
on
the
right
hand,
side
you
can
see.
We
have
done
two
token
introspection
element,
and
this
this
contains
all
the
data
that
you
would
see
in
a
traditional
Worf
token
response.
So
whether
the
token
is
active
and
all
the
other
claims
and
the
other
top-level
claims
in
that
shot
are
related
to
the
jacket-
represents
the
introspection
response.
E
So,
for
example,
if
you
wouldn't
respect
a
certain
access
token,
several
times,
data
within
the
token
introspection
element
would
be
the
same
with
the
only
exempt
exception.
If
the
access
token
is
expired,
the
token
introspection
would
only
contain
the
member
active
Falls,
whereas
the
the
claims
in
the
in
the
top-level
container,
especially
the
IAT
and
potentially
mbf
and
JT
I,
would
change,
because
those
are
the
elements
that
characterize
each
shot.
Just
is
just
a
bearer
signed
bearer
of
the
of
the
response,
and
this
allows
us
to
really
distinguish
this
different
data.
E
E
Yeah.
That's
basically
is
the
change
that
we
did
and
the
court
yeah
that'sthat's
go
ahead.
Go
ahead.
Revert
you
had
to
read
the
right,
the
right
intuition.
So
there's
just
what
one
question.
What's
next
I
mean
this
is
really
a.
This
is
a
normative
change.
Obviously,
it's
a
significant
change.
That's
from
my
perspective,
the
most
significant
change
we
ever
met.
Since
we
have
been
working
on
that
draft
I
assume
we
wanna.
We
want
to
send
that
through
a
at
least
a
working
group
review
again
before
we
go
on
for
publication,
yeah.
H
A
D
D
What
I
said
on
the
list
and
that
this
change
removes
a
lot
of
the
reservations
that
I
had
about
about
this
draft
in
terms
of
missing
for
misinterpretation
of
the
of
the
response
and
misuse
claims?
Within
the
token,
as
a
token,
and
also
confusion
of
the
various
bits
that
can
go
inside
of
a
job
body
and
therefore
into
the
John
and
introspection
registries.
F
E
F
F
Let
me
let
me
address
that
right.
I
want
to
say
that
the
validity
of
this
token.
Of
this
token
introspection
is
good
for
two
minutes
right
and
if
you
get
the
taupe,
because,
like
I
mean
it
gives
you
actually
a
caching
mechanism
right,
if
you
allow
for
the
addition
of
the
expiry
token,
the
carrier
level
as
a
way
to
indicate
to
the
relying
party
effectively,
you
can
cache
this
token
introspection
for
this
period
of
time
right.
F
So,
if
you
want
to
then
have
a
centralized
authorization
model
and
you're
looking
at
risk
factors
right-
and
you
know
what
the
you
know-
because
of
the
audience
or
whatever
what
the
token
is
being
introspected
for
right,
you
might
be
able
to
say
okay
for
this
particular
use.
You
can
cache
it,
for
you
know
five
minutes
for
this
other
use.
You
can
only
cash
it
for
one
or
for
the
you
know,
you
know
$10,000
bank
transfer,
you
can't
cash
it
at
all
right.
F
E
Think,
that's
that's
a
that's.
A
vexing
idea.
We
need
to
elaborate
on
I
would
assume
instinctively
for
a
long
living
access
token.
That
makes
a
lot
of
sense
or
you
could
use
the
expiry
expiration
claim
in
D&D
uplevel
Chuck.
E
We
have
to
do
exactly
that
to
force
a
or
you
to
allow
cashing,
but
also
have
a
certain
frequency
where
the
resource
solar
needs
to
obtain
a
fresh
copy
of
the
introspection
response
and
literature,
whether
we
have
used
out
or
for
high-risk
transactions,
because
in
that
case,
I
would
most
likely
work
with
access
tokens
with
that
very
limited
exploration,
so
the
extra
open
self
would,
but
that
I
think
the
idea
is
is
very
interesting
and
it's
it's
yeah.
It's
not
possible
with
that
with
that
with
that
structure,
yeah.
Okay,
thanks!
Oh
okay,
yeah!
Thank
you.
I
I,
like
the
suggestion
I
like
the
idea,
just
a
question
to
George,
maybe
with
the
presence
of
an
exp
claim,
would
indicate
that
the
resource
servant
is
to
call
every
single
time,
I
honestly
can't
think
of
putting
the
current
time
step
in
there,
because
it
means
it's
already
expired
and
I
wouldn't
put
a
zero
in
there
and
then,
if
I,
just
don't
include
the
claim.
The
spec
needs
to
be
clear
on
this.
F
E
I
D
C
D
A
C
E
Basically,
toka
introspection
can
always
be
used
to
introspect
tokens
that
are
not
shots,
and
that's
that's
true
in
that,
in
that
case
as
well.
So
the
assumption
of
the
draft
is
not
that
you
introspect.
The
token
has
a
certain
format.
We
just
use
a
jot
Deut
claims
in
the
same
way
as
the
original
token
introspection
draft,
thus
to
convey.
C
C
E
A
F
Here
I
think
I'm
was
next,
but
I
fully
put
it
in
the
chat
right.
The
current
token
introspection
spec
defines
some
explicit
claims
for
putting
common
data,
and
you
can
extend
it
to
return
anything
you
want.
So
my
expectation
is
the
claims.
Inside
the
token
introspection
object
are
the
same.
That
would
have
been
returned
from
the
token
introspection
endpoint.
If
you
weren't
asking
for
a
jot
response
and
in
that
context,
balto
whatever
Dana
yuan
returned
there.
A
A
E
A
A
A
A
So
go
ahead,
dick
you
wanna
say
something
years.
We
would
I
go
back
talking
him,
but
what
do
that?
One?
Is
that
what.
B
G
J
So
one
thing
I
wanted
to
mention
again
it's
something
that
it
was
touched
on
the
least,
and
it
was
about
enforcing
the
requirement
for
having
single
user
refresh
tokens
or
sender
constraints.
One
thing
was
vetted
during
the
discussion.
It
turns
out
that
the
sender
constraint
and
we
considered
also
confidential
clients,
but
the
language
wasn't
super
clear.
J
So
I
didn't
read
the
latest
draft
to
see
whether
these
clarification
was
included,
but
I
just
wanted
to
bring
it
up
in
case
it
wasn't,
but
the
other
thing
that
I
wanted
to
mention,
which
instead
was
still
open
in
the
mailing
list,
was
on
whoever
it's
a
opportune
to
require
to
native
clients
like
public
clients
that
are
not
spas
to
use
a
one-time-only
or
constraint.
I
wanted
to
reiterate
of
it.
I
think
that
the
afforded
the
course
back
and
not
a
bit
disappear.
J
It's
asking
too
much,
let's
say
vector,
that's
not
transparent
for
the
developers,
because
the
errors
that
you
can
get
in
case
you
family
to
get
the
new
a
refresh
token,
is
complicated.
So
I
think
that
there
are
we
should
we
should
definitely
a
requirement
for
sparse,
but
asking
for
native
clients
desktop
clients
tools
to
do
one-time
only
in
the
core
is
too
much.
E
Here
we
told
you
I'm
just
quite
sure
why
you
think
it's
okay
for
required
to
require
that
for
s
pas,
but
not
for
native
and
desktop
I
mean
beside
the
fact
that
I
think
native
and
web
apps
could
also
use
under
constraining
or
these
kind
of
authentication,
which
is
also
qualify
as
a
sender
constraining.
So.
J
Reason
for
which
I
differentiate
between
sparse
and
mobile
clients
is
mostly
attack
surface.
Let's
save
it.
When
you
are
in
the
Browse
way
more
ways
of
attack
you,
then,
if
you
would
have,
for
example,
in
iOS
app,
which
operates
in
a
sandbox
environment,
where
you
have
some
degree
of
access
to
the
device
and
very
easy
isolation
between
applications.