►
From YouTube: OAUTH WG Interim Meeting, 2021-03-22
Description
OAUTH WG Interim Meeting, 2021-03-22
A
Welcome
everyone,
so
this
is
the
second
second
interim
meetings
for
us,
so
as
as
as
usual,
the
note
will
applies
here.
So
if
you're
not
familiar
with
this,
make
sure
you're
you're
familiar
with
yourself
with
this,
because
this
governs
everything
that
we
do
at
the
edf.
So
it's
important
that
you
understand
this
and
today
we'll
be
talking
more
mainly
about
oauth
2.1,
as.
B
A
We
still
have
a
long
list
of
upcoming
meetings
and
next
week,
we'll
have
two
topics:
client
intermediate
metadata
subjects
chart
for
next
week,
but
today
we
will
be
focusing
on
oauth,
2.1
and
aaron.
Will
they
will
walk
us
through
this?
Any
questions,
this
any
question
about
the
the
next
meetings.
Any
comments.
A
C
Hi,
everyone,
sorry
for
being
a
few
minutes.
Late
meeting
ran
over
time.
A
Yeah
no
worries
thanks
harness
okay,
good,
so
I'll
then
hand
it
I'll
stop.
Sharing
here,
let's
see
and
I'll
hand
it
to.
A
C
D
D
Yeah,
okay,
so
thanks
everybody,
let's
jump
in
so
I
want
to
start
with
an
update
on
the
changes
since
the
last
draft,
which
were,
I
believe,
approximately
six
months
ago
now,
we've
gone
through
the
main
changes
were
driven
by
feedback
from
justin
and
vittorio's,
very
excellent
and
very
thorough
reviews.
So
everybody
should
say
thank
you
to
them
for
their
detailed
feedback.
D
The
sorry
somebody
is
feeding
back
audio
into
the
call.
Still
I
believe
there
we
go
so
yeah,
there's
a
lot
of
primarily
editorial
changes
that
were
based
on
feedback
from
justin
vittorio.
That
was
a
lot
of
stuff
that
I
just
kind
of
took,
took
the
editorial
decision
to
to
go
and
make
those
changes.
A
lot
of
it
was
rearranging
things
or
moving
things
around
clearing
clearing
up
terminology.
D
So
no
really
functional
changes
there
at
all
it
was.
It
was
just
cleaning
things
up.
There
were
a
couple
of
mechanical
bits
as
well
the
terminology
and
references
to
previous
rfcs
that
have
since
been
updated
themselves.
So
things
like
http
semantics
have
been
replaced
with
references
to
the
current
http
semantics,
not
the
older
ones,
and
then
the
comments
from
justin
inventorio
that
have
not
been
incorporated,
things
that
I
thought
were
either
required,
some
more
discussion
or
either
on
the
call
today
or
in
just
in
in
github.
D
That
kind
of
those
kind
of
things
are
all
open
to
as
issues
on
the
github
repo.
So,
basically,
I
went
through
all
the
feedback
and
I
was
like
okay.
These,
I
feel
like
are
easy.
I'm
just
going
to
make
these
changes.
These
ones
are
a
little
bit
harder,
so
I'm
going
to
punt
on
those
and
we'll
discuss
them
later
later.
So
that's
the
main
changes
since
draft
zero,
zero
they're,
also
based
on
this
feedback
feedback
and
based
on
the
conversation
that
the
editors
have
been
having.
We
have
a
couple
of
changes.
D
We
are
planning
on
making
and
have
not
yet
actually
had
time
to
do
so.
These
are
all
opened
as
issues
again,
so
we
can
track
them
on
github.
First
line
item
is
getting
through
the
rest
of
the
feedback
from
justin
and
matorio.
The
bulk
of
their
feedback
was
in
sections
one
through
six,
because
that's
where
most
of
the
spec
is
sections
seven
through
13
have
not
yet
been
processed.
So
I'm
gonna
do
the
same
thing
there
of
incorporating
the
the
easy
changes
and
opening
issues
for
the
more
difficult
changes.
D
61
is
a
major
refactor
that
we
want
to
do,
which
is
section.
Four
is
the
section.
That's
currently
called
obtaining
authorization,
and
that's
the
section
that
talks
about
how
to
start
the
authorization
code
flow
it
used
to
also
contain
how
to
start
the
implicit
flow,
and
it
also
talks
about
client
credentials,
which
is
the
sort
of
implied
authorization,
because
the
authorization
is
the
credentials
themselves.
D
D
This
is
how
to
talk
to
the
token
endpoint,
where
it
talks
about
all
the
you
know:
authorization
code
flow
as
well
as
correct,
client
credentials
as
well
as
refresh
token,
and
that
way
we
can
spell
out
the
like.
The
parameters
that
are
required
to
talk
to
the
token
endpoint
and
all
the
mechanics
around
that
so
that's
gonna.
That's
some
bit
a
bit
of
work,
so
we
we're
tracking
that,
but
that's
something
we're
planning
on
doing
65
is
a
a
interesting
one.
That
probably
is
worth
talking
about
a
little
bit
on
this
call.
D
The
the
task
for
us
was
to
find
out
from
the
security
aspect
is:
if
the
requirement
of
single-use
authorization
codes
is
no
longer
necessary
if
you're
also
doing
pixie.
The
main
reason
for
single-use
authorization
codes
before
was
to
avoid
like
authorization,
code,
injection
attacks
and
things
like
that
which
are
less
less
likely-
and
you
know
things
are
things
are
different
when
you're
using
pixie
one
of
the
motivations
for
relaxing.
That
requirement
is
that
in
practice
I
know
there
are
several
authorization
servers
that
do
not
enforce
single-use
authorization
codes.
D
D
A
lot
of
that
language
would
fit
better
now
in
line
in
the
stack
in
the
main
part
of
the
spec.
So
the
idea
is
to
go
through
the
security
considerations
section,
which
is
mainly
text
from
the
security
bcp,
take
out
all
the
normative
language,
all
the
requirements
and
put
it
up
into
the
spec,
where
it
actually
is
described
in
first
place
so
yeah.
D
These
are
all
things
that
the
others
are
planning
on
doing
and
unless
there's
any
huge
objections
to
this,
we're
just
gonna
go
ahead
with
those
okay,
oh
daniel
is
on
the
queue.
Do
you
want
to
jump
in
now,
because
I
think
the
next
yeah
the
next
section?
I
have
a
couple
of
issues
bring
up
for
the
group,
so
we
might
as
well
start
that
right
now.
B
Yes,
so
this
was
for
the
number
65
that
you
have
on
the
slide
there.
I
do
not
think
that
this
would
be
a
good
idea,
the
single-use
requirement
of
the
authorization
code.
I
know
that
in
practice
it
cannot
always
be
enforced
or
enforced
in
cases
where
you
have
requests
happening
almost
at
the
same
time.
So,
but
nonetheless,
I
think
it's
a
very
strong
security
feature
and
it
has
not
lost
its
important
with
importance
with
pixie.
B
For
example,
if
you
have
a
an
attack
where
the,
where
the
attacker
is
able
to
control
parts
of
the
authorization
request,
so
a
chosen
pixie
challenge
or
if
the
attacker
somehow
is
able
to
see
parts
of
the
token
request
containing
the
pixie
verifier
or,
for
example,
if
a
client
uses
a
static,
pixie
value,
which
of
course
it
shouldn't,
but
still
a
client
might
do
that
and
all
of
these
cases,
and
probably
some
others
that
I'm
not
have
on
my
mind
right
now.
B
B
Also
if
we
want
to
relax
that
we
might
need
to
think
about
what
actually
happens
then
so
is
the
a
is
supposed
to
send
the
same
access
token.
Do
we
have
two
access
tokens?
So
what's
the
semantics
experience
that
behind
that.
E
Yeah,
I
agree
with
daniel.
I
think
there
is
still
value
in
authorization
codes
being
single
use
even
under
pixie.
E
However,
I
think
what
would
be
beneficial,
having
talked
to
a
lot
of
developers
about
this
over
the
years,
is
clarifying
what
we
actually
intend
and
expect
single
use
to
mean,
because
we
don't
mean
you
have
to
remember
all
authorization
codes
for
all
time
and
never
see
another
one
of
the
same
value
ever
again.
E
But
we
also
don't
mean
you
can
you
know
you
can
forget
as
soon
as
you
issue
it
and
like?
Let
somebody
replay
that
a
bunch
of
times
or
something
like
that?
Most
implementations,
I've
seen
are
burn
on
first
use
and
that's
how
they
interpret
that.
We
might
want
to
capture
that
if,
if
that's,
what
the
working
group
really
intends
for
this
to
be,
but
if
we
mean
something
else
like
you
know,
instead
of
just
bringing
on
first
use,
remember
it
for
a
few
minutes.
E
F
F
I
think
we're
really
trying
to
say
that
there's
only
that
code
there's
only
that
code
is
only
valid
for
one
outstanding,
valid
request
right
now.
Something
like
that.
So
I
think
we
want
to
rephrase
it
for
what
we
mean,
as
opposed
to
the
easy
description
that
we
have
here,
but
that
isn't
would
require
you
to
have
something
with
massive
entropy
to
actually
implement
properly.
A
Okay,
phillip.
G
I
don't
mean
for
this
to
sound
like
I'm
piling
on,
but
yeah.
You
know,
echoing
what
what
justin
and
dick
just
said,
with
the
exception
that
we
definitely
want
to
rephrase
it
to
what
we
what
we
needed
to
do
where,
if
the
replay
one
comes
in,
we
ideally
want
to
mention
that
you
should
revoke
all
the
previous
tokens
issued
from
the
original
one
so
that
it
being
actually
replay
protected,
serves
a
purpose.
D
D
Yeah,
that's
great
my
main,
my
main
question
in
regards
to
that.
I
I
understand
all
that
for
sure.
My
main
question
is
the
fact
that
there
are
servers
in
the
wild
that
don't
do
this
currently,
even
though
it
is
described
in
oauth
2.0.
D
A
Thurston
you
have
on
the
line.
You
want
to
ask.
H
Well,
this
is
not
a.
This
is
not
a
response
to
aaron's
question.
I
I
wanted.
I
wanted
to
to
to
add
to
what
or
reflect
on
what
just
was
said
by
philippe
I
mean
the
rational
for
bringing
that
topic
up
was
to
simplify
implementer's
life
by
not
enforcing
the
single
single
use
requirement
for
authorization
codes.
H
Especially
in
cases
where
self-contained
access
tokens
are
reused,
it's
I
don't
any.
I
don't
know
any
mechanism
could
be
utilized
by
a
srs
pair
to
really
revoke
this
access.
Token,
except
you
have
a
back
channel
some
kind
of
proprietary
back
channel
communication
mechanism
that,
in
the
end,
revokes
a
token
or
you,
you
force
the
resource
solver
to
to
introspect
the
access
token,
with
every
request
which,
in
the
end,
would
kill
scalability
completely.
H
So
I
think
we
should
be
carefully
with
the
requirement
of
what's
going
to
happen
if
a
replay
is
being
detected
just
wanted
to
point
that
out.
A
Okay,
danielle,
sorry,
philip,
you
wanna
jump
in.
G
What
was
it
yeah
if
danielle's,
okay,
with
it
sure
yeah?
I
I
completely
get
that
and
there's
a
you
know
you
can
revoke
access
tokens
up
to
a
limited
they're
self-contained
mandating
introspection
on
every
single
use
of
an
access
token
doesn't
make
sense.
It
defeats
the
purpose
of
them
being
self-contained,
but
I'm
I'm
trying
to
echo
what
we
did
for
the
dt
certification,
where
we
actually
have
tests
in
place
where
you
can
pass
certification.
G
If
the
reuse
is
there
within
30
seconds,
but
after
30
seconds
it's
it's
a
failure,
and
now
this
could
be
more
directed
than
mike
jones.
Who
could
say
what
we
check
for
with
regards
to
the
issue?
Tokens.
A
D
Doing
a
replay
within
a
time
window
isn't
isn't
any
different
than
just
having
it
expire.
Normally
anyway,
it's
different
for
like
refresh
tokens,
you
know,
because
their
lifetimes
are
a
lot
longer,
but
in
general,
optimization
codes
are
short-lived.
D
I
This
is
mike,
so
what
felipe
is
referring
to
is
in
the
open
id
connect
certification
suite.
We
did
in
practice
find
that
way
too
many
implementations
actually
used
time-based
enforcement
rather
than
acid
consistency
across
a
database.
That's
distributed.
I
They
made
the
trade-off
to
stop
it
soon,
but
not
be
the
hit
of
synchronicity.
Therefore,
in
the
test
suite,
we
just
require
it
to
be
a
failure
after
30
seconds,
that's
kind
of
an
arbitrary
number,
but
you
know
the
result.
Is
you
can't
keep
using
it
forever,
but
it's
not
necessarily
a
timeout
either
it's.
B
Yes,
so
plus
one
to
the
two
more
precise
language
around
what
we
expect
the
as
to
do
when
replay
is
detected
or
for
detecting
replay,
but
to
a
more
general
point.
We
also
need
to
keep
in
mind
that,
as
far
as
I
know,
we
still
have
still
allow
cases
where
nones
can
be
used
instead
of
pixi.
B
D
D
It
sounds
like
we
have
a
couple
of
things
we
could
do
immediately
anyway
to
improve
this.
I
guess
at
the
very
least,
being
more
specific
about
we're,
not
saying
globally
unique,
forever
authorization
codes,
we're
actually
meaning
that
reusing
them
is
the
thing
that's
not
intended.
So
maybe
we
can
at
least
move
that
forward
and
then
try
to
find
more
language
to
clarify
this
as
well
for
the
other.
For
the
other.
D
D
H
One
sure
so,
as
most
of
you
know,
the
security
pcp
now
was
changed
to
recommend
the
issue
response
parameter
as
a
defense
against
a
as
mix-up
attacks,
and
the
question
that
we
would
like
to
raise
is
whether
we
should
add
the
issue
response
parameter,
o
of
2.1
just
to
have
a
a
solid
and
simple
mix-up
prevention
for
those
clients
that
need
it
right
now.
I
don't.
I
don't
think
we
have
any
text
about
the
issue
response
parameter
in
a
draft.
Correct
me.
If
I'm
wrong
aaron.
H
Okay,
okay
and
it
somehow
also
contradicts
our
original
or
the
approach
we
want
to
take
and
to
only
add,
mature
elements
of
oauth
2
of
2.1.
But
I
think
this
is
a
kind
of
an
exception,
because
the
working
group,
after
some
hard
work,
came
up
with
a
really
simple
solution
to
the
mix
up
a
problem
and
yeah.
We
would
like
to
discuss
whether
it
would
make
sense
to
to
add
that
parameter
to
the
spec
in
the
same
way
as
we
added
pixi,
for
example,.
D
H
Yeah,
that's
what
I
meant
with
the
light
up
with
the
last
with
the
last
statement,
so
only
for
those
clients
requiring
mixer
protection-
and
this
is
but
daniel
is
much
more
better
to
talk
about
that
attack
for
clients
that
are
subject,
and
those
are
the
clients
that
interact
with
multiple
asses.
I
Yeah
I
hear
you
torsten,
but
I
also
think
we
should
stay
with
the
triggered
intent
of
this
spec,
which
is
to
codify
what
people
are
actually
doing
and
as
soon
as
we
entertain
adding
the
issuer
response
parameter.
I
We're
also
going
to
have
discussions
about.
Well,
you
don't
need
it
when
you
have
an
id
token
with
an
issuer.
I
realize
connect
is
a
profile
of
oauth
2,
but
it's
a
common
profile
and
it
that
would
be
another
case
like
nonce
where
well
you
don't
need
pixie.
In
some
cases,
if
you
have
nonce,
you
wouldn't
need
the
issuer
response
parameter.
If
you
have
an
id
token.
H
I
think
we,
as
authors
are
very
good
and
in
the
meantime,
to
state
what
we
think
is
is
the
right
solution
and
then
carefully
define
the
exceptions,
especially
for
those
that
already
use
connect
built-in
counter
measures.
We
have
done
that
with
pixi
and
nuns,
and
I
think
we
can
do
that
with
issuer
and
the
issue
in
the
id
token
as
well.
I
mean
daniel
correct
me.
If
I'm
wrong,
we
all.
We
already
have
this
kind
of
text
in
the
security
bcp
that
talks
about
both
options.
B
Yes,
to
be
precise,
it's
in
the
latest
pull
requests
around
the
exactly
this
parameter
and,
yes,
we
have
an
exception
if
the
iss
value
is
contained
in
another
way
in
the
authorization
response.
B
I
will
we
will
hopefully
publish
a
new
version
before
the
interim
meeting
around
the
security
pcp
yeah.
I
H
I
I
hear
you,
but
that
the
idea
of
oauth2.1
was
to
get
rid
of
the
security
bcp
as
one
of
the
documents
that
an
implementer
needs
to
read
right.
We
wanted
to
consolidate
oauth
2.0,
they
borrow
a
token
draft
security,
pcp
and
a
lot
of
other
pcps
into
one
new
baseline
that
that's
the
philosophy
of
oauth2.1.
So,
from
my
perspective,
someone
reading
oauth
2.1
does
not
need
to
even
consult
the
security
pcb.
I
H
Well,
that
I
mean
we
can
we
can
check
back
the
the
meeting
minutes
from
singapore
back
then,
I'm
quite
sure,
looking
at
the
current
status
of
the
oauth
2.1
draft,
for
example,
we
integrated
all
these
considerations,
security
considerations
of
the
security
pcp
and
we
also
integrated
all
the
other
bcps
such
as
spa
and
so
on,
and
so
on
into
2.1.
I
Thing:
okay!
Well,
if
that's
the
case,
it
furthers
torston's
argument
to
include
this.
I
hadn't
realized.
We
were
gonna,
try
to
get
people
to
be
able
to
do
this
without
reading
the
security
documents.
F
Well,
the
idea
of
the
bcp
would
be
to
continue
to
be
updated
and
I'd.
Imagine
after
2.1
ships
it'll
be
updated
with
new
practices
that
aren't
included
in
2.1,
but
in
2.1
we
should
capture
the
state
of
the
industry.
So
there's
one
document
since
I've
got
the
mic,
I
was
in
the
queue
just
wanted
to
clarify
that
this
is
not
a
must.
F
It's
a
should,
and
I
also
agree
with
your
point
mike
that
what
we
should
the
normative
language
is
that
the
issuer
should
be
included
in
the
response,
either
as
an
iss
parameter
or
in
any
other
way,
where
it's
included
in
the
response,
which
would
cover
it
being
included.
In
the
id
token.
A
B
No,
maybe
just
highlighting
that
the
iss
parameter
is
really
the
only
solid,
solid
protection
against
mix-up
attacks
that
is
left
because
even
the
issuer
redirect
your
eyes
have
their
flaws.
So
we
really
need
this
parameter.
If
you
want
to
defend
against
mixer,
okay.
J
Vittorio,
I
just
wanted
to
add
my
support
to
covering
this
aspect.
I
think
that
multi-issuer
is
an
underspecified
aspect
and
that
a
lot
of
people
encounter
in
practice,
and
so
as
long
as
it
should
and
as
long
as
we
call
out
explicitly
that
the
id
token
is
equivalent.
I
think
that
it's
going
to
be
useful
for
people
to
have
the
multi-issue
scenario
addressed
explicitly
into
that
one.
D
Okay,
yeah!
Well,
I
guess
to
torsten
is
anything
else
you
wanted
to
talk
about
this
issue
before
we
move
on.
No
thanks.
A
D
D
Okay.
Well,
I
guess
kind
of
along
these
lines
same
similar
space,
the
there's,
still
kind
of
a
open
question
about
the
specific
wording
for
referencing
the
open
id
connect,
implicit
flows
so
and
there's
a
whole
bunch
of
different
ways.
We
could
approach
this
in
2.1
and
I
think
they
have
a
lot
of
very
different
properties
of
them.
So
the
the
the
state
of
the
document
right
now
is
that
there
is
nothing
in
there
called
implicit
anymore
at
all.
D
There's
just
no
mention
of
it,
and
there
is
the
specific
carve
out
for
pixie,
which
says,
if
you
I
forget,
exactly
the
wording,
but
it's
it's
basically,
so
that,
if
you
are
using
open
id
connects
response
type
id
token,
you
don't
need
to
use
pixi
if
you're
following
those
rules,
that's
the
carve
out.
The
question
is:
is
that
is
that
good
enough?
Or
should
we
add
more
text
to
clarify
the
the
intent
here?
So
the
fact
that
the
the
response
type
token
is
completely
gone
now.
D
The
there's
you
know
some
discussion
about
is
that
going
to
be
confusing
to
people
who
are
seeing
response
type
token
elsewhere,
for
example,
in
operating
connect,
so
the
sort
of
options
laid
out
here
you
can
just
not
mention
anything
which
is
kind
of
the
current
state.
We
could
explicitly
state
that
removing
response
type
token
does
not
directly
deprecate
anything
else
that
may
be
built
on
top
of
oauth,
2.,
2.0
or
2.1,
but
you
know,
go
go
investigate
on
your
own.
D
We
could
three
explicitly
prohibit
response
type
token,
which
is
effectively
what
the
security
bcp
is
doing.
We've
just
removed
that
language,
because
it's
not
defined
in
2.1
another
option
is
to
explicitly
allow
the
response
type
id
token,
with
the
condition
that
it's
not
being
used.
It's
an
access
token,
which
is
a
common
mis,
mis
implementation
that
we've
seen
and
then
another
option
is
to
encourage
openid
itself
to
officially
deprecate
the
response
types
that
contain
token,
which
is
the
access
token
in
the
response.
D
I
Okay,
mike
not
to
add
more
to
more,
but
vittorio
made
a
really
good
point
in
one
of
his
reviews,
which
is
that
the
security
characteristics
of
implicit
using
a
fragment
are
completely
different
than
the
security
characteristics
of
implicit
using
response
mode
form
post,
even
if,
because
of
the
possibility
of
token
logging
and
capture
that
goes
with
implicit
in
the
front
channel,
if
we
use
form
post
response
mode,
it's
not
the
same
thing
and
there's
no
reason.
I
We
should
be
deprecating
that
so
you
know
just
of
all
the
bullets
you
have
up
here.
I
would
just
stay
with
no
mention
if
you're
not
going
to
talk
about
it.
But
if
you
do
talk
about
it,
you
need
to
say
that
form,
post
response
mode
is
different
than
fragment.
D
I
I
hear
that
I
agree
that
it's
different.
I
don't
think
that
it's
necessarily
the
same
as
avoiding
the
implicit,
avoiding
the
authorization
endpoint
returning
the
token
at
all.
It
still
is
handing
it
to
the
browser
to
deliver
to
the
application,
whereas
it's
not
it's
not
as
secure
as
the
application
getting
it
from
the
back
channel.
So
I
don't
think
that
I
would.
I
would
not
feel
comfortable
saying
that
it
is
safe
and
I
would
definitely
not
want
to
recommend
response
mode
form
post
at
all
in
this.
In
this
draft.
I
A
Okay,
people
in
the
queue
jeff.
K
Yeah,
really,
I
was
just
going
to
agree
with
what
kind
of
mike
was
saying
there.
I,
I
don't
think
it's
really
worth
bringing
up
things
that
are
outside
of
the
scope
of
specification,
especially
when
it
comes
to
extensions
like
open
id
connect
and
everything
and
yeah
really
just
kind
of
agreeing
with
that
point.
K
J
Here
I
have
to
apologize
for
the
broken
record
effect,
but
I
have
to,
although,
from
the
lawyer
perspective,
we
are
perfectly
fine
with
not
mentioning
anything
because
people
familiar
with
how
specifications
work
can
deduce
that
the
fact
that
we
omit
this
thing
in
here
doesn't
really
prevent
open
id
to
use
implicit
for
id
tokens.
J
I
still
have
a
problem
with
all
this,
because
in
practice
I
have
a
number
of
customers-
people
in
the
community,
people
that
now
look
at
the
software
out
there
that
use
the
form
post
and
just
id
okay.
So
there
is
no
token
whatsoever,
and
now
these
people
have
a
superficial
read
of
spec
and
they
say
well,
I
can
no
longer
do
this.
So
what's
your
alternative?
J
When
are
you
going
to
give
me
a
new
version
of
sdk
and
I
don't
want
to
give
them
a
new
version
of
sdk,
because
sending
eddie
talking
via
forum
post
is
perfectly
fine.
It
has
no
betting
whatsoever
with
the
reasons
for
which
we
are
omitting
implicit
in
here.
So
all
I
need
in
order
to
have
my
life
easier
and
their
life
easier,
is
something
that's
back
which
says:
don't
worry
that
particular
case
is
fine,
and
I
think
that
not
saying
anything
does
not
solve
that
particular
problem.
J
I
think
that
the
last
thing
you
mentioned
in
here
encourage
open
id
to
officially
deprecate
response.
Types
containing
token
is
good
and
we
should
do
it
independently
like,
but
I
think
that
having
some
clarifying
some
clarifying
language
in
here
would
simply
solve
that
particular
problem,
which
is
not
an
imagined
problem
I
had
to
like
I
advertised
this
conversation
already
many
times
since
we're
bcp
so
in
in
here.
J
Just
for
being
a
concrete,
I
think
that
the
number
two
in
that
list
is
the
one
that
would
help
with
the
most
likely
that
would
prevent
that
particular
conversation.
Thank
you.
H
I
mean
the
second.
The
second
bullet
would
basically
mean
that
we
state
that,
just
because
we
remove
token
doesn't
mean
that
our
response
type
are
rendered,
but
we
would
not
take
any
position
regarding
those
response
types.
H
I
personally
think
that
it
would
be
a
much
better
way
if
the
open
id
connect,
a
b
working
group
would
take
the
opportunity
of
the
fact
that
there
is
work
on
waft
blood,
one
going
on
to
develop
a
position
and
also
publish
that
position.
Might
it
be
a
blog
post
or
an
updated
specification
stating
that,
given
the
latest
development
oauth,
for
example,
we
will
continue
to
support
those
response
types
for
the
following
reasons
and
we
will
yeah
remove
other
response
types
for
the
following
reasons.
H
J
This
thing
happens
to
be
under
a
different
institution,
a
working
group,
but
still
we
know
it
is
relevant
for
the
people
that
work
in
this
space
so
asking
them
like.
If
people
only
read
this
document-
and
they
don't
read
all
this
stuff-
that
let's
assume
the
open
id
people
put
out,
then
we
will
still
be
in
the
same
position.
F
I
want
to
push
back
on
that
victorio.
You
know
somebody
implementing
openid
connect
needs
to
read
the
open
id
connect
documents
which
then
refers
to
oauth.
I
don't
think
it
makes
sense
for
oauth
to
refer
up
to
something.
That's
using
oauth.
J
J
Now
what
I
meant
is,
even
if,
once
you
get
it
to
the
implementation,
you
have
also
have
to
go
and
consult
content
from
open
id
connect
in
order
for
you
to
form
an
opinion
and
push
back
on
the
the
use
of
implicit
for
id
tokens.
J
All
you
need
is
to
read
then,
to
read
way,
2.1
and
then,
if
you
also
read
the
open
id
stuff,
then
we'll
be
fine,
but
if
you
don't,
then
you
stop
there,
and
then
you
start
having
discussions
and
escalating
saying
I
need
to
get
rid
of
implicit,
because
these
documents
said
so
then
we
could,
if
we
have
this
stuff
from
open
id,
have
an
easy
answer
and
just
point
them
to
this
documentation,
instead
of
as
we
do
today
engaging
the
thing
is
that
I
would
like
to
avoid
having
the
conversation
all
together.
J
So
just
having
one
line
that
says
and
by
the
way,
the
fact
that
we
don't
mention
this
thing
here
for
access
tokens
does
not
jeopardize
any
of
the
things
that
we
have
that
are
out
there
using
id
token
that
one
single
line
would
be
enough
for
me
not
to
have
all
those
conversations.
Even
if
those
conversations.
F
D
No,
I
I
get
I
get
what
vittorio's
saying.
I
have
a
suggestion
to
maybe
a
question
for
vittorio
right
now.
There
is
no
mention
of
implicit
or
any
response
type
of
things
in
code
in
the
body
of
the
text
or
in
the
security
considerations.
D
It
would
be
nice
to
keep
it
that
way.
Would
it
solve
your
issue
if,
in
the
change,
like
the
changes
from
oauth,
to
section
to
mention
what
you're
talking
about
where
it's
not
part
of
the
the
normative
part
of
the
body,
but
it's
we
already
have
a
section
in
there
called
like
why?
How
is
this
different
from
a
walk,
2.0
and
it
kind
of
lists
things
out?
Would
that
be
an
acceptable
place
for
what
you're
talking
about.
J
Absolutely
it
doesn't
have
to
be
in
the
normative
area
as
long
as
if
it's
in
the
document
like
here,
we
are
talking
about
people
that
don't
know
exactly
all
the
details
of
the
spec
bureaucracy.
As
long
as
it's
in
the
document,
I
do
control
f
on
the
browser,
and
I
find
it.
Where
is
it?
I
don't
care
it
will
be.
It
will
serve
its
purpose,
regardless
of
where
it
is.
H
Yeah,
I
think
we
we
ideas,
also
part
of
the
of
the
spec
mechanics
that
I
think
allow
us
to
do
so,
because
the
response
type
registry
was
defined
by
rc6749.
So
we
can
reflect
on
that.
H
Take
a
look
into
the
registry
and
can
talk
about
which
of
those
response,
types
from
our
perspective
are
removed
and
which
are
no
recommend
no
longer
recommended
for
use
and
which
we
all
think
are
okay,
but
that
needs,
from
my
perspective,
a
cooperation
with
the
openid
connect
working
group,
because
we
need
their
feedback
and
an
agreement
on
that
or
consensus.
I
think
that's
about
a
term.
H
D
D
I
would
be
much
happier
with
the
sort
of
mention
of
the
the
caveats
or
what
it's
not
deprecating,
if
it
weren't
in
the
security
considerations,
if
it
were
only
in
the
change
log
section,
is
that
how
do
you
feel
about
that?
Dick.
D
The
the
sentence
that
victoria's
talking
about
of
saying
that
removing
you
know
leaving
this
response
type
token
out,
doesn't
affect
other
extensions.
That's
something
that
if
we
mention
it
in
the
differences
from
oauth
2
section,
I'm
a
lot
less
worried
about
it
being
mentioned
there
from
the
the
spec
point
of
view.
F
D
K
D
F
The
one
thing
I
was
going
to
say
earlier
was
we
for
sure:
don't
want
people
to
be
confused
about
what
they
can
do,
that
that
what
is
in
oid,
open
id,
sorry
what's
in
oidc's
latest,
doesn't
conflict
with
what
oauth
2.1
says
that
people
aren't
sure
which
one's
correct
so
I'll
agree
with
that.
I
agree
very
much
with
that
part
of
victoria's
statement.
F
Putting
it
in
the
differences
can
potentially
help
something
I
mean
we
just.
I
agree.
We
don't
want
to
say
something:
that's
going
to
make
it
hard
for
other
things
to
do
so.
A
Okay,
aaron,
we
have
five
minutes.
Do
you
have
more
slides,
I
think,
or
is
it.
D
Yeah,
there's
one
more,
I
don't
know
if
we
can,
I
don't.
It
doesn't
feel
like
a
five-minute
discussion
to
me,
so
maybe
I'll
just
bring
it
up,
but
not
expect
to
have
the
discussion
on
the
call.
We
can
continue
the
discussion
on
the
list
instead.
A
So
I
see
somebody
like
roberto
in
the
queue
roberto.
Do
you
have
a
question
about
this
slide
or
the
next
slide.
L
No,
a
general
question
not
for
discussing
now
a
new,
a
new
camera
in
this
great
community,
and
I
was
just
curious
if,
in
doing
this
work,
you
could
consider
in
evaluating
the
latest
http
bs
specification,
because
on
some
issues
like
tls,
the
http
workgroup
made
a
great
work
in
tuning
up
stuff,
around
certificate,
validation
and
further
security
consideration.
L
So
this
is
was
just
dropping
a
rock
in
the
in
the
pot
and
just
think
about
it
and.
L
A
I
I
K
H
D
We
can
remove
yeah,
we
can
remove
response
type
token
from
the
registry
in
this
update
right,
because
that
would
be
not
not
changing
the
you
know,
responsive
id
token,
from
opening
connect
or
anything,
and
that
would
give
it
that
would
give
the
spec
something
to
do
with
the
registry
other
than
just
referencing.
It.
A
Okay,
we
are
almost
out
of
time
and
I
think
vittorio
is
suggesting
one
more
interim
for
2.1
I'd,
be
happy
to
schedule
that
and
see
lots
of
support
too,
for
that
that's
fine
I'll,
try
to
arrange
for
one
to
continue
this,
because
it
was
a
good
discussion
here.
So,
okay,
let's
wrap
it
up,
then
I
will
yeah
any
any.
Last
minute
comments
from
from
urn
and
team.
D
Yeah,
that's
great.
We
have
a
lot
of
work
to
do
and
hopefully
the
next
meeting
will
have
a
bunch
more
changes
to
to
talk
about.