►
From YouTube: IETF106-TXAUTH-20191118-1330
Description
TXAUTH meeting session at IETF106
2019/11/18 1330
https://datatracker.ietf.org/meeting/106/proceedings/
C
A
E
E
B
F
A
C
A
G
A
H
B
So
good
afternoon
welcome
everybody.
My
colleague
dick
Hart
forgot
to
mention
that
he
is
take
heart
and
I'm
your
own
chef,
and
this
is
the
T
transactional
authorization
both
a
little
bit
of
background
and
some
settings
towards
what
we
would
like
to
achieve
here
today.
So
we
have
a
number
of
proposals
with
some
connections
between
them
that
either
extend
all
to
some
degree.
We
do
the
old
Stu
protocol.
B
We
ended
up
having
this
buff
meeting.
This
buff
by
definition,
is
not
working
group
forming.
However,
we
might,
as
a
group,
decide
that
this
is
worthy
of
a
working
group
and
then
we
will
move
forward
in
that
direction,
but
not
today
we
don't
have
a
draft
charter,
we're
not
planning
on
doing
any
humps.
B
The
main
goal
for
today
is
to
see
if
we
have
commonality
in
the
room
on
what
the
problem
is.
So
if
we,
if
it
turns
out
that
we
have
through
it,
that
we
have
three
worthy
proposals
but
they're
completely
unrelated
and
there's
no,
no,
no
connection,
no
one
direction
that
would
serve
as
a
basis
for
a
working
group.
B
We
will
not
continue
in
this
form
format,
and
each
of
the
proposals
will
will
need
to
find
its
own
way.
If
we
do
see
that
there
is
a
problem
statement,
there
is
understanding
and
concerns
us
about
a
set
of
problems
in
the
oath
to
protocol
and
note
that
I'm
saying
a
problem
statement
rather
than
this
technical
solution.
B
If
we
do
have
commonality
around
this
problem
statement,
then
there
are
several
ways
we
can
deal
with
it
and
I
could
come
up
with
with
four
for
now,
so
we
could
decide
to
form
a
new
working
group
around
transactional
authorization,
or
we
could
say
this
is
like
the
same
audience.
A
US
has
been
doing
it
for
a
while.
We,
this
can
go
back
to
the
earth
working
group,
or
maybe
someone
could
come
up
with
a
non
ITF.
B
I
A
J
Alright
hi
everybody,
and
so
this
is
about
some
of
the
limitations
of
both
too
but
within
us,
with
a
particular
focus
for
the
kinds
of
things
that
are
being
addressed
by
all
of
the
various
extensions
and
applications
and
stuff
of
a
wall.
Now
this
has
been
something
that's
a
topic
near
my
heart
for
a
while
to
the
point
that
I
actually
gave
an
entire
presentation
on
everything.
That's
wrong
with
oauth2
at
identify
in
2018,
which
is
where
a
lot
of
my
thinking
in
this
space
kind
of
kicked
off.
That's
on
YouTube!
You
can
go!
J
J
Arguably,
in
order
to
make
a
good
Roth
deployment
that
fits
your
use
cases,
you've
got
to
know
how
to
navigate
this
pile
and
figure
out
like
oh,
you
know,
am
I
gonna
need
device
slows,
am
I,
gonna
need
jots
if
I'm
gonna
be
doing
shots.
There's
like
three
different
job
ECP's
that
I
need
to
understand
and
figure
out
how
they
fit
together
to
do
what
I'm
supposed
to
be
doing
here.
J
All
of
that
is
stuff
you
have
to
understand
before
you
write
the
application,
which
is
the
part
that
you
actually
care
about,
and
so
there's
there's
a
lot
of
issues
just
with
the
growing
complexity
of
the
OAuth
world.
A
lot
of
problems
with
the
OAuth
protocol
come
from
its
overuse
of
the
front
channel
as
a
communication
mechanism.
J
Now
the
front
channel
is
one
of
OS
greatest
innovations
in
that
it
allows
a
user
to
be
present
and
the
Browse
is
really
flexible,
but
it's
terrible
from
a
security
perspective
and
there's
a
lot
of
limitations
on
what
you
can
put
through
the
browser.
This
wouldn't
be
a
problem,
except
that
OAuth
puts
absolutely
everything
through
the
front
channel
and
especially
there's
the
problem
with.
If
you're
doing
one
of
interactive
flows
so
off
code
or
implicit,
then
you
have
to
start
everything
in
the
front
channel
before
you
can
do
anything
else.
J
J
The
biggest
drawback
being
people
see
this
and
see.
Oh,
it's,
therefore,
it
must
be
secure
and
I
can
just
go
use
it
and
not
have
to
understand
anything
else
in
that
pile
which
has
caused
very
real-world
exploits
Roth
is
limited
around
a
single
resource
owner.
It
is
a
delegation
protocol
that
assumes
that
the
person
using
the
application
is
the
person
that
says
it's.
J
Okay,
to
use
the
application
user
managed
access
gave
us
a
way
to
talk
about
a
secondary
requesting
party,
but
it
is
enough
of
a
separate
protocol,
even
though
it's
built
on
top
of
OAuth
2
that
you
don't
actually
collapse
back
into
the
single
user
use
cases
o
auth
cleanly.
We
tried
to
do
that
when
we
were
writing
OMA
to
couldn't
quite
get
all
the
way
there
because
of
limitations
and
how
a
lot
is
structured.
J
Auth
was
built
and
defined
in
a
static
world
where
you
knew
the
clients
that
were
talking
to
the
resource
overs
that
were
talking
to
the
api's
and
by
the
way
we
assumed
that
everything
was
all
going
to
be
web
servers.
Probably,
but
mobile
might
be
a
thing
someday
right.
It's
a
very,
very
different
world
here
and
we've
started
to
address
that
in
the
off
space,
with
dynamic
client,
registration
and
service
discovery
and
all
of
this
other
stuff.
J
But
there's
a
lot
of
cases
such
as
ephemeral,
single
page
applications
and
ephemeral
native
clients
that
this
doesn't
really
fit
for
and
we're
starting
to
see.
Cases
where
we've
got
ephemeral.
Resource
servers
that
OS
models
really
don't
have
a
good
mapping
for
so
even
the
ways
that
we've
tried
to
expand
OAuth
doesn't
quite
reach
all
the
way
there
there's
all
of
the
different
issues
of
token
presentation.
If
you
come
to
the
OAuth
meetings
this
week,
we're
gonna
be
talking
about
pop
and
deep
hop.
There's
been
a
lot
of
work
that
was
done
on
token
binding.
J
J
Scopes
are
an
absolute
mess
they're
one
of
the
really
good
ideas
in
OAuth
2,
allowing
people
to
say
these
are
the
slices
of
my
API
that
I'm
gonna
get
be
able
to
give
you,
but
people
look
at
it
as
just
kind
of
a
and
all-you-can-eat
buffet,
because
scopes
can
mean
lots
and
lots
of
different
things.
There's
lots
of
different
dimensions
and
we're
gonna
be
talking
about
rich
authorization,
requests
which
allow
us
to
add
some
structure
to
that.
J
But
there's
more
than
one
way
to
talk
about
that
all
right,
we've
got
a
resource
indicator.
We've
got
an
audience
parameter
from.
If
you
go
back
to
the
to
the
pop
token
drafts,
we've
got
the
claims
parameter
from
OID,
see,
we've
got
the
new
bridge
authorizations
requests.
All
of
these
are
kind
of
talking
about
the
same
type
of
thing
where
it's
like.
This
is
the
kind
of
thing
that
I
want
to
get
and
they
they
don't
all
play
together
very
nicely.
A
Thanks,
so
it
in
the
agenda
here
we've
got
a
number
of
background
pieces
around
current
issues,
new
issues
Torsten.
If
you
want
to
come
on
up
here,
somebody
have
any
questions
on
you
want
to
come
up.
Please
thank
you,
earn
to
ask
Justin
on
what
he's
talked
about
here.
We'll
have
a
bunch
other
time
for
discussion
later
on
us.
J
F
K
Yes,
I've
got
all
my
slides
in
one
deck
and
I,
then
dynamically
decide
where
I
cut
off
right:
okay,
hi
everybody,
I'm,
claustrophobia,
so
calm
and
I
was
asked
to
contribute
to
this
discussion
as
well.
The
perspective
I'm
taking
is
I
would
like
to
talk
about
requirements
that
I
see
in
the
space
I
am
working
in
which
is
more
around
using
or
for
would
say,
more
security,
sensitive
api's
in
the
space
of
open
banking,
the
financial
industry,
strong
identity
attestation,
qualified
electronic
signatures,
a
healthy
government.
K
K
So
yes,
I've,
come
built
an
open
banking
ecosystem,
but
I
also
helped
a
bank
in
the
context
of
the
payment
service
directive
to
and
the
European
Union,
to
build
or
off
based
api's
and
did
some
work
in
the
cloud
signature
area
where
we
helped
or
where
I'll
have
the
clock
signature
consortium
to
adopt
ooofff
and
also
had
them
some
discussions
with
people
in
a
health
and
eat
government
space
to
just
make
sure
that
my
hypothesis
work
for
them
as
well.
Alright,
let
me
give
you
an
example.
K
Psd
to
pay
served
what
it
means.
Okay,
the
people
here
in
the
room
that
know
what
test2
stands
for.
Please
raise
your
hand.
Oh
I
knew
I
knew
that
would
came
up
all
right,
so
the
payment
service
directive
is
a
regulation
in
the
European
Union
that
our
forces,
all
banks,
all
financial
institutions
to
open
up
ap
is
to
let
third
party
access
account
information
and
initiate
payments,
and
there
are
some
very
interesting
requirements
that
the
legislation
and
the
require
the
related
technical
requirements
oblige
the
banks
are
and
the
TPP's
arm
to
fulfill.
K
One
of
them
is
that,
for
example,
for
a
payment
initiation
area
shape
a
credit
transfer.
For
example,
the
user
needs
to
consent
to
the
individual
request,
and
not
only
it
needs
to
a
consent
to
the
individual
request.
The
solution
also
needs
to
make
sure
that
the
lincoln
between
the
consent
that
the
user
has
given
and
the
execute
note
that
payment
is
really
strong.
K
K
K
That
means
the
a/s
needs
to
render
a
really
dynamic
user
consent
screen,
so
no
longer
static
strings
and
just
a
string
replacement
for
that
static
string
value,
and
you
need
to
also
carry
that
through
with
the
access
token,
and
in
the
end,
this
is
becoming
the
scope
in
a
more
conceptual
sense
of
the
access
token,
and
it's
also
transactional,
because
the
TPPA
may
only
execute
that
payment.
Once
that's
I,
think
it's
obvious,
and
there
are
all
marked
samples
I
mean
it
could
do
it
twice
right
access
to
account
information.
K
It
says
similar
use
case,
but
a
bit
difference
here.
The
client
really
needs
to
request
what
concrete
actions
it
wants
to
execute.
On
what
kind
of
resources?
In
that
case,
those
are
the
different
account
numbers
and
the
client,
for
example,
might
ask
for
get
just
get
access
for
the
balance
for
that
account
numbers,
but
also
to
get
access
to
the
transactions
that
could,
for
example,
be
and
request
by
a
personal
financial
finance
management
software,
and
it
also
contains
information
about
how
long
that
permission
should
be
valid.
K
The
third
example:
it's
in
the
arena
of
qualified
electronic
signatures
in
the
European
Union,
there
is
a
I
believe,
a
lot
of
regulations
and
directives,
and
one
of
those
directives
is
called
a
Ida's
and
the
iris
makes
defines
a
kind
of
electronic
signature
that
is
equivalent
to
a
written
signature.
So
one
can
honor
on
a
smartphone
or
a
computer,
create
a
signature,
that's
legally
binding.
K
Clearly
there
are
really
strong
security
requirements
around
that
and
when
it
comes
to
authorization
of
such
a
process,
the
user
needs
to
authorize
several
things.
First
of
all,
what's
a
certificate
being
used
to
create
that
signature?
What
documents
are
being
signed
and
you
typically
need
to
have-
you
typically
have
an
hash
of
the
author
of
the
document
and
not
the
document
itself
for
privacy
reasons,
and
you
also
need
to
explain
to
the
user
what
documents
are
going
to
be
signed
based
on
that
confirmation?
And
there
are
other
more
technical
data
and.
K
K
Well,
what
all?
What
do?
What
have
those
use
cases
in
common?
First
of
all
the
privileges,
the
client
asks
for
are
very,
very
narrowly
the
defined,
and
that's
typically
because
of
the
law
or
the
regulation,
and
this
narrow,
defined
scope
must
be
enforced.
Why
the
resource
server.
So
the
resource
server
needs
to
know
what
the
user
consented
with
what
the
client
asked
for
and
clearly
because
they
are
so
narrowly
defined.
They
are
fine-grained
and
structured,
which
also
makes
them
more
voluminous.
Then
a
scope
value,
a
traditional
scope
value
and
yes,
there
are
all
transaction
values.
K
We
have
seen
some
examples.
There
are
account
numbers,
there
are
user
names,
potentially
there
are
hashes
and
so
on.
This
all
needs
to
be
carried
in
the
authorization
process
and
those
data
can
be
PII,
which
means
that
confidentiality,
when
those
data
are
being
in
transit
from
duty
from
the
client
to
the
a
s,
that's
an
important
requirement
and
more
all
the
integrity
and
authenticity
of
those
data
is
a
key
requirement
as
well.
K
So
what
are
the
challenges
when
it
comes
to
implementing
these
kind
of
use
cases?
We've
all
evolved,
I've
split
that
into
two
aspects,
because
my
proposals
also
is
also
split
in
two
different
drafts.
First
of
all,
we
have
to
prove
a
problem
of
the
transport.
How
is
this
data
sent
from
the
client
to
the
authorization
server
I
mean
Justin
already
made
that
point.
Nearly
anything-
that's
really
important
is
sent
through
the
front
channel
today
and
it's
sent
so
in
an
unprotected
fashion,
meaning
there
is
no
integrity
protection.
K
There
is
no
authenticity
protection
and
there
is
no
way
to
ensure
confidentiality.
Yes,
there
is
a
draft
addressing
that.
It's
called
char,
Justin
I
think
you
already
mentioned
that,
so
you
can
sign
and
encrypt
those
requests
which
makes
a
request
URL
even
longer.
So
we
have
a
real
reliability
robustness
problem
here
when
it
comes
to
conveying
such
amounts
of
data
between
the
client
and
the
authorization
server,
and
we
have
a
problem
with
the
representation
I
mean
I
could
more
agree
with
with
Justin's
assessment
right.
K
So
the
scope
is
just
not
sufficient,
because
scope
was
made
for
really
simple
static.
Things
just
ask
for
read
access
to
a
profile
and
not
for
doing
transaction
specific
things.
There
is
no
there's
no
structure
in
the
scope.
All
we
were
able
to
agree
on
was
at
the
limit
or
between
scope
values.
That's
it!
So
it's
fine
for
simple
use
cases.
K
In
my
personal
experience,
it
doesn't
help
if
there
are
multiple
resource
servers,
that
you
want
to
specify
scope
values
for,
because
you
can't
really
determine
the
assignment
of
the
scope
values
to
the
resource
servers,
which
makes
all
the
introspection
really
really
hard
and
a
scope
value
could
also
be
ambiguous.
So
in
the
same
way
as
done
previously
and
in
the
past
by
the
C++
report,
you
can
just
tell
me
what's
wrong
with
that
scope
or
how
you
would
read
that
scope,
open,
ID
email
read:
what's
the
meaning.
K
J
So
what
I
did
just
just
to
echo
from
the
floor
here
is.
The
argument
was
that
whoever
defined
that
API
didn't
understand
scopes
I
would
argue
that,
which
is
what
I
think
Torsen
is
saying
you
have
to
api's,
where
they
did
understand,
scopes
perfectly
fine
and
they
step
on
each
other,
which
so
go
back
to
the
five
dimensional
Venn
diagram.
In
my
last
presentation,
that's
really
the
kind
of
space
that
we're
looking
at
here.
Where
is
no
longer
about
protecting
one
specific
API,
with
one
specific
authorization,
server
and
yeah.
That
example
thank.
K
You
for
pointing
that
out,
the
problem
I
have
is
I,
never
worked
in
an
environment
where
an
a
has
only
protected
a
single
resource.
I
ever
have
been
working
in
environments
where
single
areas
protected
multiple
resource
service,
so
I
ever
had
problems
with
that
structure.
So
we
used
Scout
values
for
just
determine
what
resource
over
is.
Is
access
being
asked
for,
but
thank
you
for
the
clarification
all
right
do.
I
have
a
bit
more
two
minutes
or
victory
or
okay.
K
Okay,
I.
K
Would
like
to
before
we
come
to
two
potential
solutions.
I
would
give
you
what
like
to
give
you
an
as
in
impression
that
the
problem
statement
suggests
an
Isis
raised
or
really
relevant,
and
I
will
do
so
by
showing
you
that
people
try
to
work
with
Olaf's
limitation
by
implementing
their
own
stuff
right.
So
just
a
selection,
if
you
want
to
know
more
happy
to
present,
so
there
are
two
classes
of
workarounds.
K
The
one
class
is
well,
let's
invent
a
new
parameter
and
put
something
additional
that
we
could
not
convey
in
the
scope
in
that
parameter.
The
the
most
prominent
example
is
open,
ID
connect
because
it
invented
the
climbs
parameter
to
convey
a
fine-grained
list
of
claims
with
additional
requirements
which
works
well
and
protection
that
the
transport
can
be
ensured
using
signed
and
encrypted
request
objects.
K
So,
in
addition
to
the
scope
that
you
can
see
oops
there,
it
also
have
a
has
a
scope.
Details
object
that
in
JSON,
JSON
format
provides
more
information,
a
lot
more
information
about
the
payment
initiation
request
and
since
those
guys
know
that
this
data
would
potentially
blow
up
the
URL,
they
don't
send
the
authorization
request
through
the
browser
they
sent.
K
The
authorization
request
in
a
post
request
directly
to
the
a
s
from
an
interoperability
perspective,
that's
a
nightmare,
but
they
solved
the
problem
right
and
there's
another
pattern
that
one
can
observe
in
in
that
space
and
it's
being
used
by
a
lot
of
those
initiative
which
is
instead
of
passing
all
the
data
in
the
authorization
request.
You
set
up
a
resource
that
contains
the
data
and
just
refer
to
that
resource
and
as
I
don't
know
who
talked
talked
about
that
I
think
it
was
Brian,
it's
always
about
sending
by
value
or
sending
by
reference
right.
K
That
could
be
happy
the
heading
about
those
those
two
slides.
So
in
those
cases-
and
you
see
that
on
there
on
the
right,
the
client
first
creates
a
resource
that
contains
all
the
data
that
are
relevant
for
the
authorization
transaction.
It
gets
an
ID
and
then,
for
example,
conveys
that
ID
in
the
authorization
request,
either
as
a
part
of
the
scope
value
or,
for
example,
as
a
part
of
the
claim.
So
the
problems
exist
Solutions
exists.
The
problem
is,
can
we
find
a
generic
solution.
J
So,
first
off
all
of
these
form
parameters
like
we
are
posting
form
parameters.
We
are
sending
things
as
form
parameters
in
URLs
and
stuff,
like
that.
That
is
drastically
limiting
our
ability
for
data
description,
and
you
know
the
parse
ability
of
all
of
this
other
stuff,
and
it's
even
leading
to
really
weird
esoteric
questions
like
what
happens
when
I
repeat
a
parameter
which
RFC
670
49
says
I'm
not
supposed
to
do,
but
it's
silent
on
what
extensions
means
so
extensions.
J
Do
that
and
then
there's
the
question
of
okay
so
now
I
need
to
do
that
and
put
that
into
a
JSON
object,
because
I'm
doing
jar
and
I
can't
have
repeated
keys,
and
this
all
just
kind
of
gets
weird
real
fast.
So
I
would
really
like
to
see
an
actual
data
language
used
throughout
OAuth
and
use
consistently
consistently
with
consistent
data
models.
All
right.
This
is
really
the
big
driving
thing
that
I
have
that
I
would
like
to
see
us
do
with
future
work.
We've
got
so
many
different
extensions
that
are
reinventing
the
same
concepts.
J
You
know,
Torsten
showed
we
didn't
coordinate
our
presentations.
This
is
really
just
this
Universal
of
a
problem.
People
are
reinventing
intent.
Lodging
patterns,
people
are
reinventing
scope,
description,
languages,
people
are,
you
know
they
keep
reinventing
these
kinds
of
things
like
so,
for
example,
you
know
the
device
flow
and
Seba
both
have
a
form
of
intent.
Lodging
like
you
make
a
back
back-channel
call,
and
then
you
go
do
something
else
and
then
eventually
an
access
token
happens.
J
J
There's
also
the
issue
that
of'
was
really
designed
in
a
very
different
kind
of
world.
You
know
what
this
server
mean
anymore:
it
used
to
mean
an
actual
physical
computer
sitting
on
a
shelf
somewhere,
and
that's
not
the
case
in
in
today's
computing
systems.
I
mean
it
could
be
a
lambda
function.
That's
totally
stateless,
it's
a
very,
very
different
world
and
has
sort
of
baked
in
limitations
and
assumptions
about
what
it
means
to
be
a
participant
in
this
ecosystem.
J
Now,
fundamentally,
the
OAuth
protocol
is
a
delegation
protocol,
in
spite
of
it
being
named
an
authorization
protocol.
It's
fundamentally
about
getting
somebody
who
has
a
right
of
access
to
say
it's
okay
for
a
piece
of
software
to
act
on
their
behalf,
and
it
does
this
by
very
brilliantly
getting
the
user
involved,
the
end
user
who's,
using
that
software
involved
at
the
right
time
in
the
process,
but
OAuth
assumes
that
that
always
happens
with
the
web.
J
Browser
and
people
aren't
always
interacting
with
systems
these
days
in
a
web
browser
to
the
point
where
we've
had
a
bunch
of
different
efforts,
try
to
do
app
to
app
authentication
trying
to
squeeze
that
into
OAuth.
We
see
people
bastardizing
the
resource
owner
password
flow
in
order
to
cram
other
credentials
into
the
back-channel
in
order
to
not
have
to
pop
a
web
browser,
or
maybe
they
can't
pop
a
web
browser
for
any
number
of
reasons
and
I
kind
of
realized.
J
When
looking
at
all
of
these
different
things,
that
a
lot
of
our
different
grant
types
are
pretty
much
about
the
kind
of
interaction
you
can
do
with
the
user,
I
mean,
arguably
it's
about
the
the
mode
of
the
client
and
things
like
that,
but
all
of
that
really
has
effect
on
how
you
can
interact
with
the
user
can
I
pop
a
web
browser?
Can
I
prompt
for
a
password?
Can
I
display
a
code
on
the
screen?
J
What
can
I
do
to
interact,
and
we
put
them
all
as
grant
types,
because
that
was
the
key
extension
point
that
OAuth
2
gave
us.
So
that's
where
we
extended
it
now,
since
we're
talking
about
web
based
interaction,
how
do
you
even
get
the
user
there?
We've
got
a
few
different
ways
to
get
them
there.
We've
got
a
few
different
ways
to
get
them
back
and
we're
already
seeing
use
cases
where
we
want
to
be
able
to
mix
and
match
these
two.
J
So
I
want
to
be
able
to
send
the
user
directly
to
a
URL
I,
don't
want
to
have
them
type
anything
but
I
have
to
pull
I
can't
I
can't
get
a
callback
response
in
the
front
channel
right
or
maybe
maybe
I
can
display
them
a
code,
but
I
can
get
a
callback
in
today.
If
you
compare
the
auth
code
flow
and
the
device
code
flow,
these
are
strongly
tied
to
each
other,
because
they're
strongly
tied
again
to
that
grant
that
authorization
grant
concept
which
always
felt
kind
of
funny
in
the
OAuth
world.
J
But
what,
if
I
wanted
to
talk
directly
to
a
native
app?
You
know,
I'm,
making
a
payment
and
I
want
my
banks,
native
application
to
show
up
on
my
device
they're
both
there.
What
if
I'm
gonna
be
doing,
did
calm
and
I've
got
a
wallet
that
something
wants
to
talk
to
you?
What,
if
it's,
not
the
current
user
that
needs
to
do
the
authorization
and
I
need
to
go,
get
somebody
else
involved
in
this
process
or
what,
if
I,
wanted
to
do
some
sort
of
challenge
response
system?
J
All
of
this
can
be
kind
of
grafted
into
the
OAuth
world,
but
it's
a
bad
fit.
It's.
It's
really
not
meant
to
do
this
kind
of
thing.
Auth
is
meant
around
there
being
one
user
with
the
web
browser
who
is
sent
somewhere
and
comes
back
and
then
again,
who
is
the
user
right?
Sometimes
the
client
already
knows
who
the
user
is.
Sometimes
the
client
has
had
the
user.
J
Login
they've,
maybe
are
using
something
like
verifiable
credentials
too,
that
they
can
actually
prove
who
the
user
is
without
getting
the
user
directly
involved
again,
it
doesn't
give
us
a
good
way
to
do
that
in
the
wild.
What
I
have
seen
done,
though,
is
people
using
the
token
exchange
extension
grant
to
OAuth
and
then,
when
that
fails,
and
they
need
to
then,
and
then
they
sometimes
need
to
get
the
user
involved,
then
they
will.
They
will
drop
back
to
the
authorization
code
flow
or
something
like
that.
J
What
if
I've
already
got
an
access
token
and
I
want
to
trade
that,
for
something
else
again
token
exchange
gets
as
part
of
the
way
there.
But
what,
if
I,
want
to
do
step-up
authentication
based
on
existing
access
token
there's
the
way
that
ooofff
works
with
its
front
channel
first
interactive
flows
is
not
a
good
fit
for
these
kinds
of
use
cases
that
people
are
very
commonly
wanting
to
do
these
days
and
if
I've
seen
this
combination
of
these
are
in
client
before
then
I
want
to
be
able
to.
J
J
Did
you
already
covered
all
of
that
Annabelle's
going
to
be
talking
about
cases
where
you
have
a
user
and
you
just
need
them
interacting
you're,
not
even
necessarily
getting
an
access.
Token
o
auth
is
all
about
an
access
token,
because
but
because
it
has
this
really
rich
user
interaction
capability.
J
You
know
people
are
using
bits
and
pieces
of
it
to
do
different
things
and
I
also
think
that
there
is
a
lot
that's
being
done,
especially
in
the
IOT
space,
where
you're
introducing
key
pairs
between
different
pieces
of
software,
but
we're
using
these
authorization
protocols
to
do
that
type
of
introduction.
It's
not
a
good
fit.
It's
not
what
a
walk
was
meant
to
do,
but
it's
it's
so
close.
It's
like
right
next
door
to
what
oh
f
does
write
a
femoral
clients
are
a
really
really
big
thing.
J
These
days,
you've
got
an
S
PA
that
spins
up
it
exists
for
the
entire
time
that
the
user
is
there
and
then
just
goes
away.
Oh
off.
To
said
that,
oh,
these
are
obviously
public
clients,
because
we
can't
pre
provision
a
shared
secret.
We
can't
have
a
client
secret
in
them,
but
we
have
keying
technologies
today
with
web
crypto
and
all
of
that
where
we
could
have
an
ephemeral
key
pair
that
protects
that
instance
for
that
session.
But,
oh,
it
doesn't
have
a
good
place
to
do
that.
J
We're
seeing
some
progress
in
D
pop,
but
that's
really
being
grafted
into
an
OAuth
world.
That
has
a
lot
of
different
assumptions
right.
We
need
to
be
able
to
bridge
these
trust
models
where
we
have
ephemeral
things
and
where
we've
got
sort
of
long-standing
policies
of
like
any
instance
of
this
class
can
do
the
following
things:
sort
of
the
more
traditional
Roth
deployment
models,
Roth,
what
not
much
longer
yeah
not
much
longer
so
Olaf
is
a
very,
very
client
every
system.
We
hang
everything
off
the
client.
My
idea
for
positing
this
entire,
this
entire
boffin.
J
All
of
this
was
what,
if
we
made
the
transaction
of
going
and
getting
the
authorization
delegation,
the
actual
thing
that
we're
AFI
against
and
hang
all
of,
our
information
and
all
of
our
decisions
based
off
of
that.
What
I
do
not
want
out
of
this
work?
Personally,
people
have
said
that
this
sounds
a
lot
like
we're
doing
soap
for
OAuth,
please,
no,
no,
it
wasn't.
Tony
Tony
wants
ws-trust
ro
off
and
he's
already
doing
that.
I
don't
want
that
either.
But
you
know
that's
that's
beside
the
point.
J
No
I!
Don't
think
that
this
needs
to
be
trans.
You
know
transport,
agnostic,
I
think
we
need
to
embrace
HTTP.
This
is
the
world
that
it's
in
I,
don't
think
that
this
also
needs
to
be
strictly
backwards
compatible.
If
we're
going
to
be
solving
this
right
and
more
on
that
later
and
I
think
that's
the
end
of
this
deck.
L
Hi
this
is
Hank.
I
am
very
happy
that
I'm
here,
because
I
don't
know
why
I'm
here,
it's
just
coincidence
and
70%,
you
said:
I
have
a
violent
agreement
with
I
have
never
seen
a
more
concise
presentation
of
my
problem
with
all
of
this
than
this
year.
Thank
you
very
much.
Also
I
think
you
would
always
have
to
keep
in
mind.
This
should
not
be
soap.
I
think
it
should
be
on
the
read
topic
of
it,
so
you
remember
not
to
miss.
J
M
J
Want
is
something
that
is
like,
oh,
you
could
put
it
on
email
or
you
could
have
this
being
a
text
message
or
whatever,
because
it's
all
self-contained
and
it
ignores
all
of
its
transport
layer,
stuff.
Okay,
that's
what
I
don't
want
yeah,
but
if
you
can
translate
it
cleanly
the
concepts
and
constructs
from
one
side
to
another-
and
you
say
you
know,
this
is
an
HTTP
header
versus
a
co-op
option
or
whatever
they're
called.
Then
then
yeah,
that's
great
okay,.
L
L
N
My
name
is
Annabel
Beckman
from
Amazon
reporting
or
talking
about
some
non
authorization
use
cases
I
see
for
a
lot
of
what
we're
talking
about
here.
So
to
start
with,
let's
just
there,
we
have,
let's
just
walk
through
some
scenarios
that
I've
been
thinking
about,
don't
know
if
anybody
else
listen
to
audiobooks
I
do
a
lot
through
my
echo
I
have
encountered
this
experience
in
the
past.
I
asked
asked
the
the
echo
to
buy
a
book,
so
I
can
have
her
play.
N
It
and
I
get
this
kind
of
an
error
message
unable
to
complete
this
purchase
and
there's
a
lot
of
authorization
related
reasons
that
this
might
be
the
case,
but
there
are
also
these
other
other
problems
that
may
be
behind
this
error
message.
My
credit
card
could
be
expired,
maybe
there's
an
insufficient
balance
of
funds
on
my
account
or
some
other
problem.
That
needs
to
be
corrected.
That
I
can't
correct
through
the
voice.
N
N
The
way
this
works
is
the
device
at
some
point
in
here
we
have
a
printer
says:
hey
Amazon,
I'm
out
of
ink,
and
ideally
the
replenishment
service
says:
okay,
great,
we'll
place
an
order
in
this
case,
sometimes
hey.
We
can't
do
that
for
some
reason.
Just
as
a
couple
of
examples
of
why
that
might
happen,
maybe
the
the
the
customer
has
not
actually
can
properly
configured
the
system
to
say
what
kind
of
ink
they
want.
Maybe
the
kind
of
ink
that
they
selected
is
no
longer
available.
N
So
again,
here
we
have
a
case
where
the
end
user
at
some
point
needs
to
go
to
some
other
context
where
they
can
fix
up
this
aspect
of
their
account
in
order
to
to
unblock
this
process
and
here's
here's
another
scenario.
Last
one
of
these
Amazon
Web
Services
has
a
simple
email
service
it
it
does
what
it
says
on
the
tin.
In
this
scenario,
we
have
the
back
end
of
a
some
customer
service
service,
calling
AWS
SES
to
send
some
email
message
and
for
some
reason
that
request
fails.
N
So,
there's
a
there's
a
common
connection
through
all
of
these,
and
that
is
that
the
customer,
the
end
user,
is
operating
in
this
context
a
but
the
problem,
and
the
resolution
is
over
here
in
context
B,
and
we
need
to
get
them
from
one
context
to
another.
Somehow
yeah,
essentially,
you
know
summarize,
how
do
we
direct
the
end
user
to
another
context
and
back
again,
potentially
in
the
middle
of
an
arbitrary
process?
This
is
the
problem.
That's
present
in
all
three
of
the
scenarios
I
just
went
through.
N
It's
also
the
problem
that
underlies
the
you
know,
authorization
tasks
that
ooofff
is
is
designed
to
serve.
You
know
authorization
or
delegation
as
Justin,
posited
that
it
that
it
really
is.
It's
really
just
a
special
case
of
this
problem,
we're
operating
in
context
a
we
need
to
get
the
end
user
to
context
B
to
go
through
some
process
and
then
return
back.
N
Justin
mentioned
front:
Channel
versus
back
channel
concept
comes
up
that
a
lot
when
we
talk
about
this,
but
there's
actually
potentially
a
lot
of
different
channels
involved
and
I
said
three
or
four.
That
may
not
actually
be
all
of
them,
but
those
were
the
ones
I
could
think
of
when
I
was
putting
these
slides
together.
So
those
are
the
ones
Holden.
N
N
N
In
another
case,
it
may
be
a
little
bit
more
complicated
than
that,
for
example,
it
could
be
the
customers
back-end
service,
making
API
calls
to
an
AWS
service,
and
then
we
have
the
end-user
notification
channel.
That
is
how
is
the
end-user
being
told
to
proceed
or
being
directed
to
to
proceed
to
to
fix
this
problem
in
sort
of
traditional?
You
know
the
OAuth
world
that
is,
you
know,
expected
to
be
the
end
user,
through
their
web
browser
being
directed
to
an
authorization
endpoint
in
the
broader
context.
N
N
Traditionally,
with
OAuth,
we
think
of
this
happening
within
an
interactive
and
user
session,
but
there's
no
guarantee
that
that's
actually
the
case
problem.
The
problems
may
be
identified
through
non
interactive
scenarios,
for
example,
if
the
in
the
interactive
scenario
did
so,
those
are
easy
for
us
to
think
about
it's.
You
know
every
OAuth
scenario
that
people
tend
to
throw
out
there,
the
non
or
interactive
scenarios,
an
example
that
I
just
presented
was
a
printer,
detecting
it's
low
on
ink.
You
know
I'm,
not
interacting
with
the
printer
app.
N
N
N
We've!
We
have
a
number
of
these
kinds
of
non
authorization
scenarios
where
we
need
to
do
this
context
switch
and
particularly
as
we
talk
about
a
transactional
authorization.
Some
of
the
solutions
that
Justin's
going
to
present
there
seems
to
be
a
natural
overlap
between
what
it's
doing
and
what
we
need
to
do
for
these
scenarios.
So
I'd
encourage
us
to
think
broadly
about
this
problem.
Space.
J
J
The
reason
for
that
is
that
there
are
a
lot
of
assumptions
that
OAuth
2
makes
that
if
you
step
away
from
those
assumptions
it
turns
out
things
start
to
get
a
lot
cleaner,
really
really
quickly
and
I
wanted
to
run
this
down
and
see
what
this
looks
like
details
of
this
project
are
on
the
website:
althought
X,
Y
Z.
We
have
Java
and
JavaScript
implementations
at
this
point
that
interoperate
with
each
other,
which
is
pretty
cool
and
no
I,
didn't
write
both
of
them
myself.
J
We
have
a
lot
of
knowledge
over
the
last
decade
about
what
works
and
what
doesn't
and
how
the
world
has
changed,
and
this
isn't
just
a
blue
sky
exercise
of
oh.
If
we
were
inventing
this
in
a
vacuum
today.
What
would
it
look
like
I
mean
we
really
need
to
pay
attention
to
what
works
in
OAuth
to
you,
because
it
is
an
incredibly
successful
and
incredibly
widely
used
protocol,
which
is
not
going
away
anytime
soon.
So
anyway,
like
I
said
it's
on,
oh
I
thought
X,
Y
Z,
you
can
follow
along
there.
J
J
Yeah
I'm,
not
yeah,
I,
don't
okay,
I,
don't
know
what
I
did
there
whoops?
Okay,
so
I'm
only
gonna
push
this
button
from
now
on.
All
right,
Oh
auth
has
really
always
been
a
transactional
protocol,
but
we've
kind
of
pretended
that
it
hasn't
been,
and
we've
kind
of
hung
everything
off
of
the
client
in
terms
of
what
it
can
do
and
what
tokens
have
been
issued
and
all
this
other
stuff
I
came
up
with
idea
of
making
the
transaction
its
own
thing,
and
this
is
evidenced
by
the
intent,
registration
or
intent.
J
Lodging
pattern
that
Torsten
and
I
have
both
brought
up
before
a
lot
of
people
have
tried
to
solve
this
inside
of
a
auth,
which
means
you've
got
to
invent
a
few
extra
things.
I
decided
to
take
a
look.
What
would
it
be
like
if
we
had
a
protocol
that
was
built
around
that
from
the
start,
all
right,
so
the
client
starts
the
AAS.
It
talks
to
one
URL
and
says
a
bunch
of
stuff
that
it
wants
to
do
in
this
transaction
resources.
J
Again
this
is
JSON,
so
we
already
out
of
the
box
have
a
way
to
say:
we've
got
a
rich
expression
of
the
kind
of
thing
that
I
want
to
do
and
I
can
give
you
a
list
of
them.
You
know
if
I
want
to
do
multiple
things
here.
I
want
to
be
able
to
bind
keys
to
things.
We
need
to
be
able
to
get
beyond
just
client
secrets.
We
need
to
have
sort
of
asymmetrical
and
potentially
also
symmetrical
I'm
on
the
fence
about
that
key
bindings
for
client,
identification
and
authentication.
J
So
how
can
I
prove
that
to
you
every
time
the
client
sends
a
key
to
the
server
or
an
identifier
of
Akitas
server
has
to
prove
possession
of
it.
Maybe
it's
going
to
sign
the
body
and
throw
that
an
extra
header.
Maybe
it's
gonna
use
the
D
pop
thing.
Maybe
it's
gonna
use
cabbage
signatures,
maybe
it's
gonna
use
em
TLS,
however,
that
works,
but
in
all
of
those
cases
the
client
says.
Here's
the
key
that
represents
me
and
I
can
prove
that
I.
J
Have
it
right
now
the
kinds
of
things
that
I
want
to
show
the
user
on
the
consent
screen.
We
need
to
have
a
place
to
put
those
I
put
those
in
the
display
field
here,
but
I
also
need
I
also
have
an
opportunity,
because
I'm
posting
this
in
the
back-channel
to
tell
you
what
I
already
know
about
the
user.
Maybe
I've
got
an
assertion
that
I've
gotten
from
you
previously.
Maybe
I've
got
something
a
verifiable
credential
from
a
wallet
that's
installed
on
a
side
application.
J
You
know,
there's
a
lot
of
stuff
that
I
could
tell
you
about
the
user
in
a
lot
of
OAuth
use
cases
today
that
can
help
das
make
that
decision.
I
can
also
tell
you
dynamically
how
I
am
able
to
interact
with
the
user,
so
I
can
take
an
arbitrary
redirect.
Url
I
can
display
a
code
and
I
can
also
receive
a
callback
URL,
like
all
of
those
are
different
dimensions
that
I
can
communicate
at
the
same
time
now
the
a
s
processes
all
of
those
bits
of
that
transactional
request.
Maybe
it
figures
out
from
that.
J
We
can
already
issue
a
token,
because
maybe
this
key
represents
a
trusted
client
for
that
particular
set
of
resources.
Hey
guess
what
we
just
invented
the
client
credentials
grant
without
having
a
different
grant
type
right
or
maybe
I-
can
give
you
enough
information
about
the
user
like
a
credential
challenge
or
something
like
that,
but
that's
enough
for
you
to
to
log
them
in
and
grant
access
and
hey.
J
Well,
this
is
where
X
Y
Z
really
starts
to
come
into
its
own,
because
you
know,
if
we're
in
a
traditional
Roth
world,
we
would
have
already
had
to
send
the
user
over
to
the
a
s
in
order
for
the
a
s
to
decide,
it
doesn't
have
to
talk
to
the
user.
At
this
point,
the
a
s
can
figure
out
like
yes,
I
need
you
to
talk
to
the
user.
So
to
do
that,
go
to
this
URL
and
the
client
goes
to
that
URL.
It
doesn't
add
any.
J
It
doesn't
add
client
IDs,
it
doesn't
add
scopes.
It
doesn't
do
any
of
that
because
it
doesn't
have
to
this
interaction.
Url
can
be
generated
specifically
for
this
transaction,
and
the
client
just
goes
to
it.
We've
already
cut
out
a
huge
swath
of
issues
that
OAuth
2
has
in
the
front
channel
today
without
having
to
add
extra
stuff.
It's
just
built
around
that.
So
we
look
up
the
transaction,
the
user
does
all
of
their
normal
user
stuff
and
we
calculate
a
hash
to
protect
our
callback.
J
A
A
J
J
Yeah,
absolutely
okay,
yeah
I
was
gonna,
go
I
was
gonna,
go
through
the
web
case
first,
because
that's
the
most
okay
oo-aah
fee,
okay
and
then
yeah
I've
I've
got
more.
I've
got
like
30,
72,
slides
or
something
so
anyway.
The
whole
idea
of
this
hash
is
that
it
connects
the
three
parts
of
the
front
channel
triangle,
so
the
clients
request
the
service
response
and
this
front
channel
responds
all
together
in
a
relatively
simple
to
calculate
cryptographic
protection.
J
You
know
you
don't
need
something
as
complex
and
structured
as
jws
in
order
to
just
tie
these
things
together.
Alright,
so
the
client
goes
and
continues
the
transaction.
It's
got
the
a
transaction
continuation
handle
that
it
can
use,
and
it
also
has
this
interaction
handle
that
it
got
from
the
back
channel
and
the
front
channel,
and
then
in
this
call
the
client
has
to
prove
possession
of
its
key
the
same
key
that
it
used
to
start.
J
The
transaction
has
to
present
that
again
that
proof
again
and
the
auth
server
needs
to
check
that
and
that
allows
us
to
even
with
an
ephemeral
client
that
just
made
up
its
keys
the
first
time
it
ever
turned
on
and
ever
talked
to
this
alt
server.
You
can
still
protect
that
to
make
sure
that
it's
not
hijacked
all
unlike
an
OAuth
public
client
so
in
other
words,
we're
getting
a
lot
of
the
benefits
of
pixie.
J
Yes,
I
know
this
is
not
the
same
model
as
pixie,
but
there's
a
a
lot
of
overlap
in
this,
and
if
the
auth
server
says
everything's
all
good,
you
get
an
access
token.
We
don't
need
to
go
into
those
I'm
going
to
very,
very
quickly
skim
through
this.
The
the
handles
part
of
X
Y
Z
is
one
of
the
more
confusing
aspects
to
explain.
I'd
be
happy
to
go
into
detail
after
the
TLDR
version.
J
Is
that
all
of
those
sections
that
I
sent
to
the
auth
server,
the
all
server
can
say
you
know
what
next
time
that
you
talk
to
me,
you
particular
client
instance
the
next
time
you
talk
to
me.
Instead
of
sending
me
that
JSON
object
send
me
this
string
and
I'll
remember
that
it
represents
that
JSON
object.
You
could
do
that
out-of-band
with
a
static
registration
page
and
more
on
that
later,
though,
so
you
start
a
new
transaction.
J
Instead
of
sending
the
JSON
objects,
you
just
send
the
strings
and
the
client
still
has
to
prove
possession
of
all
of
the
reference
keys.
Even
if
it's
not
sending
the
public
key
directly,
if
it's
sending
the
public
key
by
reference,
then
you
just
you
still
have
to
prove
possession
of
it.
An
access
token
could
come
back
with
the
transaction
handle
because
that
allows
us
to
refresh.
J
So
one
of
the
things
I
hope
you
guys
are
seeing
is
that
these
are
all
concepts
that
I
didn't
invent
in
this
project,
but
by
taking
sort
of
a
different
slice
of
things,
it
drastically
simplifies
how
everything
fits
together
and
makes
it
a
lot
more
consistent
with
each
other
without
oversimplifying
it
same
thing
with
we
can
get
back
to
simple
scope,
strings
which
are
very
useful
for
developers.
If
you
have
a
very
small,
well-defined
API.
The
difference
here
is
that
each
of
those
strings
is
defined
to
expand
to
one
of
these
objects
like
its.
J
It
is
a
handle
to
one
of
these
objects,
just
like
those
other
handles
I
said
instead
of
sending
instead
of
sending
this
objects,
and
this
string
scopes
turn
into
the
exact
same
construct,
which
already
gives
us
the
type
of
combinatorics
that
were
struggling
with
and
rich
authorization
requests.
Today,
it's
built
in
now
to
dick's
question
other
ways
to
interact
with
things
say:
I've
got
a
user
code,
this
one's,
pretty
simple
I,
send
you
back
a
relatively
static
URL
in
a
user
code.
J
You
trip
that
out
to
the
user
that
go
with
a
secondary
to
punch
that
in
interact
now
you're
looking
up
the
transaction
based
on
the
user
code
instead
of
the
instead
of
the
URL,
because
the
URL
is
static,
so
we
can't
add
randomness
there,
but
we've
got
this
user
code.
We
can
look
up
what
transaction
we're
we're
working
on
and
go
from
there.
This
is,
incidentally,
how
people
tend
to
build
the
device
flow
today.
You
know
all
servers.
Meanwhile,
we've
got
a
polling
mechanism
with
that
transaction
continuation
handle
there's
a
waiting
mechanism.
J
You
can
rotate
the
transaction
handle
every
time
you
use
it
for
security.
If
you
want
to
do
a
combined,
URL,
well,
I
realize
that
you
don't
actually
need
to
do
the
OAuth
device
flow
combined
URL,
because
we
have
a
way
to
say
here's
a
an
arbitrary
URL
that
you
can
go
to
I
can
redirect
you
to
an
arbitrary
URL
I.
Just
can't
get
you
back
right!
So
that's
why
it's
important
to
split
these
two,
so
I
can
now
send
the
user
to
an
arbitrary
URL
and
meanwhile
I'm
polling.
Now.
J
I
also
think
that
there's
a
huge
opportunity
for
us
here
to
expand
this
one
of
the
clients
that
I'm
working
with
is
using
did
comm
messages
to
talk
between
agents
and
back
channel
fabric
servers
and
stuff,
like
that.
If
the
auth
server
can
send
me
a
did
comm
message
that
I
can
hand
over
to
my
local
wallet
for
processing.
That
might
let
me
bypass
most
of
the
user
interactions
stuff,
because
I
can
just
answer
those
questions
directly
using
the
fabric
or
maybe
I
want
to
do
a
web
event.
J
Actually
do
this
with
web
authenticate
of
web,
often
and
native
phyto
api's
are
almost
there.
So
I
think
that
the
technology
to
support
this
is
moving
there.
We
should
have
a
space
to
be
able
to
do
this
kind
of
thing.
Give
me
a
challenge:
I
will
sign
the
challenge
and
hand
it
back
right,
identity,
I
think
we
can
stack
that
on
just
like
we
did
with
Open
ID
Connect
errands
actually
got
Aaron
Park
he's
got
a
great
blog
post
about
that.
Just
go
read
that
I'm
not
gonna
get
into
it.
J
I
think
we
can
bind
tokens
in
the
same
way
that
we're
doing
keep
wrote
key
proofing
with
all
of
the
regular
client
key
proofing
during
the
transaction
process.
Discovery
is
an
interesting
thing,
because
the
client
only
needs
that
transaction
URL
to
kick
off
the
whole
thing,
unlike
oh,
where
you
at
least
need
the
authorization
endpoint
and
the
token
endpoint,
and
you
need
those
two
tied
together.
J
Somehow
we've
seen
real
world
based
on
those
getting
split
up
from
each
other
with
XYZ,
because
the
interaction
URL
is
generated
and
returned
directly
to
the
client
from
the
transaction
endpoint.
You
really
only
need
one
URL
to
kick
the
whole
thing
off.
If
you
need
more
than
that,
Jorge
Fletcher
and
I
have
been
talking
about
a
way
for
the
client
to
signal.
These
are
a
bunch
of
additional
things
that
I
can
do
and
the
server
kind
of
picks
from
that
list
and
says
you
know
all
right.
J
So
here's
here's
what
you
get
to
use
in
the
course
of
this
transaction
when
you're
talking
to
me.
So
it's
a
very
simple,
like
one
round-trip
way
to
effectively
do
a
discovery
and
registration
built
into
the
transaction
protocol
without
adding
additional
stuff.
On
top
of
it.
These
concepts
I
think
map
pretty
decently
to
oauth2
there's
a
lot
of
familiar
stuff
here,
it's
just
sliced
up
in
a
different
way,
so
all
the
key
possession
that
we're
doing
with
XYZ
it
Maps
and
in
some
cases,
takes
directly
from
existing
technologies.
D
J
Options
and
I've
already
gone
over
most
of
that
kind
of
stuff.
So
today
you
tell
an
OAuth
client
developer:
here's
a
bunch
of
strings
that
you
put
into
your
configuration
in
these
specific
spaces,
we're
really
and
send
a
json
a--
or
send
a
form
post,
we're
really
sending
telling
them
the
same
things.
We
need
to
keep
this
simple
for
client
developers
more
than
anything,
so
we're
saying
here's
a
bunch
of
arbitrary
strings
that
you
put
into
this
JSON
object
and
post
it
over
to
the
thing
to
start
the
transaction
process.
J
J
You
could
kind
of
make
something
that
looks
like
XYZ
buy,
cobbling
together
a
bunch
of
existing
extensions
and
proposed
extensions.
And
that's
you
know,
that's
not
surprising,
but
what
you
get
with
the
XYZ
approach
is
something
that
is
internally
consistent
and
is
much
more
sort
of
simple
and
intentionally
designed
and
to
end
right.
So
what
I'm
asking
let's
go?
Build
OAuth,
3.
K
How
shall
I
start
while
you
are
making
up
your
mind
whether
we
should
start
working
on
over
three
I'm
gonna
talk
about
baby
steps,
I
would
say
so.
Instead
of
the
new
disruptive
solution,
I've
been
working
with
disappeared
of
some
members
of
this
community
on
solutions
that
are
built
on
top
of
OAuth
2
to
solve
the
problem.
To
some
extent,
I
would
like
to
ya
know
with
the
clicker.
I
can
also
present
them.
Alright
I
think
there's
something
wrong
with
the
presentation.
K
No
I
did
not
I
know
you
need
to
be
challenged.
Then
you
make
it
right.
Thank
you
very
much.
Ok,
I'm
gonna
present
two
drafts.
The
first
one
is
called
pushed
authorization
requests.
One
could
say
that's
an
attempt
to
have
that
first
initial
magical
request
that
Justin
just
talked
about
back
porta
2
of
2,
and
it's
basically
also
in
reintroduction
of
the
token
Eric.
The
request
token
request
that
we
already
we're
familiar
with
and
O
of
1,
so
the
pushed
authorization
request
is
based
on
work
that
we
have
done
at
the
open,
ID
foundation.
K
The
draft
basically
extends
or
compliments
jar.
The
jet
protected
authorization
request
by
allowing
to
push
the
authorization
payload
to
the
authorization
server
in
advanced
in
a
back-channel
communication
so
now
in
the
same
way
as
the
arm.
What's
the
name
of
the
end
point
in
the
XYZ?
Thank
you
in
the
same
way
as
a
transaction
endpoint
is
used
to
initialize
a
transaction,
then
you
push
the
authorization
request.
K
Endpoint
is
used
to
upload
all
the
data
of
the
authorization
request
and
then
the
client
gets
back
something
that's
sent
in
the
front
channel,
since
we
do
want
to
provide
to
provide
a
solution
within
the
Oh
of
existing
oauth2
world.
We
are
not
returning
and
the
redirect
you
Maya,
because
the
redirect
URI
is
the
authorization
endpoint.
So
you
see
we're
trying
to
get
as
far
as
we
could
within
or
off
to
that.
K
Oh,
where,
as
Justin's
proposal
is
something
that's
really
completely
new,
but
without
all
the
legend
see
that
we
have
in
an
O
of
to
base
solution
alright,
so
how
does
it
look
like
I
mean?
Basically
it's
really
that
simple,
a
traditional
OAuth
request
is
made
up
several
over
your
I
query
parameters,
so
you
just
send
a
get
request
to
the
old
authorization
endpoint
now.
Imagine
if
you
just
put
the
same
parameters
in
a
post
request-
Wow,
that's
simple
right,
but
it
gives
you
a
lot
because,
first
of
all,
you
don't
have
a
size
limitation.
K
You
can
authenticate
the
client
and
send
that
I
have
really
been
missing
an
oauth2,
because
when
the
authorization
request
hits
the
a
s,
the
a
s
summer
can
identify
the
client,
but
it
can't
be
sure
that
it's
really
declined.
It's
talking
to
up
to
the
client
tries
to
redeem
the
code.
At
the
token
end
point
so
now
we
change
that
and
that
also
dramatically
changed
the
trust
model
in
the
security
model.
K
So,
with
the
introduction
of
power,
we
can
omit
some
of
the
security
measures
that
we
right
now
require
clients
to
use
in
a
security
BCP.
Well,
that's
that's,
sometimes
some
some
way
to
go
all
right,
so
we
simply
push
that
data
to
the
pushed
authorization
request
and
get
back
a
request,
UI
and
that's
where
we
then
start
to
use
shower,
because
char
has
a
mode
where
the
client
can
use
a
request.
Your
I
to
point
to
some
plot
that
contains
the
authorization
request
data
and
that's
it.
K
We
just
modify
the
authorization
request
through
the
phone
channel
to
use
that
request
UI.
So
it's
really
simple.
You
just
take
the
data,
send
it
to
the
backend,
get
to
request
your
I
and
send
it
in
the
front
channel,
and
this
request.
Uri
does
not
need
to
really
expose
the
authorization
data,
because
in
the
end
it's
only
the
a
s
that
needs
access
to
have
access
to
that
data,
so
we
could
have
used
an
opaque
handle
instead.
But
since
we
wanted
to
be
compatible
to
jar,
we
use
a
request.
Ui.
K
There's
the
second
mode
which
allows
the
client,
instead
of
sending
all
the
individual
parameters,
to
send
a
signed,
request,
object
in
the
post
body,
and
this
is,
for
example,
a
mode
that
you
can
use
if
you
want
to
implement
non-repudiation
with
application
level
signatures.
So
it
nicely
fits
into
here.
What
you
get
is
also
request
your
eye,
so
the
difference
just
lays
in
the
value
you
push
the
data
to
the
a
s
or
the
authorization
request
itself
looks
always
the
same.
K
Just
the
client
knows
there
is
a
request
to
I
parameter
that
I
need
to
add
to
that
authorization
request
your
I
and
the
advantages
are,
from
my
perspective,
really
significant,
because
since
we
can
use
Transport
Security
now,
we've
got
integrity,
protection
and
authenticity
more
or
less
free
of
charge,
and
we
got
client
authentication,
which
means
in
the
front
end
process.
The
AAS
already
knows
yes,
I'm
talking
to
the
legitimate
client
and
the
AAS
can
really
early
refused
to
talk
to
any
client.
K
That's
not
really
legitimate
and
cannot
really
authenticate
or
is
not
authorized
for
certain
scope,
for
example,
and
the
migration
path.
Is
that
simple,
since
the
same
parameter,
even
in
the
same
encoding
are
put
in
the
post
body
instead
of
the
URI
or
quest
your
I?
And
there
are
some
other
interesting
properties
of
that
of
that
new
draft.
K
We
have
a
central
authority
where
the
client
registers
but-
and
there
are
multiple,
a
SS
that
the
client
wants
to
talk
to
so
the
client
can
dynamically
register
redirect
URI
for
the
different,
a
SS
but
use
the
same
credential
set
that
were
externally
managed.
So
there's
a
lot
of
potential
in
this
really
really
small
extension
and
Daniel
Fett
believes
that
is
also
resistant
against
mix-up
and
that
I
think.
K
What's
the
attack
you
referred
to
when
you
said
there
are
attacks
that
can
be
launched
because
we
have
two
different
endpoints
in
that
case,
since
we
are
authenticating
the
client
in
the
first
step,
we
still
have
to
analysis
and
analysis
analyze
that,
but
we
are
pretty
pretty
confident
that
also
mix-up
goes
away.
All
right,
Mars.
A
D
D
D
K
Okay,
next
topic
so
send,
since
we
now
have
to
survey
the
proposal
for
the
transport
issues
let's
take
into
how
do
we
convey
the
rich
authorization
data
in
Oh,
F,
2
dot?
Oh
there's,
another
draft,
which
is
called
draft
rich
authorization
request
drawer
that
I
brought
together
with
Ryan
and
Justin,
and
it
introduces
a
new
parameter
to
OAuth
2,
which
is
used
to
carry
fine-grained
authorization
data
in
as
what
Jason
in
the
authorization
request,
and
it
can
be
used
in
addition,
or
as
a
replacement
for
the
scope
parameter.
K
As
Justin
pointed
out,
there
is
some
text
about
around
combining
those
which
is
not
as
simple
as
it
as
it
seems
to
be
on
first
sight,
and
also
would
like
to
point
out
that
the
resources
I
think
it's
a
resources
parameter
in
exercise.
We,
the
resources,
parameter
more
or
less
uses
the
same
structure
as
the
authorization
details
or
to
be
more
precise
authorization.
We
modified
authorization
details
to
use
the
same
structure
as
XYZ.
It
does.
K
Does
it
look
like
I
mean
that's
intentionally
the
same
example
that
I
gave
in
my
earlier
presentation,
so
it's
a
payment
and,
on
the
left
hand
side.
You
can
see
the
example
on
the
right
hand,
side
it's
in
the
end,
in
our
area
of
JSON
objects,
and
every
of
those
JSON
objects
contains
the
data
that
are
specific
to
a
certain
set
of
permissions
or
a
certain
API
right.
So
the
example
here
is
the
payment
initiation
request
for
payment
initiation,
and
there
are
some
small
extensions
to
my
to
my
example.
K
First
of
all,
every
of
those
apps
are
objects
in
the
array.
Has
a
type
field,
so
it's
possible
to
have
different
structures
in
different
authorization
objects
tailored
to
the
needs
of
different
api's.
That's
basically
what
we
want
to
achieve,
so
we
want
to
have
a.
We
don't
want
to
have
a
structure
that
is
one-size-fits-all
because
it
just
doesn't
work.
As
you
have
seen,
identity
assurance,
electronic
signatures
account
information.
K
They
all
have
completely
different
structures,
and
we
want
to
have
a
support
that
API
providers
can
define
the
structure
of
the
authorization,
details
and
clients
can
use
that
to
really
express
their
requirements,
their
expectations
and
what
they
want
to
get
in
terms
of
permissions.
Using
that
structure,
even
though
we
have
defined
some
basic
common
elements
in
the
Doda
structure,
one
of
them
is
the
locations.
You
can
see
that
as
a
third
field
in
that
example,
and
the
locations
should
be
used
to
assign
that
particular
authorization
object
to
certain
resource
server
and
that's
that's
a
problem.
K
I
I
want
to
solve
for
a
long
time
in
OAuth,
because
now
you
can
assign
the
request
for
permission
to
a
certain
resource
server
which
gives
the
ability
to
later
on
filter
the
authorization
details,
objects
and
that
you're
assigned
to
an
access
token
or
an
introspection
response
based
on
the
location.
You
want
to
use
the
access
token
at,
and
it
also
gives
you
the
ability
to
request
similarly
structured
but
different
permission
on
different
resource.
So
just
imagine
you
want
to
get
access
to
a
file
server
on
different.
K
You
want
to
get
access
to
files
on
different
file
servers,
you
can
use
different
locations,
the
same
structure
and
the
author
is
in
days
authorization
details,
object,
but
different
data.
Obviously,
and
we
have
further
common
elements
that
you
will
see
when
you
take
a
look
into
the
draft
and
that's
the
way
it
can
be
used.
K
Basically,
you
can
add
the
authorization
details
as
a
URI
request,
parameter
and
clearly
you
can
also
use
power
to
send
that
request
parameter
in
the
front
channel
to
the
authorization
server,
but
you
can
also
add
the
authorization
details
to
the
request
object
in
the
end,
you
can
basically
use
authorization
details
in
any
place
where
you
use
the
scope
parameter
today
and
I.
Think
the
tricky
part
in
the
end
is
not
how
to
represent
rich
authorization
data.
The
challenge
for
a
SS
is
to
really
accept
that
author.
K
It
that
user
context,
a
user
content,
is
more
complex
and
needs
to
be
more
sophisticated
in
the
kind
of
use
cases
I
described
in
my
first
presentation.
If
you
have
variable
dynamic
data
in
the
authorization
request,
then
the
a
s
also
needs
to
be
able
to
show
that
in
the
user
content
and
the
user
content
is
a
bit
more
is
more
complex
than
just
asking
for
access
for
certain
static
stuff
right.
So
that's
that's.
K
In
the
end,
the
real
challenge
for
implement
it's,
not
that
the
JSON
structure,
so
the
a
s,
uses
the
data
type
of
the
object
and
the
content
in
the
authorization
data
to
render
the
content
and
then
conveys
the
authorization
details
through
to
the
RS
in
access
token
and
top
interest.
Spectral
responses.
I,
also
assume
that,
during
the
course
of
the
user
consent,
the
user,
for
example,
can
select
some
value
that
are
relevant
for
entered
the
transaction
as
well.
K
K
We
don't
want
to
have
a
one-size-fits-all
solution,
because
we
don't
believe
that
that
really
it's
going
to
work,
even
though
we
have
defined
some
common
data
elements
that
can
be
used
to
address
common
use
cases
and
I,
especially
like
the
capability
to
really
assign
the
authorization
data
to
certain
resource
service
and
immense
resource
specific
access
to
all
right.
That's
it.
A
Okay,
let's
see
a
second,
the
director
so
now
we're
into
some
discussion.
I'm
gonna
start
off
with
we've
had
a
bunch
of
presentations
from
people
saying
we
think
there's
a
problem
here.
Here's
concerns
we
have
with
OAuth
here's
some
new
things,
we'd
like
to
do
I'd
like
to
hear
if
there's
people
that
disagree
with
that
or
you
know-
have
concerns
around
that
and
think
you
know.
We
don't
really
have
a
problem
here,
so
we
can
balance
out
our
viewpoints.
P
Tony's
not
helpful.
We've
already
ascertained
that
this
is
Mike
Jones
from
Microsoft
I,
don't
debate
the
premise
that
Olaf
has
become
a
large
set
of
specifications
whose
combinatorial
usage
has
gotten
to
be
more
difficult,
as
people
try
to
determine
what
subset
D
is
under,
which
conditions
the
fact
that
we're
redoing,
a
security,
BCP
and
doing
a
browser
based
apps
BCP
is
indicative
of
the
need
for
guidance
to
people
for
what
use
cases
are
solved
by
which
combinations
in
today's
security
and
identity
climate.
P
Arguably
possibly
the
most
successful,
and
it's
my
cents
not
as
an
engineer
today,
but
as
a
businessperson,
which
is
a
hat
I,
sometimes
also
wear
that
if
we
go
through
the
exercise
of
creating
an
OAuth
3
without
absolutely
compelling
motivation
for
doing
so,
we
are
splintering
the
deployment
landscape
in
a
way,
that's
probably
unhelpful
to
all
and
to
the
extent
that
we
can
solve
the
problems
that
are
being
enumerated
as
Torsten
started,
to
do
using
OAuth
2,
possibly
with
extensions.
We
know
how
to
write
extensions.
P
A
I
sorry
I
should
have
clarified
a
little
more
of
my
question.
We'll
have
a
discussion
as
to
which
approach
you
want
to
take.
The
question
is:
is
there
descent,
whether
there's
a
problem,
there's
a
number
of
there's
two
different
approaches
that
have
been
presented
or
on
how
to
solve
them?
But
do
you
not
think
there's
a
problem
I.
P
A
P
Olaf
was
designed
as
an
authorization
protocol.
One
of
the
first
things
that
we
had
to
do
as
a
community
was
also
create
an
authentication
profile
of
oweth
to
enable
people
to
log
in
called
Open
ID
Connect.
If
we
would
go
down
an
OAuth
three
route,
we
would
have
to
do
the
same
thing
again
or
we
would
be
in
a
bifurcated
world
where
authorization
sometimes
happened
with
a
new
protocol.
But
if
dedication
happens
with
an
existing
one,
I
don't
see
the
acquittal
of
it
an
ID
to
of
an
ID
token
anywhere
in
the
proposals.
F
It's
Roman
I
just
wanted
to
kind
of
jump
in
the
line
to
talk
about
facilitating
if
we
could
just
split
the
conversation
between
there
are
problems
voiced
and
kind
of
providing.
Do
we
agree
if
they're
that
those
are
problems,
then
there
are
potentially
many
ways
to
solve
those
problems,
and
we
can
have
that
as
a
separate
conversation,
but
if
we
can
help
decompose
that
you
know
that
can
help
me
cuz
help
us
make
some
progress
here.
Thank.
O
You
hadn't
come
to
know
my
words.
I
appreciate
sure
I
agree
that
this
problem,
but
I'm
not
sure
how
prevalent
those
problems
are.
Whether
these
are
you
know
the
last,
the
last
five
percent
or
whether
they're
ninety
five
but
I
doubt
there
than
95
percent
case.
But
they
may
be
the
five
percent
case
and
I'm
not
sure
that
the
approach
right
so
I'm,
not
that's
all
I'm
gonna,
say
because
the
approaches
are
we'll
get
into
later.
But
I
don't
believe
that
they're
that
prevalent
out
there
that
they
would
that
they
need
to
be
fixed.
Q
A
H
B
A
Okay,
next
would
be
what's
the
right
approach.
There's
you
know,
Torsen
was
proposing
things
that
are
extensions,
justin's
sort
of
proposing,
let's
burn
it
all
down,
and
if
we
do,
then
we
can
clean
up
a
whole
bunch
of
stuff
and
something
much
simpler.
That
I
paraphrase
that
appropriately
ok
do
when
I
get
views
on
that
yeah,
so
non
Justin,
yeah,
we've
heard
your
view.
No.
J
I,
don't
think
you
have
okay,
because
what
I'm
gonna
say
is
I
genuinely
think
we
should
do
both
I,
don't
think
I
ought
to
use
going
away
anytime
soon.
It
is
wildly
successful.
It
is
very
widely
deployed.
I
think
we
should
keep
patching
the
holes
in
the
brick
wall
as
we
find
them
and
I
think
that,
while
we're
doing
that,
we
should
be
building
the
next
system.
I,
don't
think
they
are
mutually
exclusive
and
I.
Don't
think
that
putting
our
energies
into
both
of
them
is
going
to
be
detrimental
to
either.
Okay.
A
J
So
Tony
said
they
can
use
whatever
they
want
and
I
had
agreed
with
Tony
sorry,
that
was
hard
to
say,
stop
clocks
and
what,
but
no
seriously
seriously
I
think
that
oh
oo
3,
if
we
decide
to
start
that,
isn't
going
to
be
gelled
and
done
for
the
average
developer
for
a
while.
Yet
there's
going
to
be
transition,
just
as
there
was
from
Roth
one
to
OAuth
2,
just
as
there
was
from
open
ID
to
to
open
ID
connect,
just
as
there
is
from
ipv4
to
ipv6,
but
hopefully
not
that
long.
J
But
anytime,
you
have
a
new
version
of
something
that
adds
new
capabilities
that
cleans
up
existing
issues.
There
are
going
to
be
people
still
using
the
legacy
thing
for
quite
some
time.
There
are
people
deploying
brand-new
sam'l
systems
today,
where
I
would
argue
that
generally
does
not
actually
make
much
sense
from
a
protocol
perspective
right.
J
There
are
better
systems
out
there,
but
people
can
still
use
them
and
I
think
that
if
you
are
building
out
something
today
that
o
auth
to
with
its
extensions
works
for
use
that
sure
but
I
think
there's
a
lot
of
stuff
that
it
that
doesn't
address
and
to
Mike's
previous
point
on
fragmentation.
All
of
these
extensions
are,
in
fact
fragmenting
the
OAuth
2
world
yeah.
A
N
Annabel
Backman
Amazon-
this
is
sort
of
just
a
observation
of
something
I
think
we
should
think
about
as
we
debate
this
to
make
this
decision.
N
The
people
who
are
building
applications
using
OAuth
and
using
OAuth,
2
or
3,
whatever
we
end
up
coming
up
with,
are
not
the
people
in
this
room
generally
speaking,
and
so
to
the
extent
that
we
can
make
things
make
the
right
path,
the
easy
path
for
them
to
follow.
You
know
that
is.
That
is
a
good
thing,
because
they
will
people
like
to
follow
the
easy
path
right.
They
will
follow.
The
the
you
know,
simple,
clear
path:
that's
in
front
of
them
today
with
OAuth.
N
The
simple
clear
path
is
rarely
the
actual,
secure
path
for
their
use
case,
even
with
BCPs
and
everything
you
can
try
and
guide
people
to
the
right
path,
but
unless
it's
clear
and
obvious
they
are
generally
not
going
to
take
it.
One
of
the
advantages
I
see
behind
something
like
XYZ
is:
there's
a
lot
of
opportunity
there
to
make
the
simple
easy
path.
The
secure
right
path
to
follow.
O
Tony
nedelin
I
tend
to
agree
to
doing
both
is
probably
the
right
answer.
I
think
there's
people
that
need
to
continue
on
with
OAuth
2.
The
infrastructure
has
been
based
upon
it
and
they
need
to
solve
certain
cases.
So
the
extensions
that
are
that
we're
developing
today
need
to
go
forward,
and
this
group
needs
to
continue
that
work,
but
at
the
same
time
you
know
it's
been
pointed
out
that
there
are.
You
know
these,
these
areas
that
need
to
need
attention,
and
it's
gotten
so
complex
that
no
one
can
understand
all
the
pieces
put
together.
O
I
mean
it's
gonna,
take
a
while
to
get
a
cohesive
specification
to
the
simple
to
the
simplicity,
point
that
people
can
understand
it.
So
it's
not
going
to
be
tomorrow
that
this
thing
will
come
out.
It's
going
to
be
a
couple
years
down
the
road
when
it
comes
out
and
people
you
know
need
to
continue
on
today.
They
just
can't
stop
in
their
tracks.
K
Totally
understood
I
also
support
the
position
to
work
on
both
in
parallel
I
think
X,
Y
Z.
What
X
Y
Z
gives
us
is
a
is
an
orientation
right
where
we
could
go
when
we
just
get
rid
of
all
the
legend,
see
so
starting
a
clean
slate
approach
and
with
all
the
experience
we
have
in
the
community
or
we
could
be,
what
could
we
achieve
+
and
that's
for
raw
power,
our
we
came
back
port
things
from
oh
of
X,
Y,
Z
or
3
to
what
we
now
call
off
that.
K
Oh,
that's
my
position
as
an
engineer.
I
think
that
the
really
difficult
part
is
the
message
into
the
market,
and
we
should
really
be
clear
about
that.
What
our
recommendation
is
for
developers
right
now
and
whether,
for
example,
X
Y
Z,
is
mature
enough
to
go
with
it
in
a
project
and
there's
another
aspect.
K
Even
if
we
continue
to
work
on
extending
enhancing
optimizing,
oauth2
I
think
we
also
need
to
reflect
all
of
to
refactor
clean
up
whatever
I
mean,
let's
face
it
with
the
security
BCP,
we
remove
2
grands
and
have
some
other
guidance
right.
We
modify
the
code
to
go
with
pixie
alone
and
so
on.
So
potentially
we
should
talk
about
whether
it's
time
for
updating
or
off
in
some
ways
call
it
o
of
2.1.
Something
right
also
simplify.
What
we
have
today,
just
saying
use
that
no
longer
use
that,
just
as
an
idea.
B
B
Extended
beyond
beyond
its
capabilities
as
I'm
saying,
Oh
still
being
extended,
but
at
some
point
it
became
clear
that
there
needs
to
be
a
new
version
and
in
fact
a
question
is
a
complete
overhaul
of
a
question.
1
I
question:
1
systems
are
still
very
much
out
there
and
I
think
it's
been
10
years,
so
there
will
be
a
very
long
transition
period
and,
of
course,
the
more
successful
the
protocol,
the
longer
the
transition
period.
B
B
R
R
There
is
just
too
much
for
people
to
really
implement,
and
so
I
don't
see
that
there's
any
real
conflict
between
extending
because
and
reducing,
and
if
you
reduce
you
want
to
do
that
reduction
all
in
one
go
and
not
in
a
series
of
individual
pieces,
because
you
know,
if
you
deprecated
individual
functions,
then
it'll
never
happen.
If
the
only
way
you
can
really
signal
we're,
getting
rid
of
the
old
stuff
is,
if
you
have
a
major
revision,
but
that
major
revision
doesn't
need
to
be
a
complete
change
of
syntax
like
HP
1.12,
ATP
yeah.
S
Hi
I'm
Erin
perky
from
octo.
My
job
is
literally
flying
around
teaching
people
about
OAuth,
so
I
have
a
lot
of
I've,
seen
a
lot
of
people
struggling
with
understanding.
Why
we
are
like
at
the
point
where
we're
at
with
this
today,
which
is
a
lot
of
jumbled,
specs
a
lot
to
read,
or
some
kind
of
stole,
my
Thunder
there
with
the
2.1,
but
my
idea
what
that
was
basically,
let's
capture
what
we
do
have
today
in
what
works
you
know
off,
which
is
you
know,
sending
this
core
we've
added
a
bunch.
S
We've
removed
things
through
the
various
extension
tube
ECP's
kind
of
capture
that
as
like
here's.
What
actually
here
is
the
simplest
version
of
what
does
work
today
with
the
grants,
the
extensions
that
that
are
well
deployed,
you're,
removing
things
that
are
not
good.
You
are
no
longer
necessary
and
giving
that
its
own
name,
that
that
you
know
the
intent
there
is
to
give
people
a
simple
path
of
reading.
S
You
know,
starting
with
one
document,
instead
of
trying
to
navigate
their
way
through
a
pile
of
20
and
I,
think
that
is
sort
of
the
how
I
would
want
to
approach
the
sort
of
cleaning
up
of
what
we
have
right
now
and
at
the
same
time
like
Justin,
was
say,
I
do
think
that
I'm,
a
sort
of
rethinking
from
the
ground
up
is
not
a
terrible
idea
and
I
do
think
it's
still
worth
pursuing
in
parallel.
But
that's
I
mainly
want
to
just
get
get
this
point
out
about
lets.
S
T
Brian
Campbell
with
pain,
I
sort
of
wanted
to
agree
with
Aaron
in
the
sense
that
there
are
a
lot
of
different
documents
out
there.
It
can
be
very
intimidating
and
confusing
to
come
to.
I.
Also
think,
there's
on
flip
side
of
it
there's
a
lot
of
value
to
the
different
composability
of
the
documents.
You
can
assemble
things
for
your
needs.
T
Sorry-Sorry,
better
I'm
taller
than
air
no
offense,
there's
a
lot
of
there
is
a
valuable
side
of
the
number
of
documents
as
well,
which
is
that
there's
composability
there
and
different
needs
and
deployments
can
compose
those
in
ways
that
make
sense
for
their
needs
and
we're
seeing
a
lot
of
that,
both
in
individual
deployments
and
in
like
larger
consortiums
and
other
working
groups
that
are
doing
profiles
of
this
stuff.
To
do
it.
I.
T
A
complete
rewrite
is
daunting,
I'm,
not
sure
I
would
have
the
time
and
I'm
not
sure,
there's
really
the
the
appetite
and
the
energy
to
to
apply
to
both
of
those
things
and
then
I
think
that
likely.
Another
document
at
this
point
would
even
if
it's
an
OAuth
3,
would
just
exacerbate
that
confusion
about
which
pieces
of
this
do
I
use.
Then
it's
not
which
of
the
OAuth
2
pieces,
do
I
compose
together,
but
do
I
use,
which
of
those
or
do
I
use
this
new
thing
and
do
I
wait
for
that.
Do
I?
T
How
do
they
interact
so
I?
The
old
xkdc
comic
comes
to
mind.
It's
a
few
smiles,
but
so
I,
I
guess
I.
Just
I
want
to
be
careful
in
in
how
quickly
we
we
jump
to
taking
on
to
work
and
realize
that
there's
an
impact
on
the
marketplace
is
wide
and
I
think
we
should
be
be
considered
of
that
before
we
jump
into
it
and
well,
it's
often
times
appealing
to
do
new
work
to
set
out
and
solve
all
the
known
problems
we
saw
we
know
about
in
the
last
protocol.
T
It
sounds
interesting
and
it
sounds
fun.
It's
challenging
it's
new,
but
it's
a
lot
harder
to
start
over
correct
all
the
problems
that
you
know
about
and
not
introduce
new
problems.
Then
it
then,
it
often
seems
like,
as
you
go
out
at
first
block
flash,
it's
quite
a
bit
more
time-consuming
more
challenging
than
you
might
expect,
and
we
would.
T
H
People
want
to
use
them
in
environments
which
were
not
initially
envisioned
almost
it's
the
definition
of
a
widely
successful
protocol,
and
then
you
obviously
stretch
the
boundaries
a
little
bit,
and
sometimes
you
may
need
to
ask
yourself
is
always
really
the
right
thing
for
the
given
problem
at
hand.
And
do
you
really
need
to
stretch
it
that
far
or
would
it
be
better
to
use
something
entirely
different.
A
A
F
So,
as
the
ad
of
cloth
I
mean,
I
have
talked
with
the
chairs
kind
of
extensively
on
what
happens
if
we
do
it
both
ways,
and
we
need
to
have
a
kind
of
a
broader
conversation
and
one
of
the
things
that,
in
our
conversations
that
came
up
is
we
need
to
be
a
little
more
specific
to
better
understand.
You
know
what
are
the
new
things
we
want
to
have
and
I
think
the
new
emergent
thing
in
this
conversation
here
is:
we
would
need
to
be
specific
as
to
what
gets
back
toward
it.
A
T
Was
rambling
I'll
try
to
be
less
rambling
now,
but
yes
to
some
extent,
but
more
so
have
some
concern
about
the
amount
of
just
the
amount
of
time
and
attention
available
from
participants
in
this
and
other
working
groups,
and
the
ability
to
you
know
really
just
devote
the
kind
of
time
that's
necessary
to
build
a
second
system
protocol
from
the
ground
up.
What
and
maybe
those
problems
coming
in
try
to
be
less
round
there.
Maybe
just
to
summarize
that
we've
had
sort
of
two
main
issues
come
up.
T
One
is
the
number
of
documents
currently
in
OAuth
I
think,
while
a
new
protocol
is
one
way
to
try
to
deal
with
that,
we
could
also
consider
doing
some
sort
of
this
document
or
some
sort
of
BCP
or
some
sort
of
roadmap
type
document.
That
would
be
one
way
to
work
with
that
and
in
terms
of
the
problems
with
OAuth
sort
of
hitting
the
system
limits,
hitting
the
limits
of
the
kinds
of
things
we
want
to
do.
T
There
were
a
few
well
articulated
shortcomings
today
and
there
may
be
others,
but
there
are
a
couple
or
articulated
today
and
a
couple
of
viable
extensions
to
solve
those
within
the
framework
of
OAuth.
Now
and
so
I
might
be
a
point.
That's
the
sort
of
the
incremental
path
that
is
pragmatic
to
follow.
At
this
point,
yeah.
P
Jones
Microsoft
I
I
I
will
say
that
that
I
do
see
lots
of
examples
of
the
community
when
they
see
a
real
problem,
such
as
needing
a
signed
authorization
request.
Creating
the
solution
deploying
it
standard
it.
We
need
to
finish
a
LOF
jar,
but
that's
you
know
nearly
done,
but,
for
instance,
in
the
financial
world,
the
financial
api's
in
europe
in
japan
and
some
of
the
anze's
countries
are
using
these
extensions
to
OAuth
successfully.
N
Annabel
Beckman,
Amazon,
so
I
think
a
lot
of
attention
has
been
brought
to
the
fact
that
there
is
a
whole
lot
of
different
related
drafts
or
author
related
specs,
and
it's
certainly
true,
but
there's
so
fall
into
two
different
categories.
I
feel
one
is
the
category
of
additional
features
for
a
specific
use
cases
that
that
people
might
need
the
other
is
the
category
of
stuff.
You
need
to
do
in
order
for
your
secure
deployment
to
actually
be
secure
and
I.
Think
the
big
problem
today
is
that
that
latter
category,
that
stack
is
pretty
high.
N
It's
is
a
lot
in
there
and
anybody
deploying
implementing,
deploying
this
stuff
needs
to
be
familiar
with.
All
of
that
and
some
of
the
the
reason
for
that
stack
being
there
is
in
part
because
of
incorrect
assumptions
that
are
made
when
it
was
designed
or
assumptions
that
made
sense
at
the
time,
but
no
longer
old
animal.
Yes,
all
right,
I'm,
gonna
cut
you.
A
A
T
H
F
So
III
mean
so
we're
at
a
time.
It's
obvious.
We
need
to
keep
talking
so
I
think
the
top-line
things
I
heard
is
there
is
a
number
of
problems
voiced
here.
There
is
a
recognition
that
these
are
problems
and
there's
recognition.
We
need
to
talk
about
how
we
would
solve
those
problems.
We
don't
have.
We
don't
appear
to
have
kind
of
consensus
here
for
exactly
how
we
would
tackle
them.
There
are
a
number
of
kind
of
presented
here
in
the
mic
line,
but
they
were
a
couple
I
I,
think
quite
you.
F
J
So
question
for
the
chair:
this
is
Justin.
Where
should
that
conversation
take
place,
because
we
did
stand
up
the
TX
off
list
ahead
of
this
Boff
to
start
things
off
I
know
a
lot
of
the
people
are
already
on
that
list.
We
do
also
have
the
OAuth
list,
which
is
gigantic
so
where?
Where
should
we
have
that.
F
Given
that
we're
trying
to
talk
about
where
to
do
the
work
and
we've
started
it
here,
potentially
Cheops
I
would
say
that
we
use
TX
author
right
now
to
to
kind
of
sort
that
out
and
we
can
make
that
clear
on
the
OAuth
list
and
in
the
OAuth
meetings
kind
of
as
well.
So
again,
what
I
think
we
have
consensus
on?
We
have
a
problem.
What
we
don't
have
consensus
on
is
how
to
tackle
that,
and
we
need
anything
sort
that
out.