►
From YouTube: IETF110-GNAP-20210309-1600
Description
GNAP meeting session at IETF110
2021/03/09 1600
https://datatracker.ietf.org/meeting/110/proceedings/
B
We
are
leaf
and
iron.
Well,
I'm
iran
and
I'm
here
and
we're
at
the
nap
working
group
and
let's
go
the
note.
12
applies
to
this
meeting.
So
if
you,
if
you're
new
to
the
itf
or
haven't,
read
these
materials,
yet
please
take
some
time,
go
through
them
and
understand
the
the
implications,
especially
ipr
implications
of
whatever's
being
said
at
the
meeting.
B
B
No
blue
sheets.
We
do
need
a
minute
taker
and,
as
we
said
before,
we
started
it's
a
great
opportunity
for
someone
who's
new
to
the
group
to
get
involved
and
to
get
to
know
the
people
to
ask
people
for
their
names
to
clarify
points
and
so
on,
and
we
need
a
minute
taker.
Please
let
us
know
if
you
can
do
it
and
I'll
stop
at
this.
B
B
C
A
D
E
B
B
Please
speak
up
by
resign
by
raising
or
please
q,
to
speak
up
by
raising
your
hand
in
the
application.
The
agenda
for
today
is
almost
exclusively
about
the
core
protocol
and
will
be
led
by
the
editorial
team.
At
the
very
end
of
the
meeting
we
will
discuss
next
steps.
The
knee
prepared
is
some
additional
material.
We
will
get
to
that.
E
A
E
B
B
E
E
E
All
right,
so
next
slide
differences
since
ietf109,
we
have
everything
linked
handily
in
this
slide
deck,
so
the
the
slide
deck.
I
believe
you
can
download
from
the
meeting
materials.
If
you
are
curious
and
then
all
those
links
are
clickable,
so
we
have
published
two
two
incremental
drafts
of
four's
the
current
draft,
and
this
is
the
full
diff,
but
we're
gonna
break
this
down.
Go
ahead
to
the
next
slide,
everything
that
we
have
been
working
on
in
the
draft
is
captured
in
github.
So
that
includes
the
discussions
about.
E
What's
been
going
on,
the
some
you
know,
justifications
and
and
thoughts
going
into
those
threads.
Everything
is
captured
as
issues
and
then
created
as
pull
requests
to
actually
change
the
document.
So
you
can
click
on
that
link
which
looks
at
all
of
the
poll
requests
that
have
been
merged,
that
are
the
diffs
of
between
the
two
documents.
E
So,
starting
at
the
top,
there
was
a
there
was
previously
oh
another
option
for
sort
of
kicking
off
the
flow
which
was
to
use
a
short
url
instead
of
a
long
or
regular
url.
That
kind
of
overlapped
too
much
with
the
regular
url
redirect
slash
the
sort
of
qr
code
device
style
redirect
and
we
thought
it
wasn't
needed.
So
that
is
now
dropped.
A
lot
of
you'll
you'll
sort
of
see.
E
This
theme
here
throughout
these
changes,
which
is
a
lot
of
what
we're
trying
to
do,
is
simplify,
simplify
some
of
that
so
trying
to
reduce
the
number
of
optional
pieces
to
make
it
just
so
that
it
is
less
less
normative
text
less
optional
pieces,
so
that
there's
more
chance
of
actually
having
something
functional
and
interoperable
the
next
one
140.
That
is,
we
we
dropped
the
section
in
the
spec
that
talked
about
how
to
request
open
any
connect
claims.
E
E
E
122
163
grouping
interaction
modes,
so
interaction
modes
are
the
different
ways
that
a
client
can
say
it
can
interact
with
the
user
it
can.
It
can
tell
the
server
hey,
I
can
redirect
the
user
in
a
browser,
or
I
can
show
them
a
code
on
a
screen
I
can
be
redirected
to,
or
I
cannot
be
redirected
to
things
like
that.
Those
are
all
the
different
modes.
E
Those
are
now
grouped
and
labeled
more
explicitly
so
that,
hopefully,
just
by
looking
at
json
syntax,
you
have
a
better
idea
of
what
each
of
those
pieces
is
actually
meant
to
do
and
don't
have
to
go
and
look
it
up,
hopefully,
lastly,
dropped
reading
the
grant
and
token
again.
This
was
in
the
in
the
theme
of
in
the
theme
of
trying
to
simplify
and
remove
optional
things.
E
Nobody
seemed
to
care
about
having
this
option
available,
and
this
was
previously
a
way
to
sort
of
have
the
client
query
the
server
to
ask
about
tokens
and
ask
about
progress
reports
and
things
like
that,
but
without
any
concrete
use
cases
or
concrete
needs,
it's
just
generally
better
to
not
have
those
options
in
there.
So
there's
less
stuff
to
even
worry
about
in
the
first
place.
E
Okay,
so
next
slide.
This
is
an
example
of
the
new
syntax
for
requesting
an
access
token.
So
you'll
see
there's
this
sort
of
container
access,
token,
the
little
yellow
border
on
the
outside,
and
that
is
now
meant
to
say,
hey.
The
client
is
asking
for
an
access
token
and
then
within
that
are
the
different
aspects
of
the
request.
E
One
of
those
aspects
is
called
access.
That
is
a
new
name
for
it
and
that
talks
about
it's
a
it's
a
it's
a
full
object
that
talks
about
the
different
kinds
of
things
it's
actually
asking
for,
so
that
that
might
be
excuse
me
that
might
be
asking
for
specific
actions
which
kind
of
roughly
correspond
to
oauth
scopes.
E
You
might
be
asking
for
access
to
particular
apis
at
specific
locations.
Those
are
those
urls
you
can
throw
in
data
types
in
there
as
well.
So
those
are
all
now
grouped
there.
Those
don't
have
to
be
rich
objects.
They
can
also.
It
can
also
just
be
a
string.
So
the
simple
case
is
that
one
that's
called
reference
or
labeled
reference
where
it's
just
read.
E
So
the
idea
is
that
that
would
correspond
to
some
sort
of
rich
thing
on
the
server
side,
on
the
authorization
server
that
isn't
necessarily
described
in
detail
by
the
client
so
again
we're
trying
to
make
it
so
that
the
simple
cases
work
simply.
But
you
do
have
more
flexibility
to
be
more
specific
if
you
need
to,
and
then
flags
and
labels
are
again
other
aspects
of
the
request,
so
flags
are
broken
out.
E
Instead
of,
I
think
we
used
to
have
it
as
boolean
values,
but
now
the
presence
of
the
of
the
string
there
indicates
that
it
is
part
of
the
request.
Those
are
again
things
the
client
is
requesting
and
then
label
as
if
the
client
is
asking
for
it's
really
only
useful
to
clients
asking
for
more
than
one
access
token.
It's
asking
the
server
to
label
that
token
with
that
label
when
it
returns
the
multiple
tokens.
E
E
So
same
idea
here.
This
is
actually
only
slightly
different
than
the
previous
syntax,
but
this
is
how
this
is
the
part
where
the
client
tells
the
authorization
server,
how
it
can
interact
with
the
user.
So
there's
two
parts
to
the
interaction
with
the
user.
There's
how
the
client
can
start
the
interaction
and
how
the
client
can
finish
the
interaction,
so
the
start
would
be.
E
I
can
redirect
the
user's
browser,
because
I'm
interacting
with
the
user
in
a
browser
already
or
it
could
be,
that
it's
more
like
a
browserless
device
or
like
a
a
smart
tv
where
it
doesn't
have
a
browser.
It
doesn't
have
the
ability
to
interact
with
the
user
that
way,
but
it
can
show
them
a
code
like
a
user
code
where
they
can
type
it
in
on
a
separate
device.
So
those
are
the
two
different
modes
in
this
example
of
how
a
client
can
start
the
interaction
and
how
the
client
can
finish
the
interaction.
E
If
the
client
has
the
ability
to
be
redirected
back
to
from
the
authorization
server,
then
that's
method
redirect
there's
also
a
method.
I
believe
it's
called
now.
I'm
blind
now,
I'm
creating
the
name
of
it.
Doesn't
matter
push
that's
what
it
is
method
push
where
if
the
client
has
the
ability
to
receive
a
post
request
directly,
so
that
would
be
something
that's
like
on
a
server
rather
than
on
a
mobile
phone.
E
E
Obviously
it
can't
enforce
that,
but
it
is
a
request
from
the
client.
So
the
grouping
is
the
main
new
thing,
and
this
again
these
functions
were
already
there
before.
Okay,
next
and
last
slide.
For
me,
editorial
changes
there's
a.
We
did
a
whole
bunch
of
this
stuff
and
again
these
aren't
super
critical.
E
I'm
not
gonna
spend
too
much
time
on
the
details,
but
the
idea
of
the
editorial
changes
is
it's
just
stuff
that
we
thought
read
better
in
the
spec,
and
this
is
you
know,
fixing
typos
clarifying
language,
it's
not
changing
any
functionality
or
any
syntax,
or
anything
like
that.
So
did
a
handful
of
that
and
there's
a
couple
of
actually
new
fixes
since
o4
pending.
G
Yeah,
I
think
I'm
broadcasting
now,
okay-
and
I
I
will
say
before
we
move
on
on
that
last
one-
a
big
thanks
to
fabian
for
taking
the
lead
on
the
terminology
discussion.
There
was
a
even
though
it
kind
of
counts
as
editorial,
because
it's
not
changing
the
technical
stuff
naming
stuff
is
hard
and
he
did
a
lot
a
lot
of
really
good
work
to
to
move
that
forward.
G
So
thanks
for
that
all
right,
so
we
did
a
lot
of
work
since
the
last
ietf,
and
so
the
question
now
is
what
are
we
working
on
next
right?
So
today
we're
going
to
talk
about
two
things
in
detail:
fabian's
going
to
be
discussing.
Subject,
identifiers
and
you
know
identifying
users
and
different
use
cases
that
tie
into
that
and
I'm
going
to
be
spending
some
time
talking
about
these
on-device
use
cases
and
the
fallout
from
that.
G
In
some
of
the
interim
calls,
we
had
a
lot
of
discussions
about
self-sovereign
identity
and
how
that
could
relate
into
the
knapp
world,
and
so
I'll
be
talking
about
that
a
little
bit
later
on,
but
there's
two
other
issues
that
I
wanted
to
touch
on.
Really
quick
here
we're
not
planning
on
getting
in
depth
in
either
of
these
on
this
call,
but
the
editors
have
identified
all
of
these
areas
as
things
that
we're
going
to
try
and
prioritize
between
now
and
the
next
ietf
meeting
for
work
on
this
specification.
G
G
So,
first
off
there
are
a
lot
of
questions
about
how
we
handle
key
presentation
and
message
signing
in
the
draft,
and
there
are
some
changes
happening
outside
of
the
ganap
working
group
that
we're
going
to
be
benefiting
from
first
off
the
http
message.
Signature
draft
is
progressing
in
the
http
working
group.
It
was
a
little
bit
stuck
for
a
bit
and
trying
to
help
get
that
unstuck,
because
I
think
that's
going
to
be
useful
for
a
wide
variety
of
things,
not
just
for
us
here
in
canap.
G
Also,
thanks
to
some
implementation
experience
from
aaron
and
myself,
we've
got
some
ideas
and
some
feedback
from
some
some
other
folks
posting
in
the
issue.
Tracker
we've
got
some
ideas
on
how
we
might
be
able
to
change
how
we're
using
the
jose
based
signature
mechanisms
to
make
them
a
little
less
awkward
in
practice,
and
this
this
goes
to
show
that
you
know
getting
multiple
engineers
to
implement
something
and
see
where
they
disagree.
G
G
Another
big
discussion
that
we
need
to
have
as
a
working
group
is
managing
key
rotations.
We've
got
a
bunch
of
different
things
that
use
keys
all
throughout
this
protocol.
It's
really
kind
of
built
into
the
fabric
of
the
protocol
itself,
but
we
need
to
figure
out
how
we're
going
to
manage
these
different
states
of
rotating
these
keys.
G
What
does
it
mean
for
a
client
to
rotate
a
key?
Does
that
mean
that
all
of
the
access
tokens
that
have
been
issued
to
that
client
do
they
use
a
new
key
or
the
old
key
are?
Do
we
allow
an
as
to
separate
those?
Do
we
require
an
as
to
separate
those
there's
a
lot
of
questions
about
how
to
do
that
and
in
a
way,
that's
predictable,
because
this
is
deep
in
the
security
model
of
the
protocol
itself.
G
These
are
discussions
that
that
we
need
to
have,
and
some
some
of
the
things
that
we
hope
to
be
able
to
tackle
within
the
next
few
months,
but
now
I'm
going
to
hand
it
over
to
fabienne
to
talk
about
one
of
the
big
areas
that
we're
going
to
try
and
tackle,
and
that
is
that
of
subject
identifiers,
so
fabian.
Just
let
me
know
when
you
want
the
next
slide.
Yes,
that's.
H
H
Next
slide,
please
so
the
way
we
decided
it
would
be
a
good
subject
to
cover
is
because
we
looked
at
the
list
of
open
issues
and
basically,
we've
got
a
lot
that
actually
correspond
to
that
subject.
So
it's
either
subject
identifiers
by
themselves
or
as
sessions
which
are
related
also
to
the
to
the
subject
as
well.
H
So
the
first
pr
that
we
can
discuss
is
in
padding
match
status.
It's
subject
types,
so
it's
184
and
thank
you
andrew
for
submitting
that.
So
it's
it's
good,
also
to
to
say
that
you
can
actually
participate
actively
and
in
in
such
a
case.
We
actually
reviewed
the
proposal
and
we
actually
accepted
it,
and
everyone
can
actually
follow
that
on
github.
H
So
that's
in
the
request
and
then
in
the
response
you
get
the
list
that
you
expect
so
just
to
summarize
a
bit
how
it
works
today
in
the
drafts,
you've
got
a
user
part
which
is
really
what
the
client
tells
about
the
current
user.
What
you
know
from
from
from
a
fact
on
the
client
side,
so
it's
really
more
kind
of
a
hint
to
the
authorization
server.
Then
you've
got
the
request
where
you
actually
can
request
some
some
information
about
the
user
and
the
authorization
server
will
actually
respond
using
the
response.subject.
H
So
one
of
the
other
issues
we
had
is
so
we
have
two
issues
related
to
emails,
so
there
are
16
and
42,
and
basically
these
two
issues
relate
to
the
same
idea
that
maybe
email
is
not
the
best
way
to
actually
describe
the
subject.
Identifier,
at
least
it's
not
the
one.
We
want
to
encourage
in
in
most
cases
for
different
reasons.
The
first
one
is
that
we
don't
have
really
a
good
way
to
make
it
unique.
H
H
But
you
do
have
a
lot
of
interesting
things
and
there's
a
new
version
which
has
just
been
published
and
so
you've
got
accounts.
Email
phone
issuer
and
you've
got
also
aliases
as
well.
What
I
would
propose
is
also
to
cover
what
I
called
es
reference
or
as
a
reference.
It
depends
if
it's
specific
to
gnapp
or
if
it's
something
generic
for
the
second
event
working
group,
and
that
would
be
a
kind
of
opaque
reference
to
the
actual
user,
and
it
would
be
something
that
the
authorization
server
would
would
drive
the
next
slide.
H
H
Discussions
on
the
actual
scope
of
the
subject
identifiers,
so
the
question
mostly
is
about
whether
it's
global
or
whether
it's
it's
a
local
identifier-
and
I
know
that
denis,
for
instance,
has
some
more
ideas.
Some
more
granular
ideas
on
that
here.
What
we
would
propose
is
to
actually
take
that
from
the
definition
that
was
accepted
by
the
working
group,
and
it's
said
that
it's
basically
a
statement
asserted
locally
by
an
is
about
a
subject.
So
here
what
we're
saying
is
we're
not
going
to
cover
global,
unique
identifiers
anyway?
H
H
So
basically
the
idea
is
it's
more
to
go
around
something:
that's
unique
to
the
authorization
server,
so
we
can
actually
identify,
and
then
we
can
correlate
users
that
are
actually
identified
by
the
authorization
server,
but
it's
not
a
global
system
per
se
and
then,
of
course,
we
can
decide
in
more
granular
ways
what
we
want
to
do
with
that.
But
that's
for
a
later
discussion.
H
H
The
idea
is
that
in
open
id,
you've
got
some
discussions
on
how
to
make
the
identifiers
portable
from
one
implementation
to
another
or
from
open
id
connect
to
deeds
and
so
on,
and
so
there
are.
There
are
basically
two
ways
we
could
support
that.
The
first
one
is
through
sec
event,
aliases,
which
are
already
existing
in
the
spec,
and
then
it's
related
to
the
subject,
types
that
we
discussed
a
bit
earlier.
H
We
also
have
assertions
which
are
described
into
the
map
draft
and
then
it's
assertion,
types
which
are
related
to
that
information.
So
the
reason
why
we
can
cover
portability
thanks
to
that
is
because
you've
got
a
list
of
options,
so
either
a
list
of
fallacies
or
a
list
of
assertions
related
to
the
same
identity,
and
so
you
can
actually
get
from
one
system
of
identifiers
to
the
next
and
that's
what
you've
got
listed
into
the
into
the
issue.
171
and
you
can
read
the
the
draft
of
the
specification
for
that.
It's
interesting.
H
The
question,
however,
is
whether
portability
is
really
in
the
scope
of
what
we
want
to
do.
It
seems
a
bit
more
transactional
like
going
from
an
open
id
connect
provider
to
a
search
of
an
identity,
type
of
presentation,
but
anyway,
what
we
can
do
is
is
support
interpretability
between
various
identity
systems,
and
so
we
are
agnostic
to
whether
it's
open
id
connect
or
some
other
type
of
identity
system.
But
we
need
to
actually
support
what
exists,
and
so
that's
what
kidnap,
I
think,
can
can
bring,
and
the
current
structure
actually
helps
for
that.
H
And
here
we
have
several
options.
The
one
that's
currently
in
the
spec
is
what
I
call
option
two.
Basically,
what
we
have
is
a
is
a
it's
not
called
as
reference.
It's
called
a
bit
differently,
but
the
idea
would
be
to
actually
have
an
opaque
reference
or
a
string
which
looks
random
and
that's
actually
referring
to
the
current
transaction.
H
A
question
that
arises
here
is:
do
we
want
to
make
it
only
local
to
the
authorization
server?
Basically
considering
there's
only
one
single
authorization
server,
although
we
want
to
to
deal
with
with
that
information,
a
bit
like
what
we
have
in
ess
sub,
where
you've
got
basically
the
server
and
then
you've
got
the
subject,
identifier
which
are
set
right,
so
you
could
have
actually
a
list
of
gnap
authorization,
servers
potentially
and
then
you've
got
option,
one
which
is
more
as
an
extension
to
sec
events.
H
H
So
it's
just
a
suggestion
here
and
here
the
good
thing,
if
we
do,
that
is
that
we
actually
can
just
reuse
the
subject,
identifier
types
and
use
the
additional
types
in
the
registry.
So
that's
something
that's
the
sec
event.
Working
group
has
been
providing.
It's
just
never
been
used
yet,
so
we
need
to
to
actually
make
it
practical
in
in
to
to
be
used
within
app.
H
H
Another
item
which
is
currently
discussed
into
the
issues
is
the
assertions,
so
we
do
have
a
subject
identifier
and
next
to
that
we've
got
some
assertions.
The
typical
use
case
that
we
have
in
the
draft
today
is
open
id
token,
so
id
tokens
that
you
have
here
on
on
the
right
hand,
side
of
the
screen
so
you've
got
an
example.
H
Today,
it's
only
one
value,
you've
got
only
one
assertion
and
the
question
from
issue
43
was:
do
we
want
to
support
several
assertions
like
an
array
or
is
it
enough
as
just
one
single
value?
So
what
I
would
propose
is
actually
that
it's
very
useful
to
have
potentially
several
values
here,
and
so
I
would
propose
an
array
instead
of
of
just
a
single
value,
also,
we
have
issue
41
and
that
relates
to
what
kind
of
a
sessions
we
want
to
support.
H
H
H
The
rest
is
basically
json
based,
and
here
we
would
have
to
deal
with
something
on
top
of
that,
and
the
question
is
related
also
to
whether
we
could
use
that
as
an
extension.
I
think
it
would
make
sense
for
compatibility
reasons,
because
you've
got
a
lot
of
systems
that
are
based
on
some
other
sessions,
but
it's
a
good
case
for
an
extension
next
slide.
Please.
H
I
basically
had
in
mind
that
it
could
be
either
one
or
the
other,
but
then,
when
you
look
at
id
token,
it
makes
sense
to
actually
put
that
into
an
assertion,
and
so
it
would
be
just
the
same
for
deeds
and
for
other
types
of
systems.
So
the
idea
would
be
that
you
have
an
identifier
and,
alongside
this
identifier,
would
have
assertions
that
could
prove
some
identity
or
that
could
prove
some
facts
on
on
that
identity.
H
It's
also
the
it's
again
the
case
for
the
email,
and
so
you
do
create
a
kind
of
association
between
a
weak
identifier
like
the
email
and
the
stronger
identity
assertions
like
an
id
token-
and
this,
of
course,
is
a
bit
less.
The
case
is
you've
got
if
you've
got
on
low
back
reference
and
the
stronger
identity
assertion,
because
this
opaca
session
is
related
only
to
the
authorization
server
and
it's
also
something
where,
in
some
cases
we
could
use
more
advanced
types
like
verifiable
credentials,
for
instance,
next
slide.
H
Thank
you
dustin.
So
this
brings
us
to
the
remaining
issues
and
they
all
go
around
the
same
question
so
resource
owners
versus
end
users
and
that's
something:
we've
been
discussing
quite
a
lot
in
the
mailing
list
and
that's
something
we've
been
discussing
also
in
many
cases
in
during
the
interim
meetings,
and
so
we've
got
issue,
for
instance,
197,
and
we
see
that
in
the
text
today,
we've
got
identifying
the
user
returning
user
information
so
again
that
relates
to
request.user
and
that
request
and
that
request
to
user.
H
H
H
So
what
exists
today
is
in
the
oauth
world.
You've
got
basically
the
assumption
that
basically,
the
resource
owner
is
the
same
as
the
end
user.
In
most
cases
and
in
uma
2.
You
basically
consider
that
they're
different,
so
we've
got
a
few
very
detailed
use
cases
from
participants
in
the
group
and
that
they're
very
detailed,
but
the
problem
today
is:
we've
got
a
fragmented
ecosystem
and
each
time
we've
got
a
new
interaction
like
sea
balance
and
so
on.
H
We've
got
to
think
again
from
scratch
and
what
we
want
to
do
also
with
gnap,
is
try
to
solve
this
issue
too,
and
especially
in
the
specification
we've
got
some
diagrams
at
the
beginning
of
the
document,
so
we've
got
1.4.3,
which
is
really
a
synchronous
consent
and
what
we
mean
by
that
is
we're
going
to
reach
out
to
some
remote
resource
owners.
At
some
point,
we've
got
also
sequence
diagram,
1.4.4,
and
here
it's
software
only
authorization.
H
What
in
my
own
balance,
I
call
automated
rule
engine
and
the
problem
is
section
four,
which
is
about
interaction,
only
covers
sequences,
1.4.1
and
1.4.2,
which
also
are
the
one
that
aaron
actually
described
earlier.
So
that's
the
user
interface
interactions
so
either,
but
they
are
redirect
or
via
a
map
or
in
some
cases,
very
push-based
interaction.
H
H
H
What
we
want
to
have
in
mind
also,
is
that
ultimately
it's
the
decision
of
the
authorization
server,
it's
something
that
it
should
validate.
It
should
make
sure
that
is
the
one
that's
responsible
for
that
choice
and
in
many
cases
at
least,
for
complex
applications.
The
only
way
to
know
for
sure
is
when
you've
completed
the
user's
authentication.
H
H
H
I
could
ask
also
some
assertions,
and
actually
I
described
what
I
called
ins,
which
are
optional,
so
you
don't
have
to
provide
them,
but
you
can
in
the
request-
and
I
described
actually
the
part
in
two
in
in
two
sections.
The
first
one
is
self
and
that's
what
I
actually
described
as
the
equivalent
of
what
we
have
today
as
a
request.user
self
is
just
used
here
to
clarify
that
it's
not
meant
as
a
role.
H
Of
course,
all
of
that
is
just
a
well
a
suggestion
to
the
authorization
server
just
to
help
him
make
the
right
decision.
But
then
we've
got
issue
49,
which
is
probably
the
most
difficult
to
solve,
and
it's
something
we've
got
in
many
places
already
in
in
the
issues
is
whether
it's
a
shoot
or
it's
a
whether
it's
a
must,
but
at
least
you've
got
the
idea
that
the
int
is
only
something
that's
going
to
try
to
help,
but
the
authorization
server
is
the
one
that
makes
the
decision
next
slide.
Please.
H
So
if
we
look
at
the
practical
sequence
so
1.4.3,
I
imagine
one
case
which
would
be
a
parental
control,
app
and
you've
got
a
child.
That's
actually
going
to
ask
for
approval
of
his
dad.
So
obviously
the
end
user
is
a
child
and
the
remote
resource
owner
is.
Is
that
in
that
case,
so
you've
got
principle
and
the
way
I
described
it
is
async,
because
it's
sequence,
1.4.3
is
actually
describing
the
seconds
diagram
as
as
asynchronous,
then
you've
got
resource
owner
and
the
resource
owner
would
be
a
subject.
H
Also-
and
here
you've
got
an
assertion
and
within
that
accession
I
didn't
put
the
entire
stuff
because
it's
limited
in
space,
but
it
would
be
a
decentralized
identifier,
for
instance.
In
that
case,
of
course,
you've
got
many
questions
on.
How
do
you
know
it's
a
legitimate
deed
and
so
on,
but
we
can
probably
deal
with
that
and
it's
in
any
case,
that's
a
question
we
would
have
as
soon
as
you've
got
some
remote
connections
to
make.
H
So
that's
the
first
way
to
well
that's
the
first
sequence.
We
can
deal
with
so
remote
owners
here
and
on
the
next
slide.
We've
got
the
proposal
for
sequence
1.4.4,
so
here
you've
got
the
automated
rule,
so
the
use
case
is
the
child
wants
to
watch
a
thing,
but
maybe
it's
too
young,
so
usually
the
way
that
you
could
implement
that
is
so
in
the
self
structure.
H
You've
got
an
assertion
like
you've
got
a
verifiable
credential
on
the
date
of
birth
or
you've
got
a
zero
knowledge
proof
on
the
age
and
then
in
the
principle
structure
you
would
just
say
that
it's
automated,
so
it's
not
async
asynchronous
here.
It's
just
an
automated
rule,
running
on
the
authorization
server
and
we
say
true
to
activate
the
automated
rule.
So
the
client
would
actually
say
that
to
the
authorization
server,
please
check
the
automated
rule
to
actually
accept
or
deny
the
access
to
the
theme.
H
The
idea
also
is
to
actually
make
it
composable,
so
a
sign
could
fail.
So
that's
one
of
the
big
issue
with
trying
to
reach
out
to
remote
resource
owners,
so
he
could
be
unavailable,
so
the
dad
could
be
doing
something
else
and
or
he
couldn't
respond
quickly
enough
or
maybe
he's
doing
some
other
work
or
whatever,
and
on
the
other
case,
if
you
are
using
an
automated
rule,
ending
it
could
be
limiting.
H
H
So
the
idea
is
it
could
be
composable.
If
we
do
that
and
on
the
next
slide
we
could
actually
even
potentially
reach
out
to
multiple
resource
owners,
which
is
something
we
don't
really
see
as
a
typical
use
case,
because
it's
a
bit
limited,
but
we
could
imagine
inference
on
that.
Child
would
actually
reach
out
to
that.
H
But
maybe
marvin
is
nicer,
and
so
we
would
want
to
actually
reach
out
also
to
them,
but
in
in
general,
in
the
general
case,
what
we'd
like
to
do
is
to
be
able
to
actually
manage
potentially
resources
which
are
which
are
shared
between
multiple
parties,
and
so
that's
what
we
could
do
here.
Of
course,
we
need
to
keep
it
simple,
so
I
imagine
something
like
quickest
or
quorum.
H
Of
course,
if,
if
you've
got
only
one
arrow,
it
would
be
ignored,
but
then,
if
you've
got
multiple
resource
owners
who
share
the
decision,
you
need
to
decide
how
the
decision
would
would
be.
So
maybe
it's
going
a
bit
too
far.
I
don't
know
if
it's
something
we
want
to
do,
but
at
least
it's
we
can
imagine
that
it
could
be.
It
could
be
something
next
slide.
Please.
H
So
the
exercise
is
interesting
because
it
shows
that
in
here,
in
yellow
you've
got
subject
ins,
which
is
a
new
structure,
to
actually
provide
some
ahead
of
time
int
to
the
authorization
server.
So
the
idea
is
you've
got
the
self
structure
or
the
user
structure.
In
the
current
version
you
would
add
a
principal
description
which
is
optional,
also
and
automate.
H
It
is
an
internal
structure
within
the
principal
structure
which
is
also
optional
and
based
on
that
it
would
be
a
kind
of
help
for
the
authorization
server
to
determine
what
to
do,
and
so,
depending
on
the
values
you
take,
it
would
actually
bring
you
to
the
different
sequences.
So
today,
the
only
two
that
we
cover,
as
are
on
the
top
and
side
of
the
right
hand,
side
of
the
of
the
screen
here
so
sequence,
1.4.1
on
sequence,
1.4.2
and
both
basically
correspond
to
the
case
where
you've
got
a
user
interface.
H
That's
used,
and
basically
you
send
the
end
user
to
this
interface
because
is
also
the
resource
owner,
and
the
two
cases
at
the
bottom
of
the
screen
in
blue
are
the
two
additional
seconds
diagram
that
are
actually
in
the
draft
today.
But
aren't
three
in
in
detail,
and
especially
in
section
four
and
the
fact
that
we
have
did
in
the
example
allowed
to
imagine
something
like
a
deep
cam
engine
to
actually
communicate
and
we'll
see
that
in
the
next
slide.
H
H
So
that's
obviously
useful
for
case
1.4.3,
and
I
would
still
consider
that
the
client
has
to
know
the
deeds.
We
wouldn't
have
some
kind
of
automatic
discovery
of
deeds
or
whatever.
I
think
it's
completely
out
of
scope,
but
if
we
do
that,
we've
got
an
easier
integration
with
self-serving
identity,
and
it's
also
something
more
importantly
for
gnabs
that
lose
asynchronous
patterns
to
reach
remote
on
us
and
for
sequence,
1.4.4.
H
H
H
So
it's
dennis
that
has
asked
this
question
and
that's
interesting
because
he
was
saying
that
subject
is
is
something
where
it's
mostly
human,
which
is
true,
but
here
we
see
that
in
some
cases
the
subject
will
actually
be
a
machine
that
could
be
a
rule
ending
from
from
a
company
or
it
could
be
some
other
device
from
a
remote
owner
next
slide.
Please.
H
And
so
here
we
get
back
to
a
kind
of
extension
proposal
to
what
aaron
has
been
showing
at
the
beginning
of
the
slides
of
the
session.
So
it's
the
same
interact
description
that
we
had
it's
just
that
here
in
the
start
value
actually,
I
did
did
come,
so
that's
actually
something
that
was
already
discussed
in
xyz
back
in
the
time.
H
H
H
So,
in
terms
of
benefits
on
downside,
so
what
I've
tried
to
imagine
is
how
we
could
actually
carry
out
some
real
identification.
It
doesn't
at
all
remove
the
need
for
runtime
evaluation
by
the
authorization
server.
Actually,
I
would
even
suggest
it
in
increases
that
that
requirement,
because
the
authorization
server
ultimately
is
the
one
that
actually
decides
about
what's
going
on.
H
H
It's
actually
clarifying
whose
concern
so
that's
entirely,
embedded
within
the
subject
structure.
Now
you
can
actually
cover
the
interaction
within
the
interact
structure
and
the
what
is
really
related
to
the
client
and,
of
course,
we've
got
a
lot
of
security
and
privacy
configurations.
I
don't
pretend
to
have
solved
that
right
now
and
anyway,
should,
unless
again
is,
is
kind
of
an
issue,
so
we'll
have
to
do
that
next
slide.
Please,
and
I
think
it's
the
last
one.
H
So,
just
a
word
to
say
that
all
your
feedbacks
and
comments
on
suggestions
and
text
proposals
will
be
very
welcome
so
here
today
the
goal
was
to
actually
try
to
reflect
a
bit
on
what
we
have
as
issues
and
propose
a
few
ideas.
You've
got
here
a
summary
of
my
personal
preference.
It's
just
a
suggestion.
H
Again,
it's
not
as
an
editor.
It's
just
to
try
to
generate
some
ideas
and
you've
got
the
kind
of
summary
compared
to
what
we
said
today.
The
only
difference
with
the
slides,
that's
also
a
personal
preference
here-
is
that,
due
to
one
of
the
previous
comments
I
had
on
whether
lincoln's
subject,
identifiers
on
a
session
would
be
potentially
a
security
issue
is
to
try
to
determine
whether
we
should
have
it
as
a
main
structure
or
whether
it's
only
in
the
int
part
that
we
actually
support
sec
events.
So
that's
something
we
should
discuss.
H
B
B
I
think
I
I
don't
have
an
acknowledgement
from
the
authors
yet,
but
I
think
they
will
want
to
move
it
to
working
group
last
call.
So
if
there
are
important
changes
that
we
want
in
that
draft,
I
think
this
is
a
great
time
to
do
it
before
now
and
the
next
ietf,
instead
of
trying
to
register
additional
tags
after
the
fact
where
we
still
don't
have
a
process
for
it,
and
it
will
be
more
difficult
to
to
get
it
aligned
with
the
architectural
thinking
of
the
second
working
group.
G
G
I
really
believe
we've
got
an
opportunity
to
take
a
better
stab
at
this,
and
but
I
think
it's
going
to
be
really
really
important.
First
to
get
this
right,
I
think
it's
going
to
be
really
important
for
us
to
look
at
the
the
architecture
and
interconnections
of
all
of
these
different
things.
The
right
way.
G
So
traditionally,
this
has
been
talked
about
as
the
bring
your
own
authorization
server
problem
and
the
kind
of
naive
way
to
do
this
is
to
say,
okay,
so
the
authorization
server
is
a
function
of
your
device,
something
that
you
carry
with
you
and
it's
it
issues
the
access
tokens,
if
it
authenticates
the
user.
Great
we've
got
ways
to
do
that:
it
has
a
means
of
doing
cryptographically,
verifiable
items
and
things
like
that.
G
This
pattern
of
just
doing
everything
on
the
user's
device
it
seems
to
it
seems
to
make
sense
from
sort
of
a
naive
point
of
view,
but
there
are
a
lot
of
problems
when
you
actually
drill
down
into
doing
this
and
we're
seeing
this
a
lot
with
the
psyop
work.
It's
like
you
know.
How
do
you
discover
an
authorization
server?
That's
not
reachable
from
http
right.
So
if
you've
got
a
client,
that's
not
on
the
device,
but
you
still
want
the
user
to
be
able
to
authenticate
it.
How
do
you
do
that?
G
G
All
the
time
today
is
that
you've
got
you
end
up
people
building
out
kind
of
a
proxy
authorization
server,
so
the
actual
authorization,
server
or
actual
resource
server
is
somewhere
internal
and
whatever
you
present
to
this
proxy
as
be
it
an
api
gateway
or
some
other
thing,
ends
up
being
translated
to
something
internal
for
the
actual
resource
servers
to
consume.
This
is
a
well-known
pattern.
It's
well
understood
and
it's
going
to
keep
happening
like
people
keep
using
this,
but
now
really
we've
just
shifted.
G
So
the
way
that
this
pattern
works
is
that
when
the
client
instance
starts
its
negotiation
with
the
authorization
server
like
fabian
showed
in
his
proposed
syntax,
one
of
the
things
that
it
can
say
is
hey.
I
know
how
to
present
a
bunch
of
verifiable
credentials
from
the
user.
I
can
get
you
in
touch
with
their
digital
wallet
through
didcommer,
any
other
kind
of
mechanism
that
you
like.
G
I
can
facilitate
that
connection,
so
so
you
know
if
you
want
to
interact
with
the
user.
That
way
do
that.
So
in
this
way
we
can
facilitate
the
pattern
of
the
user,
interacting
not
with
the
authorization
server,
but
with
a
separate
party
might
be
a
device
on
their
wallet.
It
might
be
a
different
web
service
entirely
as
long
as
the
as
has
a
way
to
make
those
connections,
and
it's
doesn't
have
to
be
up
to
gnap,
to
define
all
of
the
ways
those
connections
can
be
made.
G
Very
importantly,
so
can
app
can
solve
the
common
use
case
of
oh.
I
just
need
to
get
the
user
in
front
of
a
web
page
at
the,
as
we've
got
ways
to
do
that.
Oauth
showed
us
how
valuable
that
is,
and
that's
wonderful,
but
for
the
cases
where
the
user's
not
doing
that,
we
shouldn't
be
pretending
that
that's
what
we're
doing
and
that's
fundamentally
that's
what
the
self-issued
op
work
from
openid
connect.
G
Does
it
pretends
that
you're
doing
a
redirect
based
web-based
type
of
thing,
where
fundamentally
you're
really
doing
something
else,
and
so
what
I'm
proposing
is
that
we
shift
our
terminology
a
bit
and
shift
how
we're
approaching
what
each
of
these
components
does
in
a
way
that
will
facilitate
this
more
general
type
of
thing
and
the
best
part
about
this,
if
you
ask
me,
is
that
we're
not
even
inventing
this
like
this
has
been
around.
This
pattern
has
been
around
for
ages.
G
If
you
go
to
any
of
the
cloud-based
oauth
providers
out
there
right
now,
they
have
mechanisms
for
a
federated
login
to
the
authorization
server,
so
there's
no
account
at
the
as
that
the
user
is
authenticating
to,
and
in
some
cases
the
user
is
not
even
providing
interaction
and
can
and
consent.
It's
just
the,
as
is
being
told
through
an
assertion
that
this
is
the
user.
That
is
here
right
now.
You'll
trust
me
because
you've
been
configured
to
trust
me
and
you
can
validate
this
and
then
the
as
takes
that
information
and
says
okay.
G
The
problem
comes
from
the
fact
that
if
you
look
at
how
the
oauth
2
core
is
written
and
therefore
how
a
lot
of
the
assumptions
that
have
kind
of
gone
into
the
start
of
gnap
are
written,
we
we
kind
of
don't
admit
that
this
is
a
possibility,
like
a
lot
of
the
assumptions
are
about,
and
you
look
at
the
diagrams
a
lot
of
the
stuff
in
there
is
about.
Oh
now,
you
redirect
the
user
over
here.
Now
you
present
a
code
to
the
user.
G
Now
you
know
you
do
these
bits
and
pieces
to
move
to
move
the
steps
along,
and
I
think
that
we've
got
a
really
fantastic
opportunity
to
codify
what
we're
doing
with
the
as
here
in
ganap.
We
no
longer
have
to
assume
that
the
user
logs
in
and
interacts
there.
We
no
longer
have
to
assume
that
that
the
user
is
that
what
the
user
is
bringing
is
their
own
access
token
or
their
own.
Their
own
authorization
server
or
anything
like
that,
which
has
always
been
a
hard
sell,
but
instead
we
can.
G
By
shifting
this,
we
can
say
that
all
right,
we
are
allowing
the
user
to
bring
things
to
this
component,
which
is
the
authorization
server,
but
it's
no
longer
the
all-seeing
almighty
all-powerful
component
that
it
had
previously
been
assumed
to
be-
and
this
gives
us
as
fabian,
was
just
showing
some
really
important
extension
points
for
talking
about
who
the
user
is,
who
the
resource
owner
is
how
we
can
interact
with
them.
You
know
gnapp
can
provide
all
of
that
structure
in
order
to
facilitate
this
style
of
approach
much
much
better
than
we
ever
had
previously.
G
Oh,
and
this.
This
also
can
allow
us
to
start
to
talk
about
the
asynchronous
and
sort
of
separate
user
and
resource
owner
use
cases
that
fabian
was
just
talking
about
and
that
user
managed
access
really
brought
to
the
forefront
where
the
person
that's
making
the
request
and
the
person
that's
authorizing.
The
request
are
not
the
same
they're
not
the
same
entity,
but
with
knapp.
G
But
I
think
that,
shifting
how
we
talk
about
it
is
going
to
be
really
important
to
making
sure
that
we
can
frame
our
conversations
in
how
we
address
these
use
cases,
because
I've
seen
a
lot
of
problems
on
the
list
in
people
applying
terms
from
the
oauth
world
and
from
the
knapp
world
in
ways
that
really
go
outside
of
what
each
of
these
different
roles
does.
What
each
of
these
different
roles
is
capable
of.
So,
yes,
you
may
want
to
gather
claims
on
an
entity
that
is
not
the
authorization
server.
G
You
may
want
to
gather
consent
on
something
that
is
not
the
authorization
server,
but
the
authorization
server
still
needs
to
be
told
that
that
consent
has
happened
so
that
it
can
issue
a
token.
We
should
be
able
to
do
that,
and
we
can
do
that,
but
we
can't
start
saying
things
like.
Oh,
it's,
the
client
that
gathers
the
consent
right
or
it's
the
resource,
server
that
interacts
with
the
resource
owner
to
define
consent,
because
those
roles
don't
do
those
things.
G
I
think
that
we
will
end
up
addressing
a
lot
of
the
currently
open
issues
in
terms
of
how
we
do
these
different
use
cases
that
people
want
to
use
gnap
for,
but
in
a
way,
that's
not
inconsistent
with
the
other
use
cases
that
we
know
people
want
to
do,
which
is
to
say
all
of
the
oauth
2
and
open
id
connect
stuff
that
is
really
well
known
and
understood
today,
and
that's
all
I
had
for
presentation,
I
was
I'm
expecting.
This
might
generate
some
conversation
here.
G
I
totally
agree
there's
policy
under
that,
sometimes,
though,
like
if
we
look
at
the,
if
I
go
back
to
the
to
the
sort
of
cloud
login
thing
thing,
sometimes
the
policy
at
the,
as
is
somebody
logged
in
from
this
domain,
and
the
client
is
known.
You
know
it's
a
known,
client
id
so
spit
out
a
token.
That
is
the
sum
total
of
the
policy
and-
and
I
mean
in
some
asses
some
that
I
have
personally
worked
on
the
policy
is
spit
out
a
token
with
whatever
parameters.
G
You
know
this.
This
other
external
piece
of
software
told
me
to
do
right
so
yeah,
I
agree,
but
that
policy
doesn't
necessarily
have
to
fit
the
the
model
of
you
know
what
user
is
present,
what
user
clicked
a
button
and
they
are
logged
in,
and
we
have
an
account
and
all
of
that
kind
of
stuff
yeah
that
that's
the
part
I
was
pushing
back
on,
not
not
policy
in
general.
E
Aaron,
I
don't
think
I
have
anything
to
add
at
this
point:
justin
pretty
much
summarized
it
but
yeah.
I
was
just
gonna
echo
that
the
policy
doesn't
have
to
be.
This
user
is
pre-known
already
and
we
know
about
what
they're
allowed
to
do.
The
policy
might
be.
This
user
exists
in
some
external
system
and
I'm
trusting
that
external
system
to
go
ahead
and
make
the
token
to
just
go
ahead
and
make
the
token
now
and
yeah.
D
I
had
a
question
related
to
what
justin
just
mentioned.
Having
worked
on
selfish
edup
in
general,
I
agree
with
just
as
comments,
but,
as
you
know,
the
salvation
of
pima
was
quite
different,
as
you
pointed
out,
was
sort
of
you
know
the
rest
of
oauth
flows
and
you
know
it
uses
hybrid,
slash,
implicit
flows.
So
is
the
point
of
this
discussion
to
figure
out
the
saturn
scope
for
gnab
discussion
too,
or
is
that
already
in
scope
for
nap?
Like?
Are
you
trying?
Are
you
trying
to
incorporate
that?
G
Yeah,
so
speaking
as
an
individual,
I
think
that
the
goals
or
the
desired
outcomes
of
self-issued
op
ought
to
be
in
scope
for
gnat
and
that's
that's
driving
a
lot
of
what
I'm
proposing
for
you
know
this.
This
sort
of
slight
shift
in
thinking
and
addressing
terminology
here.
I
personally
do
not
think
that
it
makes
sense
to
have
the
either
the
actual
technology
or
even
the
model
of
selfish
udop
as
part
of
ganap
right
so
from
a
technology
standpoint.
It's
it's.
G
G
Incan
app
is
a
really
important
is
a
really
deeply
important
architecture
decision
and
it
drastically
simplifies
how
to
work
across
all
of
these
different,
very
complex
use
cases,
one
of
the
biggest
problems
that
I've
seen
in
the
field
with
oauth
2
is
you
have
to
choose
your
grant
type
ahead
of
time,
and
that
makes
a
lot
of
assumptions
about
sort
of
who's
there.
Who
can
say,
okay
and
what
you
can
do
next
and
in
oauth.
There's.
There's
no
way
to
switch
to
a
different
grant
type.
G
You
just
have
to
kind
of
throw
that
out
and
start
something
new
and
in
the
wild
we've
seen
this
take
the
take
the
shape
of,
for
example,
starting
with
an
assertion-based
flow,
and
then,
when
that
fails,
do
one
of
the
interactive
flows
with
the
structure
in
gnapp,
though,
because
it's
meant
to
be
negotiated
over
time,
you
can
present
the
assertion
and
also
say
this
is
how
I
can
interact
and
also
say
by
the
way.
I
can
you
know,
here's
the
user's
wallet
address.
G
If
you
want
to
go
talk
to
them,
you
can
present
all
of
that
to
the
as
at
once
and
then
the
as
gets
to
decide
which
of
those
pieces
that
it
needs
right
and
then
to
yarn's
point
like
that's.
That
is
the
policy.
That's
where
the
policy
comes
into
play
because
the
as
needs
to
decide
you
know
which
of
those
bits
it
needs
to
act
on
depending
on
what
it
is
you're
asking
for,
or
you're
asking
for
information
about,
the
current
user.
G
Are
you
asking
for
information
about
how
to
get
to
an
api?
You
know
what
have
you
so
yeah
from
my
from
my
individual
perspective.
I
think
that
the
goal
of
allowing
the
user
to
bring
identity
claims
and
facilitate
that
through
this
protocol
totally
makes
sense,
and
we
should
totally
embrace
that
the
goal
of
having
the
user
carry
the
complete
authorization
server
with
them
to
generate
identity
claims
to
their
client.
I
don't.
G
With
us,
but
especially
because,
if
you
look
at
psyop
end
to
end,
it
can
actually
always
start
with
an
http
call
the
whole
psyop
discovery
and
the
big
debate
that's
happening
in
that
group
right
now
with
what
to
do
with
the
self
issue,
dot
me
urls
and
how
that
relates
to
the
issuer.
You
know
if
you
count
that
as
the
first
step,
we're
not
actually
doing
that
something.
That's
that
different
here.
It's
just
we're
facilitating
it
in
a
way,
that's
consistent
with
how
we
facilitate
other
types
of
of
protocol
interactions,.
G
Okay,
so
yeah
from
an
editor's
perspective.
I
don't
know
if
this
means
we
need
to
would
probably
means
we
need
to
change
a
lot
of
the
framing
language
in
the
in
the
spec.
I
think
a
lot
of
fabienne's
subject.
Identifier
discussion
is
going
to
push
things
in
a
similar
direction.
That's
this
is
the
reason
why
we
thought
that
these
were.
G
B
G
G
I
noticed
a
lot
of
frustration
and
trying
to
get
people
to
talk
about
the
same,
the
same
things
using
the
same
words
right,
which
is
always
hard,
and
so
in
any
event,
I
can
write
up
a
summary
of
the
position
that
I've
sort
of
put
today
and
drop
that
on
the
list.
If,
if
you
would
like
that
sounds
very
good,
all
right,
I'm
assuming
fabian
should
probably
do
the
same.
He's
actually
got
other
other
write-ups.
That
he's
already
started
for
that.
H
Yes,
of
course,
well
this
the
subject.
Identifier
discussion
is
so
there's
really
two
parts,
there's
a
part,
that's
quite
clear,
because
it's
basically
the
git
of
issues
and
we
just
need
to
take
that
down
and
the
resource
owner
versus,
subject
well
versus
end
user
is,
is
really
more
prospective.
So
it's
something
that
I
can
summarize,
but
it's
very
well.
It's
really
open
to
this
question.
It's
really
something
that
we
need
to
cover
in
the
next
next
weeks
and.
G
G
Okay
looks
like
roman
agrees
with
that
stuff
as
well
so
fabi,
and
I
will
will
each
do
that
with
these
two
main
topics,
and
hopefully
we
will
also,
you
know,
start
when
there's
bandwidth,
we'll
we'll
start
the
discussions
on
the
the
key
rotation
and
signing
bits
as
well.
Hopefully,
during
this
period
and
anything
else
that
comes
up
obviously
everything's,
always
on.
G
B
A
B
I
I
I
I
Now,
when
you
look
at
the
definition
of
the
resource
server,
I
have
problem
with
the
definition,
because
you
only
speak
on
protected
resources
and
speak
about
a
valid
access
token.
What
is
valid
access
token?
Is
it
a
gnab
token
or
token?
A
cookie's
token?
I
don't
know.
If
I
look
at
the
iso
definition,
there
is
no
concept
of
protected
resource,
it's
simply
an
access
to
an
object
which
is
controlled
by
the
resource
server.
So
I
would
propose
a
definition
that
is
slightly
different.
It's
a
server
that
provides
operations
to
objects
referenced
by
specific
client
requests.
I
I
I
If
you
have
discovery
mechanism
for
the
as
it
can
disclose,
which
token
format
it
supports
and
the
same
for
the
rs
now
in
terms
of
trash
relationship,
so
it
is
an
important
point.
The
rs
trust
a
set
of
authorization
servers
for
some
set
of
privileges
which
may
be
rights
and
or
attributes
that
are
contained
into
an
access
token
from
one
of
more
the
trusted
authorization
servers
with
such
relationship.
I
Don't
need
to
have
a
prior
relationship
between
every
as
and
rs
simply
the
rs
needs
to
to
tell
which
is
it
is
trusting.
So
this
is
very
important
because
it
allows
a
large
scalability
and
it
allows
also
in
probability,
however,
in
case
an
as
delivers
capabilities
on
some
object
on
behalf
of
a
resource
owner.
I
I
I
I
I
Now
let
us
focus
only
on
the
case
when
the
access
control
rules
are
capability,
based
in
that
case,
crs
must
cooperate
with
ro
able
to
deliver
capabilities
on
the
object
of
the
rs
under
his
control.
In
that
case,
the
arrow
may
be
either
a
process
or
a
human
being.
So
you
see
that
the
ro
in
one
case
may
be
process,
human
being,
in
other
case,
maybe
process
human
being
or
iot.
I
What
is
very
important
is
when
there
is
a
ro
associated
with
a
s
that
delivers
a
capability
on
a
resource
under
the
control
of
rs.
That
capability
is
analyzed
and
filtered
by
the
access
decision,
function
on
the
resource
server
side,
and
then
it
can
filter
which
method
delivered
by
a
given
authorization
service
can
be
accepted.
I
I
I
I
I
You
see
that
the
ro
is
an
access
decision
function
and
that
are
all
exist
in
both
cases,
whether
access
control
lists
or
capabilities
are
being
used,
and
it
fits
well
with
the
definitions
that
have
written
at
the
bottom
of
the
slide
fits
well
because
it's
a
subject,
it's
an
entity.
I
will
not
say,
subject
it's
an
entity
that
may
grant
or
deny
operation
on
resources
it
has
authority
upon.
I
I
My
belief
is
that
section
should
to
be
filled
before
doing
all
the
design
of
the
protocol,
because
privacy
after
design
is
usually
unable
to
address
privacy,
consideration
which
has
not
been
considered
before
the
design
of
the
protocol,
and
I
will
focus
on
two
important
privacy
considerations,
user
choice
and
consent
and
user
notice
next
slide
in
the
current
draft
user.
Consent
is
only
considered
to
take
place
at
a
single
authorization
service.
I
I
I
What
is
important
to
explore
the
consequences
when
you
look
at
the
privacy
property
and
one
security
property,
one
privacy
property,
for
example,
that
is
met
if
you
use
fido,
first
identity
online.
Its
resource
servers
should
not
be
able
to
link
their
user
accounts
by
using
the
content
of
the
access
token
they
receive
from
the
same
rs
or
from
different
rs
and
once
of
the
property.
I
Two
collaborating
clients
should
not
be
able
to
anonymously
use
access.
Token
of
the
other
client
on
the
same
rs,
for
example.
If
you
could
believe
that
you
have
an
access
token,
that
say
I
am
older
than
18
well,
there
should
be
some
way
to
be
able
to
detect
that
something
is
wrong
if
one
client
sends
a
token
to
the
other,
it
means
that
the
token
should
contain
something
else.
Next
slide.
I
If
you
include
a
globally
unique
identifier
into
an
access
token,
then
you
may
know
that
this
access
token
is
for
that
person
and
not
for
that
other
person.
So
if
you
think
you
have
the
capabilities
that
say,
you
are
over
18.
Well,
you
are
able
to
detect
that
estimate.
There
is
something
wrong
and
the
consequences
is
the
following:
if
an
access
token,
that
only
contains
where
or
no
capability
is
sent,
client
corporation
attack
will
succeed.