►
From YouTube: OAuth WG Virtual Interim Meeting, 2020-04-20
Description
OAuth WG Virtual Interim Meeting, 2020-04-20
A
Okay,
let's
go
so
this.
Is
that
not
well
just
a
reminder?
We
still
am
under
the
they're,
not
well
so
make
sure
make
sure
you're
aware
of
this
and
understand
this.
This
is
the
series
of
meetings
that
we
we
are
planning.
So
as
a
reminder,
we
still
have
three
more
to
go
and
today
is
mainly
thurston
will
walk
us
through
the
par
and
and
our
presentations.
D
B
B
Okay,
thank
you
very
much
so
hello,
everybody.
So
the
first
topic
of
today
is
the
current
status
of
pushed
authorization
requests
draft.
I
will
quickly
flip
through
the
the
concept
and
then
present
you
some
of
the
open
issues
that
we
currently
see
and
that
we
would
like
to
discuss
with
you.
B
We
meaning
all
the
others
that
you
can
see
on
the
slides
of
brian
net.
Hey
phillip
and
myself,.
B
All
right,
what's
pushed
authorization
request,
so
basically
it's
a
new
endpoint
that
allows
a
client
to
instead
of
sending
the
authorization
request
payload
through
the
browser
allows
that
clients
to
push
that
payload
in
a
back
channel
direct
request
to
the
oauth
authorization
server
and
the
authorization
server
and
term
provides
the
client
with
a
so-called
request
ui.
B
This
concept
has
been
introduced
by
the
jaw
drafts,
which
I
think
yesterday
had
been
updated
to
21
and
this
this
request
ui,
is
then
used
as
the
parameter
to
to
initiate
the
authorization
request
with
the,
as
this
par
draft
supports
two
different
modes
of
operation.
B
B
So,
let's
first
quickly
take
a
look
onto
how
power
changes
the
way
clients
use
oauth.
What
you
can
see
here
is
a
traditional
oauth
request.
So
all
the
parameters
are
added
to
the
request.
Ui,
as
your
iquery
parameters
and
power
now
takes
the
same
parameters
in
more
or
less
the
same
encoding
and
sends
them
via
a
post
request
to
the,
as
and
as
you
can
see,
because
it's
it's
marked
in
bold.
B
B
Instead
of
sending
something
with
the
ui,
you
send
the
same
data
in
a
post
request
to
the
back
end,
but
as
we
will
see
the
consequences
and
the
effect
are
pretty
significant.
B
The
aes
answers
with
a
reference
to
the
data,
the
client
just
pushed
to
the
back
end
and
this
data
this
request
ui,
is
then
in
turn
used
as
a
reference
to
this
data
in
the
authorization
request
and
the
authorization
request
parameter
request.
Ui,
that's
being
used
has
been
defined
in
the
jar
specification,
so
par
in
the
end,
utilizes
a
parameter
that
was
introduced
with
hr
specification.
B
And
the
benefit
is
significant.
First
of
all,
there
is
support
for
large
authorization
requests,
so
a
post
request
can
basically
contain
more
or
less
unlimited
data,
which
also
means
that
more
complex
authorization
requests.
For
example,
if
you
use
the
claims
parameter
of
open
id
connect
or
the
authorization
details,
parameters
that
we
will
talk
about
in
the
next
yeah
next
presentation,
you
can
use
those
without
any
problems
regarding
the
robustness
of
your
authorization
requests.
B
Moreover,
the
request
is
protected
by
tls,
so
transport
layer
security
gives
you
integrity
and
confidentiality
protection
and
at
least
for
confidential
clients,
so
that
that
holds
true
for
confidential
and
public
clients,
which
is
a
very
important
aspect,
because
you
don't
need
to
set
up
client
credentials
to
to
to
make
that
happen
even
for
public
clients,
and
if
you
are
using
that
with
confidential
clients.
B
The
ais
is
also
able
to
authenticate
the
client
and
to
authorize
the
client
and
validate
authorization
request,
pre-order
start
of
the
user,
interaction
which
means
early
refusal
as
possible
before
the
user.
Interaction
has
been
started,
which
is
much
more
robust
than
sending
redirects
back
and
forth,
and,
and
that's
the
that's,
the
the
second
mode.
If
you
use
the
signed
request,
option,
then
par
also
gives
you
non-repudiation
with
cryptographically.
B
Underpinning
the
status
the
current
status
of
the
draft
it
has
been
adopted
by
the
working
group,
I
think
it
was
in
december
or
in
january
I
don't
remember,
but
around
around
this
time.
Thank
you.
Thank
you
very
much
for
all
of
you
that
that
voted
in
favor
of
adopting
the
spec
and
it's
already
been
used
in
in
several
places.
B
So
to
start
with
the
financial
grade,
api
working
group
at
the
openid
foundation
made
part
a
part
of
the
new
happy2
baseline
profile,
and
there
are
quite
a
several
implementations
out
in
the
field
in
different
programming,
languages
and
different
frameworks
and
products,
and
it's
also
already
been
used
in
in
several
projects.
B
Just
to
name
a
few.
The
eid
system
in
norway
just
introduced
power
as
part
of
their
solution,
and
we
at
yes
also
use
power
as
part
of
our
electronic
signature
service
and
it
replaced
the
previous
solution
that
used
lodging
intents
so
typed
resources
representing
complex
authorization,
quests
with
a
simple,
straightforward,
robust
mechanism
and
there's
also
implementation
planned
in
the
norwegian
e-health
system
and
as
part
of
happy
2,
it's
being
proposed
as
part
of
the
australian
custom
or
data
rights
initiative.
B
So
there's
a
lot
of
things
going
on
feedback
so
far
is
is,
is
pretty
good
because
it's
a
simple
mechanism
which
really
has
a
has
a
lot
of
benefits
from
from
both
and
so
client
and
authorization
server.
But
there
are
still
some
topics
to
be
solved.
B
There's
one
that
was
raised
on
the
list,
and
this
is
about
yeah.
A
deviation
between
the
jar
spec
and
the
power
spec
and
jar
defines
that
the
request
ui
must
refer
to
a
jwt,
but
obviously,
in
the
case
of
power.
This
is
not
as
important
since
the
object.
The
request
ui
points
to
is
being
produced
and
consumed
by
the
same
entity,
which
is
the
authorization
server
and
yeah
annabelle,
proposed
some
wording
how
we
could
more
or
less
relax
that
requirement
in
the
par
spec.
B
And
I
would
like
to
raise
that
question
here
as
well,
so
rethought.
How
do
we
handle
q
management
and
and
and
people's
yeah.
F
I'm
I'm
in
favor
of
this
wording
that
annabelle
proposed.
I
guess
it
would
be
nice
if
well,
the
jar
seems
sort
of
past
being
able
to
make
any
changes
in
this.
This
is
a
nice
elegant
way
of
dealing
with
the
particular
policy,
so
I
would
like
to
see
this
incorporated.
E
When
you
say
brian
incorporate
it
where,
where
would
you
in
that
most
likely
this.
E
The
char
document
to
relax
those
rubbing
a
little
bit
right.
G
A
E
D
So
another
another
way
to
deal
with
the
contradiction:
if
we're
not
looking
to
actually
change
jar
change,
the
the
wording
in
jar
is
to
use
a
different
query
parameter
other
than
request
uri.
D
The
requirements
and
things
that
are
in
jar,
but
without
using
it
directly
now
I
personally
like
the
elegance
of
combining
the
solutions,
but
oh
and
yes,
sorry,
this
is
justin
richer
and
I
I
personally
kind
of
liked
the
elegance
of
combining
those
different
parts
of
the
solutions.
But
the
truth
is
jar
was
built
at
a
much
earlier
time
with
different
things
in
mind
and
therefore
we
get
ourselves
into
kind
of
a
kind
of
weird
place
where
we
have
to
say.
E
Different
roman,
where
how
how
far
along
are
we
with
char
to
make
such
a
change.
E
In
the
char
document,
when
I
look
at
the
the
status,
it's
still
an
is
cheap
sort
of
like
processing,
so
ad
follow-up,
so
it
doesn't
look
like
it
needs
four
more.
Yes,
so
I
think
it's
still
it's
still
in
a
place
where
it
can
change.
I
E
It
needs
to
be
that
traumatic.
It
may
see
other
changes
being
folded
in
doing
the
isg
processing,
so
that
could
be
another
one.
If
the
group
thinks
that
that's
a
good
idea.
G
Yeah,
I
think
you
may
have
just
answered
my
question,
but
it
was
my
question
was
more
along
the
lines
of
how
big
a
change
to
jar
is
this
right,
I
mean
jar
is
trying
to
ensure
that
there's
consistency
in
the
object,
because,
in
that
context
the
request
uri
references,
something
outside
the
aes
right,
so
I
mean
I
think,
if
it
can
be.
You
know
a
very
like
a
similar
sort
of
concept
to
what
annabelle
proposed
here
within
jar.
That
basically
says
if
the
request
uri
is,
you
know
effectively
if
the
entity
generating
the
request.
G
Uri
is
the
same
as
the
entity
consuming
the
request.
Uri
then
right
the
the
requirement
of
it
of
it,
pointing
at
a
jwt,
you
know,
doesn't
stand
or
whatever
I
agree
to
justin's
point.
It
gets
a
little
a
little
weird,
because
how
the
request
uri
is
being
used
is
a
little
bit
different
right.
G
It's
a
little
bit
different
of
a
semantic,
whereas
in
in
par
it's
more
of
a
session,
it's
more
of
a
session
reference
right
or
or
an
authorization
reference,
an
authorization
request
reference
and
which
is
a
little
bit
different
of
a
semantic
than
the
request
uri,
which
is
basically
telling
the
as
go
pull
this
object
from
some
other
site
and
to
be
completely
clean.
Using
justin's
suggestion
to
use
another
parameter.
Name
is
probably
the
cleanest
from
a
semantic
perspective.
B
Okay,
it
sounded
like
there
was
a
response
to
george.
I
don't
want
to
say
I
wanted
to
say
something:
do
I
need
to
add
to
the
queue
as
well
or.
B
Okay,
so
I
personally
would
like
to
hear
the
opinion
of
implementors
that
already
implemented
par.
I
see
philip,
is
in
the
call
anyone
else
that
already
already
has
implemented
power
hasn't.
D
So
in
our
implementation
at
athlete,
we
were
able
to
reuse
a
lot
of
the
machinery
for
doing
request
uris,
but
the
way
that
we
managed
this
was
kind
of
doing
what
bell
says
in
the
text
here
in
that
we
were
able
to
recognize
uris,
that
we
know
that
we
generated
because
we
generated
them,
and
then
we
branch
our
we
branch,
our
processing,
based
on
that.
D
So
it
just
so
happens
that
our
underlying
data
model
uses
all
the
same
fields
that
a
request
object.
Would
you
know
you
wouldn't
have
to
do
it
that
way?
But
the
important
thing
is
that
the
requirement
of
jar
ultimately,
is
that
the,
as
has
to
be
able
to
understand,
what's
at
the
other
end
of
the
mri
when
it's
not
generated
by
the,
as
that
must
be
a
jot
when
it
is
generated
by
the
as
we
really
don't
care.
D
The
cleanest
thing,
apart
from
having
a
new
parameter
with
newly
defined
semantics,
would
be
to
have
jar
fix
that
language.
Now.
I
will
also
add
that
I
believe
my
reading
of
the
intentions
of
several
bits
of
jar
on
in
conversations
on
the
list
with
nat,
who,
I
don't
believe,
is
on
a
call.
D
My
understanding
is
that
the
intention
was
not
to
have
it
restricted
for
this
kind
of
use
case.
It's
just
that
this
use
case
is
completely
outside
of
that.
So
there
used
to
be
language
in
jar
that
it
had
to
be
an
http
url,
for
example,
or
there
was
language
that
assumed
that
it
was
an
https
url
specifically,
even
though
it
was
defined
as
a
uri.
D
So
I,
if
we're
able
to
tweak
the
language
in
jar,
so
that
the
requirements
are
conditional
in
the
way
that
annabelle
recommends
here,
we
would
be
much
better
off
than
trying
to
back
patch
that,
and
I'm
with
hannes.
I
think
that
that
is
actually
not
changing
the
intention
of
the
specification,
and
you
know,
modulo
what
the
ads
say.
I
think
I
would
personally
say
that
that
fits
within
this
sort
of
late
round
edit,
because
we're
not
we're
not
changing
the
requirement,
we're
clarifying
what
we
meant
by
the
requirement.
J
All
right,
philip
scocan
here
is
one
of
the
one
of
the
implementers
similar
to
what
justin
just
said.
Since
this
reuses
the
same
parameter,
I
was
able
to
use
a
lot
of
the
existing
middleware
pipeline
to
process
the
request
when
it's
part
of
a
push
authority
or
authorization
request,
endpoint
or
or
as
the
the
regular
authorization
endpoint.
A
B
E
Yeah,
I
think
I'm
mailed
to
the
list
with
the
suggested
wording
so
that
we
can
confirm
this
with
on
the
list
which
we
have
to
do
anyway,
would
be
good,
and
then
we
can
take
that
step
and
roman
can
then
sort
of
pass
this
along
to
the
ist
as
they
are
making
their
reviews
anyway.
H
Right
thanks
for
saying
that
harness
yeah,
I
want
to
see
the
the
proposed
kind
of
text.
Oh
you
know
in
writing
before
I
commit
to
us
being
able
just
to
do
this
as
a
late
stage,
edit
versus
kind
of
re-running
it
through.
B
B
I
can
I
can
get
in
contact
with
nat
and
talk
to
him.
What
do
you
think
about
that
and.
E
What
we
have
to
just
bring
this
sort
of
posted
to
the
list
anyway,
where
he
and
and
everyone
else
sees
it,
because
it's
not
a
you
know,
it's
not
his
document.
It's
it's.
The
working
group's
talking.
A
B
To
yeah
I
I
just
wanted
to
reach
out
to
ned.
I
mean
I
had
expected
him
to
attend
today,
but
he
also
commented
on
that
exactly
that
topic
in
my
slide
deck
I
I
was
just,
would
just
reached
out
to
him
and
put
see
out
see
whether
we
can
sort
it
out
quickly.
So
I
mean
okay.
B
Here's
my
proposal
step
one.
I
talked
to
the
editors
net
and
john
step.
Two
we
come
come
up
with
a
joint
proposal
that
will
be
my
objective
and
we
post
that
to
the
list.
Yeah
perfect.
H
Hey
just
so,
I
can
summarize
to
make
sure
I
I'm
tracking
so
based
on
this
conversation.
The
editors
are
gonna
chat:
how
to
synthesize
it
they're
going
to
put
a
proposal
on
the
mailing
list.
The
the
group
can
kind
of
talk
about
it
and
from
there
we
can
decide
how
to
best,
if
at
all
jam
it
into
whatever
document
is
required.
Right,
yep.
B
So
next
topic,
okay,
so
there
are,
I
think,
two
more
topics.
No
three
topics,
question
regarding
time:
management
to
the
chairs.
It's.
A
B
I
would,
I
would
quickly
flip
flip
over
those
on
just
to
give
people
an
impression,
and
then
I
think
we
have
to
handle
it
in
a
traditional
way
by
sending
messages
or
posts
to
the
list
yeah.
So
so
three
more
topics
of
first
one
is:
can
the
as
require
par.
It
was
a
topic
that
brian
brought
up
on
the
list
recently,
which
basically
means,
from
my
perspective,
the
as
is
requiring
the
request
ui
instead
of
a
traditional
request
or
authorization
request
and
additional,
also
par
yeah.
B
Next
topic
is:
if
an
as
may
require
a
request
object.
I
mean
it's
it's
it's
a
similar
topic
right.
What
can
the
as
require
regarding
client
functionality?
Either?
The
client
may
specify
that
it's
only
using
request
object
or
there
is
an
asy
policy
in
place
that
enforces
the
same
for
a
certain
deployment
or
ecosystem.
B
B
So,
as
I
said,
I
propose
we
send
posts
to
the
list
regarding
those
different
topics
and
get
your
feedback.
Your
thoughts
and
contributions
on
our
topic
sounds
good.
B
B
B
From
my
perspective,
the
requirements
behind
reach
authorization
requests
very
much
came
from
the
open
banking
space
and
electronic
signing,
because
we
saw
there
that
a
simple
scope
is
simply
not
sufficient
to
to
fulfill
the
requirements
of
of
of
those
of
those
areas.
B
On
the
right
hand,
side,
you
see
an
example
of
a
request
for
payment
initiation,
which
contains
a
lot
of
data
that
needs
to
be
passed
on
and
consented
by
the
user.
So
traditional
or
solutions
that
have
been
implemented
in
the
last
couple
of
years,
typically
use
external
resources,
capturing
this
kind
of
requirements
and
then
link
those
resources
in
the
request
with
authorization
details.
B
I
think
we
have
a
much
better
solution
and
basically-
and
I
will
come
to
back
to
that
later-
on
authorization
details
is
based
on
on
work
that
justin
has
done
in
oauth
xyz,
so
there
is
a
similar
structure
in
xyz.
I
also
contributed
to
that.
So
it's
it's.
It's
kind
of
a
back
part
of
things
that
were
done
in
xyz
to
the
off
space
to
to
leverage
that
functionality
to
a
lot
of
clients.
B
The
nice
thing,
with
a
rich
authorization
request
is
that
also
different
authorization
requirements
for
different
resources
can
be
combined
in
the
same
request.
So
in
that
case,
for
example,
we've
got
a
request
for
payment
initiation,
but
also
request
for
access
to
account
information,
but
you
can
mix
and
match
other
other
elements
as
well
and
because
it's
structured,
you
can
clearly
delineate
what
data
belong
to.
B
What
kind
of
request
and
the
result
of
there
is
a
set
of
common
elements,
common
data
elements
that
are
predefined
by
the
by
the
specification
that
help,
for
example,
to
to
define
what
concrete
resource
a
authorization
requirement
is
related
to.
So
you
can
say:
okay,
this.
B
This
requirement
for
payment
initiation
goes
to
the
resource
located
at
example.com
payments,
whereas
the
account
information
is
related
to
to
another
resource
server,
which
also
gives
some
indication
regarding,
in
the
end
filtering
of
of
authorization,
details
that
are
attached
to
certain
access
tokens
and
coming
up
with
a
solution
for
all
the
infrastructure,
access
tokens.
B
The
author
authorization
details
parameter
can
be
used
basically
everywhere,
where
the
scope
parameter
can
be
used.
So,
in
a
traditional
authorization
request
in
a
pushed
authorization
request
in
a
cbar
request,
in
whatever
everywhere
we
can
use
the
scope
parameter,
including
the
token
request,
you
can
use
a
authorization
details
parameter
on
the
right
hand,
side.
You
see
a
use
of
the
authorization
details
in
the
context
of
a
push
authorization
request
and,
in
the
end,
push
authorization
request.
A
bit
was
triggered
by
the
work
on
ridge
authorization
request,
because
we
we
realized
our
requests.
B
Authorization
requests
are
getting
much
bigger
and
we
need
to
way
to
to,
in
a
robust
fashion,
in
a
secure
profession,
to
convey
this
data
to
the
authorization
server.
So
that's
why
par
and
rar
perfectly
go
together.
B
All
right
advantages,
first
of
all,
it's
a
flexible
and
type
safe
way
to
represent
written
authorization
data
because
it's
structured
because
we
use
json,
but
it's
also
type
save,
because
there
is
an
indicator
or
a
identifier
for
the
type.
If
you
want,
you
could
use
the
type
field,
for
example,
to
cut
to
carry
the
identifier
of
your,
for
example,
json
schema
and
in
the
end
that
allows
to
really
define
structures
for
authorization,
details
that
are
api
or
resource
server
specific.
B
B
This
comes
at
a
cost
because,
in
the
end,
the
authorization
server
needs
to
be
able
to
interpret
this
data
structures.
But
from
my
perspective,
this
complexity
already
exists
because
the
requirements
already
exist
and
the
use
case
already
exists.
But
the
way
the
data
were
passed
to
the
as
we're
different
homegrown
in
the
last
couple
of
years
and
more
complex
than
what
we
now
have.
If
foreign,
we
also
have
defined
some
common
data
elements,
first
of
all,
to
as
a
required
elements,
but
also
to
address
common
use
cases.
B
All
right
current
status-
the
draft
already
also
has
been
adopted
by
the
working
group
here
again.
Thank
you
very
much
for
your
support
and
for
voting
in
favor
of
the
recent
authorization
request,
spec
and
in
the
same
way
as
power.
Also,
roar
has
been
adopted
by
the
openid
foundation's
happy
working
group
as
powers
part
of
their
baseline
profile,
and
there
is
there
is
some
really
good
implementation
experience
right
now.
B
The
first
point
is
because
it's
a
back
port
from
o
of
xyz.
We
also
more
or
less
leverage
the
experience
that
we
are
drawn
by
implementing
xyz
and
in
different
programming
languages
and
there's
also
product
support,
offly
implemented
already
and
there's
projects
using
rar.
B
So
in
the
novoritian
e-health
system,
it's
being
used
on
the
before
mentioned
solution
for
electronic
signature
uses
rubber,
and
I
also
have
been
informed
that
the
norwegian
tax
system
will
be
introducing
rar
this
atom
for
authorization
requests
in
the
context
of
text,
declarations
for
small
and
medium
businesses
and
yeah
again.
Also,
this
mechanism
was
proposed
as
part
of
happy2
for
adoption
by
the
australian
customer
data
rights
initiative.
B
So,
there's
a
lot
of
things
going
on
and,
interestingly
also,
the
xov
proposal,
which
is
the
second
proposal
for
the
txof
working
group,
also
adopted
authorization
details
in
the
end,
it's
coming
back
into
the
tx
off
initiative,
in
contrast
to
rar
to
par.
I
think
rar
needs
a
lot
more
work
in
this
working
group.
The
base
design
works.
This
has
been
shown
by
the
different
implementations
that
has
been
conducted
in
the
last
couple
of
months
and
also
the
previous
work
in
the
open
banking
space.
B
But
a
lot
of
details
need
to
be
worked
out
and,
as
and
justin
pointed
out
in
a
in
one
of
our
conversations,
the
difference
between
rawr
and
what
xyz
does
raw
has
also
to
to
handle
scopes
and
and
resource
indicators,
and
so
on.
We'll
come
back
to
that
in
the
open
topics
or
open
issues,
and
I
assume
there
might
be
a
need
for
additional
features:
some
implemental
feedback,
for
example.
B
We
are
in
intensive
discussions
with
people
in
the
australian
cdr
initiative
around
also
adding
a
grant
management
facility
that,
in
the
end,
also
has
a
relation
to
to
rar,
because
in
the
end,
the
authorization
details
will
be
part
of
the
grants
that
the
user
consents
to
and
the
as
needs
to
manage.
B
First,
as
I
pointed
out,
interplay
with
scope,
audience
the
resource
parameters
and
and
claims
in
the
in
the
in
the
tokens
still
needs
more
work,
and
I
really
ask
anybody
in
the
call
to
read
the
the
draft
and
and
give
us
feedback
on
that
topic.
B
For
example,
takataka
from
from
all
fleet
gave
us
very
valuable
feedback
on,
especially
on
the
use
of
the
resource
parameter
in
conjunction
with
authorization
details.
But,
as
I
said,
there
is
more
work
to
do
and
I
hope
to
get
more
substantial
feedback
from
implementers.
B
Then
there's
also
this
that's
a
similar
topic
use
of
the
authorization
details
parameter
in
a
token
request
to
narrow
down
previously
granted
content,
which
makes
a
lot
of
sense
because,
especially
in
used
in
conjunction
with
the
off
code
flow,
a
client
may
ask
for
a
lot
of
authorization
details
but
then
narrow
down
a
certain
access
token
to
a
certain
authorization,
detailed
scope.
B
Given
the
structure
of
authorization
details
then
there's
the
question
of
required
versus
useful
common
elements.
The
spec
right
now
does
not
really
distinguish
clearly
between
those.
I
think
the
only
thing
we
say
is
that
type
is
a
is
a
required
parameter,
but
we
need
to
be
more
specific
on
that
and
then
we
need
more
feedback
on
that
topic,
as
well
as
rar
is,
is,
is
a
back
part
of
what
has
been
done
in
xyz.
B
We
should
try
and
we
need
to
try
to
keep
an
alignment
between
rar
and
txof
back
and
forth,
because
there
will
be
implementation
experience
on
one
side
and
there
will
be
implementation
experience
on
the
other
side
and
we
need
to
make
sure
that
we
really
consider
all
those
experiences
in
both
places,
even
if
those
are
living
in
different
working
groups.
But
since
we
have
an
overlap
regarding
the
authors
and
editors
of
those
specifications,
I
think
we
are
very
good
prepared
for
that.
B
We
also
get
the
question
of
how
schemas
and
versioning
work
with
authorization
details
and,
yes,
we
need.
We
need
guidance
on
that.
B
We
already
had
this
cast
the
topic
of
versioning
and
we
came
up
with
the
conclusion
that
we
don't
need
specific
versioning
support,
but
if
an
application
wants
to
use
different
versions
of
a
authorization,
detailed
object
and
use
different
type
identifiers,
including
a
kind
of
version
identifier
in
the
same
way
as
most
cases
done
with
urls-
and
there
is
another
topic
the
last
on
my
list-
and
I
will
have
another
slide
on
that
to
to
in
more
in
detail-
illustrate
what
the
challenge
is,
and
this
is
enrichment
of
authorization
details
in
the
token
response
and
the
the
basic
the
basic
idea
behind.
B
That
is
that,
in
the
course
of
the
authorization
process
it
might
happen,
and
it
happens
that
the
data
in
the
authorization
details
object
are
being
enriched
either
because
the
user
decided
something,
for
example.
If
you
want
to
do
a
payment,
the
user,
for
example,
might
have
selected
a
account
or
if
the
reliant
party
wants
to
access
certain
accounts,
the
user
might
selected
might
have
selected.
Those
or
the
ais
meets
a
policy
decision.
For
example.
B
How
long
is
this
authorization
details,
objects,
gonna,
be
valid
and
the
current
idea,
although
it's
not
in
the
spec,
yet
is
to
to
allow
the
as
to
provide
the
the
client
with
that
enriched
authorization
details
object,
including
all
this
data
that
were
determined
in
the
course
of
the
authorization
process,
but
the
client
says
the
client
has
all
the
information
that
needs
to
understand
the
authorization
or
the
access
token
and
the
range
and
the
and
and
the
scope
of
the
access
and
the
refresh
token,
and
potentially
also
some
data
that,
in
the
end,
will
be
used
to
parameterize
apis.
B
Here
on
the
live
left
hand
side,
you
see
an
authorization
request
for
account
information.
It
just
says
I
want
to
access
the
list
of
accounts
and,
yes,
I
want
to
have
recurring
access,
and
our
assumption,
though,
is
that
in
the
course
of
the
process,
the
user
decided.
Okay,
this
this
client
is
going
to
get
access
to
one
of
my
current
accounts
and
one
of
my
credit
cards
and
the
duration
of
this
authorization
is,
I
think,
it's
today
it
might
have
been
expired
already.
B
Yeah
we
at
yes
come
find
out,
found
that
very
useful
in
the
design
of
one
of
our
apis,
and
we
think
it
makes
sense
to
have
that
in
the
spec
and
in
the
end,
from
my
perspective,
it's
it's
lined
with
even
with
as
texan
rc
6749,
where
the
scope
value,
for
example,
is,
is
reflected
in
the
token
response,
if
the
as
modified
the
initial
parameter
value
that
were
sent
in
the
orders
in
the
original
authorization
request,
all
right,
that's
it
potentially,
my
co-authors
want
to
jim
in
and
raise
other
topics.
A
A
G
G
Get
off
mute
so,
as
you
know,
trust
I'm.
I
I
love
this
idea
and
I'm
actually
looking
to
steal
it
for
a
couple
of
other
things.
The
the
general
concept,
I
think
the
interop
part
of
it
is
going
to
be
really
difficult
because
it
really
feels
like
we're
enabling
fine-grained
authorization
and
everybody's
fine-grained
authorization
model
is
different
right,
so
every
as
is
going
to
have
a
different
set
of
types
and
accounts
and
things
that
are
related
to
the
transactions
that
they
do.
G
So
I
think
we're
going
to
have
to
be
a
little
bit
careful
about
what
interop
means
in
that
context
and
and
allow
that.
But
you
know
in
basic
because
effectively
all
you're
really
saying
is,
I
can
send
an
authorization
details
in
and
I
can
get
a
response
back
and
as
long
as
I'm
doing
whatever
the
as
knows
about
right,
it'll
work
right.
G
If
I,
if
I
take
a
type
from
a
different
as
from
as1
and
send
it
to
as2
the
likelihood
that
as2
will
recognize,
that
is
small,
and
I
think
it
also
puts
the
expectation
that
there's
a
lot
more
smarts
in
the
client
right
oatu,
you
know,
was
trying
to
make
the
clients
be
somewhat
dumb.
This
requires
the
clients
to
actually
have
a
high
sub
a
high
knowledge,
especially
if
you're
talking
about
mobile
apps,
a
high
knowledge
of
the
fine-grained
authorization
model.
None
of
that,
I
think,
is
a
problem.
G
B
B
The
first
one
is
just
the
container:
that's
not
that
difficult,
I
think,
and
the
other
layer
is
on
the
level
of
the
type
and
for
me,
in
my
mental
model,
the
type
of
authorization
details
object
goes
along
with
a
certain
api
specification
of
a
certain
api
and
so
on.
So
if
that
api
is,
for
example,
being
implemented
by
different
deployments,
then
the
asses
of
those
different
deployments
needs
to
understand.
G
G
We
have
this
set
of
interoperable,
like
open
banking
apis
and
for
those
we
will
define
these
set
of
types
that
you
can
use
right
and
therefore
we
get
interop
across
an
organization
within
that
namespace
right
or
within
that
sort
of
problem
vertical
right
and
then
other
places
may
have
other
problem.
Verticals
with
you
know
their
details,
their
detailed
types,
but
that
should
be
left
out
of
sp
out
of
scope
from
the
rar
perspective.
So
I
think
we're
in
agreement
there
yeah.
D
Yeah
plus
one
to
everything,
fourson
just
said,
but
also
that
I
think
there
are
actually
about
two
and
a
half
layers
of
of
interim
and
I'll,
explain
why
it's
a
half,
because,
in
addition
to
defining
the
type,
I
do
think
it's
both
important
and
useful
that
we
define
a
set
of
sort
of
common
dimensions
to
this.
D
Authorization
request
object
that
different
apis
can
reuse,
otherwise
we're
just
going
to
go
into
a
space
where
people
are
saying
the
same
thing
in
syntactically
different
ways
for
no
good
reason.
Now,
if
you
have
a
reason-
or
you
just
want
to
define
your
own
term
and
your
own
meaning
for
that
term
within
your
api
sure,
I
think
we
should
allow
that
and
the
specs
shouldn't
restrict
that.
D
But
I
think
that
people
are
going
to
be
looking
for
things
like
this
is
the
set
of
urls
or
url
patterns,
or
something
like
that
that
I
can
use
this
on.
You
know
these
are
the
sets
of
verbs
that
I
can
use.
You
know
the
read
versus
right
type
of
things
which
we
put
under
actions.
D
I
think
it
was
called,
and
so
there's
things
like
that-
that
we
can
define
that
people
can
reuse
if
they
want
to
brian's
raised
a
really
good
point
in
conversation
and
that's
the
question
of
how
do
we
define
you
know
how
strictly
do
we
define
those
terms
such
that
if
I
have
a
type-
and
I
want
to
redefine
one
of
those
common
fields
to
mean
something
that's
specific
to
my
api?
Am
I
allowed
to
do
that?
D
That's
one
of
the
interrupt
questions
that
this
group
is
going
to
have
to
have
a
concrete
answer
for
so
yeah.
I'm
I'm
with
george
that
interop
for
this
is
going
to
be
difficult,
but
the
layered
approach
is
absolutely
the
way
to
go
here,
because
ultimately,
interoperability
for
this
stuff
is
going
to
be
defined
by
the
apis,
that
it's
protecting.
I
Hi,
this
is
matt
from
coyle,
yeah,
torsten
and
justin.
Thanks
for
this,
this
work
like
it's
definitely
as
somebody
who
try
to
implement
something
with
like
access
to
accounts
and
trying
to
push
it
into
scopes.
I
The
reason
being
is
like
I
just
don't
think
that,
like
a
lot
of
the
cases
that
are
going
to
use,
this
are
going
to
be
very
specific
anyway,
and
if
you
look
how
people
are
implementing
oauth,
like
there's
very
few
things
that
they
would
be
doing
where
it
requires
this
complexity,
where
things
are
going
to
be
uniform
across
the
whole
stack
and
that
yeah,
I
would
just
say,
be
cautious
about
trying
to
add
too
much
too
much
normative.
I
Language
in
here,
like
I,
like
already
being
like
using
this
you'd,
probably
be
doing
like
custom
stuff
already
at
that
level,
and
I
think
then,
that
layer
of,
like
people
developing
sort
of
what
you'd
call
like
as
level
schemes
for
authorization
details.
Those
asses
can
be
interoperable
if
they
all
understand
what
they're
asking
for
and
that's
fine.
A
B
B
B
D
No,
I'm
good
you've
covered
the
main
points
that
I
care
about.
Thank
you.
A
Okay,
then,
I
think
we're
done
for
today,
yeah.
That
was
good
thanks,
thorsten
appreciate
that
and
we'll
see
you
next
week,
guys.