►
From YouTube: IETF98-OAUTH-20170327-1710
Description
OAUTH meeting session at IETF98
2017/03/27 1710
A
A
A
C
C
D
D
G
G
D
D
D
D
First
I
would
like
to
thank
Derek
for
all
his
work
over
a
couple
of
years
and
you've
seen
he
has
been
in
worked
in
other
activities
now
and
unfortunately
had
to
leave
or
I've
stopped
co-chairing
the
working
group.
So
Kathleen
drop
put
out
the
message
asking
for
volunteers
to
take
a
seat
next
to
me
in
the
in
upcoming
meetings,
so
think
about
that.
D
D
Here's
the
agenda
we
need.
We
need
to
do
a
little
bit
of
a
gender
bashing,
because
some
of
the
presenters
are
not
here
on
friday,
which
is
our
second
session
in
this
week.
So
apologies
for
that
Mike
or
how
should
we
reach
outlet
tell
me
quickly
on
so
we
do
the
presentation
NAB.
You
are
not
going
to
you're
going
to
be
here
friday.
Okay,
so
you
know
you
need
to
do
the
kpop
presentation
today
and
William
I.
Think
you're
also
not
here
Friday.
D
E
Ok,
hi
everybody,
William
Dennis
product
manager
at
Google,
so
I'm
talking
today
about
the
earth
to
dodo
device
flow
draft,
so
I'll
just
start
with
a
quick
recap
for
anyone,
who's
unfamiliar
what
this
draft
is.
So
this
is
an
authorization
flow.
That's
specifically
designed
for
devices
that
have
an
internet
connection,
but
they
don't
have
a
browser
or
they
have
limited
input
or
some
combination
of
that
in
this
flow,
the
user
will
actually
review
the
authorization
request
on
a
secondary
device.
E
So
this
could
be
their
their
phone
or
it
could
be
a
laptop
he's
kind
of
a
an
example
of
a
app
on
a
TV.
So
it's
displaying
the
the
coat
the
URL
that
the
user
has
to
visit
and
enter
the
code,
so
the
usual
basically
just
go
to
that
URL
end
of
the
code
approve
the
request.
While
this
is
happening,
the
device
is
actually
polling
the
token
endpoint,
and
if
the
user
does
complete
the
section,
then
they'll
get
back
either
a
authorization
granted
or
authorization
rejected.
E
These
codes
typically
have
an
expiry.
So
after
about
30
minutes,
for
example,
this
would
this
would
end
up
not
working.
So
the
requirements
are
that
indicate
internet
connection
and
display
mechanism.
So
it
really
doesn't
matter
what
that
mechanism
is,
it
could
be,
could
be,
visual
could
be
audio,
but
there
needs
to
be
some
way
for
the
device
to
actually
instruct
the
user.
What
that
code
is
so
it
doesn't
need
a
two-way
connection
to
the
user's
device.
So
that's
an
important
distinction.
E
What
this
means
is
that
a
lot
of
different
apps
like
say
an
Xbox
app
or
a
smart
TV,
app
various
different
kinds
of
apps
that
are
capable
of
connecting
the
internet,
but
I'm
not
capable
of
communicating
with
the
local
device
that
don't
have
any
kind
of
convenient
input
mechanisms
or
a
browser
so
broadly
applicable
to
that
class.
So
TV,
apps
printers,
you
know
it
what
it
isn't
for
is
a
device
that
has
a
browser
and
a
rich
input
mechanism
of
its
own
and
I
guess.
E
There
are
some
exceptions
to
this,
but,
but,
broadly
speaking,
you
know
those
devices
like
iOS
or
Android
or
Windows
or
Mac
device
should
be
using
just
regular
earth
to
using
the
earth
to
net
for
native
apps
PCP
okay.
So
what
are
the
changes?
Since
last
time
it
has
a
new
and
fairly
unwieldy
name,
the
name
is
attempting
to
to
explain
the
type
of
device,
so
this
is
applicable
to
avoiding
conflicts
with
other
ones.
We'd
love
to
have
input
on
the
name,
but
preferably
on
the
list,
so
that
we
don't
waste
peoples
important
time
here.
E
But
the
point
we're
trying
to
make
is
that
if
your
device
has
a
browser,
the
keyboard,
then
this
probably
isn't
the
old
flu
that
you're
looking
for
the
other
change
was
we
had
this
parameter?
That
was
basically
a
knob
response
type
in
the
device
authorization
request.
I
think
this
was
a
holdover
from
when
the
spec
was
sort
of
more
closely
related
to
the
oauth2
authorization
flow.
It
just
sort
of
stayed
in
there
turned
out.
No
one
was
actually
implementing
it.
So
when
we
deleted
it,
we
looked
at
Google's
implementation.
E
We
weren't
using
it
Justin,
looked
at
the
miter
implementation
that
they
weren't
using
it,
though
there
weren't,
even
won't,
even
like
mostly
ignoring
it,
was
just
completely
ignored.
So
this
is
a
good
chance.
If
anyone
would
like
to
preserve
this,
like
potential
extension
point
speak
now
or
forever
hold
your
peace
and
I
will
point
out
that
the
device
authorization
endpoint
is
not
the
old
authorization
avoid.
This
is
a
really
important
distinction
to
make.
These
are
completely
separate,
endpoints
and
there's
a
good
reason
for
this.
E
The
OAuth
authorization
in
point
is
assuming
that
there's
a
user
station
that
there's
a
user
agent
and
user
interaction,
whereas
the
device
authorization
endpoint
is,
is
more
of
a
back-channel
thing
that
the
device
is
doing
just
to
pull
down
just
to
initiate
the
device
authorization
request,
the
other
change.
This
was
a
suggestion
by
James
manager
from
Telstra
was
to
provide
a
standardized
way
of
embedding
the
code
in
the
verification,
your
eye
now,
and
so
this
what
we
came
up
with
a
fairly
straightforward
method
of
composition.
E
Now,
importantly,
this
is
an
optional
enhancement,
so
a
server
who
is
receiving
this
verification.
Your
eye
does
not
have
to
honor
the
fact
that
the
code
is
on
that
URL.
That's
a
very
important
point,
so
clients
cannot
actually
assume
that
that
that
will
be
processed.
It's
it's
a
hint
more
than
it
is
anything
else.
The
reason
behind
that
is
mostly
security.
So
we
have
some
concerns
around
this
device
flu
that
it
could
open
some
avenues
to
phishing
attacks
and
by
embedding
the
code
in
there
is
sort
of
it
potentially
makes
that
easier.
E
So
we
don't
want
to
force
authorization
servers
to
process
that
authorization,
so
is
that
due
process
is
probably
want
to
have
like
a
bluetooth
like
pairing
confirmation
screen
using
that
value,
rather
than
just
simply
accepting
any
continuing.
For
that
reason,
you
basically
want
some
evidence,
or
you
want
the
user
to
confirm
that
they
are
looking
at
their
device.
That
has
this
code
or
they
just
heard
their
device
that
has
this
code,
not
that
they
just
clicked
a
link
on
an
email.
Oh.
I
There
I,
maybe
wasn't
there
I
mean
there-
is
yours,
you're,
still
sort
of
opening
yourself
up
to
a
little
bit
of
an
attacker
right,
so
I
mean
the
user
in
my
book.
Might
okay
that
much
attention
to
what
it's
going
to
use
display
a
little
ok
button
and
it's
gonna
be
really
comfortable
to
hear
that
ok,
button
right,
I
100%.
E
Agree,
it's
unlikely
that
Google
is
going
to
implement
this,
but
I,
but
that's
it.
I
can
still
see
the
value
to
it
and
the
value
is
just
demonstrated
here.
So
this
is
an
example
where
the
TV
app
has
decided
that
they,
you
know
that
say
all
their
users
use
QR
codes
and
it
would
be
convenient
to
display
a
QR
code,
and
so,
in
this
case
it's
helpful
to
have
some
mechanism
of
composition
of
those
two
things
to
avoid
them
being
separate.
E
So
the
spec
now
documents
that
method,
but
then
leaves
it
up
to
the
authorization
server
to
decide
how
to
process
it.
So
if
you
decide
that
you're
worried
the
users
won't
follow
your
instructions
or
won't
when
understand
what
their
pairing
then,
please,
you
know
require
entry
of
the
code.
This
is
likely
what
we're
actually
going
to
do.
F
Justin,
richer
yo.
It's
just
going
to
point
out
that
one
thing
that's
nice
about
this
is
that
it
does
degrade
nicely.
It's
that
if
you
don't
support
extra
parameters
or
composing
URLs
or
whatever
on
your
server
you're
just
going
to
prompt
the
user,
which
is
what
you
would
do
had
that
not
been
passed
in
any
way.
J
Get
this
kind
of
text
I
mean
you're,
proposing
a
feature
and
saying:
oh,
you
don't
have
to
implement
that
and
we
most
likely
will
not
implement
that.
That's
basically
what
you
said
for
security
reasons,
I
assume.
So
why
is
ins
feature
in
its
back?
I
mean
in
the
end,
the
device
flow
is
from.
My
perspective
is
vulnerable
to
session
fixation
right
because
you
can
set
up
a
transaction
and
then
you.
K
J
E
And
you're
done,
let
me
unpack
that
weight
so,
firstly,
I
agree
with
you
in
general
that
it's
really
bad
idea
to
specify
things
that
you
don't
think
people
going
to
use.
I
am
very
much
against
that.
So
I
was
really
hesitant
to
put
this
in.
However,
this
week,
I
have
heard
of
people
that
are
playing
to
use
this.
So
it
seems
like
this
is
something
that
is
going
to
be
used.
So
let's
talk
about
the
security
for
a
minute,
then,
if
I
was
implementing
this,
how
I
would
do
it
is?
K
I
Another
option
would
be
to
have
security
considerations
text
saying
this
is
a
really
bad
idea.
If
you
were
to
add
this
kind
of
parameter,
you
know
here's
how
you
might
do
it,
but
it
would.
It
will
lead
you
to
these
things
right,
and
you
know
there
is
a
reason
why
we're
not
putting
this
in
this
back.
E
I'm
not
convinced
that
it's
a
bad
idea
for
everybody,
so
a
case
came
up
on
the
weekend
where
you
know
there
might
be
a
device
that
has
a
QR
scanner.
I
don't
know,
I
think
it's
a
it's
a
useful
composition
to
document
and
we've
documented
in
such
a
way
that
no
one
is
forced
to
use
it
and,
as
justin
said,
it
does
fall
back
extremely
grace,
lee
so
William
who
proposed
that
feature
James
manager.
He
actually
put.
E
J
Totally
surprised
because
I
I
learned
James
as
a
very
paranoid
to
type
so
type
of
guy,
but
ok,
I,
just
I
just
took
a
look
on
the
dr
and
into
the
security
conservation
section.
It
discusses
this
a
kind
of
attack,
it's
called
remote
fishing,
but
I
think
it
needs
more
more
more
fully
analysis
and
discussion,
because
I'm
not
really
convinced
that
this
cannot
be
utilized
in
a
combination
of
fishing,
with
click
checking
and
all
this
stuff,
because
in
the
end
of
you,
just
everything
you
do
is
show
a
confirmation
screen.
J
E
F
F
F
Other
consideration
is
that
it
is
really
really
hard
to
spell
out
ux
in
a
spec
like
this
for
things
as
diverse
as
I
authorization
servers.
So
the
best
we
could
do
if
we're
to
include
this
as
a
feature,
is
to
give
an
example
of
one
way
that
might
not
be
horrible,
but
requirements
beyond
that
I
think
might
be
lost.
Yeah.
F
E
I
think
is
fair.
I
mean
I'm
so
interested
to
hear
of
anyone
that
wants
to
use
this.
As
you
know,
since
there
is
additional
risk
that
we
one
way
is
just
document
the
risk
right,
so
it
I
think
everyone
agrees
that
this
is
taken
slightly
more
risk,
so
I
think
what
we
want
to
do
is
if
anyone
who
actually
needs
this,
they
should
get
that
on
the
record,
I
guess,
as
as
a
reason
for
introducing
that
risk,
III
think
I
would
be
happy
to
put
James
manager
on
his
behalf
on
there,
because
he
proposed
it.
E
F
Our
use
case
is
not
to
get
into
too
many
details,
but
it
is
a
two
device
use
case,
but
the
secondary
device
requires
and
authorized
login
from
a
trusted
system
and
a
trusted
third
party,
not
the
end
user
themselves.
So
it's
a
device,
verification
kind
of
flow.
It
technologically
fits
perfectly
with
the
device
flow.
Hence
why
I
agree
that
the
title
is
terrible,
but
again
not
here,
suggestions.
D
F
I
F
It's
wasn't
having
a
discussion
of
whether
or
not
it
should
be
included,
because,
honestly,
in
our
case,
that's
so
far
outside
of
the
process,
because
it's
a
third
party
and
a
trusted
kiosk
and
stuff,
we
don't
actually
need
it
to
be
the
device
URL.
It
has
that
parameter
in
the
code
and
everything
okay.
K
F
G
Lucy
Lynch
n
SRC,
so
honis
asked
if
we
should
pull
the
room,
I
I
actually
called
sparkly
unicorns
here,
I,
don't
think
you
have
enough
data
referring
to
several
people
that
you've
heard
from
might
have
a
use
case
without
any
background
one
the
specifics
of
why
they
have
a
use
case
and
Justin
just
said
he
can
get
by
without
it.
I
would
really
like
to
see
an
example
of
something
that
a
requirement
that
we
need
this
feature.
That's.
E
E
Mean
yeah
so
I
find
myself
any
interesting
position
here
because
actually
opposed
this
before
I
wrote
before
I
wrote
a
version
of
it
that
that
literally
here's
a
I
post
it
and
until
I
sort
understood,
lemoore
and
I
attempted
to
write
a
version
that
I
would
become
too,
with
even
from
that
position
of
being
skeptical.
I.
Think
that's
a
very
good
point.
I
think
that
anyone
who
wants
this-
probably
we
wanted
to
have
them,
speak
up
and
make
sure
that
there
is
a
validated
use
case.
I
completely
agree
so
Joe
John.
F
Brooke,
it's
not
working
John
Bradley
thing,
so
I
have
talked
to
people
doing
more
industrial
IOT
as
opposed
to
consumer
IOT,
where
they
have
a
trusted
portal.
That
they're
trying
to
register
devices
in
and
one
of
the
requirements,
is
to
have
more
entropy
in
the
code,
primarily
because
there
they
have
no
UI
on
the
actual
device
itself,
their
pre
printing,
this
on
a
sticker
for
pre-registering
it.
F
M
K
M
D
E
J
F
Is
still
a
conversation
with
the
device
manufacturer
that
that
the
notion
at
the
moment
is
that
those
codes
are
only
active
for
a
window
when
you
go
through
some
boot
up
process
with
configuration
process
with
the
device,
but
the
code
would
be
used
multiple
times,
but
you
would
have
to
do
something
with
the
device
push
a
button
plug
it.
In
stick
your
hand
in
the
boiling
oil,
or
these.
J
Are
supposed
to
I'm?
Not
I'm
not
surprised
about
this
answer
I
would.
I
would
suggest
to
to
treat
this
use
case
differently
and
to
specify
it
differently,
because
if
the
use
is
the
dakotas
more
or
less
use
as
an
identifier
for
the
device
for
provisioning
purposes,
it
is
completely
different
from
the
from
the
semantics
of
the
device
code
in
this
fact.
D
So
maybe
what
we
should
do,
because
we
also
need
to
pay
attention
to
the
time
is
we
maybe
should
move
that
to
an
email
to
the
email
list
and
discuss
the
requirements
a
little
bit
more
and
then
the
source
and
said
like
trying
to
figure
out
like
RV
ahhhh?
Maybe
we
I
think
we
need
to
think
this
through
a
little
bit
more
yeah
sounds
like
ya,
but.
E
I
guess
my
hypothesis
is
that
it
would
be
possible
to
do
this
in
a
way
that
is
secure
from
usability
and
therefore
we
shouldn't
prevent
it
that
was
sort
of
why,
in
the
end
that
I
accepted
at
this
Phi
being
it
so
I
felt
like
I,
wouldn't
put
it
past
someone
to
come
up
with
a
good
pairing,
you
I
that
that
really
tells
use
it.
You
know,
are
you
looking
at
the
TV
that
is
applying
that
code?
You
know
make
sure
they
actually
I
mean
I'm.
N
E
N
D
E
E
B
E
E
You
know
printer
doesn't
have
a
browser
or
keyboard,
so
you
go
and
I
want
to
configure
box
or
I
want
to
configure
Google
Drive
or
something-
and
you
click
the
button.
And
then
the
printer
is
doing
this.
This
is
displayed
on
the
printer
and
then
you
pull
out
your
phone.
You
know
potentially
scan
a
QR
code
or
type
in
the
code,
and
then
you
can
approve
that
request
for
the
printer.
The
printer
then
gets
0
with
access
token.
E
So
we
also
added
security
considerations
to
the
document,
so
the
previous
drafts
actually
didn't
have
any
so
so
we're
covering
a
whole
bunch
there
so
be
good
to
good.
To
get
working
group
feedback
and
review
on
those
points,
and
maybe
we
can
add
some
more
okay,
so
this
is
a
hopefully
an
uncontroversial
change.
We
added
a
definition
for
the
earth
to
authorization
server
metadata,
actually
we're
already
using
that
I
did
something
drop
testing
earlier
today
with,
if
Justin,
it's
quite
useful.
Having
that
as
a
sort
of
machine
readable
documentation,
it's
quite
useful.
E
We
also
clarified
that
the
rules
around
expiry,
so
we
do
recommend
that
their
tokens
expired
at
some
point,
that
that
is
really
up
to
you
to
control
her
and
and
there's
no
requirement
that
they
expire,
but
but
typically
they
will
and
in
terms
of
running
code.
So
the
Google
a
s
was
non-compliant
in
in
two
ways.
One
was
that
we
used
grand
type.
That
was
not
the
one
in
the
spec,
so
we've
actually
already
fixed
that,
and
the
second
is
the
the
code
parameter
where
we're
still
actually
using
code.
E
E
So
my
tid
1.3
will
have
this
feature.
Reportedly.
Just
and
I
ran
an
interrupt
testing
today
in
the
terminal
room
and
we
actually
got
up
to
work
with
a
few
bugs
and
a
few
doses
and
a
few
databases
they
got
corrupted,
but
it's
all
good,
so
that's
open
source.
You
should
go
to
try
that
out
from
a
client
perspective.
E
D
E
D
E
K
B
K
E
O
F
F
Applying
that
so
there
was
also
a
question
with
the
token
revocation
specification
went
through
of
whether
or
not
we
should
allow,
revocation
of
other
things
like
authorization,
codes
and
all
of
these
other
temporary
credentials,
and
things
like
that,
and
we
as
a
working
group,
decided
that
the
complexity
of
supporting
revoking
these
credentials,
which
are
partial
and
intended
to
be
temporary,
was
was
not
worth
sort
of
the
extra
over-engineering
that
would
be
required.
So
currently,
there
is
no
nothing
in
the
spec
about
revocation.
F
E
A
really
good
point,
so
the
this
flow
uses
a
device
authorization
in
point,
but
then
just
the
regular
token.
In
point,
the
Refresh
token
access
token
that
issued
on
that
token
in
point,
at
least
in
our
implementation,
are
exactly
the
same
as
any
other
token,
that's
issued
just
with
a
little
bit
of
different
metadata
attached.
So,
yes,
you
can
use
all
token
replication.
You
can
drop
them
on
the
floor.
You
can
you.
K
E
D
C
L
The
phone
yeah
not
too
much
change.
I
can
also
talk
about
those.
So
thanks
for
giving
me
time
today,
4xl
describing
this
old
j-pop
thing,
the
earth
shape
of
j-pop
actually
is
a
parallel
document
to
6750,
which
is
bearer
token
usage
is
this:
is
jay
TT
pop
tokenization?
Ok,
so
we
talked
about
something
like
this
probably
two
years
or
three
years
ago,
and
then
we
believe
that
the
tow
combining
is
going
to
solve
them
all
and
we
stopped
you
know
considering
these
kind
of
things,
but
that
was
not
quite
a
case
on
some
circumstances.
L
It
clearly
wasn't
the
token
binding
for
the
short
time
is
not
giving
us
as,
for
example,
in
the
cases
that
I'm
know
about
is
they
can't
touch
any
restriction.
Everything
has
to
be
done
at
their
application
layer
and
also
need
somehow
to
tie
back
to
tl's
client
authentication
or
something
like
that,
and
they
actually
need
it
now,
for
example,
you
can
open
banking,
they
have
to
call
it
now,
so
I
am
John,
so
other
people
came
up
with
something
called
j-pop
right
and
I
just
sent
out
the
draft
04
to
the
mailing
list.
L
The
draft
defines
JP
j-pop
talkin,
send
that
constrain
token,
which
is
there
are
two
types
of
them
d
and
constraint:
token
client
ID
constraint
talking
and
then
there
are
key
constraint
tokens
as
well,
which
is
actually
described
it
pretty
much
in
RFC,
7800,
okay
and
then
we
talked
about
the
resource
access
method.
One
way
to
do
is
to
tie
into
the
neutral
tils.
The
other
is
the
signature
pretty
much
as
in
the
digest
authentication,
and
then
we
talked
a
little
bit
about
authorization,
error
and
iono
consideration.
L
Confirmation
object
can
be,
can
have
several
times
it's
saying
CN,
but
its
type
of
DN
confirmation
mail
right.
It
used
to
be
CN,
but
it's
now
the
end.
So
so
in
the
in
the
confirmation
you
just
have
the
end
of
the
string
and
then
client
like
ID
confirmation
method.
You
have
you've
got
client
ID
down
there.
L
Access
method,
I
didn't
create
any
special
slides,
because
it's
pretty
much
in
just
one
part
of
thing:
it
that
comp
confirmation
record
a
confirmation
for
the
call.
An
object
actually
has
much
to
the
what
you
got
in
the
TLS
client
authentication.
So
that's
pretty
straightforward
for
the
signature
method.
L
It's
pretty
much
the
same
as
the
digest
authentication
except
it's
not
using
md5
but
generally
yes,
that's
it
and
downside
of
has
not
start
standardizing
it
now
is
that
groups
like
open
banking
standards
in
the
UK
will
probably
start
doing
their
own
things
or
not
even
mandating
anything,
but
the
each
bank
start
doing
their
own.
Well,
how
I
think
the
other
ability
so
I
think
it's
a
good
idea
to
start
doing
here
now.
So
my
request
to
the
working
group
is
to
please
adopt
the
draft.
F
So
John
Bradley
ping,
so
one
of
the
things
that's
motivated,
pushing
this
forward.
Now
we
sort
of
we
thought
about
doing
it
last
year
in
the
year
before,
but
without
a
clear
consumer
of
this,
we
didn't
want
to
confuse
people
with
the
work
that
we're
doing
on
token,
binding
and
I.
Think
token.
Binding
is
still
the
right
way
for
consumer
applications,
but
we
have
banks
that
are
doing
server
to
server
stuff
and
they
have
their
own
CA
and
they
have
their
own
set
of
laws
etc.
And
you
know
they're
looking
for
advice.
F
F
So
there
are
the
open
banking
consortium
in
the
UK
was
created
as
a
result
of
UK
government
regulations
around
opening
an
opening
up
banking
API
is
in
the
same
way
that
PSD
to
is,
except
that
they
have
a
deadline
of
the
end
of
this
year.
For
the
major
eight
banks
to
actually
have
Oh
off,
AP
is
opened
up,
so
they
are
under
a
tight
time
line
so
telling
them
we'll
get
back
to
you
in
a
year
or
so
is
also
a
walk,
isn't
making
them
happy.
M
Okay,
Tony
Madeline,
so
we
you
know
we
tried
to
wait
for
token
binding
off
so,
but
we've
had
to
implement
some
stopgap
measures
in
between
and
but
it
is
different
than
what
you
guys
have
done
here.
So
you
know
I'm
not
sure
that
the
current
draft
would
be
the
only
way
that
I
would
approach
this
there's
other
things
too.
That
we
would
probably
want
to
consider
if
we
we
needed
to
take
on
this
working
item.
Can.
P
Brian
Campbell
pain,
I
did
read,
I.
Think,
oh
one
of
us
this
morning
before
you
push
three
more
revisions,
so
I'm
not
sure
how
up
to
date
it
is,
but,
in
my
opinion,
there's
way
too
many
options
in
this
and
hearing
the
use
cases
that
it's
driven
out,
which
is
neutral
TLS
for
these
banks.
So
they
don't
go
off
and
do
something
else,
and
if
that's
the
problem
we're
trying
to
solve,
we
should
solve
that
problem,
which
would
mean
getting
rid
of
the
the
j-pop
part
of
it.
The
the
nonce
challenge-response
signature.
P
It
was
me
and
I
think
we
could
do
away
with
a
number
of
the
the
confirmation
methods
around
mutual
TLS
that
either
aren't
applicable
in
some
cases
or
introduce
a
lot
of
complexity
on
the
resource
side,
like
the
the
jku
method.
Would
that
that
complexity
belongs
at
the
authorization
server
layer
or
not
not
at
each
of
the
individual
resources
of
the.
F
F
With
Brian
that
we
should
maybe
have
one
thing
that
we
actually
do,
but
unless
we
actually
compare
the
options,
get
some
input
from
Microsoft
or
other
people
and
then
pare
it
down
to
one
maybe
two
ways
of
doing
it:
I
agree,
but
unless
we
actually
write
down
what
the
options
are
it's
hard
to
discuss
it?
That's.
P
Fantastic
unless
again,
if
you're
trying
to
solve
a
very
specific
use
case
on
a
tight
time
frame,
another
approach
would
be
to
solve
that
use
case
on
a
tight
time
frame,
instead
of
enumerated
all
possible
options
and
then
trying
to
get
input
from
someone
that
probably
won't
give
it
that
will
be
totally
different
and
then
slow
down
the
whole
thing.
And
what
I'm
suggesting
is
that
this
approach
likely
will
not
get
you
the
results
you
want.
L
H
H
Okay,
so
anyway.
Well
that's
what
I'm,
seeing
I'm
kind
of
a
new
to
this
group
I've
been
watching
the
mailing
list.
I'm
seeing
is
a
kind
of
a
convergence
on
what
you're
doing
from
high
level
perspective
is
going
to
cryptographic,
groups
of
trust
in
what
you're
doing,
whether
the
clients
and
the
authorization,
authentication
and
I
don't
know
like
this
groups
and
focus
on
like
interactive
authentication
and
authorization.
Well,
the
open
ID
with
the
authentication
and
I
think
you
really
need
to
look
from
my
perspective
at
what's
happening
out
there
with
other
groups.
H
I
took
part
in
the
industrial
internet
consortium
in
what
they
were
going.
They
all
seen
Alliance
and
you
know
in
what
they
were
doing
and
plus
our
company
investigated
this
for
about
a
year
with
an
initiative
that
we
had
internally
so
yeah
I'd
love
to
talk
to
some
people
about
it.
But
I
see
some
convergence
and
I
see
you
moving
toward
cryptographic
approaches.
But
you
also
have
all
this
legacy
way
of
doing
everything
through
the
user
agent
using
redirect
yeah.
D
I
think
there's
also
you
may
be
interested
in
the
work
to
be
doing
in
ace.
I,
don't
know
if
you
think
that
group
are
earlier
today
where
we
are
using
OAuth
specifically
for
the
IOT
use
case,
where
we
are
not
always
involving
the
user,
quite
naturally
so
I
don't
know.
If
you
aware
of
that
effort,
so.
F
So
listen
to
some
pointers.
This
doesn't
have
anything
any
impact
or
relationship
with
the
user
authentication.
This
is
about
device
authentication
where
Goldman
Sachs
is
using
a
certificate
to
authenticate
itself
to
Barclays,
and
they
want
to
make
sure
that
the
tokens
that
are
issued
are
actually
presented
by
goldman
sachs.
Take
that
book,
yeah.
H
That's
why
I
mentioned
that's?
Why
you
need
to
consider
whether
you
really
want
to
do
that
because
that's
the
use
case,
but
a
lot
of
the
IOT
guys
are
pursuing
that
exact,
no
user
interaction,
pure
cryptographic,
proof
and
versus
interactive.
You
know
verification
where
it's
come
from
in
the
past.
There's.
F
Interactive
user
consent
and
verification
of
the
user.
In
issuing
the
token,
the
question
is
wielding
the
token,
and
it's
not
really
about
what
I
want
to
do
with
you,
as
you
know
that
the
large
financial
institutions
seem
to
have
their
own
opinions.
The
question
is:
how
do
we
keep
them
from
shooting
themselves
in
the
foot
by
some
rather
creative
things,
I've
seen
them
for
Moses
yeah.
D
J
Anyway,
come
back,
I
bet.
This
is
awesome,
a
lot
of
questions
pop
up
in
my
mind,
where
I'm
standing
in
the
line.
First
of
all,
can
you
really
nail
down
the
use
case
you
want
to
address?
Can
you
really
give
us
a
statement
nail
down
the
use
case?
You
want
a
dress.
Can
you
do
that?
Please
John?
Where
do
you
start
speaking,
Jonas
Jonas
coming
from
me,
so
you
want
me
to.
L
L
There
would
you
ask:
what's
the
use
case,
so
the
use
case
we
have
at
hand
is
most
urgent.
One
is
that
the
the
bank's
wants
to
set
up
their
own
CA
and
they
won't
issue
that
certificates
to
the
FinTech
companies
and
they
want
the
FinTech
companies
to
use
that
certificate
to
authenticate
their
client
to
the
authorization
server
and
time
which
is
which
is
not
the.
J
L
J
D
F
John
Bradley
again,
so
the
feedback
that
I've
gotten
from
the
banks
is
all
they
really
care
about.
Is
that
distinguished
name?
They
don't
actually
care
about
any
of
the
other
confirmation
methods,
but,
coming
before
this
group
and
saying
oh
look,
aren't
we
smart
we're
going
to
use
distinguished
names
for
uniquely
identity,
identifying
things
I
can
expect
some
number
of
people
to
have
so
we've
provided
some
alternatives.
F
F
F
If
you
you
know
so
what
the
banks
want
to
do
is
issue
a
certificate
to
Goldman,
Sachs
and
issue
a
software
statement
along
with
that
that
sentence
that
says
what
the
distinguished
name
is
and
then
have
Goldman
Sachs
go
around
to
all
the
other
banks
and
be
able
to
use
that
software
statement
to
register
and
all
of
the
actual
transactions.
The
client,
authentication
and
token
presentments
all
have
to
be
done
over
TLS
channels
contain
the
distinguished
name
that
that
the
central
banking
authority
put
in
the
original
software
statement.
F
J
Okay,
so
that
the
last
questions,
a
last
question
is
the
more
about
the
role
of
the
of
this
group.
In
this
whole
activity,
I
mean
having
been
or
having
tried
to
chair
a
working
group
at
another
standardization
body
which
tries
to
provide
a
another
industrial
initiative
with
the
protocol
and
API
amber
pinning.
My
question
is:
are
we
supposed
to
provide
this
banking
initiative
on
time
of
all
the
ideas
and
protocols
and
ap
is
that
they
can
a
complete
accomplish
their
goal?
J
L
J
C
F
So
I'm
I'm,
not
so
crazy,
is
to
suggest
that
we
can
have
an
RFC
by
the
end
of
the
year
or
even
maybe,
by
the
end
of
the
following
year.
No
an
appointment
track
record
but
having
something
that
that
they
can
at
least
point
to
and
as
a
working
group
draft
actually
helps
them
significantly,
because
that's
just
the
way
that
their
their
bureaucratic
process
works.
If
there
is
something
in
a
standards
body,
it's
easier
for
them
to
at
least
discuss
it,
because
it's
not
coming
from
a
single
vendor.
F
J
I
hear
the
words
this
is
tossing
again.
The
worst
case
that
can
happen
is
that
in
a
year
time
frame
we
have
a
we
haven't
draft,
which
describes
something
it's
being
implemented
several
places,
and
afterwards
every
every
proposal
for
a
change
is
answered
by
no.
This
is
already
implemented
and
deployed.
We
can't
change
that
and
I've
seen
the
too
often
so.
I
am
saying
concern.
G
Lynch
and
SRC
a
plus-12
what
torsten
just
said
the
the
idea
of
putting
a
draft
out
so
that
you
have
something
for
a
conversational
point
with
people
who
are
in
a
fast
implementation
process.
When
you
know
you're
not
going
to
have
completed
or
dependable
work
makes
me
even
more
concerned
about
the
scope
of
the
document
and
the
number
of
options,
as
opposed
to
the
single
use
case.
That
you're,
addressing
the
only
positive
I
see
out
of
this,
is
that
you
would
get
additional
potential
solutions
on
the
tables
in
stone
said
they
would
submit
immediately.
D
On
the
other
hand,
I
also
think
it's
good
if
they
are
consumers
who
want
to
use
OS
and
actually
reach
out
to
yours,
working
group
in
some
sense,
that's
a
positive
thing.
You
know
like
people,
just
don't
randomly
do
things
they
actually
come
to
us,
because
they
believe
that
we
can
work
this
out
with
all
the
caveats
that
are
good
idea
but
questioned
by
some.
First
of
all,
we
are
running
out
of
time
and
second,
who
has
read
the
document,
not
the
one
that
NAT
submitted
today,
but
some
other
some
version
yeah.
D
D
Okay,
that's
good,
really
good!
Okay,
thanks
very
much!
So
if
I
read
them
time
correctly,
then
we
actually
done.
Is
that
correct,
I
think
we
ran
a
little
bit
over
time,
so
we
have
to.
Luckily
we
have
some
time
left
on
Friday
to
go
through
the
rest,
so
we
actually
good
Oh
blue
sheets.
Has
everyone
signed
the
blue?
She
if
you
haven't
signed
the
blue
should
raise
your
hand,
so
we
can
pass
it
around
yeah
funny.