►
From YouTube: IETF113-OAUTH-20220321-1330
Description
OAUTH meeting session at IETF113
2022/03/21 1330
https://datatracker.ietf.org/meeting/113/proceedings/
A
Hi
everyone,
let's
get
started.
B
A
A
Good
okay,
let's
quickly
wave
at
the
remote
participants,
they
can
all
see
us
that's
excellent,
wave
over
there.
So
roman,
can
you
see
us
roman
folks
are
perfect.
D
Welcome
everyone
great
to
see
you
in
person.
Finally,
lots
of
familiar
faces,
some
new
faces
too,
which
is
great-
and
hopefully
this
is
just
a
beginning
of
better
days,
hopefully
more
more
face-to-face
meetings.
So
welcome
to
that
oauth
working
group
and
let's
get
going.
D
This
is
not
not
well
so,
if
you're
not
familiar
with
this,
especially
for
those
new
faces
here,
please
make
sure
to
get
familiar
with
this.
This
governs
everything
that
we
do
at
the
ietf,
and
it's
important
that
you
may
know
this
stuff
right
so
take
your
time
and
and
spend
some
time
looking
at
this.
D
Again
because
this
is
our
first
time
doing
kind
of
a
hybrid
model,
a
type
of
conference,
so
if
you
are
in
person,
make
sure
that
use
you
use
a
meet
echo,
and
this
is
the
on-site
tool.
Please
so,
and
you
will
use
that
to
join
the
queue.
D
Even
if
you
are
in
person
here
and
you
keep
the
audio
and
video
obvious,
obviously
off
and
for
remote
participants
again,
you
can
make
sure
that
audio
and
video
are
off
unless
you
wanna,
present
or
or
say
something,
and
we
highly
encourage
you
that
to
you
to
use
a
a
headset.
D
So
now
we
have
a
few
sessions,
so
this
this
our
first
session
for
this
week,
a
another,
the
other
official
session
is
on
thursday.
At
the
same
time,
we
have
also
two
side
meetings,
one
on
tuesday
tomorrow
at
two
and
one
on
wednesday.
At
six
pm,
everyone
is
welcome
to
attend
again
it's
it's
public
meetings,
so
anyone
can
attend
those
too.
D
A
quick
work
group
updates
first
rfc
9207
was
published,
congratulations
to
danielle
and,
I
think
creston.
I
don't
think
he's
here
right,
congratulations,
guys
and
thanks
for
everyone
who
contributed
to
that
document
and
reviewed
and
provide
feedback,
so
awesome
work.
Thank
you,
a
rfc
edit
queue.
We
have
a
one
jot
response
for
or
tokens
introspection.
I
think
we're
just
waiting
for
this
to
go
through.
We
can't
do
much
about
this.
D
A
worker
consensus
we
have
the
first
one
is
a
christina's
and
mike's
document
is
a
simple
document.
We're
progressed
very,
very
well
very
quickly,
so
we
have
consensus
on
this
one
and
we
will
make
progress
on
this
one
soon.
D
E
D
So
yeah
now
I'm
filled
so
harness
is
halfway
through
this
document,
but
hopefully
we
will
make
progress
on
this
one
soon
eh
on
the
right
document.
We
kind
of
drop
the
ball
in
this
one
and
we
will
pick
it
up
pretty
soon,
so
we
will
start
working
on
this.
One
too.
A
D
I
didn't
see
him
okay,
so
that's
the
update
that
we
have
any
any
questions.
Any
comments
about
this.
D
Okay,
hey!
So
here
is
our
agenda.
Beside
the
chairs
update
mike
sorry,
brian
will
start
oh
go
ahead
mike
so.
F
D
D
So
brian
will
start
with
d-pop.
After
that
I'll
be
talking
about
three
direction.
Attacks
and
aaron
will
will
finish
with
the
oauth
2.1,
so
that's
for
today
and
for
thursday
we
have
a
device
flow
and
peter
we'll
talk
about
this
victoria
will
talk
about
step
up,
authentication
brian
will
be
in
supporting
role
and
daniel
will
be
talking
about
libraries
there
on
on
thursday,
so
yeah.
I
have
lots
of
interesting
stuff
to
to
to
discuss
any
questions
or
comments,
suggestions,
personal
attacks
on
the
chairs.
D
I
All
right
welcome
nice
to
see.
I
Again
here
we
go,
this
is
weird.
This
is
really
weird,
so
bear
with
me,
so
depop
oauth2
demonstrating
proof
of
possession
at
the
application
layer
doing
a
picture
up
here
for
iatf.
This
is
on
the
other
side
of
austria,
though
so
close,
but
not
quite
so
sorry,
it
is
it.
Is
it
just.
I
What
if
I
speak
a
little
louder?
Okay,
I
will
try
to
speak
louder,
all
right
next
slide
man.
This
is
awkward
all
right,
little
expectation
setting
here
I
got
45
minutes,
hopefully
not
going
to
use
it
all
got
a
little
jet
lag
so
again.
Bear
with
me
I'm
going
to
do
a
full
overview
of
the
depop
protocol,
trying
to
note
particular
places
explicitly
where
changes
have
occurred
recently.
I
So
depop
the
objectives
of
depop
really
quickly
and
in
general,
providing
a
pragmatic
application
level
proof
of
possession
mechanism
for
oauth,
2
access
tokens
and
refresh
tokens
when
they're
issued
to
public
clients,
the
pragmatic
was
a
little
bit
qualified
prayer,
it
is
still
pretty
pragmatic,
but
it's
maybe
not
as
simple
as
it
once
was,
and
it's
not
terribly
efficient
because
it
uses
public
key
cryptography
on
basically
every
request,
but
that
is
sort
of
the
price
of
admission
and
where
we've
ended
up
with
things.
I
But
I
wanted
to
point
that
out
and
just
head
it
off
right
at
the
beginning
next,
so
it
has
been
a
while
last
time
we
were
all
together
was
ietf.
106
in
singapore.
Lots
happened
since
that
time
we
presented,
I
believe,
was
draft
three
of
defect.
I
Individual
draft
sometime
later
around
the
beginning
of
the
following
year,
got
a
call
for
adoption,
actually
got
it
adopted.
We've
had
several
drafts
since
really
this
was
just
an
opportunity
to
to
say
hello
again
to
everyone
in
person
and
throw
another
photo
up
here
of
a
nice
ietf
city.
It's
nice
to
be
back.
This
is
weird,
but
it's
really
nice
to
be
back
in
front
of
everyone
and
see
some
faces
inside
and
out
the
meetings.
I
But
since
that
time
give
me
the
next
slide.
We've
published
a
few
things
so
into
the
overview
of
d-pop
in
general.
D-Pop
is
this
proof-of-possession
mechanism
it's
achieved
by
sending
something
we
call
a
d-pop
proof.
Jwt
is
sent
as
an
http
header.
What
this
does
is.
It
demonstrates
a
reasonable
level
of
proof
of
possession
in
the
context
of
the
given
http
request.
I
This
header
is
sent
the
same
way
with
mostly
the
same
syntax
and
semantics
on
both
requests
to
the
token
endpoint
at
the
authorization
server
and
on
protected
resource
requests,
the
as
uses
it
to
bind
tokens
that
it
issues
to
the
the
public
key
contained
in
the
proof
and
the
rs
uses
the
proof
to
verify
bound
tokens
just
an
example
at
the
bottom.
There,
it's
just
a
d-pop
header
and
a
jot
and
a
fairly
simple
illustration
of
the
token
request
includes
the
proof
bound
tokens
are
issued.
I
I
The
general
anatomy
of
a
deep
prop
proof:
here's
the
jot
exploded,
they're
explicitly
typed,
because
that's
one
of
the
best
practices
these
days,
d-pop
plus
jot
using
that
structured,
structured,
suffix,
syntax.
We,
the
ad
part
of
the
normal
job
there.
We
only
it
only
supports
asymmetric
signatures,
part
of
just
the
way
that
it
works,
because
these
keys
are
sort
of
established
almost
like
on
a
trust
on
first
use
basis.
You
present
the
key
and
proof
that
you
control
the
associated
private
key,
so
it
only
really
works
with
asymmetric
signatures.
I
The
actual
key
itself
has
included
the
jwk
header,
and
this
is
the
key
both
the
signature
over
this
jot
will
verify
from
and
that
including
the
content
of
the
jaw,
and
the
request
is
what
proves
possession
of
the
associated
private
key.
I
We've
got
a
jti
just
for
a
unique
identifier
for
following
replay
some
minimal
information
about
the
http
request.
This
is
what
binds
it
to
the
request:
it's
not
a
an
integrity
mechanism
over
the
whole
request
or
anything
like
that.
It's
a
it's
a
minimal
amount
of
http
information
that
just
associates
with
this
proof,
with
that
particular
request
or
a
subset.
K
I
Information
about
that
request,
there's
an
iat,
an
issue
that
time
and
these
proofs
are
then
only
accepted
for
a
reasonable
window
around
the
iit
when
receiving
it.
In
oh
three
draft
of
three,
we
introduced
a
hash
of
the
access
token,
that's
included
there
only
on
protected
resource
access
in
draft
04,
we
introduced
the
server
provided
nonce.
So
if
the
server
challenges
with
the
nonce,
the
client
has
to
follow
up
by
including
the
nonce
and
a
claim
in
the
proof.
I
Next
slide,
please
so
an
access
token
request
when
actually
requesting
tokens,
it's
a
normal
request
of
the
token
endpoint
at
the
authorization
server,
but
a
depop
proof
header
is
included
in
the
request
shown
here
in
purple.
It's
just
a
jot
as
a
header
you'll
see.
Otherwise
this
is
a
normal
authorization
code
request.
I
The
access
token
response
looks
familiar
access.
Token
is
issued
normal
stuff
here
refresh
token,
but
the
response
types
indicates
that
this
access
token
has
been
depop
bound
by
the
inclusion
of
the
depop
value
and
header
for
public
clients,
clients
that
don't
have
credentials
associated
with
this
authorization
server.
The
refresh
token
is
also
bound
to
the
the
public
key
and
the
depop
proof
next
slide.
I
Just
following
up
with
that,
it
looks
the
same.
A
refresh
token
request
is
the
same
kind
of
thing
requested
the
token
endpoint
normal
refresh
token
stuff,
but
the
default
proof
header
is
also
included
here.
The
result
of
this
would
be
since
this
is
a
public
client
there's
no
other
credentials.
This
refresh
token
was
bound
to
that.
I
Next
and
what
an
actual
depop
bound
access
token
looks
like
either
for
job-based
access,
tokens
or
tokens
that
are
introspected,
it's
just
the
cnf
claim
and
in
turn
that
includes
a
sha-256
hash
of
the
jwk
thumb
print
of
the
public
key.
That
was
in
the
proof.
So
basically
it's
binding
this
token
to
that
public
key
through
a
hash
of
the
public
key
included.
In
the
token,
using
the
cnf,
the
confirmation
clam
syntax,
with
a
jkt
for
json
webkey
thumbprint,
I
think,
was
a
little
short
for
tried
to
keep
it's
relatively
compact.
I
It
includes
the
access
token
with
d-pop
as
the
scheme
and
also
includes
d-pop
proof
in
the
in
the
header,
and
what
this
allows
is
this
token,
then,
is
bound
to
the
public
key
in
here
and
part
of
the
validation
includes,
then
validating
the
proof
signature
accepted
and
then
in
turn
validating
that
the
hash
associate
of
the
public
key
in
the
access
token
matches
up
to
the
hash
in
the
in
excuse
me
matches
up
to
the
public
key
in
the
proof
itself.
That's
a
bad
explanation,
but
I
hope
you
get
the
idea
next.
I
So
for
protected
resource
access,
we
have
a
401
with
the
wa
authenticate
challenge
to
indicate
that
depop
is
needed
in
the
case
that
there's
a
protected
resource
request.
Without
any
token,
at
all
again,
it
can
respond
with
a
401
and
depop
is
the
scheme,
and
here
it
can
also
indicate
the
algorithms
it
accepts
for
the
proof
itself.
So
these
are
signature,
algorithms
that
are
acceptable
in
the
depop
proof,
so
the
types
of
algorithms
that
it
can
sign
and
for
a
request.
I
This
is
very
similar
to
the
bearer
scheme,
but
a
little
bit
information
additional
information
is
necessary
for,
like
the
signing
algorithms,
a
response
to
a
protected
resource
request
with
an
invalid
token,
for
whatever
reason
in
this
case
it
was
invalid
because
the
confirmation
didn't
match
the
public
key
in
the
in
the
proof.
So
again
it's
just
a
401,
the
dub
dub.
I
K
I
I
Some
examples
of
how
this
works
is
the
authorization
server
errors
provides.
This
error
code
use
depop,
nonce
and
the
nonce
itself
is
always
included
in
a
header
of
depop
nods.
So
basically,
this
is
just
saying,
try
again
and
include
this
nonce
in
that
element
of
the
proof.
I
When
you
send
it,
it's
a
little
bit
different
on
a
protected
resource
challenge,
because
we
have
the
www
authenticate
in
play
there,
and
in
that
case
it's
the
same
error
code,
but
delivered
as
a
parameter
on
wwe
authenticate,
and
the
nonce,
though,
is
again
delivered
in
the
header.
So
no
matter
where
it
is,
the
nonce
comes
back
as
a
loan
header
and
that's
useful,
particularly
in
the
case
that
you
can
provide
a
new
nonce
even
for
successful
requests,
which
just
tells
the
client
on
the
next
one
use
this
nonce.
I
This
allows
a
more
efficient
means
of
the
server
providing
new
nonces
without
constant
back
and
forth
the
challenges
that
just
looks
like
this:
whatever
it
is,
it's
an
okay
but
a
new
nonce
is
provided,
and
so
in
the
subsequent
request,
the
client
would
use
that
nonsense.
Proof,
rather
than
whatever
the
last
one
it
had
was.
C
I
Some
metadata
the
authorization
server,
so
we
talked
a
little
bit
about
how
the
resource
server
can
signal
the
alg
proof,
algorithms,
that
it
supports
the
authorization
server
can
provide
the
algorithms
it
supports
through
the
use
of
metadata.
It's
just
one.
New
metadata
parameter,
depop
signing
out
value
supported,
and
this
just
signals
support
for
depop
in
general,
at
the
as
by
its
presence,
as
well
as
the
particular
algorithms
that
it
supports
it's
a
array
of
strings
in
drafts.
Five
and
six.
I
We
added
client
registration
metadata
both
for
client
registration
and
for
the
general
sort
of
model
of
client
metadata
is
useful
as
a
as
a
way
of
sort
of
providing
a
common
data
model
for
clients.
In
general,
we
had
a
depop
bound
access
tokens
and
it's
just
a
boolean
value.
That
indicates
whether
this
client
will
always
use
depop
or
not
when
requesting
tokens
from
the
authorization
server.
I
This
felt
like
a
fairly
common
switch
that
might
be
needed
to
enforce
particular
policy
around
one
client
so
say
this
client
is
always
going
to
use
depop
if
it
doesn't
something's
wrong
and
reject
it
next
slide.
Please
thank
you
refund,
so
binding
an
authorization
code
to
a
depop
key
in
draft05,
which
is
relatively
recent.
I
I
This
comes
in
the
authorization
request,
the
as
binds
the
authorization
code
it
issues
as
a
result
of
that
request
after
the
whole
dance
to
that
thumb
print
and
then
on
code
rejection.
It
checks
that
thumb
print
against
the
depop
proof
provided,
in
the
token
request,
otherwise
rejects
it.
This
enables
a
more
end-to-end
binding
of
the
whole
authorization
flow
to
a
particular
depop
key
that
was
lacking
in
prior
versions.
I
If
they're
both
provided,
they
need
to
be
the
same
quick
example
of
what
that
looks,
like
no
scary,
surprise,
but
it's
just
an
additional
header
and
a
get
request
that
would
be
sent
through
the
browser
includes
the
thumbprint
of
the
key
by
that
parameter.
Name
next
slide,
please!
I
So
looking
ahead
next
steps,
ietf
114
is
scheduled
to
be
in
philadelphia,
we'll
see
if
that
happens
or
not,
but
a
couple
of
things
that
are
kind
of
open
right
now
that
I'm
aware
of
one
is
whether
or
not
the
application,
depop
jkt
media
type
registration
is
really
necessary.
This
is
the
pattern.
That's
been
followed
by
a
number
of
of
other
documents,
but
as
I
look
at
it,
it
feels
like
a
bit
overkill
to
actually
go
out
and
register
a
whole
new
media
type
for
this
one
type
of
jot.
I
I
I
So
those
are
two
sort
of
administrative
problems
that
that
I
think
need
to
be
fixed
for
sure,
but
they
are
basically
just
minor
administrative
issues
so
that,
in
terms
of
the
protocol
definition
and
functionality
itself,
I
feel
like
we're
approaching
a
place
where
working
group
last
call
is
a
reasonable
thing
to
start.
Considering
so
I'll
put
that
out
there
are
we
closing
in
on
working
working
group
last
call,
and
yes,
that
is
philadelphia
and
gritty's
from
philadelphia.
D
I
thought
roman
was
trying
to
join
the
yeah
mike
if
you
can
join
the
queue.
Please.
C
Roman
jumping
in
to
help
with
some
of
the
administrative
things:
okay
go
ahead,
please
so,
jumping
in
on
the
middle
one
is
six
authors
excessive
for
the
style.
Yes,
that
is
the
letter
of
the
law
of
the
style
guide.
If
the
working
group
really
feels
that
it's
important
to
to
have
all
of
those
authors,
I
will
support
them
in
that.
We
just
need
to
document
that
appropriately
in
the
shepherd
write-up
and
I
will
carry
and
support
the
group
in
that
decision
through
the
isg.
C
I
Was
very
harsh
about
it,
so
I
was
assuming
we
would
need
to
cut
down,
but
if
you
think
it's
something
we
can
push
through
with
a
little
bit
of
explanation,
that
would
be
great.
C
Yeah
I
mean
we
could
talk
about
this
offline,
but
it's
my
understanding
that
all
the
authors
there
have
very
much
kind
of
contributed
there
and
there's
a
very
tight
story
as
to
why
we
why
we
have
that
list,
and
that
seems
important
to
the
working
group
unless
someone
kind
of
disagrees
with
me,
so
I
will
help
through
the
process
to
make
sure
that
the
document
stays
as
it
is.
With
that
author.
D
D
The
the.
F
Queue
I
I
did,
you
can
see
it
on
the
yellow
screen
there
good
it's
a
beautiful
thing,
nice.
This
is
mike
jones
from
microsoft.
My
memory
of
the
description
of
the
jot
type
claim
is
that
those
are
intended
to
be
media
types
with
a
special
syntax
edition
that
you're
allowed
to
leave
off
application
slash.
F
I
Your
memory,
I
believe,
is
correct.
I
think
that's
right.
It's
just
every
time
I
sit
down
to
do
it.
It
seems
kind
of
crazy,
but
maybe
we
should
just
go
ahead.
There's
also
a
structured
suffix
for
plus
jwt
registered,
but
I
suppose
that
it's
I
wanted
to
think
about
that
sort
of
as
like
a
wild
card
for
you
could
just
go
ahead
and
use
this
as
a
media
type,
but
it
sounds
like
from
what
you're
saying
we
should
just
go
ahead
and
bite
the
bullet
and
do
the
registration
right.
F
N
We
can
hi,
I
I
on
the
registration,
I
would
say
we
should
go
ahead
and
do
it
on
the
working
group
last
call.
I
would
support
to
go,
go
to
the
last
call
within
cisco.
We
are
planning
to
use
this
kind
of
this.
This
solution
for
webex
in
order
to
mitigate
theft,
risk
for
the
tokens
we
use
for
internal
services
and
we've
been
following
this
draft
pretty
closely
and
the
refinements
in
the
five
and
six
and
over
has
been
at
the
point
where
the
returns
are
dimension
diminishing.
N
I
think
it's
good
enough.
I
I
we
think
we
should
go
ahead
with
the
last
last
call
for
this
draft.
D
Yeah,
okay,
so
do
you
wanna,
maybe
then
kind
of
update
the
the
document
based
on
that
discussion
with
mike
and
and
then
we
can
probably
start
our
group
last
call:
okay,
okay,
awesome!
Anything
else!
E
D
Okay,
can
you
hear
me?
Okay,
let's
get
going
so
I'm
gonna
be
talking
about
three
direction.
Attacks
next
slide,
please!
So
this
there
was
an
article
that
prompted
the
whole
discussion
here.
The
the
article
was
talking
about
some
specific
vendors
and
and
issues
around
implementation
of
a
free
directions
and
just
to
be
clear,
those
same
problems
and
issues
that
we
will
discuss
right
now,
not
specific
for
those
vendors,
it's
just
much
much
wider
than
that.
So
next
slide
please!
D
So
let's
talk
about
that.
How
the
whole
thing
starts
with
the
attacker
setup.
Initially,
the
the
attacker
creates
an
account
on
the
victim's
platform,
creates
an
application
of
that
platform
and
it
crafts
an
authorization
request
with
the
goal
of
redirecting
that
user
to
an
application
that
controls
by
controlled
by
by
the
attacker
and
then
send
that
request
to
a
the
victim
through
sms
or
email
or
whatever
right
next
slide.
Please.
D
Is
that
better?
Can
you
hear
me
better?
Okay,
okay,
so
this
is
a
typical,
a
authorization
request.
You
have
a
the
get
request
with
a
response
type,
a
redirect,
uri,
a
scope
and
a
client
id,
and
obviously
the
host
that
hosts
that
endpoint
we're
showing
a
host
name
that
is
shared
between
all
tenants.
Some
other
deployments
will
show
the
tenant
itself
also
in
the
url,
the
issues
applicable
to
either
deployment
right
next
slide.
Please.
D
Okay,
so
let's
talk
about
what
the
rfc
is
talking
about
today
like
what's
how
to
handle
those
error
cases,
so
the
first
part
is
talking
about
a
redirection
uri.
If
there
is
a
problem
with
redirection,
uri
or
a
client
identifier,
then
the
authorization
server
should
inform
the
resource
owner
and
must
not
automatically
redirect
the
user
right,
which
is
good.
That's
what
we
want
right.
D
The
second
part
is
that
it
says
if
the
resource
only
denies
that
request
or
if
the
request
fails
for
any
other
reason,
then
the
authorization
server
informs
the
client
by
adding
some
other
parameters
and
redirecting
the
user
right.
So
that's
the
rfc
today
and
notice
that
it
says
authorization
server
informs
the
client.
D
D
The
first
one
is
if
there
is
a
problem
with
the
request,
there
is
an
invalid
response,
type
or
a
scope.
So
after
the
user
authenticates
and
if
there
is
a
one,
one
of
those
parameters
are
invalid
and
the
and
the
client
id
and
redirect
uri
is
controlled
by
the
attacker.
D
D
So
the
second
one
is,
after
the
user
authenticates.
Typically,
you
will
get
the
consent.
You
have
to
either
confirm
or
decline.
So
in
this
case
it
doesn't
matter
what
you
do,
whether
you
accept
it
or
decline.
It
you'll
still
be
redirected
to
that
attacker.
A
controlled
application
next
slide.
Please!
D
This
issue
is
talking
about
event,
redirection
even
before
the
authentication.
So
this
is
an
example
of
a
a
crafted
message.
It's
just.
The
only
thing
that
there
is
is
a
client
id,
every
other
parameter
is
missing
and
that
and
the
user
redirected
automatically
to
a
specific
application.
D
Okay,
so
this
one
is
the
the
most
challenging
challenging
issue,
probably
that
that
we'll
face
here.
So
this
is
around
silence
a
solid
authentication-
and
this
is
an
oidc,
a
kind
of
specification
which
which
allows
allows
that
that
allow
you
to
check
if
a
user
is
still
authenticated
or
the
consent
is
still
valid,
without
really
prompting
the
user
right
and
again.
In
this
case,
the
user
will
be
redirected
to
that
application
controlled
by
the
the
attacker
next
slide.
D
So
the
question
is:
do
we
need
a
rethinking
here
around
how
to
handle
error
error
error
handling
right,
so
do
we
want
to
say
hey?
The
server
should
always
be
responsible
for
handling
those
error
cases.
D
D
So
what
I'm
looking
for
here
is
that
really
thoughts,
discussions
and
see
what
what
should
be
done
here.
So
that's
that's
my
last
slide
and
looking
for
people
to
line
up
and
have
some
discussion
here.
Any
thoughts.
P
I
didn't
know
if
I
I
didn't
know
if
I
should
just
like
talk
through
meat
echo
or
since
we're
in
the
room
or
what
no,
that
was
a
joke.
That
was
fine
anyway,
so
everything
you're
describing
here
is
kind
of
like
this
is
the
known
trade-off,
the
well-known
trade-off
of
doing
anything
in
the
front
channel.
P
You
know
it's
kind
of
an
inherently
fishable
space
and
you
know
the
the
documents,
especially
the
you
know,
the
updated,
bcps
and
stuff
like
that.
Do
a
pretty
good
job
of
describing
that
not
going
into
exactly
the
specificity
of
these
particular
attacks.
I
agree
so
to
me.
I
I
realize
that
we're
trying
to
ship
as
much
as
fast
as
we
can
adding
a
few
additional
paragraphs
to
the
bcp
to
describe
the
specifics
of
these
attacks
to
me.
That
makes
the
most
sense.
P
I
don't
think
that
this
makes
sense
as
its
own
document
just
talking
about
one
little
description
thing.
If
that's,
what
you're
going
to
do,
you
may
as
well
write
it
in
a
blog
post
and
call
it
a
day,
because
more
people
would
actually
read
it
there,
and
I
don't
think
that
this
really
needs
to
hold
up
the
bcp,
because
I
don't
think
that
this
this
is
really
a
new
attack.
This
is
really
just
a
description
of
how
bad
this
attack
surface
really.
Is
that
we've
all
already
know
about
right
with
just
more
specifics.
Yeah.
F
Mike
jones,
microsoft
justin,
I
like
your
characterization
of
adding
descriptions
of
things
we
already
know.
I
think
that
is
an
appropriate
kind
of
response
to
the
thinking
that
the
working
group
has
done
around
this
and
it's
good
thinking.
Q
Daniel
yeah,
I
agree
that
this
is
probably
so.
The
security
bcp
is
probably
the
right
place
for
this,
but
probably
the
next
version
of
the
security
bcp.
So
I
think
at
some
point
we
agreed
that
we
don't
want
to
add
any
future
attacks
to
the
security
vcp.
D
Q
It
usually
entails
a
lot
of
discussion
and
probably
delay
in
the
already
quite
late
document.
D
Q
F
Mike
jones,
microsoft,
speaking
to
daniel's
remark,
we
still
have
to
go
through
itf
review.
We
still.
K
F
D
R
Apparently,
I'm
the
shortest
one
here:
okay,
hi
aaron
peraki
from
octa
slides
there.
I
don't
get
a
clicker
right.
R
So,
thank
you.
I'm
gonna
give
an
update
on
oauth
2.1
and
talk
about
some
of
the
things
that
have
changed
since
the
last
time.
We've
talked
about
it,
some
of
the
plan
changes
and
then
I've
identified
a
couple
of
issues
to
discuss
either
here.
Since
apparently
we
have
quite
a
lot
of
time
left
or
during
the
side
meetings
for
more
faster
paced
discussion
if
needed.
R
So
since
last
time
we
met
which
was
virtually-
and
I
believe,
october
or
november,
or
so
we've
gone
we've,
we
identified
some
things
there
and
have
done
many
of
those
updates.
So
thanks
to
several
people
who
have
contributed
to
the
document
to
help
make
all
that
possible,
the
tls
has
is
now
mandatory
for
redirect
urls,
except
for
loopback
interfaces.
So
that
was
a
nice
update
to
see.
We've
talked
about
that
before,
hopefully
not
a
surprise.
R
R
So
that's
all
now
consolidated
and
it's
kind
of
just
assumed
right
at
the
beginning
and
then,
instead
of
repeated
all
the
way
throughout,
there's
been
a
lot
more
editorial
clarification
clarifications
based
on
vittorio
and
justin's
extensive
feedback,
as
well
as
some
additional
pull
requests
that
were
submitted
by
other
people
in
the
community.
So
that's
wonderful!
R
Another
big
reorg
that
happened
is
or
is
ongoing.
It's
not
finished
yet.
We've
been
pulling
out
from
the
security
considerations
it
turns
out.
There
was
a
lot
of
things
in
there
that
was
actually
normative
and
that's
not
really
a
good
place
for
normative
text,
so
we've
been
pulling
that
into
the
appropriate
spot
in
the
main
document
and
that
counts
both
texts
from
the
security
considerations
of
6749,
as
well
as
other
drafts
that
were
extensions.
So
that's,
hopefully
easier
to
see
now
as
well.
R
The
another
change
was
the
refresh
token
guidance
so
that
now
matches
the
security
bcp,
which
has
had
already
updated
its
guidance
previously.
So
we're
trying
to
keep
that
in
sync-
and
I
guess
that's
going
to
go
for
the
discussion
we'll
have
this
week
as
well
about
these
redirection
issues,
so
I'll
have
to
roll
that
up
too.
R
I
do.
I
do
think
that
it
makes
the
most
sense
to
essentially
wait
on
the
security
bcp
until
that's
more
or
less
final
and
anything
that
goes
into
that
gets
pulled,
pulled
into
2.1
and
then
a
there
is
a
new
section
which
is
now
in
there,
which
explicitly
mentions
the
implicit
flow,
because
there
have
previously
been
no
reference
to
it
at
all.
There's
a
new
section
in
there
talking
specifically
about
it
explicitly
in
relation
to
openid
connect.
R
It
is
essentially
saying
that
the
implicit
flow,
the
the
oauth
issuing
tokens
from
the
authorization
endpoint,
is
what
is
being
removed
from
the
spec,
rather
than
something
called
the
implicit
flow,
and
that
leaves
the
room
open
for
opendconnect
to
still
define
the
response
type
id
token,
which
is
a
form
of
an
implicit
flow
in
openid
connect.
So
hopefully
that
is
now
clear
for
people
who
are
wondering:
why
is
there?
No
implicit
flow
is
because,
specifically
it's
the
oauth
one
that
we
don't
want
next
slide
please.
R
So
this
is
a
lot
of
work.
There's
still
more
to
do,
and
I
have
been
going
through.
R
Victoria
and
justin's
feedback
have
made
it
through
about
sections
part
way
through
section,
eight
now
we're
getting
into
9
10,
11,
12
and
13..
So
there's
still
a
few
more
sections
left.
Some
of
that
is
started.
Some
of
that
is
still
remaining,
and
that
is
hopefully
we'll
go
through
that
there's
still
more
normative
text
in
the
security
considerations
which
still
needs
to
get
pulled
in
in
line
again.
R
I've
just
been
sort
of
doing
that
slowly
as
I've
been
going
through
the
doc
there's
the
issue
we
identified
at
the
last
meeting,
which
is
expanding
the
there's
a
section
in
there
called
differences
from
oauth
2
and,
as
we
discussed
at
the
last
session,
we
intend
to
be
more
explicit
about
the
changes
that
are
causing
certain
roles
to
do
things
differently
and
documenting
exactly
what
is
breaking
for
who,
since
a
lot
of
the
later
extensions,
do
modify
behavior
of
compared
to
6749
by
itself.
R
There
are
a
handful
of
open
issues
that
is
the
link
to
them,
so
please
go
there
and
read
them.
Essentially,
what
I've
been
doing
is,
as
I've
been
going
through
the
reviews
from
mainly
from
justin
vittorio,
I
have
been
making
a
lot
of
the
suggested
changes
that
are
relatively
straightforward
and
what
I
believe
are
not
controversial
at
all.
Mostly
it's
been
editorial
stuff
anytime,
there's
been
something
in
there.
That
is
something
that
is.
R
There
is
not
a
clear
resolution
to
I've
been
pulling
it
out
as
an
issue
so
that
we
can
actually
track
it
better
and
and
make
sure
we
get
around
to
talking
about
it.
So
there
there
are
a
handful
of
those
in
the
github
right
now
which
we
still
need
to
process.
R
Some
of
that
can
happen
here
in
the
room,
something
that
can
happen
during
the
site
sessions.
Some
of
it
is
probably
better
for
the
mailing
list
so
or
the
github
thread,
so
please
feel
free
to
jump
in
on
those
next
slide.
R
So
for
the
I
guess
I
should.
I
guess
I
should
pause
since
what
I
have
left
for
this
is
a
couple
of.
I
think
it's
three
issues
I
identified
as
things
that
would
probably
be
a
good
good
issues
to
talk
about
in
a
larger
setting
synchronously
now,
but
before
I
go
and
describe
those
and
actually
get
dig
into
this,
do
we
have
any
comments
or
questions
about
the
progress
so
far.
P
Hey
aaron
justin
richard
first
off
great
work.
It
is
no
small
task
pulling
all
of
this
text
together
and
making
it
make
sense.
I
just
wanted
to
if
we
could
go
back
a
slide.
I
just
wanted
to
bring
to
light
a
very,
very
important
point
here
on
number
97
that
that
might
have
been
elighted
a
little
bit
and
that's
that
the
notion
of
what
is
backwards.
P
Compatibility
in
the
tech
in
the
in
the
context
of
oauth
2.1
is
going
to
vary
depending
on
whether
you're
talking
about
compatible
for
a
client
for
an
as
whether
you've
got
a
2o
client
talking
to
a
208
or
to
a
2
1
as
or
vice
versa,
or
something
like
that,
and
so
I'm
I'm
very,
very
glad
that
that
is
a
focus.
That
is
also
something
I'm
going
to.
R
Okay,
then,
let's
go
ahead
and
move
on
to
number
five.
R
Yes,
so
at
the
last
meeting
we
had
brought
up
this
issue,
which
is
this
new
mechanism,
the
iss
response
parameter.
R
R
So
now
we
have
to
have
the
discussion
again.
So
the
idea
with
this
is
it
is
a
security
fix
for
clients
that
talk
to
multiple
authorization
servers.
It
is
a
pretty
straightforward
mechanism,
which
is,
I
believe,
why
it
it
breezed
right
through
the
whole
process
and
moved
through
pretty
quickly
it,
and
it
only
applies
to
clients
that
talk
to
multiple
as's.
So
if
you
are
only
talking
to
one
as
then,
you
can
pretty
much
ignore
this
draft
completely
and
don't
worry
about
it.
R
So
the
question
now
is
now
that
it
is
an
rfc.
Is
it
considered
best
practice
and
if
so,
do
we
bring
it
into
2.1
or,
at
the
very
least,
reference
it
from
2.1
as
either
a
requirement
or
a
possibility
or
etc,
etc?
There
are
now
these
these
questions
to
have.
So
that
is
the
first
first
issue.
Any
thoughts
from
the
room.
F
Mike
jones,
microsoft,
out
of
fairness,
I
was
one
of
the
people
who
said
wait.
It's
now
an
rfc,
I'm
fine
folding
in
guidance
at
least
saying.
If
you're
going
to
talk
to
multiple
authorization
servers,
do
yourself
a
favor
and
present
them
prevent
the
mix-up
attack.
R
So,
along
those
lines,
is
it
a
better
idea
to
incorporate
the
text
of
the
rfc
into
2.1
or
in
the
appropriate
place
reference
out
to
it?
Saying
here
are
some
conditions
go
read
the
mechanism
over
there.
F
As
a
sometimes
editor
I'll
say
include
an
example
of
using
it
in
the
normative
text,
but
I'd
be
fine,
referencing
it
rather
than
pulling
it
all
in.
I
realize
there's
attention
but
because
you're
you
and
the
co-authors
are
correctly
trying
to
create
something.
That's
more
readable
and
I've
gotten
some
additional
feedback
that
it
is
more
readable.
So
you
know
good
for
you
and
good
for
us,
but
it's
a
judgment
call.
A
Q
Q
Daniel
here
from
yes.com
yeah,
so
I
would
also
support
what
mike
said
so,
including
very
brief
guidance
that
you
should
do
that,
and
maybe
also
the
like
the
most
common
case,
which
is
pretty
easy
right.
You
at
the
issuer
there,
but
in
the
rc.
We
also
have
some
guidance
around
what
you
do
when
you
don't
have
this
idea
of
an
issuer
in
your
oauth
deployment
and
so
on.
So
there's
there's
a
lot
more
guidance
around
some
corner
cases
there
or
like
combination
with
jam,
or
something
like
that.
Q
So
therefore
it
would
probably
make
sense
to
to
describe
the
common
case
and
then
refer
to
the
rfc.
For
the
other
cases.
R
Okay,
I'm
happy
with
that,
for
my
own
sake
later
did
that
get
captured
in
the
notes.
I
Sort
of
more
of
a
question
of
brian
campbell
from
paying
identity,
as
you
mentioned,
it's
it
doesn't
apply
to
most
clients
that
are
just
talking
to
1as,
but
the
actual
mechanism
of
doing
it
is
something
the
as
has
to
do
so.
I'm
I'm
a
little.
I
I
was
maybe
wondering
if
you
could
clarify
or
start
thinking
about
how
you
portray
that
in
a
document
like
this,
where
you
it's
the
optionality,
sort
of
condition
on
something
the
client's
doing,
whereas
the
as
is
the
one
that
has
to
support
it
or
not,
or
at
least
be
on
that
side
of
it.
How
are
you
going
to
resolve
that?
That.
R
Is
a
very
good
point:
it
seems
like
probably
the
right
way
to
handle
it
is
to
describe
the
situation
as
if
your,
as
is
likely
to
be
used
by
clients
that
will
support
other
asses.
Then
then
you
need
to
do
this
because
you're
right,
it
is
something
that
the
ais
has
to
build.
Support
for.
I
R
But
I
I
also
think
that's
actually
pretty
realistic
because
I
think
realistically
or
actually
sorry,
there's
another
condition
or
another
call
out
in
the
iss
draft,
which
is
using
separate,
redirect
uis
per
client.
Is
that
correct,
or
per
as
client
can
use
multiple
redirect
uris
per
aes.
Q
Yeah
daniel
here,
if
I
remember
correctly,
we
mentioned
that
this
could
be
used
in
theory,
but
there's
I'm
not
sure.
If
we
even
discuss
this
in
detail
in
the
rfc,
it's
in
a
security
bcp
there's
an
example.
So
there's
more
discussion
on
why
you
could
use
that
to
defend
against
mix-up
attacks,
but
also
why
it's
maybe
not
a
good
idea.
So
there's
some
some
subtle
details
there
that
you
need
to
take
care
of
okay.
Q
R
Sorry,
it
was
a
little
bit
of
a
tangent.
I
was
just
thinking
in
realistically
deployments
are
going
to
likely
either
like
they
tend
to
work
as
a
whole.
There's
there
tends
to
be
nas
that
someone
is
going
to
be
using
and
then
a
bunch
of
clients.
So
I
think
realistically,
it's
not
really
a
problem
in
in
saying
the
sort
of
like
if
your
ass
is
likely
to
be
one
of
many
that
a
client
works
with
in
practice,
then
that's
I,
I
think
it
will
cover
it
realistically.
F
The
iss
parameter
was
kind
of
motivated
by
the
openid
connect
issuer
in
the
first
place,
and
it's
one
of
these
cases,
if
you're
doing
pure
oauth
and
you're
not
doing
connect
all
of
the
supplies.
If
you're
already
doing
connect,
you
already
have
an
issuer,
and
so
the
parameter
would
be
duplicative.
F
R
R
Q
S
Very
excited,
I
seem
to
remember
that
the
part
of
the
discussion
was
that
you
want
to
have
a
effort
in
the
request
without
having
to
dig
inside
the
id
token,
and
there
was
some
reason
for
that
because,
like
there
are
situations
in
which
really
talk-
and
it
might,
you
might
have
to
wait
until
you
decrypt
it
and
instead
having
the
issue
in
the
request.
Even
in
the
case
of
open
id,
was
useful,
because
then
you
were
able,
for
example,
to
know
what
key
you
need
to
use
for
actually
going
inside
ready
talking.
Q
Benefit
so
you
mentioned
that
in
pure
auth.
There's
no
issue
right,
but
I'm
also
that's
probably
a
separate
topic,
but
I'm
also
strongly
advocating
for
always
having
metadata
in
auth
2.1,
which
would
mean
that
you
would
also
have
an
issuer.
Q
M
M
N
R
Okay,
number
101
on
github.
This
is
something
I
discovered
as
I
was
reading
through
the
text.
I
was
copying
and
editing
technically
rfc
6750
requires,
but
it's
in
the
security
considerations
section
that
access
tokens
must
have
a
limited
lifetime.
R
That
is
not
ambiguous.
R
So
this
is
the
reality
today
and
the
question
is:
what
do
we
do
to
reconcile
that
because
it
seems
kind
of
weird
to
publish
a
new
document
that
is
going
to
even
more
clearly
state
that
this
is
not
allowed,
because,
essentially
what
the
reason
I
found
this
was.
R
I
was
going
through
the
security
considerations,
pulling
out
normative
text
in
line
into
the
higher
up
in
the
docs,
so
people
actually
read
it,
and
this
is
one
of
those
things
which
I
think
people
didn't
read
and
then
have
just
ignored
because
it
was
was
in
security
considerations.
So
maybe
the
question
is:
was
this
in
security
security
considerations
because
it
was
not
intended
to
be
a
real?
Must.
R
F
So
as
the
primary
editor
of
6750
mike
jones
speaking
I'll
say
that
I
inherited
a
bunch
of
text
from
another
aaron
and
I
did
with
it
what
seemed
best
at
the
time,
but
I
remember
no
intent
to
have
a
normative-
must
even
be
in
security
considerations.
In
fact,
stuff.
I've
edited
since
that
I've
tried
to
avoid
ever
doing
that,
but
the
isg
didn't
call
me
out
on
it.
P
Justin
richard
to
me,
this
really
like
the
paragraph,
is
still
decent
advice
and
it
should
be
phrased
as
advice.
P
If
you
have
bearer
tokens,
which
is
what
this
whole
section
is
about,
then
it's
a
good
idea
to
not
have
them
live
forever
and
that
can
be
reasonably
interpreted
in
a
number
of
ways,
including
having
a
time-based
expiration,
but
also,
as
you
mentioned
down
at
the
bottom
lifetime,
doesn't
need
to
necessarily
mean
that
it's
time-based,
like
you
know
you
can
expire
based
on
in
or
you
can
be
revoked
based
on
an
event
or
on
suspicion
or
on
client,
deregistration
or
any
number
of
other
things.
P
That's
not
clear
from
this
text,
and
so
I
agree
in
expanding
that.
I
don't
think
that
this
should
have
any
normative
weight
at
all,
though,
because
this
is
this
is
security
advice
about
you
know,
this
is
the
thing
about
bearer
tokens
and
one
way
to
to
limit
the
attack.
Surface
is
to
limit
the
lifetime,
and
so
I
say
get
rid
of
this:
don't
don't
call
it
a
must
or
a
should
or
anything.
P
E
J
Wow
will
it
work?
You
guys
hear
me
yeah,
yes,
wow
kind
of
fun.
I
guess
the
thing
you
know
a
little
bit
to
dustin's
point
that
I'm
sort
of
struggling
with
here
is
half
of
what
we're
trying
to
do
in
oauth.
2.1
is
remove
things
that
are
security.
You
know
bad
practice
right
I
mean
otherwise
we
could
say,
put
don't
use
implicit
flow
in
the
security
considerations
and
leave
it
there.
J
So
if
we
think
that
allowing
forever
access
tokens
is
a
bad
idea,
then
it
seems
relevant
to
me
that
we
put
some
normative
language
around
that
in
the
the
text
I
mean,
as
justin
pointed
out
it
does.
You
know
you
could
limit
it
to
end
uses
or
any
number
of
other
things.
It
doesn't
have
to
be
time
based,
but
I
worry
about
just
leaving
it
open
and
allowing
you
know
bad
practice
to
continue.
P
Oh
justin,
richard
just
to
victoria.
I
think
you
were
yeah.
D
P
Fine,
I
was
just
gonna
say
if
this
does
remain
a
normative
requirement.
I
guarantee
that
I
am
not
going
to
follow
it
because
I
have
active.
I
I
mike
says
that
I
am
a
bad
person.
That's
irrelevant
to
this
part
of
the.
P
Okay
with
this,
because
of
the
way
that
we
have
a
very
sort
of
very,
very
limited
space
in
which
these
tokens
get
that
get
issued,
they're
not
issued
using
6749
tooling
at
all
right,
and
so
that's
a
case
where
we
looked
at
this
and
we
actually
decided
to
implement
these
quote-unquote
forever
access
tokens
for
use
in
this
system,
because
within
our
security
model,
it
actually
makes
sense
for
that
very
very
limited
case.
P
P
R
S
So
a
largely
a
victorio
octa.
I
largely
agree
with
the
spirit
that
has
been
expressed
so
far.
I
think
that
the
intent
there
is
good,
but
the
way
in
which
it's
expressed
is
anachronistic
and
a
bit
simplistic
in
today's
world,
in
which
it's
fashionable
to
do
continuous
authentication.
S
Let's
say
that
again,
they
want
to
use
fashionable
stuff
like
zero
trust
and
similar,
but
if
you
are
using
introspection
for
example,
or
any
other
mechanism
in
which
you
can
deal
with
a
revocation
of
tokens,
one
circumstances
allow
or
circumstances
suggest
that
it's
time
to
do
it
as
long
as
those
circumstances
never
arise,
and
you
are
still
okay
with
the
security
posture
of
the
color
that
stuff
technically
can
live
forever.
I
do
agree
with
george,
but
I
think
about
it.
S
Well,
I
don't
know
if
we
can
have
a
normative
text
because
of
the
nature
of
what
I
just
described.
It
might
be
difficult
to
describe
in
formal
terms
what
that
means,
but
I
do
think
that
we
need
to
help
people
understand
that
they
do
need
to
do
the
work
that
we
shouldn't
just
like
do
a
fire
and
forget
like
here
is
the
talk
and
use
it
forever.
It's
more
of
a
make
sure
that
you
have
a
sensible
criteria
to
decide
whether
this
thing
should
still
be
allowed
to
operate,
or
if
instead
circumstances
has
changed.
S
S
Was
one
example
of
a
token
that
lives
forever
because
somehow,
like
you,
don't
know
what
you?
Maybe
your
user
has
done,
something
that
suggests
that
the
circumstances
are
still
yeah.
I'm
still
trusting
this
thing,
but
it's
just
one
example
like
the
the
example
that
justin
brought
up
is
different,
but.
S
R
I
was,
I
was
trying
to
find
something
normative.
That
is
also
least
less
specific
to
particular
cases,
so
that,
like
what
you're
asking
for
is
don't
don't
hard
code.
These
keys,
such
that
they're,
just
hard-coded
everywhere,
like
make
sure
that
you're
building
a
way
to
revoke
them,
but
the
particular
reason
for
revocation
is
not
something
we
can
normatively
require
like
say
or.
S
S
Like,
for
example,
introspection
is
a
good
way
of
saying
you
must
call
home
or
if
you
don't
want
to
do
introspection,
but
you
want
to
have,
I
don't
know,
allow
lists
or
block
lists
for
your
their
tokens
like.
Ultimately,
I
don't
feel
that
we
can
be
in
a
position
of
imposing
to
people
what's
best
for
their
architecture.
D
J
Yeah,
so
I
think
my
biggest
concern
is
sort
of
what
you
stumbled
across
aaron,
which
is
this
is
in
the
security
considerations
and
probably
nobody
ready.
So
I
I
I
I'm
you
know
I'm
hearing
the
the
difficulty
of
coming
up
with
normative
texts
to
sort
of
imply
the
correct
security
behavior,
but
somehow
I
think
we
have
to
make
it
more
clear
in
the
default
section
of
2.1.
J
Here
are
all
these.
You
know
here's
some
examples
effectively.
You
need
to
protect
the
access
tokens,
as
vittorio
just
said,
and
here's
some.
You
know
different
ways
that
you
can
do
that
right.
There
isn't.
You
know
just
a
reference
to
go,
read
the
section
in
the
security
considerations
so
that
we
hopefully
do
a
little
bit
better
education.
Even
if
it's
non-normative.
G
Okay,
peter
peter
castleman,
microsoft,
so
I
I
don't
have
a
particular
problem
with
this
idea
that
the
lifetime
of
the
token
must
be
limited.
I
actually
think
it's
good,
because
if
you
don't
have
the
notion
of
an
end
state,
you
have
no
way
to
get
there
so
to
vittorio's
point
by
defining
an
end
state.
You
have
to
define
mechanisms
to
get
there
right.
So
it's
revocation
mechanisms,
it's
events.
It
may
be
expiration
times
right.
There
may
be
a
number
of
those
ways.
G
You
may
want
to
consider
giving
guidance
on
what
limit
it
means
right,
so
that
could
be
defined
or
enacted
in
a
number
of
ways.
But
I
think
if
you
omit
it
forever
is
an
incredibly
long
time
right
and
and
often
doesn't
last
more
than
say
a
year
or
five
years
or
something
like
that
right.
So
so
I
think
I
actually
don't
have
problem
with
that
statement.
It's
more
about
how
you
define
limited
and
giving
guidance
to
the
implementers
around
how
they
construct
policies
but
having
the
ability
to
revoke
in
case
something
goes
wrong.
R
R
R
It
actually
has
a
requirement
that
authorization
servers
that
support
the
native
apps
bcp.
All
support
support
all
three
of
these
redirect
uri
methods
for
native
apps,
which
is
private,
ui
schemes.
So
that's
claiming
or
defining
your
own
url
scheme,
and
it
gives
some
examples
of
ideally
using,
like
reverse
dns
based
ones,
but
that's
not
a
requirement
either
claiming
https
urls,
which
is
a
feature
that
ios
and
android
platforms,
support,
and
also
the
loopback
interface
of
just
opening
up
a
port
on
the
device
and
authorization
servers
must
offer
at
least
these
three.
R
So
technically,
if
you
follow
fappy,
you
also
are
not
following
the
native
apps
pcp,
so
that
is
the
current
that
is
currently
the
way
that
it
is
written.
So
now
that
this
gets
brought
into
oauth
2.1,
it
seems
a
little
bit
weird
again
to
say
that
if
you're
following
tapi's
rules,
which
are
meant
to
be
more
secure,
that
you're
then
also
not
able
to
follow
2.1.
Q
Daniel
danielfatiers.com,
I'm
not
sure
if
there's
actually
conflict
there,
because
it
hinges
on
whether
you
want
to
support
native
apps
at
all,
and
I
know
a
couple
of
deployments
that
don't
intend
so
that
intentionally
don't
support
native
apps.
I
think
the
same
applies
to
floppy.
R
Q
Yes,
so
I'm
I'm
not
sure
what
the
exact
wording
is
in
puppy
right
now,
but
yeah.
So
probably
it's
a
good
idea
to
leave
the
door
for
not
supporting
this.
S
I
know
for
sure
that
there
are
customers
that
want
to
get
caught
dead,
supporting
the
loopback
interface
so
having
a
mask
that
includes
the
finger
will
automatically
means
that
those
people
will
be
out
of
compliance.
So
I'm
strongly
in
favor
on
not
having
a
must
in
there.
We
could
get
rid
of
a
loopback.
That
would
be
fantastic,
but
I
know
it
would
be
too
good.
So,
at
the
very
least,
I
would
not
force
people
to
implement
it
if
they
want
to
do
a
native
client.
D
I
I'm
not
sure
what
I
was
going
to
say
now
I
get
closer
to
the
mic.
I
don't
think
there's
neces
it's
not
uncommon
for
profiles
like
fappy
or
otherwise
to
further
narrow.
What's
allowed
based
on
other
things,
I
mean,
for
example,
fappy
disallows
client
secret
authentication,
which
is
required
by
the
base.
So
I
don't.
K
I
That
said,
though,
I
I
think
the
way
that
this
text
is
being
pulled
from
a
bcp
about
a
very
narrow
context
and
over
it
would
probably
be
better
to
somehow
qualify
it
with
not
must
or
under
the
conditions
that
you're
supporting
native
apps.
You
should
do
these
things
yeah,
so
it's
both
it's
both
okay
and
I
think
you
should
change
it
great.
If
that
makes,
if
that
makes
sense,.
T
Money
hub
yeah,
I
I
kind
of
agree
with
what
brian's
saying.
I
definitely
think
the
wording
needs
to
be
changed.
I
mean,
if
I
understand
compliance,
you
know
it's
only
if
I
fully
support
native
apps.
I
need
to
rough
all
three.
So
maybe
if
I
want
to
support
not
fully
native
apps,
I
get
a
new
support
too.
So
I
think
it
definitely
needs.
The
wording
is
a
bit
strange.
T
T
That
would
just
be
my
suggestion
and
I,
but
also
if
we're
trying
to
make
things
more
secure
unless
there
are,
is
a
good
reason
to
support
the
the
pri
private
uri
scheme,
then
maybe
that
that
should
be
excluded,
because
you
know
the
reason
we
exclude
it
in
fappy
was
because
of
you
know
the
fact
that
in
you
know
many
the
mobile
systems,
you
know
different
apps
could
claim
the
same.
R
Yeah,
that's
another
option
is
to
to
require
claimed
url
schemes
and
loopback
and
make
the
private
uri
scheme
optional.
Just
mention
that
it's
a
possibility
or
just
not
require
not
require
any
of
them.
I'm
I
I'm
kind
of
curious
what
the
reason
actually
was
for
the
requirement
of
offering
all
three
of
them
in
the
first
place,
and
I
kind
of
suspect
it
was
a
optimistic
attempt
at
interoperability,
which
kind
of
seems
like
maybe
that
wasn't
the
right
goal
for
that
feature.
D
J
Yeah,
so
I'm
I
think,
I'm
in
favor
of
not
explicitly
forcing
authorization
servers
to
support
all
these
mechanisms,
and
I
am
in
favor
sorry
I
am
in
favor
of
ordering
them
by
best
security
practices
right,
so
we
should
be
telling
people
use
the
claimed
http
https,
urls,
right
and
and
unless
you
have
a
really
good
reason
to
do
something
else.
Just
don't
right.
You
know.
If
you
have
to
support
some,
you
know
legacy
version
of
os
that
maybe
doesn't
support
it
or
whatever.
J
Well
then,
you
know,
maybe
you
have
to
right
and
you
have
a
really
good
reason
for
it,
but
otherwise
I
think
we
should
be
pushing
people
toward
the
secure
options
which,
at
this
point
is,
you
know,
claim
https
urls,
and
you
know
whether
we
want
to
put
other
you
know
guidance
in
here
around
other
ways.
You
know
that
the
os's
are
now
supporting.
You
know
to
get
app
at
the
stations,
that's
probably
a
different
topic,
but
in
this
particular
case
I
would
much
prefer
we
sort
of
push
people
toward
the
secure
solution.
R
In
the
draft
reorder,
the
the
list
claimed
https
urls,
first
loop
back,
second,
private
private
url
schemes;
third,
just
at
least
make
sure
they're
ordered
that
way.
R
And
then
just
remove
the
sentence
that
says
that
they
must
the,
as
must
support
the
three,
because
nobody
cares
about
that
requirement.
Apparently
is
what
I'm
hearing
and
then
maybe
some
fiddling
about
explaining.
Why
they're
in
a
certain
order
or
whatever,
but
I'm
seeing
some
just
removing
the
the.
R
Url
first
loopback
second
private
ui
scheme
at
the
bottom,
maybe
even
adding
in
some
text
about
why
you
would
want
to
support
it
at
all,
just
to
better
set
the
context.
Yeah,
I'm
happy
with
that.
Okay,
good,
I
believe.
That's
the
last
slide.
R
Oh
just
okay!
Yes,
so
those
are
the
three
that
I
want
to
talk
about
today.
I
felt
like
they
were
more
complicated
than
a
lot
of
the
other
ones
and
requires
more.
R
Joint
thinking
power,
so
there
are,
however,
a
lot
more
things
to
talk
about.
This
is
not
done,
and
I
would
very
much
appreciate
more
of
the
discussion
happening
asynchronously
on
those,
so
the
list
I'm
keeping
track
of
is
here.
That
is
where
anything
that's
open
is
still
I'm
going
to
close
it
at
some
point,
one
way
or
another,
but
before
this
is
considered
done,
if
you
want
to
to
chat
on
github,
that
makes
it
very
easy
for
the
editors
to
keep
track
of
the
discussion.
R
D
R
Yeah,
I'm
happy
to
sort
of
post
the
state
of
the
state
of
the
draft
to
the
mailing
list
to
let
people
know
what's
going
on
and
call
out
some
of
those
issues.
I
do
feel
like
some
of
the
issues
are
relatively
minor,
so
I'm
less
concerned
about
about
the
the
whole
mailing
list
record
for
some
of
them.
Obviously,
some
of
them
are
a
little
bit
more
substantive,
okay,.
D
I
Sorry
yeah
only
just
followed
up
this
morning,
but
back
at
the
end
of
last
year
there
was
a
threat
on
the
mailing
list
about
the
credentialed,
client
type
and
kind
of
nothing
ever
happened,
and
it
was
not.
Nothing
was
done
in
the
latest
draft
about
it,
and
so
I
wasn't
sure
if
that
was
a
forgotten
about
or
a.
K
I
B
R
Had
completely
forgotten
about
that
issue,
I
guess
my
recollection
of
that
thread
was
that
there
was
some
discussion
and
no
real
resolution
to
the
mailing
list
thread
either.
So
I
think
that's
why
it
sort
of
died
out.
Was
it
just
got
lost
right.
A
Having
an
issue
wouldn't
hurt
right,
yeah,
you.
R
A
G
R
Definitely
definitely
it's
so
hard
to
go
back
to
the
mailing
list
and
find
all
of
the
threads
that
are
relevant
to
this
draft,
so
yeah.
If
you
want
to
file
it
as
an
issue,
then
we'll
it'll
make
sure
that
it's
tracked.
It's.
G
R
R
And
then
we
can
pick
up
the
mailing
list
site
again
too.
If
you
want
to
talk
about
it
there
or
we
can
talk
about
it
now,
because
we,
I
think
we
still
have.
I
A
Like
if
you
guys,
when
I
go
ahead,
all
right,
no
problem
for.
I
R
I
R
I
I
I
Around
it,
outside
of
the
section
that
it
was
defined,
qualifies
every
single
usage
of
it
is
confidential
or
credentialed
client
must
do
this
confidential
or
credential
client
has
to
authenticate,
so
they
are
treated
as
synonymous
throughout
the
document,
just
with
more
words.
I
So
I,
the
suggestion
from
me-
and
I
think
others
sort
of
backed
it
up-
was
to
get
rid
of
the
distinction
entirely
and
provide
some
somewhere
any
discussion
around
the
various
levels
of
trust
and
establishment
and
pre-registration
and
so
forth.
In
that
I
forget
what
it
is.
2.4
section
describe
the
the
nature
of
it,
but
keep
the
two
types
as
they
are.
U
D
R
The
brian
did
a
very
good
summary
of
the
of
the
state
of
the
issue
anyway,
that
was
that
was
a
good
recap
of
it,
my
so
the
original
text,
that's
in
there
every
time
you
see
the
or
credentialed
and
the
new
text
previously
said
confidential
clients
or
clients
with
credentials,
which
I
I
personally
thought
was
more
confusing
because
elsewhere
it
says
confidential
clients
have
credentials,
otherwise
a
public
client
doesn't
so
that
was
what
it
was
trying
to
reconcile
was.
R
There
is
like
there
is
something
between
the
two,
because
apparently
we
can
have
confidential
clients
or
clients
that
have
credentials
that
are
not
confidential
clients
and
that's
already
in
the
original
draft.
So
that's
what
it
was
trying
to
do.
So
if
I
agree
that
maybe
the
like
it
could
use
some
more
clarification
around
the
conditions
under
which
a
client
may
have
credentials
that
are
not
it's
not
a
confidential
client.
D
P
Justin
richards,
so
brian's
not
entirely
wrong.
The
the
term
is
a
is
definitely
a
bit
confusing.
That
said,
aaron
is
100
correct
that
we
have
more
than
just
confidential
client,
which,
in
the
67
49
days
was
statically
configured
you
know
hand
registered.
Somebody
called
a
sysadmin
to
go,
set
up
a
config
file
somewhere
type
of
client
and
then
public
client,
which
was
just
you,
get
a
client
id
by
calling
the
sysadmin
and
having
them
set
that
up
without
a
client
id
and
that's
it.
P
We
don't
live
in
that
world
anymore
and
I
think
it
is
very,
very
important
for
oauth
2.1
to
not
only
acknowledge
that,
but
also
to
like
embrace
that
I
personally
kind
of
like
the
direction
of
credentialed
client
as
sort
of
being
situated
in
between
that
said.
I
think
we
may
want
to
approach
this
in
a
slightly
different
way
in
that.
P
If
the
definition
of
confidential
client
is
simply
a
client
that
has
a
secret
that
it
can
keep
right.
So
a
a
client
secret
or
a
key
set,
or
something
like
that
and
public
client
does
not.
So
it's
a
bit
of
an
expansion
and
clarification
of
the
original
definitions.
Without
all
the
assumptions,
then
there
is
an
orthogonal
dimension
of
how
that
confidential
client
making
sure
I'm
using
the
right
terms
how
that
confidential
client
came
into
possession
of
its
secrets
and
under
what
circumstances?
P
That's
what
I
think
credential
client
was
trying
to
capture,
but
by
putting
it
on
that
same
dimension,
I
think,
may
have
been
a
little
confusing,
so
I
think
we
might
actually
be
able
to
have
a
better
and
more
thorough
discussion
by
sort
of
expanding
the
the
reach
of
what
confidential
client
actually
means
and
making
sure
that,
when
we're
talking
about
condo
financial
clients,
if
we
mean
one
specific
sub
category
of
that,
then
we
name
that
subcategory,
because
there
are
different
security
considerations
that
you
have
for
statically
pre-registered
web
servers
versus
a
a
mobile
app
that
gets
a
secret
provisioned
on
install,
as
part
of
you
know,
an
install
framework
versus
something
that
does
a
full
off-the-street
dynamic
registration
versus
the
whatever
the
you
know.
P
All
of
these
are
very
different,
takes
on
how
to
get
to
that
state,
with
the
goal
still
being
to
get
to
the
state
where
an
individual
instance
of
a
piece
of
client
software
has
access
to
a
secret
that
can
authenticate
that
instance
of
client
software,
and
so
I
think
what
we
might
be
able
to
do
is
to
back
off
in
all
of
the
places
that
say,
you
know
confidential
or
credentialed
or
whatever
just
say
confidential
in
all
of
those
places,
and
then
in
our
definition
and
discussion
of
what
confidential
means
and
how
you
get
there.
R
P
Yes,
absolutely
and
bike
shedding.
All
of
those
categories
is
going
to
be
a
mess
there.
I
don't
think
there's
any
way
around
that.
I
think
that
having
named
categories
is
going
to
be
very
helpful
for
all
of
those
and
credentialed
client
was.
It
was
a
good
stab
at
that
to
help
some
of
that
differentiation.
R
Okay,
I
see
where
you're
going
with
that
for
sure
I
think
that's,
I
think
that's
doable.
D
I
So
I
would
unfortunately,
for
what
they
are
I'd,
prefer
them
not
to
be
changed,
and
then
it
comes
down
to
just
better
explaining
them,
and
I
think
that
orthogonal,
access
of
trust
that
that
justin
described
works
and
gives
people
the
knowledge
that
they
need.
But
it's
not
like
you
wouldn't
authenticate
a
client
with
credentials
just
because
of
the
way
it
was
initially
established,
you're
still
going
to
check
those
credentials
you're
still
going
to.
I
So
it
doesn't
back
to
what
I
said
before
it
doesn't
change
sort
of
the
functional
places
where
you
refer
both
of
them
and
say
they
have
to
authenticate,
but
just
a
description
of
how
sort
of
the
provenance
or
the
trust
and
the
application
or
client
comes
to
be,
as
that
orthogonal
access
of
of
yeah
words
that
you'll
come
up
with
that
are
better
than
what
I'm
saying.
R
One
of
the
one
of
the
other
attributes
is
around
whether
or
not
the
user
gets
prompted
for
consent.
There's
an
explicit
mention
that
says
public
clients
should
be
should
always
be
prompted,
even
if
it's
like
a
first
party
client,
if
there's
something
around
those
lines
or
was
the
other
way
around
of
confidential
clients
might
want
to
skip
the
consent
phase.
I
don't
know
which
one
it
was
and
now,
but
it's
it's
not
just
about
the
authentication
of
the
client.
It's
about
other
implications
of
how
much
that
client
is
essentially
trusted
by
the
as.
B
I
So
yeah
there's
probably
more
touch
points
for
clarity,
but
but
the
same
thing
applies,
I
think
you
know
a
client
that's
registered
through
an
open
portal.
Anybody
can
is
no
different
than
a
client.
That's
registered
via
open,
dynamic,
client,
registration
versus
dynamic,
client
registration.
That's
done
through
some
sort
of
you
know,
bespoke
access
token
issuance
to
get
in
there
in
the
first
place
is
more
trusted.
Maybe
then.
T
Yeah
dave
song
money
hub
yeah,
I'm
basically
just
just
to
agree.
We
we
had
a
few
issues
and
people
asking
okay.
What
what
is
this
credential
client
and
trying
to
look
through
the
current
draft
to
see
what
you
actually
have
to
do
differently
and-
and
apart
from
that
initial,
do
you
trust
the
identity?
T
That
seemed
to
be
only
the
only
thing
as
far
as
I
could
see
so
yeah,
I
just
very
much
agree.
I
think
if
we
can
keep
it
simple
and
then
just
call
out
this,
you
know
I
think
brian
made
a
really
good
point.
It's
not
all
confidential
clients
are
are
equal
either.
In
terms
of
you
know
how
much
trust
there
is
whether
they're,
just
yeah,
registering
so
yeah
very
much
agree
with.
What's
said
before
great.
D
J
I'll
just
add
I
I'm
in
agreement
the
dynamic
client
registration's
back
57-91.
J
No
sorry
75-91,
I'm
dyslexic
this
morning,
basically
implies
that
when
you
go
through
dynamic,
client
registration,
you
have
a
confidential
client
that
uses
the
word
confidential
client
in
a
few
places
based
on
the
response,
so
you
know,
I
think,
potentially
to
brian's
point.
Keeping
those
words
to
represent
those
class
of
clients
makes
sense
so
that
we
don't
introduce
a
new
term,
but
all
of
the
other
points
are
super
valid
right.
Just
because
you
have
a
confidential
client
doesn't
mean
that
it's
trusted.
It
just
means
that
it
can.
J
You
know
accurately
authenticate
itself,
and
you
know
the
other
things
like
you
know.
Should
you
show
consent
or
not,
you
know
probably,
could
apply
even
to
some
kind
of
confidential
clients
if
they're
not
trusted
in
the
sense
of
an
open,
you
know
dcr
kind
of
a
model,
so
there's
a
lot
of
implications.
There.
V
D
V
Going
I
just
wanted
to
say
that
it
might
be
better
to
define
new
terms,
possibly
multiple
terms,
to
define
different
facets,
because
otherwise,
everywhere
we
use
public
and
confidential.
We're
going
to
have
to
revisit
those
such
as
registration
to
make
sure
the
older
term
breaking
anything
to
work
on
them.
D
I
I
Maybe
if
I'm
wrong
about
that
david-
and
I
would
I
would
flip
it
the
other
way,
because
these
terms
are
used
throughout
a
number
of
documents
that
are
not
touched
directly
by
oauth
2.1,
but
will
still
be
compatible
with
2.1
and
it's
all
of
its
framework
as
bad
as
the
names
are.
I
think
they
should
remain
the
same
so
that
they
don't
introduce
further
breakage
or
confusion
with
with
those
documents.
S
S
Many
systems
are
predicated
on
the
idea
that
a
confidential
client
is
a
singleton
and
the
infrastructure
and
the
service
and
the
programming
model
which
is
offered
to
the
developers
is
based
on
that
and,
in
fact,
the
confusion
tied
to
that
is
also
observable
when
people
try
to
use
such
systems
for
iot
or
similar
in
which
they
try
to
distribute
the
credential
to
clients
but
to
a
scale
which
wasn't
designed
for
so
long
story
short.
S
I
think
that
if
we
decide
to
generalize
the
term
of
confidential
client
to
anything
that
has
a
credential
with
no
regard
with
whoever
is
singleton
or
not.
However,
the
assignment
of
this
credential
was
done
in
a
circumstance
in
which
you
would
have
some
I'd
say:
extra
insurance
that
you
knew
something
about
the
registrar.
S
Then
I
think
that
we
we
needed
to
like
convince
ourselves
that
we
will
not
break
or
that
we
will
not
create
even
further
confusion
and
potentially
contradict
ourselves
because,
like,
although
we
never
said,
I
believe
anywhere,
that
this
thing
represents
a
single
tone.
S
Originally,
this
thing
was
websites
which
were
naturally
and
then
everything
else
was
somewhat
derived
from
that.
So
long
story
short,
I
guess
I'm
saying
I'm
a
bit
worried
about
making
that
sweeping
generalization
because
of
the
potential
side
effects
and
given
that
have
a
mic.
S
I'll
also
say
that
to
me,
it's
odd
that
we
might
say,
excuse
confidential
clients
from
showing
consent,
but
instead
asking
to
public
clients
to
do
so
because
public
clients
today,
unless
you
use
the
tricks
like
urls,
claim
the
urls
and
similar
very
travesty,
like
you
can
use
whatever
client
id
you
want
and
pretend
to
be
someone
else
so
asking
for
a
consent
in
that
particular
case,
in
which
you
have
very
little
confidence
that
the
bits
that
are
running
are
actually
representing.
S
The
thing
that
was
registered
as
a
client
seems
somewhat
contradictory,
but
that
was
an
aside.
The
tldr
is,
let's
be
careful
about
generalizing
what
the
confidential
client
is.
D
I
I
think
it's
it's
pretty
widely
accepted
that
confidential
clients
are
those
with
credentials,
regardless
of
how
they've
gotten
them
and
again,
I've
certainly
written
a
number
of
documents
that
say
that
and
rely
specifically
on
that.
So
I
don't
think
we're
redefining
anything
and
provenance
of
trust
and
chris,
like
the
reason
right
or
wrong.
The
reason
that
lack
of
consent
has
allowed
for
confidential
clients
is
because
the
picking
up
of
the
actual
what's
consented.
The
access
tokens
is
restricted
to
that
client.
I
Yes,
the
initial
authorization
request
can
be
anything
but
because
they
have
to
authenticate,
because
the
callback
only
goes
to
a
registered
url.
That's
why
they're,
allowing
for
that
that
part
to
be
skipped,
at
least
in
the
text,
I
believe,
is
what
it
said.
So
it's
not
quite
the
right
comparison
unless
I'm
missing
something.
S
Ahead,
thank
you
so,
on
the
whether
it
matches
the
reality,
I'm
not
sure.
Let's
say
that,
that's
what
we
might
have
a
place
on
the
specs,
but
if
you
look
at
practical
usage,
for
example,
if
you
look
at
what
some
of
the
twitter
clients
do
when
you
install
it
on
windows,
that's
a
public
client
as
in
it
has
the
same
id
in
every
installation.
But
then,
in
the
moment
in
which
you
install
this
thing,
you
get
a
key,
so
you
still
have
one
entry
but
and
it
behaves
like
a
public
kind.
S
It
is
a
public
client
is
a
native
thing
running
on
the
desktop,
but
you
do
get
a
key.
So,
although
we
might
not
have
to
say
formalize
that
particular
flow,
but
that
thing
behaves
just
like
the
credentialed
client
that
you
attempted
to
place
into
that
one.
So
I
think
it's
a
bit
more
advanced
than
the
reality
is
like
that.
Anything
that
has
a
credential
is
a
confidential
client.
In
reality,
in
fact,
like,
I
think
there
are
a
number
of
practical
example
in
which
that
is
not
the
case.
R
I
think
the
I
think
what
you
just
said
was
actually
relevant
to
the
thing
that
justin
mentioned,
which
is
that
the
the
other
factors
of
what
the
system
is
doing
with
this
client
is
what's
dependent
on
how
that
that
secret
was
obtained,
and
the
fact
is
that
it
has
a
secret
and
most
of
the
things
in
the
spec
are
things
like
if
you
have
a
secret
use
it
things
like
that.
So
I.
J
J
Ahead.
Okay,
so
I
I
guess
I
don't
want
public
clients,
and
maybe
I'm
misunderstanding,
what
you
were
saying
victorio,
but
I
don't
want
public
client
definition
to
me,
a
native
app
right,
because
if
my
client
on
the
native
app
can
basically
create
a
public
private
key
pair
where
the
private
key
isn't
stored
in
the
tpm
of
the
device
right
and
and
then
it
can
use
that
for
proving
its
identity
when
it
makes
calls.
I
don't
think
that
should
be
considered
a
public
client
in
in
that
context.
J
J
So
if
the
client
can
protect
a
secret
and
when
we
were
talking
about
dynamic,
client
registration,
you
know
the
expectation
was
the
secret
is
instant
specific
and
therefore
it
can
kind
of
protect
it,
because
it's
the
secret
itself,
is
not
embedded
in
the
binary
someone
to
get.
It
would
have
to
jailbreak
the
device
itself
to
get
access
to
the
instant
specific
piece.
J
Then
that
would
be
considered
a
confidential
client.
So
you
know,
maybe
the
problem
we
have
here
is
that
we
have
a
bunch
of
you
know
different
interpretations
of
what
these
terms
mean,
and
you
know
we're
trying
to
sort
that
out
and
it
has
ripple
effects,
as
brian's
pointed
out
against
existing
specs.
But
I
you
know
that
has
been
my
interpretation.
Confidential
clients
are
ones
that
can
successfully
protect
the
secret
public.
Clients
are
ones
who
can't,
regardless
of
where
they're
running.
S
Go
advertor
great,
so
I
think
that
this
this
discussion
is
really
an
excellent
example
of
clearly
we
have
different
points
of
view
and
different
interpretation
of
how
this
thing
went,
because
for
me
being
very
pragmatic
and
having
to
deal
from
the
developer
side.
The
main
difference
is
that
there
is
only
one
twitter
website,
but
there
are
millions
of
twitter
installations
like
everyone
on
the
phone,
everyone
instance
and
then
whoever
tweeter
decides
that
they
want
to
identify
a
particular
instance
or
not
it's
up
to
them.
S
So
I
can
model
the
twitter
client
using
a
public
client,
and
then,
if
I
want
some
extra
guarantee,
I
can
find
a
way
of
also
assigning
a
key
so
that,
although
I
still
have
the
same
client
id
and
the
current
id
is
the
thing
that
deals
with
the
nature
of
a
client.
I
have
those
extra
guarantees
in
which
I
can
recognize
the
instance.
Now
I
can't
claim
that
this
is
a
normative,
because
this
stuff
is
not
covered.
S
All
I'm
saying
is:
this
is
the
way
in
which
I've
been
operating
and
helping
customers
model
things
or
observing
others
modeling
their
own
system.
To
me,
this
just
points
to
the
fact
that
if
we
go
in
the
direction
of
saying
no
now
we
formally
want
to
say
that
anything
that
has
a
credential
is
a
confidential
client.
Then
we
need
to
be
explicit
and
saying.
S
Okay,
if
you
were
doing
the
thing
that
I
just
described
in
which
you
have
those
enhanced
public
clients
in
which
you
can
recognize
the
instances
of
a
client,
but
we
all
have
the
same
client
id.
You
need
to
distinguish
these
from
singletons,
in
which,
when
you
have
a
website,
then
it's
just
one,
and
so
let's
use
it
a
different
way.
Let's
call
it
the
confidential
client,
plus,
plus
or
max
or
365,
depending
on
the
company,
but
like
yeah,
perfect,
so
yeah
just
wanted
to
qualify.
P
Oh,
the
microsoft
jokes
in
this
room,
justin
richard
once
again,
I
think
victoria
that
sorry,
you
were
saying
all
lunch
about
how
everybody
gets
your
name
wrong,
and
I've
known
you
for
years.
I
think
vittorio
and
I
actually
do
agree
violently
in
different
directions,
so
everything
that
he
just
described
about
how
you
have
the
special
class
of
a
public
client.
That's
not
acting
like
a
public
client.
P
I
would
call
that
a
confidential
client
that's
not
acting
like
a
statically
registered
confidential
client
and
that's
why
I
really
think
we
do
need
this,
this
different
dimension.
In
order
to
talk
about
these
things,
I'm
with
george
and
with
the
the
language
that
we
have
in
dynamic
registration.
That
said,
once
you
get
the
credential,
then
you
are
a
confidential
client
like
that
was
that
was
one
of
the
the
selling
points
of
dynamic
registration
was.
P
It
was
take
your
public
client
and
turn
it
into
a
confidential
client
in
a
way
that
oauth
could
actually
think
about
it.
Being
a
confidential
client
with
all
the
security
caveats
that
this
is
not
the
same
as
a
statically
registered
one
and
then
with
software
statements
and
registration,
jots
and
all
of
that
other
stuff
people
have
bootstrapped
a
lot
of
other
layers
of
trust
on
on
top
of
that
as
well
to
have
even
more
gradients
here
of
trust.
P
P
That
should,
however,
not
be
part,
I
would
argue
of
the
definition
of
what
makes
a
public
or
confidential
client
right,
because
if
I
decide
to
give
everybody
the
same
client
id
everybody
in
the
world,
the
exact
same
client
id
and
differentiate
them
based
on
their
keys.
Instead,
I
could
write
that
system.
It's
kind
of
a
dumb
idea
in
oauth
world,
because
so
much
is
leveraged
on
the
client
id
that
public
identifier.
P
What's
that
yeah?
That's
what
twitter
did?
That's
what
that's?
What
a
bunch
of
other
things
out
there
have
done,
and
google
did
google
did
that
back
in
the
oauth
one
days
as
well,
with
their
weird
ex-off
extension
thing,
whatever
that
was
called
regardless.
The
point
being
that
I
don't
think
that
this
should
be
wrapped
around
the
client
identifier
at
all.
P
I
do
think
that
it
does
make
sense
to
collapse
down
to
these
two
categories.
If
we
can
then
have
this
larger
discussion
about
how
you
got
into
that
category,
that.
R
Is
really
what
I'm
hearing
is
that
there's
a
lot
of
factors
about
clients
that
you
want
to
treat
differently
depending
on
a
lot
of
different
things,
none
of
which
have
to
do
with
whether
or
not
it
has
a
secret?
Yes
exactly,
and
it
applies
to
both
clients
with
and
without
a
secret.
All
those
factors
apply
to
both
clients.
So
I
don't
know
it
seems
like
it
seems
like
there's
two
different
issues
going
on
one.
R
I
agree:
let's,
let's
simplify
the
terms
and
then
two
there's
a
lot
of
stuff.
We
need
to
talk
about
like
there's
more
things,
to
add
about
these
different
considerations
and
everything
that
I've
heard
is
definitely
like
a
good
thing
to
to
bring
in
as
a
hey.
If
you
know
you
have
the
situation-
and
I
think
some
of
that
exists
in
the
current
draft,
but
it
was
more
more
tied
to
the
public
or
confidential
type
which,
as
we've
seen,
is
not
actually
the
correct
place
to
tie
it
right.
P
So
yeah
we
should
be
making.
We
should
be
making
distinctions
when
there
actually
is
a
difference
between
things
and
in
a
lot
of
the
discussion
that
I've
noticed
here
today.
A
lot
of
the
decisions
being
made
are
actually
decisions
that
are
on
top
of
the
oauth
protocol
and
not
within
the
oauth
protocol
itself.
P
R
So
vittorio's
concern
was
ripple
effects
of
redefining
the
term
and
I
think
that's
something
that's
worth
paying
attention
to,
but
I
don't
necessarily
think
it's
a
deal
breaker.
I
don't
think
it's
something,
that's
good
that
we
should
stop
and
revert
this
plan
so
proceed
with
caution
and
I'm
happy
to
keep
that
in
mind
as
we
work
on
these
changes.
Okay,
we
have
two
minutes
here
and
I
want
to
allow
george
to
get
into
the
mic.
J
George
sure
I'll
be
real,
quick.
I
think
victoria
your
model
is
a
really
interesting
one
and
actually
surprisingly
one.
I
heard
right
when
I
think
about
dynamic,
client
registration.
I
always
think
about
issuing
each
instance
of
a
client,
its
own
client
id
and
specifically
that
so
that
I
can
block
that
particular
client
instance
separated
now
you
could
do
that
by
the
key
as
well
right.
So
I
would
like
you
know
I
guess
for
me
the
question
is:
where
do
we
have
these
larger
conversations
about
models,
because
I
think
it's
super
important
right.
J
We
probably
have
some
best
practices
or
some
patterns
for
the
way
things
are
implemented,
and
you
know
does
that
go
into
a
spec.
Do
we
pull
that
out
into
something
else,
but
I
think
that
would
be
really
helpful
for
developers
to
understand
that
there
are
multiple
models
and-
and
you
know
the
pros
and
cons
of
doing
you
know
things
one
way
or
another.
D
R
R
D
R
It's
very
productive.
I've
got
my
homework
cut.
D
Out
for
me,
awesome
good
thanks,
aaron
yeah
great
discussion.
Thank
you
all
we
are
done
for
today,
but
we
still
have
three
more
sessions,
so
two
side
meetings
and
we
have
thursday.
Also
as
an
official
meeting
okay
see
you,
there
go
ahead
mike
last
last
minute.