►
From YouTube: OAUTH WG Interim Meeting, 2021-04-05
Description
OAUTH WG Interim Meeting, 2021-04-05
A
C
A
To
present
the
slides
or
show
the
slides
sure
I
can
do
that
yeah,
because
we
are
two
presenters
today
I
will
present
the
first
half
of
the
slides
and
justin
will
take
over
them
all
the
rest
of
the
slides
sounds
good.
D
Sounds
good,
no
problem.
Okay,
let's
get
going
then
again
a
note,
well
a
reminder
that
this
not
well
applies
here,
and
this
is
the
list
of
interim
meetings
today,
we'll
be
talking
about
rar,
thurston
and
justin
will
be
presenting
next
week.
Hopefully,
daniel
will
talk
to
us
about
security,
bcp
and
notice
that
I've
added
also
a
new
enter
meeting
for
may
3rd
to
continue
that
discussion
about
oauth
2.1.
D
E
F
F
You
see
my
slides
or
that,
yes,
okay,
we
see
the
intermediate
slides.
Oh.
A
A
A
D
Has
hasn't
done
that?
Please
add
your
name
and
let's
get
going
it's
yours,
okay,.
A
A
The
rich
authorization
request
draft
next
slide.
Please
there
is
authorization
request.
Giraffe
was
adopted
as
working
good
grant.
I
think,
a
year
ago
I
think,
during
the
last,
the
last
physical
or
in
presence
itf
meeting
in
singapore
and
what
it
does.
It
introduces
a
new
parameter
authorization
details
that
allows
an
application
to
convey
fine-grained
authorization
data
in
the
form
of
json
objects.
A
The
idea
came
up
when
we
had
the
fappy
working
group
at
the
openid
foundation
analyzed
a
couple
of
standardization
efforts
in
the
open
banking
space,
where
we
saw
a
lot
of
different
patterns
that
were
used
to
convey
structured
and
also
transaction
specific
authorization.
Data
which
wasn't
possible
is
not
possible
with
the
scope
as
it
sounds
today
and
based
on
what
we
learned
there.
The
proposal
was
made
to
use
the
json
structure
that
we
that
we
now
have
in
the
authorization
details
parameter.
A
So
there
are
other
use
cases
as
well.
That
inspires
the
development
of
a
rower
and
those
are
also
factors
where
raw
already
is
being
adopted.
Open
banking
is
already
mentioned,
see
the
over
in
australia
and
fdx
in
the
us
are
taking
a
look
into
using
rawr
in
e-health,
norwegian,
e-health
sector.
They
are
already
using
rar
and
the
cloud
signature
consortium,
the
standardization
body
for
remote
signature
creation
apis
also
decided
to
adopt
rich
authorization
requests
on
the
right
hand,
side.
A
You
can
see
an
example,
so
a
rich
authorization
request
always
has
a
type
field,
so
the
authorization
server
can
determine
the
type
of
the
authorization
object
in
kanban,
based
on
the
type
yeah
determine
how
to
process
a
certain
type.
In
that
case,
it's
an
example
of
a
authorization
for
a
payment
initiation.
A
So
it
tells
us
what
currency
and
amount
the
merchant
wants
to
to
transfer
the
name
of
the
creditor
and
the
target
account.
But
it's
just
an
example:
it's
it's
a
very
universal
concept
that
can
be
used
with
all
kinds
of
of
of
structured
json
data.
A
This
same
structure
is
also
used
by
nab
and
we
are
continuously
synchronizing
with
an
absolute
to
to
keep
the
specs
and
the
syntax
in
sync
between
which
authorization
requests
and
and
and
map
next
slide.
Please.
A
So
I
checked
and
we
presented
last
time
at
itf
107,
which
is
a
year
pretty
much
exactly
a
year
ago.
In
the
meantime,
we
produced
three
new
revisions.
A
What
we
did
is
we
restructured
the
whole
draft
for
better
readability,
because
the
first,
the
first
drafts
were
more
organized
along
the
sequence
of
a
certain
use
case.
Now
it's
more
structured
along
the
end
points,
authorization,
endpoint,
token
endpoint
and
then
the
introspection
or
representation
of
authorization
details
in
our
access
tokens
and
we
added
a
lot
of
clarifications
so,
for
example,
how
resource
the
resource
parameter
as
defined
in
resource
indicators,
works
together
with
authorization
details,
and
we
also
explained
how
authorization
detail
can
be
enriched
in
the
course
of
an
authorization
process.
A
So,
for
example,
there
are
use
cases
where
I
rely.
A
client,
for
example,
ask
for
access
to
account
data,
for
example,
bank
account
data
without
specifying
the
the
actual
accounts
it
wants
to
access
that
can
be
decided
by
the
user
and
then
the
authorization
details
object
becomes
enriched
in
the
course
of
the
process
and
is
then
played
back
to
the
client
with
the
with
the
additional
information,
and
we
also
did
we
also
added
text
around
error,
handling
for
unknown
authorization,
details,
parameters
and
so
on.
A
So,
as
you
see,
no
no
substantial
change,
basically
killing
the
spec
in
its
core
is
pretty
stable,
but
we
incorporated
feedback
that
we
got
from
implementers
and
and
reviewers.
What
we
also
did
is
we
added
implementation
considerations,
because
it
turned
out
that
there
were,
even
though,
from
my
perspective,
the
spec
is
pretty
simple.
There
was
always
the
question
that
what
do
I
need
in
my
product
in
my
project
in
order
to
support
greater
authorization
requests?
I
will.
A
A
So,
regarding
implementation
consideration,
so
we
mostly
focused
on
what
what
it
takes
in
an
authorization
server,
implementation
to
support,
rich
authorization
requests,
and
one
observation
is
that
processing
of
authorization
requests
containing
authorization
details
as
well
as
a
presentation
of
the
authorization
details
to
the
user,
for
example,
in
the
user
content
varies
significantly
among
the
different
authorization
data
types.
A
We
found
it
a
a
good
idea
to
spell
out
what
we
always
expect
products
to
do
in
order
to
support
rich
authorization
required
of
all
products
should
allow
deployments
to
determine
the
presentation
of
authorization
details
the
whatever
the
product
does
I
mean
this
is
at
the
description
of
the
of
the
of
the
implementer
might
be
just
some
user
interface
tweaking
might
be
a
support.
B
A
I
already
gave
guys
one
example
that
the
user
might,
for
example,
want
this
to
select
the
accounts
in.
She
wants
the
client
to
get
access
to,
but
there
are
other
other
examples
as
well,
and
it
should
also
be
possible
to
merge,
requested
and
pre-existing
authorization
details.
So,
for
example,
let's
just
assume
the
client
already
obtained
a
grant
has
access
to.
A
Let's
say
one:
one
account
can
read
a
balance
and
in
the
next
authorization
request,
the
the
the
same
client
also
wants
to
extend
or
enhance
this
this
authorization
to
be
able
to
access
that
transaction
history
of
the
same
account
that
should
be
possible
or
might
be
might
be
allowed
by
by
an
implementation
as
well,
and
there
are.
A
There
are
a
couple
of
couple
of
ways
that
can
be
implemented
and
we
had
with
some
discussions
with
different
implementers,
how
they,
how
they
could
or
how
they
implement
raw
support
and
also
with
implementers
that
not
based
on
raw
but
facing
similar
requirements
in
the
open
banking
states
how
they
have
implemented.
This
kind
of
custom
logic,
and
one
of
them
is
one
way,
is
to
from
the
as
yeah
allow
a
redirect,
for
example,
to
a
custom
custom
module
that
then
presents
the
the
rich
authorization
request
to
the
user.
A
Gathers
the
authors
gathers
the
content
and
then
yeah
informs
the.
As
about
the
outcome
of
that
process,
it's
also
possible
to
have
apis
or
callbacks
in
one
way
or
the
other,
so,
for
example,
in
one
might
envision
that
the
aes
allows
to
implement
callbacks
from
the
core
of
the
aes
to
some
custom
model
modules
that
implement
the
custom
logic
for
certain
deployments.
A
But
it
goes
also
the
other
way
around.
So
some
some
up,
some
as
projects
or
products,
don't
have
a
user
interface
for
example.
Instead,
the
deployment
builds
a
authorization
endpoint
completely
on
its
own
and.
B
A
Calls
into
the
product
to
get
information
about
what
what
parameters,
where
present
in
the
authorization
request,
and
I
can
also
send
back
the
result
of
the
user
consent
to
their
product
and
there
are
other
options,
including
also
to
just
create
a
fork,
for
example,
of
an
open
source
project
and
and
do
a
custom
build.
And
why
did
we
do
this?
B
A
To
implement
raw
support,
even
though
it's
it's
pretty
simple,
so,
for
example,
at
yes.com
we
implemented
raw
on
top
of
an
existing
product
without
any
product
support.
A
A
So
there
is
one
other
questions
or
no
keep
going.
Okay,
good.
So
there's
one
there's
one
open
topic
that
we
would
like
to
bring
to
your
attention
and-
and
today
in
the
call-
and
this
is
yeah
the
question-
whether
we
add
a
authorization
details
parameter
as
a
token
request
parameter
so
far.
The
spec
only
only
specifies
the
authorization
details
request
as
an
authorization
request
parameters,
but
there
are
questions
raised
on
the
list
or
in
discussions
so,
for
example,
in
the
oauth
security
workshop
that
led
us
to
this
discussion.
A
All
it
will
get
to
know
is,
in
the
token
response,
what
authorization
details
the
user
in
the
end
are
concerned
with
there's
also
the
question
of
whether
it
will
be
possible
to
downscope
privileges.
So,
for
example,
if
a
client
obtained
privileges
for
a
couple
of
apis
and
then
with
the
first
access
token,
once
again,
just
a
very,
very
narrowly
sloped
access
token.
A
First
of
all,
the
authorization
details
need
to
be
assigned
to
a
refresh
token
and
later
on,
with
the
refresh
token
grant,
the
client
would
need
to
be
able
to
tell
the
as
please
assign
this
subset
of
privileges
that
exist
in
the
pre-existing
grant
to
my
access
token
and
clearly,
there's
also
another
use
case,
which
is
support
for
the
client
credentials
flow
in,
in
which
case
the
client
just
would
request
using
the
authorization
details
parameter
in
the
token
question.
A
So
all
those
different
impulses
aim
in
the
same
exactly
the
same
direction,
which
is
the
authorization
details,
token
request,
parameter
and
the
tricky
bit
or
what
this
particular
tricky
bit
is
then
in
in
this
case,
we
need
to
compare
what
we
requested
and
what's
already
there.
Well,
it's
just
in
the
key
detail
states
that
you
want
something
you
have
something,
and
the
question
is:
what
will
you
get
next
slide
please
and
with
that
I
head
over
to
justin
to
explain
how
he
solves
about
comparing
authorization,
details.
G
All
right,
thanks,
torsten
before
I
go
in,
do
we
have
any
questions
about
the
the
first
section
state
of
the
draft
and
things
like
that
before
I
dive
into
this
topic,
I
don't
see
anyone
queuing
in
chat.
D
G
Okay,
all
right,
so
this
whole
idea
of
comparing
these
authorization
details
objects
is
is
fundamental
to
a
lot
of
the
parts
of
the
protocol
and
it
shows
up
in
places.
G
You
know,
there's
the
obvious
places
like
downscoping
that
torsion
was
just
talking
about,
but
then
there's
also,
this
notion
of
you
need
to
compare.
You
know
say:
you've
got
a
client,
that's
allowed
to
do
certain
things
and
then
they're,
asking
for
more
than
what
that
client
is
allowed
to
do
or
the
user
is
trying
to
approve
more
than
what
their
role
as
the
resource
owner
allows
them
to
do.
You
need
to
be
able
to
compare
these
kinds
of
things
with
each
other
next
slide.
G
Please
and
we're
we're
kind
of
used
to
doing
this
in
with
scopes,
because
what
you're
supposed
to
see
is
that
if
somebody
is
asking
for
a
b
c
scopes,
then
that
means
that
they
are
by
definition
of
6749,
requesting
more
than
a
and
b
their
scopes
are
designed
to
be
additive.
G
But
the
real
world
doesn't
really
work
like
that,
and
we
all
know
that,
because
sometimes
scope
c
is
included
when
you
ask
for
scope
a
that's
just
part
of
the
definitions
of
scope,
a
and
c
they're
part
of
the
same
api
and
they're
related
to
each
other,
or
sometimes
you
get
a
scope
that
turns
on
special
special
processing
at
the
as
or
at
the
rs.
It's
not
really
asking
for
a
different
kind
of
access.
It's
just
it's
another
flag
to
send
to
the
aes
as
part
of
processing.
G
You
don't
have
to
look
very
far
to
see
real
world
examples
of
this.
I
pulled
these.
You
know
we
all
know.
Openid
connects
open
id
scope,
turns
on
things
like
the
id
token
and
all
sorts
of
other
bits
of
processing
and
the,
and
it's
only
in
combination
with
like
open
id
and
email.
Does
the
open
id
connect,
email
scope
even
have
semantic
meaning
right
so
also
right,
the
github
api.
G
If
you
ask
for
the
repo
scope,
then
that
actually
includes
everything
that
is
inside
the
repost
status,
scope
and
more
so
there's
subsumptive
definitions
here.
So
it's
not
as
clean
as
the
original
oauth
scope.
Design
was
intending
it
to
be
these
real
real
world
use
cases,
but
the
thing
with
scopes
is
that,
because
it
is
a
set
of
strings,
you
can
still
kind
of
get
by
by
doing
a
lazy,
simple
comparison
and
mostly
kind
of
get
away
with
stuff.
G
And
of
course,
these
scope
comparisons
happen
all
over.
The
protocol,
like
I
was
just
saying
you
know
if
a
client
is
registered,
to
only
be
able
to
ask
for
certain
scopes
or
a
resource
owner
can
only
approve
certain
scopes
or
you've
got
an
assertion
or
refresh
token
coming
in
and
somebody's
asking
for
a
different
set
of
scopes.
You
have
to
figure
out.
G
Does
what
they're
asking
for
align
with
what
they're
allowed
to
do
for
any
one
of
those
one
or
more
of
those
various
reasons
that
I
was
just
talking
about,
and
there's
probably
a
bunch
of
other
corner
cases
too-
that
I'm
not
really
getting
into
right
now
next
slide,
please
so
we've
got
to
figure
out
how
to
do
this.
With
these
big
bridge
authorization,
sales
objects,
yeah
justin.
Do
you
mind
if
I
ask
a
question
on
the
previous
slide,
yeah.
G
H
G
I
would,
I
would
ask
if
that
you
could
use
the
queue,
though
just
so
that
we
don't
do
that
you're
fine
now,
but
just
in
the
future.
Okay,
sorry.
G
H
So
with
the
first
statement
like
it
may
be
intuitive
to
say,
if
someone
requests
a
scope
of
abc
that
this
actually
is
more
than
a
plus
b,
but
that
by
itself
hasn't
really
that
assumption
hasn't
really
been
made
in
the
scopes.
At
least
in
oas.
Are
you
sort
of
like
assuming
that
in
the
in
the
spec
and
spelling
it
out
or.
G
No,
that's
actually
spelled
out
in
67
49,
I'm
just
trying
to
find
the
exact
yeah.
I
think
it's
in
section
three
three.
Maybe
I
need
to
so
section
three
three.
If
the
value
contains
multiple
space
delimited
strings,
their
order
does
not
matter,
and
each
string
adds
in
an
additional
access
range
to
the
requested
scope.
G
Okay,
that's
that
is
technically
the
definition
of
scopes,
but
that's
not
really
how
people
use
them
in
practice
because,
for
example,
if
I
have
repo
and
repo
status,
adding
repo
status
doesn't
add
an
additional
range.
H
Right
right,
yeah,
I'm
more
worried
that
some
something
of
course
that
they
are
not
this
joined
necessarily
destroying
permissions,
but
I
was
more
worried
that
something
would
take
permissions
away.
So
it's
it
may
be
less
intuitive
than
or
deployments
may
be
less
intuitive
than
one
would
think.
G
Right
I
mean
you:
could
you
can
imagine
a
negative
access
scope?
I
personally
couldn't
find
an
example
of
one
for
to
bring
up
on
the
skull,
but
but
I
I
guarantee
you
that
somebody's
done
that
somebody
has
a
scope
that
says
actually
do
less
than
if
I
hadn't
sent
it
to
you
yeah,
just
because
it's
possible
like
it,
because
it's
technologically
possible.
H
G
Yes,
thank
you
great
point
though,
but
yeah
it
is.
It
is
section
3.3
in
in
the
oauth
2
spec
yeah.
Thank
you
thanks
for
reminding
me
about
that.
Yeah,
that's!
Okay!
Everybody
forgets
that
part,
because
that's
not
how
we
use
it,
but
that
brings
us
to
how
how
do
we
compare
authorization
details
because
you
know
scope
strings
like
I
said
you
can
kind
of
get
away
with
being
fast
and
loose
parse
it
into
a
set.
Do
some
basic
set
math
and
it
mostly
kind
of
works.
G
It
fails
in
the
right
direction,
most
of
the
time.
So,
with
these
authorization
details,
we've
got
a
few
options
of
how
we
can
approach
this
in
the
actual
extension
spec
text
in
rar.
G
We
could
just
not
say
anything
and
hope
for
the
best
which
is
kind
of
what
we
have
right
now.
The
editors
don't
believe
that
that's
the
best,
the
best
approach
here
just
to
say
we
could
have
language
about
how
to
compare
json
objects
that
are
in
the
array
coming
in
comparing
values
across
different
fields.
G
We
could
explicitly
define
that
it
is
fully
out
of
scope,
but
the
editors
have
talked
about
this.
Recently,
based
on
the
conversations
that
have
happened
on
the
list,
and
we
actually
think
that
the
best
approach
is
to
kind
of
combine
two
and
three
here
is
to
say
that
the
the
details
of
this
are
defined
by
the
type
value,
just
like
all
of
the
rest
of
the
processing
of
the
authorization
details
is
defined
by
that
type
value.
G
It's
sort
of
name
spaced
into
there
and
the
comparison
is
similarly
bound
to
that,
but
also
give
examples
of
what
common
kinds
of
things
you
you
might
see,
so
that
we're
not
leaving
developers
to
completely
start
with
a
blank
page
in
how
they're
approaching
things,
because
the
truth
is
we're
probably
going
to
see
a
bunch
of
common
patterns
and
that's
what
I'm
gonna
go
through
next
next
slide,
please.
G
So,
if
you're
looking
at
two
different
authorization
requests
on
the
right
hand
side,
you
see
that
we
have
added
more
things
into
the
object
into
the
actions,
locations
and
data
types
field.
We
just
added
additional
values,
and
so
it's
a
really
simple
logic
to
say
that
if
everything
is
defined,
you
know
orthogonal
and
separate
from
each
other.
G
If
your
api
is
very
very
cleanly
designed
like
this,
and
if
you
have
more
stuff
in
the
object,
you're
asking
for
more
things,
if
you
have
different
stuff
in
the
object,
you're
asking
for
different
things
now
for
the
reasons
we
talked
about
before,
we
can't
assume
that
this
is
a
universal
thing,
but
this,
we
think,
is
probably
going
to
be
a
common
enough
pattern
to
at
least
call
it
out
as
an
example
for
people
who
are
designing
their
apis
and
looking
to
use
rar
so
that
they
could
figure
out
how
to
how
to
actually
do
this
very
important
comparison
function.
G
Next
slide,
please
another
thing
that
we
know
exists
out
there
is
this
notion
of
subsuming
values
so
say,
for
example,
when
I
get
the
right
access,
I
automatically
get
read
access
just
because
of
the
way
my
api
has
been
designed
or,
more
specifically,
the
way
the
rights
to
my
api
have
been
designed,
and
so
my
as
when
comparing
these
things
would
need
to
know
that
you
know.
If
I
already
have
write
access-
and
I
ask
for
read-
then
I'm
not
actually
asking
for
more.
I
don't
need
to
go
re-prompt.
G
The
user
and
say
just
read
access
because
the
users
already
said
yes,
this
is
fine
and
that
can
go
across
all
of
these
different
dimensions.
All
of
these
different
fields.
Next
slide,
please
a
lot
of
apis,
I
think,
are
we're
going
to
see
them
deployed
with
sort
of
a
reasonable
set
of
defaults.
G
So
if
I
don't
specify
something
in
say,
data
types,
when
I'm
talking
to
the
photo
api,
it's
going
to
assume.
Oh,
you
probably
mean
images.
We
already
see
default
scopes
in
a
lot
of
oauth
deployments
today,
when
you
don't
ask
for
any
scopes,
the
server's
allowed
to
say:
oh
here's,
the
box
of
scopes
that
you
get
just
in
that
case,
and
we
think
that
we're
going
to
see
that
same
type
of
pattern
across
different
rar
types
as
well
and
thorson's
actually
got
a
whole
section
in
the
latest.
G
It's
at
least
in
the
editor's
copy.
I
don't
remember
if
it's
in
the
published
draft
yet
about
filling
in
this
kind
of
protocol
detail.
So
when,
even
though
you
ask
for
just
read,
maybe
you
you
actually
get
told?
Oh,
it
was
read
at
this
location
with
this
type
with
this
identifier.
G
With
this
you
know
specialty
field,
whatever
all
of
that
gets
gets
sent
back
to
you
at
the
end,
but
the
as
still
has
to
be
able
to
compare
these
kinds
of
things,
because,
if
you're
going
in
and
just
asking
for
read-
but
you
only
have
read
at
a
non-default
location
then
is-
is
that
asking
for
more?
G
Is
that
asking
for
less
and
the
as
needs
to
be
able
to
figure
figure
out
how
to
compare
these
things
when
they're
not
complete
next
slide,
please,
we
can
also
have
similarly
something
with
an
additional
piece
of
detail
added
along.
G
So
in
this
straw
man
example,
I'm
now
asking
for
not
just
any
photo
api,
but
a
very
specific
either
photo
or
collection
of
photos
or
something
that
that
identifier
points
to,
whereas
before
I
had
access
to
everything
at
that
server
and
now
I'm
asking
for
more
stuff,
there
is
more
stuff
in
that
object,
but
I'm
being
more
specific,
so
it's
actually
a
lesser
set
of
access
than
previously
done
and
for
anything
that
allows
this
type
of
narrowing
of
access
at
runtime,
which
a
lot
of
advanced
apis.
G
I
It
was
just
because
you
mentioned
it
in
the
slide
a
couple
of
times
and,
and
I
think
semantics
get
complicated
both
in
the
protocol
world
and
then
the
user
world,
when
you
actually
have
to
display
it,
although
in
my
experience
we
don't
end
up
actually
displaying
the
authorization
request
to
the
users,
it's
usually
protocol
negotiation
between
clients
and
servers
anyways
and
at
least
the
cases
I
encountered
or
encounter,
but
in
the
case
of
your
example
of
the
client
requests
repo
and
doesn't
know
that
it
has
all
the
downgrade
scopes
like
repo
status.
I
G
So
it's
not
a
matter
of
the
client
necessarily
knowing
it
it's
about
the
as
being
able
to
compute
the
fact
that
there
are
all
of
those
implicit
scopes
when
things
come
in
we're
not
talking
about
what
you
send
back
to
the
client
we're
talking
about
when
the
client
asks
for
something
in
any
of
these
contexts,
it's
going
to
have
a
set
of
things
that
are
allowed
or
a
set
of
things
that
are
authorizable
and
the
authorization
server
needs
to
be
able
to
compare
that
with
what
was
requested.
G
So,
yes,
you
could
you
could
in
fact
return
that
kind
of
thing
if
it
made
sense,
but
I
mean
look
at
the
example.
That's
on
the
screen
right
now.
Would
that
mean
that
the
server
would
have
to
send
back
a
list
of
all
possible
identifiers
and
all
possible
action,
combinations
and
locations,
and
things
like
that
back
to
the
client,
you
could
do
that.
C
I
can
I've
been
here:
justin
yeah
go
ahead.
Sorry,
this
is
this
is
aaron
parkey.
I
have
a
concrete
example
of
why
it
would
not
be
practical,
and
that
is
if
the
authorization,
server
and
resource
server
are
not
tightly
coupled
where
the
as
is
a
product
that
doesn't
know
the
inner
workings
of
the
rs
and
the
scopes
will
be
enforced
at
the
rs
level.
So
the
authorization
server
might
not
even
know
that
the
scopes
overlap.
I
C
Authorize
any
scopes,
it's
just
you
know
it's
a
product
decision
and
a
policy
decision
so
that
just
that
is
something
that
happens
in
practice
and
in
those
in
those
cases,
it's
the
resource,
servers
that
are
up
to
the
ones
that
are
enforcing
the
particular
api
operations,
against
particular
lists
and
combinations
of
scopes.
Right.
A
This
is
foster
speaking.
I
would
just
like
to
add
that
I
mean,
or
what
you
just
pointed
out,
is
in
the
end
part
of
the
design
right
and
drawing
the
boundary
between
as
and
rs
or
the
they
know
that
the
more
the
es
knows,
the
more
it
can
authorize
and
especially
in
the
use
case
that
we
see
authorization
details.
The
aspect
elites
needs
to
know
more
than
we
thought
in
traditional
oauth
use
cases,
but
trying
to
answer
phil's
question
I
think,
what's
just
but
just
where
justin
tries
to
get.
A
That
is
something
different.
So
clearly
the
es
can
can
return
everything
that
it
can
resolve.
So
the
draft
already
states
that,
if,
if
the
as
wants
to
enrich
the
authorization
details
object,
it
can
do
so
at
any
time.
So,
for
example,
if
the
authorization
request
contains
defaults,
as
shown,
I
think
in
the
previous
slide
or
the
the
slide
before
the
escort
could
easily
add
other
details
and
play
that
back
to
the
client.
A
But
the
problem
that
that
we
are
after
here
is
that
the
as
first
needs
to
determine
what's
already
existing
and
what?
What
is
what
the
client
asked
for
to
e
to
in
the
in
the
end,
to
come
up
with
the
with
the
set
of
require
of
privileges
that
it
needs
to
access
to
to
get
content
from
the
user?
So
that
that's
that's
the
that's
the
kind
of
question
we
want
to
tackle
here.
G
Right,
thank
you,
tarson
yeah,
and
that's
that's
what
I
was
trying
to
say
at
the
beginning.
Is
that
it's
it's
interesting
and
you
could
do
that,
but
that's
fundamentally
not
what
we're
trying
to
answer
here.
That's
that's
not
germane
to
the
problem
that
this
is
trying
to
address
and
solve.
G
You
know,
because
this,
no
matter
what
you
tell
back
to
the
client,
the
as
still
has
to
make
a
decision
about
whether
or
not
to
grant
some
access-
and
I
mean
ultimately
the
rs-
also
has
to
make
a
similar
decision,
but
it
tends
to
be
a
little
bit
simpler
from
the
rs
perspective,
because
all
it
needs
to
know
is
you
know
enough
about
its
own
api,
which
you
would
expect
it
to
be
an
expert
on
already
to
know.
G
If
the
thing
that's
coming
in
is
is
able
to
be
done
fundamentally,
though,
under
the
hood.
All
of
these
do
require
you
to
compare
these
kinds
of
objects.
G
The
current
draft
next
slide,
please
because
this
gets
even
more
fun
when
you
realize
that
this
is
that
this
is
a
set
you're
you're
allowed
to
have
multiple
different
things
now,
oauth
scopes
are
a
set
from
a
data
structure,
perspective
they're
encoded
as
a
single
string,
but
they
are
a
set
of
different
objects,
and
so
I
can
ask
for
multiple
things
and
you
know
maybe
asking
for
write
on
images
includes
read
on
metadata,
or
maybe
it
doesn't,
and
I'm
asking
for
two
different
kinds
of
things,
and
did
I
even
need
to
ask
for
that
additional
scope?
G
And
when
you
know,
and
to
phil's
question,
if
what
I
get
back,
you
know
is
that
going
to
include
the
entire
cross
product
of
everything
that
I
might
be
able
to
use
that
access
token,
for
maybe
maybe
I'll
only
get
the
subsumpted
values.
That's
that's
going
to
be
sort
of
up
to
the
up
to
the
higher
level
and
next
slide.
G
The
this
gets
really
really
out
there
when
you
start
to
realize
that
we
don't
have
control
over
api
designers,
and
that's
fundamentally
the
question
here,
because
who
are
we
as
security
protocol
designers,
to
say
that
you
know
your
baz
value
of
true
is
equal
to
or
greater
or
less
than
or
whatever
the
quack
value
of
co-ops.
G
You
know
it's,
I'm
realizing
that
I
wrote
these
slides
without
realizing.
I'd
have
to
say
them
out
loud,
but
the
the
point
here
is
that
apis
have
lots
of
different
kinds
of
designs:
lots
of
different
orthonoc
orthogonal
approaches
to
how
access
is
determined
and
rich
authorization
requests
need
to
be
a
carrier,
an
enabler
for
all
of
those
types
of
things
and
all
of
their
various
definitions
of
fine
grain.
G
So
what
do
we
do
next
slide?
Please
we've
seen
a
bunch
of
things
and
honestly,
all
of
them
are
correct.
Those
are
all
reasonable
ways
to
compare
objects,
so
oauth
doesn't
really
take
a
stance
on
the
nature
of
the
api.
That's
protecting
and
that
has
hugely
been
to
oauth's
benefit
other
protocols.
Other
security
protocols
have
taken
very,
very
strong
stances
and
saying
like.
G
So
rar
needs
to
be
able
to
keep
living
in
that
world,
and
and
in
order
to
do
that,
what
we're
proposing
next
slide
is
to
provide
guidance
to
tell
people
that,
when
you're
building
an
authorization
server
and
to
someone
of
a
lesser
extent
the
resource
server,
you
need
to
be
able
to
do
this
comparison.
You
need
to
be
able
to
say
in
these
different
contexts
what
more
or
less
is,
and
things
like
that,
and
that's
part
of
your
definition
of
what
your
type
value
types
of
objects
are.
Now.
G
We've
already
got
some
language
in
there
about
when
you're,
defining
a
new
rich
authorization
type.
What
that
looks
like
and
sort
of
you
know
what
needs
to
come
into
this
and
we've
taken
in
some
language
from
the
genaps
specification
into
rar,
and
you
know
vice
versa,
as
torsten
mentioned
we're
trying
to
keep
these
in
sync
as
as
much
as
it
makes
sense
to
that
when
you're
defining
this
type,
then
you
right
now,
you
already
need
to
consider,
like
you
know
how
all
of
your
bits
connect
together.
G
G
What
we're
proposing
is
that
we
also
specify
that
you
have
to
say
how
you
compare
things
both
within
your
type
and
even
have
some
suggestions
about
how
an
as
might
compare
things
across
types
so
that
we
get
somewhat
reasonably
predictable
behavior,
even
though,
fundamentally
it's
all
going
to
be
down
to
the
kind
of
definitions
that
the
types
themselves
make
so
the
spec
can
show
common
patterns
as
examples
as
non-normative
examples
and
the
requirements
will
be
around
okay.
This
is
how
you
need
to
make
this
comparison.
G
How
you
actually
calculate
the
comparison
is
up
to.
You
will
will
kind
of
point
you
in
some
common
directions,
but
you've
got
to
decide
that
and
you
need
to
be
able
to
understand
what
that
means,
this
more
or
less
or
even
just
different
type
of
thing
needs
to
be
able
to
be
defined
when
you're,
defining
this
type
and
when
you're
using
rar.
G
I
Let's
just
call
them
rules
for
now
as
a
comparison
and
the
as
knew
that
and
and
then,
when
you
got
to
the
rs,
all
the
rs
had
to
do
was
to
match
a
role
with
the
actual
access
control
decision
of
whether
a
client
could
do
something
in
the
api,
but
it
was
stateless
with
regards
to
who
the
client
was
simply
new.
This
client
has
role
x.
Therefore
he
can
do
whatever
x
says
he
can
do.
It
doesn't
really
matter
whether
it's
justin
or
not
in
this
level,
this
model
it
does
bring
up.
I
I
I
The
enforcement
model
changes
because
because
the
rs
has
to
figure
this
all
out
and
do
a
lot
more
work.
G
Does
that
make
sense?
Can
I
respond
to
phil
before
we
go
back
to
the
yeah
yeah
guys
yeah?
I
just
want
to
say
I
I
wholeheartedly
disagree
that
it
changes
the
model.
Rar
fundamentally
allows
for
the
same
width
of
deployment
and
enforcement
type
of
things.
That
scope
does.
You
could
do
all
of
this
calculation
on
the
as
and
then
the
rs
simply
has
to
say.
G
If
this
string
is
in
this
json
object
at
this
time,
then
the
answer
is
yes,
and
I
give
you
data,
you
know
the
it
does
not
necessarily
mean
the
rs
has
to
be
any
smarter
than
any
rs
is
today,
but
also
doesn't
necessarily
mean
the,
as
has
to
know
more
about
the
apis.
It's
protecting,
given
what
aaron
was
saying
earlier
about
the
about
the
kind.
B
Of
you
know
naive
umbrella,.
G
As
deployment
power,
which
we
know
also
exists
and
that
exists
today
with
scopes,
like
that's,
not
new
for
rar
that's
none
of
this
is
new.
I
I.
I
Would
simply
than
that
I
mean
yes,
all
things
are
possible,
but
because
of
that,
what
I'm
seeing
here
is
that
you're
now
getting
to
a
case
where
the
api
assumes
the
acs
is
doing
something
which
in
many
cases,
the
as
won't
because
it
doesn't
have
the
full
context,
because
what
it's
authorizing
it's
not
authorizing
it.
It's
it's
not
authorizing
at
all
anymore.
It's
it's
consenting.
I
It's
gathering
a
consent
for
a
contract
embodied
by
the
raw
request,
but
it
doesn't
necessarily
probably
more
often
than
not
doesn't
know
what
it
actually
means
and
if
the
rs
is
assuming
that
the
as
made
it
a
fully
aware
decision,
we're
going
to
end
up
with
decoupled
decision
making,
which,
which
is
good
in
some
cases
but
in
other
cases,
could
lead
to
finger
pointing
that
just
said.
Well,
you
authorized
it.
So
I'm
doing
it,
but
no,
no!
You
were
supposed
to
actually
read
the
contract
before
you.
You
know.
I
That's!
That's
all
I'm
trying
to
raise
as
long
as
we
express
that
that
those
roles
and
what
each
party
should
be
doing
clearly
and
what
the
ramifications
are.
It's
fine.
G
Okay,
phil.
I
would
suggest
that
that
that
is
actually
better
text
for
say
oauth,
2.1
or
security
considerations,
because
all
of
that
exists
today
with
scopes.
Those
are
deployment
patterns
and
sort
of
externalization
of
authority
decisions
that
rar
doesn't
change.
What
rawr
makes
more
difficult
is
the
fact
that
we
have
these
multi-dimensional
objects
that
are
harder
to
compare
than
strings.
G
A
Because
in
the
in
the
end,
the
as
always
acted
as
a
as
a
as
a
gatekeeper
on
behalf
of
the
rs,
that's
that's
built
into
the
oauth2.2.0,
our
fundamental
principle.
So
we
don't
change
that.
What
we
do
is-
and
we
didn't
invent
that
right,
so
the
fine-brained
authorization
that
we
that
we
try
to
standardize
here.
It's
something
that's
happening.
A
It's
happening
all
over
the
world
since
I
would
say
2017
with
the
raise
our
rise
of
open
data,
because
open
data
just
needs
more
more
details,
content
because
of
the
obligations
due
to
the
deteriorating
the
obligations
from
regulation
and
so
on.
So
and
it's
it's
been
implemented
in
different
ways.
And
what
we're
doing
here
is
we
give
it
a
simple
and
standardized
syntax.
I
I
I
agree.
This
is
positive
in
the
sense
that,
when
what
you're
expressing
is
more
actually
ends
up
being
more
specific,
because
you
have
the
language
to
express
something
more
specific
and
then
then
the
decision
is
clear:
if,
if
you
are
using
a
complex
expression
structure
to
to
express
conflict
features,
that's
that's
the
danger
of
it.
That's
what
I'm
saying!
I
I
like
the
example
when
you're
saying:
okay,
you
have
access
you're,
authorized
right
access
to
update
this
image
and
when
we
get
into
the
weeds
about,
does
that
imply,
read
or
not
that
that
was
kind
of
driving
me
nuts,
because
I
don't
think
that's
what
you're
trying
to
do.
I
think
you're
trying
to
that's
trying
to
be
cool
with
the
language.
I
think,
though,
the
objective
is
specific.
Authorization
is
not
more
powerful,
role-based
authorizations
and
stuff
like
that.
K
Sure-
and
I
I
think
I
mean
it's
all-
I
think
the
same
topic-
I
agree:
justin
torsten
that
we're
not
adding
something
new,
but
with
scopes
being
space
delimited
strings
right.
I
can
do
that
set
math
as
an
as
and
be
pretty
oblivious
as
to
what
it
really
means,
potentially
at
the
rs,
and
I
can
do
things
like
down
scoping
tokens,
I'm
not
sure
you
can
do
down
scoping
tokens
for
an
as
that
is
acting
as
sort
of
an
as
as
a
service
and
the
rs
is
defining
the
types
right.
K
I'm
not
sure
downscoping
is
possible
in
those
contexts
and-
and
that
may
be
okay,
but
I
think
that
it
makes
it
much
more
difficult
to
use
rar
at
the
token
endpoint
directly,
because
the
comparison
mechanism
logic
is
not
under
the
purview
of
the
as
right.
You,
the
as
almost
needs
to
go
to
the
rs
and
says
hey.
I've
got
a
token
with
this
in
it
right
a
refresh
token,
with
this
rar
in
it
and
they're
asking
for
this
other
rar.
K
Is
it
okay
right
if
the
rs
is
really
the
authority
element
of
of
those
types
and
we're
just
using?
I
think,
as
phil
was
saying,
the
the
a
s
as
the
consent
mechanism,
so
a
rar
coming
to
the
authorization
endpoint
that
gets
presented
to
the
user
and
the
user
says
yes
right,
we're
pushing
the
authorization
decision,
all
the
way
to
the
user,
hoping
the
user
can
make
a
good
one
right
and
let
it
flow
through
when
the,
as
has
to
make
an
a
behind
the
scenes,
silent
authorization
decision
between
two
rars
from
a
comparison
perspective.
K
I
think
that's
going
to
be
very,
very
difficult
in
some
circumstances,
if
it's
very
tightly
coupled
definitely
doable
not
a
problem,
but
if
it's
loosely
coupled
I'm
not
sure
it's
going
to
be
feasible.
G
Yeah,
if
I
can
just
respond
to
george
yeah,
I
totally
agree
that
it
is
much
easier
in
some
circumstances
than
in
others,
and
that's
that's
a
large
part
of
what
we
were
looking
to
do
with
providing
this
guidance.
G
G
Maybe
you,
your
aeropath,
is
you
just
deny
everything
that
that
comes
in
as
looking
different
or
you
always
get
consent
if
the
object
is
different
at
all
in
any
way
and
as
could
decide
to
do
that
and
that
would
be
sort
of
the
safe,
dumb
set
math
approach
we
don't
want
to,
and
I
don't
think
we
can
specify
that
safe,
dumb
set
math
as
what
every
as
will
do
in
all
circumstances,
because
I
don't
think
that
that's
actually
correct,
and
I
don't
think
that
that
matches
what
apis
are
using
today
and
will
use
in
the
future
for
these
authorization
objects.
G
But
that's
that
does
need
to
be
part
of
this
discussion,
though,
that
you
know,
if
you're
going
to
do
this
comparison
or
if
you're
going
to
do
this
type
of
decision,
you
need
to
be
able
to
make
that
comparison
and
here's
kind
of
what
that
comparison
looks
like
and,
like
I
said
before
I'll,
even
say
that
all
of
that
comes
into
play
even
at
just
the
authorization
screen.
You
know
what
I
show
the
user.
G
What
I
you
know
whether
or
not
I
just
immediately
return
an
error,
because
a
client
asks
for
more
than
it's
allowed
to
you
know
all
of
that
comes
into
play
before
the
user
even
gets
gets
prompted
anything
on
a
page.
G
D
D
L
Yeah,
so
this
this
might
be
out
of
scope,
because
it's
getting
a
little
bit
into
the
api
leads
for
the
rs
side,
but
it
this
feels
like
the
like.
From
the
client's
perspective,
it
seems
like
it
could
be
very
difficult
for
a
client
to
be
able
to
build
an
authorization
or
like
one
of
these.
These
were
authorization
requests
without
having
some
knowledge
of
the
resources
that
they're
needing
to
to
request.
L
So
would
this
require
that,
like
the
user
go
through,
the
client
go
through
one
flow
in
order
to
get
access
to
say,
query
the
list
of
available
objects
then,
and
then
be
able
to
generate
these
requests
in
order
to
actually
functionally
make
use
of
this.
You
know
as
a
client,
and
is
that?
How
is
that
different
or
better
than
the
sort
of
pattern?
L
That's
already
taken
pulled
in,
say
the
the
home,
the
smart
home
space,
where
the
authorization
server
has
the
the
customer,
the
user
choose
the
the
resources
they're
granting
access
to
prior
to
redirecting
back
to
the
the
client,
with
an
authorization.
G
Code
yeah
so
in,
in
my
view,
from
a
developer's
perspective,
clients
are
written
to
call
specific
apis
and
do
specific
things,
so
this
is
largely
going
to
be
something
that
is
going
to
be
it's
for
most
clients.
It's
going
to
be
coded
into
the
client
itself
and
not
dynamically
negotiated
for
situations
where
you
do
need
that
dynamic
negotiation,
where
you
have
a
client
that
can
call
different
apis
that
are
going
to
have
different
objects
or
even
fill
in
different
values
on
different
objects.
G
Yeah
you're
going
to
need
some
more
smarts,
but
rar
doesn't
provide
those
smarts
so
much
as
provide
you
a
structure
for
describing
where
those
smarts
go
at
the
end
of
the
day.
It's
you
know,
look
what
oauth
developers
do
right
now
you
tell
a
developer
put
this
string
in
this
query:
parameter
and
it'll
work
right.
That
string
happens
to
be
a
set
of
space-separated
scope
values
but
from
the
developer's
perspective,
they're
just
trying
to
call
the
api.
It's
I
put
this
string
in
this
value
and
things
work.
G
C
Thank
you.
Thank
you,
though.
I
think
both
models
are
totally
valid
yeah.
I
just
want
to
say
both
models
are
totally
valid
and
I
expect
that
we
would
see
both
in
practice,
but
there
are
definitely
cases
where
that
information
will
start
with
the
client.
So
that's
what
this
spec
is
trying
to
address
of
the
client
assuming
the
client
does
already
know
what
it's
trying
to
request,
whether
that's
a
particular
dollar
amount.
For
example,
like
I'm,
trying
to
transfer
only
under
a
hundred
dollars
or
make
a
payment
under
100
or
whatever
it
is.
C
B
C
Are
cases
where
das
might
provide
a
list
of
things
to
authorize
that
the
client
doesn't
know
about
right.
H
Question
for
I
was
just
in
general
sort
of
responding
to
justin.
I
was
wondering
whether
this
that
this
dynamic
interaction
model
would
at
all
be
desirable
to
standardize
like
from
your
experience,
so
you
mean
the
rs
discovery
type
of
model,
yeah
kind
of
it
would
be.
I
think
it
would
have
to
be
more
than
that,
but
okay,
like
because
you
distinguish
between
those
two
models
in
some
sense.
G
And
so
if
a
client
has
to
call
a
specific
api,
it's
going
to
plug
in
whatever
values
into
its
oauth
library
to
make
that
work
so
making
that
more
dynamic
makes
sense
in
the
context
of
more
widely
deployed
apis
and
we're.
Seeing
that
in
cases
like
you
know,
the
open
banking,
so
you've
got
the
financial
vertical
with
fire
in
the
healthcare
vertical,
but
those
all
have
kind
of
their
own
resource
discovery
layers
that
they
output.
Things
that
you
plug
into
the
that
you
plug
into
the
authorization
layer
into
the
oauth
layer.
G
We
have.
We
have
similar
considerations
in
the
ganap
protocol
about
you,
know
the
rs
and
the
as
and
how
they
can
possibly
connect
to
each
other.
But
it
follows
the
same
model.
At
the
end
of
the
day,
the
client
is
just
going
to
request
something
at
the
a.s,
and
the
a.s
still
has
to
figure
out
what
that
means.
B
A
To
I
think,
just
jeff
asked
with
raw
you:
can
you
can
have
both
models?
So,
as
aaron
pointed
out
the
use
case
where
the
client
just
assembles
an
authorization
request,
object
sends
it
to
the
ais,
gets
the
access
token
and
is
done.
Payment
is
one
of
those
an
account
information
is
a
bit
more
complex
because
you
typically
start
with
give
me
a
list
of
your
accounts
and
then
okay.
A
I
would
like
to
access
the
transactions
on
this
particular
account,
but
potentially
because
the
user
selected
that
account
in
the
current
defined
phase
of
the
client
and
then
you
use
that
value
and
compose
a
new
authorization
request,
object
and
that's
perfectly
possible
with
with
what
we
have
in
the
spike
right
now,
and
it's
also
being
done.
A
I
think
what
would
be
very
interesting
from
an
interoperable
perspective
would
be
to
really
have
a
model
where,
as
an
rs,
can
really
exchange
ideas,
information.
Sorry
because
sometimes
you
really
end
up.
I
agree
with
george.
Sometimes
you
are
approaching
a
territory
where
the
s
and
the
rs
needs
to
needs
to
to
talk
to
each
other
in
the
course
of
the
user
content
process.
A
I
I
typically
try
to
circumvent
that,
because
it's
introducing
a
lot
of
dependencies,
latency
and
so
on.
So
what
we
have
right
now
in
our
in
our
implementations
is
we've
got
more
or
less
a
some
logic
in
the
as
really
carefully
modularized.
A
That
does
something
on
behalf
of
the
rs
but
does
not
need
to
really
call
back
to
the
to
the
rs,
but
that
that's
that's
a
new
kind
of
interaction
model
right
now.
I
don't
think
we
need
a
standardization
for
that.
That's
part
of
the
implementation
design
decision
space
but
might
be
a
topic
of
future
work.
D
B
No
naturally,
I
was
just
agreeing
with
what
justin
was
saying
about
the
if
the
client
normally
knows
what
it
needs
and
that
entails
title
coupling.
But
given
that
you
made
a
mistake
of
giving
the
slot,
I
wanted
to
make
a
general
comment,
which
is
authorization
is
a
very
deep
rabbit
hole
and
many
people
already
fell
through
that
before.
B
So
I'm
wondering
if
there's
any
value
in
looking
in
comparing
the
subset
of
the
specific
authorization
aspects
that
you're
considering
in
rar
versus
prior
art,
like
is
alpha
covering
some
of
those
things.
Is
it
possible
that
some
of
the
apis
that
would
want
to
use
rar
as
a
way
of
communicating
requirements
are
already
using
some
of
these
other
standards
to
specify
at
rest
what
their
permissions
and
authorization
logic
is?
So
I
like
I,
I
don't
have
a
any
specific
example.
D
Okay,
maybe
a
quick,
quick
reply
to
this
and
then
we'll
we'll
finish
it
here.
G
Yeah,
so
we
set
out
explicitly
to
not
create
or
define
a
full
query
response
or
or
or
policy
description
like
executable
policy
description
language
with
rar
we're
trying
to
skate,
as
close
as
we
can
to
sort
of
the
simple
like
set
of
access
rights
structure
that
scopes
gives
us
but
allow
for
sort
of
another
step
of
specificity.
Beyond
that
granted.
Somebody
could
use
rar
to
carry
all
of
this
other
stuff,
and
you
know
they'd
be
allowed
to
they're
they're
json
objects.
G
They
can
define
their
own
types
if
if
they
choose,
but
we
explicitly
didn't
want
to
get
into
that
space
and
honest,
I'm
sorry,
we
don't
have
enough
time
for
me
to
say
why
zakamal
failed.
D
Yeah,
it's
we're
done
here.
So,
okay.
I
think
you
guys
know
how
like
how
to
proceed
with
this.
I
think
I
don't
think
anybody
is
saying.
No,
don't
don't
provide
this
guidance.
I
think
it
makes
sense.
It's
just
that
the
details
that
we
need
to
flush
out
and
and
discuss
later
on,
okay,
and
in
any
last
comments,
questions.