►
From YouTube: OAUTH WG Interim Meeting, 2020-08-10
Description
OAUTH WG Interim Meeting, 2020-08-10
A
I
think
it's
starting
okay
welcome
everyone.
First,
we
have
a
note
taker
and
dick
is
gonna,
be
taking
notes
again.
So
thanks
thanks
again,
we
appreciate
that
roman
will
be,
will
not
be
able
to
attend
today.
So
we
have
an
id
today.
If
you
have
any
questions
about
that
so
or
questions
related
to
adwork,
let
me
know,
and
and
I'll
I'll
take
it
with
a
with
a
with
roman
later
on.
A
A
I
just
want
to
mention
a
draft
that
neil
just
submitted
or
sent
to
the
an
email
to
the
mailing
list
about
this
specific
draft.
That
was
part
of
jose.
I
guess
so.
Please
take
a
look
and-
and
if
you
have
any
comments
or
or
any
feedback
and
send
that
to
the
list,
and
then
we
will
try
to
schedule
a
meeting
for
for
this
to
discuss
this
document
in
in
one
of
the
coming
weeks.
B
I'd
I'd
like
to
consider
doing
one
on
d-pop
but
was
hoping
to
get
a
new
draft
visit
revision
published
before
and
I'm
I'm
not
entirely
sure
when
that's
going
to
happen.
So
I
don't
we
can
talk
offline
about
it.
But
if
there's
a
meeting
later
in
the
series,
maybe
they
could
go
towards
depop
that
that
might
work
well.
For
me,
anyway,
yeah
sounds.
A
B
Okay,
all
right
awkward
transition.
Welcome
to
this
interim
here
we're
dedicating
this
one
to
talk
about
pushed
authorization,
authorization
requests-
hopefully
there's
not
too
much
controversial
or
new
here,
but
seemed
like
a
good
opportunity
to
sort
of
touch
base
on
the
document
and
talk
about
status
next
steps.
So
a
few,
a
few
sort
of
half-assed
visual
puns
here
in
the
beginning
and
I'll
be
more
of
them
coming
up
through
the
rest
of
the
dock.
But
let's,
let's
jump
right
into
it.
B
B
This
allows
for
large
authorization
requests
and
there's
a
lot
of
different
reasons.
This
might
happen.
Authorization
details
coming
out
of
rar
can
be
rather
verbose.
The
claims
parameter
from
connect,
it
can
be
pretty
large.
We've
seen
scopes,
run
amok
in
jwt,
encoded,
state
parameters
and
other
things,
all
of
which
can
kind
of
come
together
and
and
cause
for
significantly
larger
authorization
requests
than
maybe
were
first
envisioned
and
those
can
and
sometimes
do
run
into
browser
length
limitations
on
uris
and
this
pushing
it
to
the
authorization
server
allows
for
working
around
that
particular
issue.
B
The
direct
client
to
authorization,
server,
https
connection
provides
integrity
and
confident
confidentiality
protection
on
the
request
itself,
which
is
otherwise
difficult
to
come
by
possible
but
difficult,
and
you
get
the
opportunity
to
do
client,
authentication
and
authorization
prior
to
the
start
of
any
user
interaction,
at
least
for
confidential
clients,
which
isn't
possible
through
the
normal
authorization
request
mechanism,
because
the
client
isn't
authenticated
at
that
point.
It's
just
identified,
so
it's
a
chance
to
do
some
checking
up
front
and
even
check
some
policy
and
potentially
deny
requests
earlier
on
in
the
process.
B
If
policy
so
dictates,
jumping
right
into
the
protocol
details
and
see
what
it
looks
like
the
starts
out
with
a
client
taking
what
would
be
its
authorization
request,
parameters
and
encoding
them
in
the
post
body
of
http
request
to
the
authorization
server
you
see
here.
The
normal
stuff
you'd
expect
the
response
type
state
client
id
redirect
uri.
B
We
did
the
pixie
parameters
here,
just
to
show
sort
of
newly
accepted
best
practice
and
scope,
and
also
in
this
you'll,
see
that
there's
a
authorization
header
doing
http
basic
authentication
for
the
client.
But
all
this
is
happening
in
a
direct
request
from
the
client
to
the
authorization
server
assuming
all
goes
well.
B
At
this
point,
that's
all
there
is
to
it
it's
relatively
simplistic
in
terms
of
of
what
it
is
and
what
it
does,
but
it's
fairly
powerful
in
enabling
some
improved
security
in
a
simplified
means
for
a
lot
of
clients
a
little
bit
of
history
on
this
here
it
was
conceptualized
in
matt's,
mind.
I
think
a
long
time
ago,
just
never
really
got
written
down.
There
was
a
half-hearted
subsection
about
it,
written
in
fappy
for
a
while,
but
not
sufficient
to.
B
I
can't
read
my
own
stuff
here
because
of
webex
okay.
Here
we
go
so
not
a
lot
has
happened
since
the
adoption,
but
a
couple
changes
here
and
there
and
more
recently
we
had
a
draft
02
published
earlier
in
july,
and
this
was
coming
out
with
updates,
based
largely
on
questions
and
issues
that
were
raised
in
the
last
interim
on
it,
as
well
as
a
few
little
list
discussions.
B
Some
of
the
larger,
if
you
will
changes,
although
they're,
relatively
small
in
the
scheme
of
things,
were
to
add
some
metadata
around
policy,
so
a
require
pushed
authorization.
Requests.
Metadata
parameter
was
added
both
for
the
client
and
authorization
server
to
allow
the
metadata
to
express
policy
for
only
accepting
pushed
authorization
requests
either
in
the
context
of
an
individual
client
for
the
client
metadata
or
for
an
authorization
as
a
whole
as
a
way
to
indicate
that
that's
the
only
way
it
will
accept
authorization
request.
B
So
it
tries
to
clarify
that
you
basically
do
what
you
can
in
the
back
channel
when
and
then
do
the
rest
through
the
normal
course
of
processing
and
just
ensure
that
all
the
normal
validation
does
in
fact
occur.
Even
if
it's
you
know,
regardless
of
where
it
happens,
and
even
if
it's
a
little
bit
redundant,
that
you
can't
can't
not
do
validation,
but
you
should
try
to
do
validation
at
the
front
front
end
and
I'm
pretty
sure
the
document
says
it
more
eloquently
than
the
mumbling
I
just
did.
But
that
was
added
there.
B
We
added
a
little
bit
of
guidance
and
some
options
around
how
the,
as
can
structure
the
request,
uri,
it's
all
optional
and
just
stuff
you
can
do
if
it's
useful.
The
ais
is
still
at
the
liberty
of
doing
the
the
uri,
whatever
makes
sense
for
it,
but
we
introduced
oauth
base
uri
to
to
be
something
you
could
use
in
place
of
your
own
necessity,
your
own
value
that
you
make
up
and
maybe
keep
some
people
from
making
up
their
own
uris.
B
B
One
thing
that
came
up
in
the
last
interim
meeting
or
around
it
was
the
reality
that,
at
the
time,
jar
was
pretty
clearly
stating
that
the
request
uri
had
to
refer
to
a
jwt
encoding
of
the
authorization
request,
and
we
talked
a
little
bit
about
par
means
that
that's
not
strictly
necessary,
because
your
the
authorization
server
is
basically
referring
to
data
of
its
own
keeping.
So
that
that
requirement
was
both
not
validatable
and
not
necessary.
B
B
Wasn't
something
that
was
you
know
needed
to
be
interoperable
was
something
that
was
entirely
within
the
as's
disposal.
It
didn't
necessarily
have
to
be
a
jwt,
so
it's
not
a
change
actually
to
par,
but
a
fix
to
jar
back
in
draft
22
resolved
an
outstanding
issue
that
we
did
have
with
with
par
itself,
I'll,
probably
inter
interchange,
jar
and
par
a
few
times,
but
hopefully
I'm
using
them
in
the
right
context.
B
Sorry,
there
we
are,
and
not
long
after
the
o2
revision.
We
also
pushed
out
an
o3
just
a
little
bit
later
in
july,
mostly
really
small,
minor,
stuff
kind
of
clean
up,
an
editorial
thing
and
a
few
things
people
noted
on
on
o2,
there's
no
major
like
wire
changes
the
protocol.
So,
despite
this
being
a
quick
turnaround,
I
think
it's
actually
indicative
of
a
fairly.
B
B
B
I
felt
like
rereading
it.
There
was
a
little
bit
of
potential
confusion
about
that.
It
might
be
making
the
request
itself
so
try
to
try
to
clarify
that
that
the
actual
authorization
request
with
the
with
the
request
uri,
is
initiated
by
the
by
the
client,
but
done
so
by
the
client,
invoking
the
user
agent
to
actually
make
the
request.
B
So
that
went
out
earlier
or
the
end
of
last
month-
and
you
just
mentioned
that
you
know
there
are
now
a
pretty
significant
number
of
implementations
and
usages
by
other
sdos.
These
are.
This
is
not
necessarily
a
complete
list,
but
these
are
the
ones
that
I'm
aware
of
including
an
implementation
I
recently
did
in
in
product
myself
and
was
was
pleased
with
the
the
state
of
the
document
and
the
the
applicability
to
actual
implementation.
B
So,
generally,
good
news
here
and
in
my
standard
sort
of
gratuitous
closing
plot
slide
of
in
this
case
the
city
of
the
next
likely
cancelled
in-person
meeting,
I'm
guessing,
we
won't
see
each
other
in
bangkok,
but
you
never
know
and
really
at
this
point
I
think
the
action
item
I'm
asking
the
working
group
to
consider
is
that
is
it
time
to
take
part.
A
working
group
ask
call
based
on
implementation,
experience
and
the
feedback
thus
far
and
the
stability
of
the
draft.
I
I
I
think
it's
ready.
A
D
B
B
Okay,
oh,
I
also
see
one
question
here:
just
it's
probably
just
expedient
to
go
through
this.
Should
the
insensitive
parameters
like
prompt,
also
be
added
to
the
power
request,
or
can
it
be
added
in
the
authorized
call
so
the
I?
The
idea
with
with
par,
is
that
everything
that
would
otherwise
be
in
the
authorization
request
is
done,
is
sent
in
the
par
request
itself
and
then
only
the
uri
and
the
client
id
to
be
compliant
with
jar
ascent.
B
E
Any
questions
can
you
hear
me
right
now
is
denny
speaking.
Yes,
we
can
okay.
Thank
you.
So
first
there's
another
question:
my
family
name
is
panka
p-I-n-k-a-s
and
at
the
same
time
I
have
not
a
question,
but
basically,
at
the
moment
the
draft
includes
a
security
consideration
section
that
it
doesn't
include
a
privacy
consideration
section,
and
I
would
appreciate
that
a
privacy
consideration
section
could
be
added
to
the
draft
before
the
last
call.
B
Would
be
in
there?
The
latest
document
does
allude
to
the
possibility
of
pii
type
information
being
in
the
request
itself
and
the
advantages
to
sending
those
in
the
in
the
par
request
versus
through
the
browser,
in
the
clear
where
it
might
might
be
more
likely
to
be
seen
by
those
for
whom
it
was
not
intended.
E
B
E
D
B
D
B
No-
and
I
I
totally
agree
with
that-
I
just
I
know
I
know
I've
I've
written
at
least
one
somewhere
at
somebody
else's
urging
I
don't
know
offhand.
I
can
certainly
find
out-
and
let
you
know
after
the
fact,
but
I
don't
have
it
at
the
fingers
now.
My
my
particular
concern
here
would
be
more
about
the
particular
content
of
it
and
and
relevancy
to
this
document
versus
a
broader
set
of
of
issues.
D
B
Is
it
yeah
the
most
recent
one?
Let's
see
I'll,
just
read
it
just
in
case
the
oauth
2
spec
has
both
clan
id
and
response
type
as
mandatory
parameters
of
the
authorized
call,
but
with
par
only
client
id
is
mandated,
along
with
the
request.
Uri
feels
like
par,
is
not
being
compatible
with
oauth2.
Is
this
a
concern
that
we
should
look
into
it's
a
fair
question
and
I
I
guess
I
would
defer
then
to
the
work
in
jar
which
right
or
wrong,
took
the
liberty
of
saying
that
those
parameters?
B
A
B
A
A
D
A
F
B
Maybe
just
to
answer
the
question
or
provide
some
insight.
All
you
need
to
do
is
review
it,
and
you
know
if
there
are
problems
that
you
see
raise
them
in
the
last
call,
by
sending
an
email
to
the
to
the
working
group,
pointing
out
the
issues
and
hopefully
offering
solutions
if
possible,
or
if
you
don't
find
a
problem,
simply
saying
I've
reviewed
the
document
and
it
looks
okay
is,
is
also
very
helpful
so
that
that's
all
there
is
to
it.