►
From YouTube: IETF114-GNAP-20220728-1400
Description
GNAP meeting session at IETF114
2022/07/28 1400
https://datatracker.ietf.org/meeting/114/proceedings/
A
B
B
D
D
D
B
C
E
B
Welcome
so
we
have,
we
have
basically
a
big
status,
update
and
walk
through
of
your
shoes
today,
so
we're
gonna
get
to
the
meet
here,
but
let's
just
sort
of
quickly
remind
everybody
about
the
note
well
and
about
the
itef
code
of
contact
which
we
actually
didn't
put
on
a
slide,
but
you've
seen
it
many
times
this
week.
So
you
know
you
know
what
it
is
and
also
it
does
involve
masking
up,
which
I
will
not
demonstrate
here.
We
go
so.
C
B
B
B
No,
nobody
feels.
Oh,
I
mean,
I
think
we
can
worst
case.
We
can
deal
with
that.
I
think
because
there
isn't
all
that
much
probably
to
to
a
minute
this
this
time
around.
So
so
we
have
the
editing
team.
Justin
is
remote.
He
he
did
say
that,
oh,
he
is
actually
here.
So
I'm
going
to
turn
it
over
to
justin
and
aaron.
I
think
aaron
is
going
to
be
the
one
standing
at
the
upfront
here
and
walking
us
through.
B
C
B
B
G
G
Yes,
it
works
the
rough
agenda
for
the
session
is
we
have
some
updates
to
share
about
the
various
the
two
documents
that
are
part
of
the
the
group
right
now
and
I'm
gonna
go
over
some
of
the
changes.
What
they
mean
share
kind
of
details
on
on.
What's
happened
with
that
and
then
also
talk
about
some
of
the
stuff
that
we
are
planning
in
the
future
and
I
think
we've
identified.
G
Issues
that
maybe
we
can
talk
about
here
as
well,
so
the
the
full
dip
links
are
on
the
slides,
they're
clickable,
if
you
are
on
the
pdf
from
the
meeting
materials
and
we're
going
to
go
over
the
the
changes
here.
So
there's
two
drafts:
there's
the
core
protocol
that
talks
about
client
authorization,
server,
communication
and
there's.
The
second
draft
is
the
resource
server
draft
that
talks
about
resource
servers,
validating
requests
coming
in
and
what
they
need
to
do
to
to
deal
with
that.
G
G
We've
been
working
on
github,
so
if
you
are,
if
you
want
to
see
the
details
of
all
of
the
changes,
they're
very,
very
meticulously
documented
on
github,
which
I
appreciate
and
you
can
go,
find
the
pull
requests
that
have
emerged
along
with
the
discussions
that
have
happened
there
and
we've
been
trying
to
do
a
good
job
of
making
sure
every
change
goes
into
a
pr
that
gets
tagged
and
tagged
properly.
And
now
you
can
see
them
all
by
clicking
these
links.
G
It's,
I
think,
that's
one
of
the
largest
numbers
we've
been
able
to
deal
with
between
meetings,
so
that's
great
a
lot
of
good
progress
there
and
then,
unfortunately,
none
of
the
issues
on
the
resources
were
draft
have
been
closed
from
the
changes.
So
it
was
just
other
things
that
were
that
were
changed,
so
the
changes
that
we've
grouped
them
into
editorial
versus
actual
functional
changes.
So
all
of
these
are
links
to
issues
on
github
again,
if
you're
curious
about
the
actual
text
behind
these.
G
Behind
these
changes
in
the
draft,
the
so
there's
text,
consistency
just
means
that
we
found
some
inconsistencies
with
the
text
in
the
spec
which
have
been
corrected,
so
they
are
now
better
describe
what
they're
talking
about
and
editorial
is
things
that
you
know
don't
have
any
functional
changes,
but
are
otherwise
maybe
more
significant
changes
and
that
release
number
10
is
just
the
mechanics
of
doing
the
release.
So
I
think
we're
going
to
go
into
some
of
these
in
detail
yeah.
G
We
now
have
fancy
diagrams
in
svg,
which
is
the
new
way
to
do
diagrams
in
these
rfc's.
We
have
the
ability
to
publish
svg
now,
one
of
the
cool
things
about
this
is
it's
actually
generated
from
the
ascii
art
source,
so
kind
of
cool,
which
also
means
it
has
a
nice
fallback
to
if
this
is
represented
in
ascii,
the
there's
been
some
changes
on
the
on
the
idea
of
future
proofing
for
new
jose
signature
methods,
and
that
was
again
we're
not
trying
to
like
lock
it
down
to
the
current
snapshot.
G
G
The
tldr,
I
guess,
is
that
there's
mitigations
for
many
of
the
security
issues
that
were
identified
have
been
mentioned
in
the
spec
already,
which
is
good,
but
there
will
need
to
be
more
analysis
done
if
an
app
is
ever
used
as
an
identity
protocol,
so
that
is
yeah
thanks
for
doing
that.
It's
a
lot
a
lot
of
reading,
I'm
sure
and
a
lot
of
writing.
G
G
There's
a
new
state
diagram
which
is
try
to
describe
how
how
we
expect
the
state
of
the
entire
system
to
change
over
time
who's.
Talking
to
what
there's
some
discussion
around
that
and
there's
now
actually
a
new
change
that
allows
interactions
to
time
out,
which
basically
means
that,
if
it's
explicitly
mentioned
that
we're
not
expecting
like
the
as
to
hold
on
to
things
forever.
G
So
again,
those
are
all
linked.
If
you
want
to
see
the
actual
details.
This
is
an
example,
one
of
the
syntax
changes
where
it
was
just
kind
of
a
over
from
some
previous
syntax
that
I
think
it
had
more
options
in
it
before
and
by
removing
some
of
these
options.
Now
the
syntax
is
kind
of
redundant,
so
it
just
uses
a
string
for
that
user
code.
A
Right
just
on
that
last
one,
I
want
to
note
that
that
that
syntax
change
is
there's
now
user
code,
url
and
user
code
as
two
separate
modes,
whereas
before
they
were,
they
were
one
thing
and
it
was
confusing,
because
sometimes
you
could
do
one
and
sometimes
the
other,
and
it
wasn't.
It
wasn't
clear
on
what
a
client
would
actually
need
to
expect
at
any
point.
G
Yeah-
and
I
think
that
is
a
theme
that
you'll
you'll
see
with
a
lot
of
these
changes-
is
that
it's
we're
trying
to
make
it
so
that
a
client
developer
doesn't
kind
of
knows
what
to
expect
by
the
data
that's
coming
back
and
they
don't
have
to
go
and
look
it
up
necessarily
because
it's
kind
of
just
obvious
what
it
does
so.
Hopefully,
this
helps
this
is
that
split
token
feature
that
sort
of
previously
existed
that
we
have
now
dropped.
G
The
idea
was
a
request
for
a
token
might
return,
actually
multiple
tokens,
which
the
idea
was,
if
you
have
multiple
apis,
multiple
resource
servers
and
you
wanted
them
to
be
able
to
not
have
to
validate
the
same
looking
token,
if
you
want
actually
different
tokens
targeted
different
resource
servers,
you
could
get
them
all
in
one
request,
it
sounds
like
a
cool
feature.
I
agree,
it's
a
cool
feature.
Apparently
nobody
was
interested
and
it
also
complicates
things
quite
a
bit.
So
if
there
isn't
demand
for
it,
it
makes
sense
to
drop
it.
G
F
G
G
You
used
to
have
just
this
string,
which
is
essentially
internal
internal
description
of
what
that
is
between
the
the
at
the
ais.
The
new
mode
actually
gives
it
the
ability
to
have
all
these
different
attributes
of
that
method,
because
the
because
http
signatures
can
use
different
algorithms
and
different
digest
different
signatures
and
different
digest.
Algorithms,
so
http
signatures
by
itself
is
not
enough
to
actually
describe
what
we
actually
mean
so
there's
now
an
expanded
version
of
this
that
describes
the
exact
bits
that
are
required.
G
This
one
is
a
fun
one
that
actually
I
need
to
go
file,
an
issue
on
one
of
the
oauth
specs
for
this
as
well.
The
the
hash
algorithm
names
there's
been
this
convention
of
using
abbreviations
for
them
or
shortened
versions
of
the
names,
and
there
is
an
actual
registry
that
describes
exactly
like
the
short
string
to
the
actual
method
and
a
lot
of
specs
haven't
been
using.
It
and
they've
just
been
sort
of
crossing
your
fingers
that
people
are
going
to
figure
it
out.
A
This
is
what
we've
come
up
with
for
the
state
diagram
from
the,
mostly
from
the
as's
perspective,
of
what
something
of
what
a
grant
request
can
go
through
during
its
life
cycle.
So
either
it's
it's
waiting
to
be
approved
or
it
has
been
approved
and
it
can
move
back
and
forth
between
those
states
until
eventually
it
gets
to
a
state
where
you,
you
can't
get
anything,
you
can't
get
anything
more
out
of
it
all
right.
A
I'm
gonna
go
through
each
of
these
states
and
talk
about
kind
of
what
they
mean
and
how
they
move
between
each
other,
and
this
is
a
new
section
that
is
in
the
that
is
in
the
draft,
and
I
just
I
do
want
to
take
a
a
a
quick
second
to
point
out
that
we
mentioned
fancy
diagrams
this
diagram.
This
actual
diagram
is
actually
in
the
draft
as
ascii
or
not
as
ascii
as
svg,
and
that
just
makes
me
very
happy
that
that
we
can
do
that
in
rfcs.
A
C
A
States,
so
this
means
that
the
as
is
trying
to
figure
out
what's
going
on,
it's
looking
at
the
context
of
the
request.
All
of
the
information
that's
come
from
the
client
instance,
any
information,
that's
come
from
the
end
user
and
the
resource
owners
and
anybody
else,
and
it's
trying
to
figure
out
what
do
I
need
to
do
next?
A
This
is
a
transitive
state
in
that
you
know,
you're
not
really
meant
to
stay
here
for
a
long
time,
but
while
you're
in
this
state
you're
not
issuing
any
tokens
you're,
not
you
know
issuing
any
user
information
you're
trying
to
figure
out
what
what
actually
needs
to
happen
and
if
you
need
more
information,
you
move
to
the
pending
state.
So
usually
that
means
you
need
interaction
for
the
end
user.
Sometimes
it
means
you
need
to
asynchronously
go
contact
a
resource
owner.
A
Sometimes
it
means
you
need
more
information
from
the
client
instance
and
but
in
all
of
those
cases,
you're
going
to
move
to
the
pending
state
if
you're,
all.
If
you
are
satisfied
as
the
as
with
everything
that
you've
been
rece,
that
you've
received
for
this
request,
so
you've
either
already
interacted
or
the
client
gave
you
enough
information
that
you
can
just
issue
things
right
away,
then
you
move
to
the
approved
state
and
then,
if
you
get
to
a
point
where
you
just
you
realize
that
you
can't
process
anymore.
A
So
there's
this
you've
exhausted
your
interaction
capabilities,
the
client
hasn't
given
you
new
information
or
you're,
just
in
sort
of
an
error
state
and
you
need
to
say
like
yeah.
This
is
this
is
done,
I'm
not
giving
you
anything
else.
You
move
to
the
finalized
state,
we're
going
to
step
through
those
now
next
slide.
Please
so
pending
means
that
the
as
needs
more
information,
it
has
gone
through
its
context
and
it
has
determined
that
it
needs
information
from
somewhere.
A
This
is
the
state
that
the
request
is
in
when
you're
waiting
for
the
user
to
go
log
into
the
site
and
interact
or
enter
the
user
code
or
get
redirected
or
use
the
app
or
whatever
other
mechanisms
that
you're
using
during
the
interaction
phase.
This
the
grant
is
basically
sitting
there
waiting
and
pending.
A
A
You
could
go
from
pending
to
processing,
to
figure
that
out
and
straight
back
into
pending
since
you're
waiting
for
more
people
to
kind
of
show
up
and
do
their
thing
that
may
or
may
not
be
actually
using
the
client.
Let's
see
here,
no
modifications
can
be
received
when
you're
in
this
state,
so
the
client
can't
send
any
updates
to
the
request.
It
can't
change
what
it's
asking
for
it
can't
you
know,
request
new
access
tokens
or
anything
like
that.
A
It's
just
you're
not
issuing
anything
when
you're
in
this
state
and
if,
during
this
state,
by
the
way
this
this
was.
This
is
a
bit
that
wasn't
wasn't
called
out
in
the
text.
Previously,
it
is
actually
possible
for
your
interaction
methods
to
time
out,
because
you
know
you're
not
gonna
have
a
re,
a
redirect
that
is
just
open
forever.
You're,
not
gonna
have
a
user
code
that
is
just
valid
until
the
end
of
time.
A
You're,
probably
gonna
throw
those
away
at
some
reasonable
timeout,
and
if
that
happens
and
you're
saying
that
like
no,
this
is
completely
cancelled
and
I'm
not
doing
anything
like
that.
You
can
drop
straight
into
the
finalized
state,
which
is,
which
is
the
which
is
a
terminal
state.
Next
slide.
Please.
D
A
A
Okay,
so
the
approved
state
is
when
the
as
is
decided
that
it
has
everything
that
it
needs
and
it
can
issue
some
access
tokens
or
some
subject:
information
directly
back
to
the
client
instance,
when
the
in
this
state,
the
client
can
continue
the
it
can
request
new
access
tokens
based
on
the
current
state
of
the
grant.
So
anything
that's
already
been
approved.
The
client
can
ask
for
additional
access
tokens
to
be
issued
during
this
state.
Again,
if
the
as
approves
that
this
is
this,
is
where
that
piece
happens.
A
The
client
can
also
modify
the
request
so
either
step
up
or
step
down,
or
you
know
a
subset
of
access
or
something
like
that.
It
can
send
a
modification
request
to
the
as
at
which
point
it
moves
back
to
processing,
because
now
the
as
has
to
figure
out.
What
do
I
do
with
this
new
context
of
information?
A
Do
I
need
more
information,
so
I
go
back
into
the
pending
state
or
are
they
asking
for
a
subset
of
everything,
so
I
can
just
give
them
the
new
token
or
give
them
the
new
claim
set
and
just
go
on
with
our
day
right
from
here
and
if
the
as
revokes
the
request-
or
you
know
it
times
out
or
whatever
the
as
decides,
this
can
also
move
directly
into
the
finalized
state
from
here
next
slide.
Please
and
finally,
no
pun
intended
the
finalized
state
is
a
terminal
state.
A
This
means
that
the
grant
is
done
and
nothing
more
can
happen.
So
when
you're
in
this
state,
you
are
not
issuing
any
new
tokens
anytime,
you
get
a
modification
or
a
continuation
request.
That
is
an
error
and
calling
out
this
as
a
sort
of
a
separate
terminal
state,
we
believe,
is
actually
going
to
be
really
helpful
for
developers.
Realizing
that,
like
these
aren't
things
that
necessarily
have
to
stick
around
that
you
know
you
have
to
keep
around
forever.
A
Once
you
decide
as
the
as
once
you
decide
that
no
more
continuations
can
actually
happen.
Nothing
more
can
be
gotten
out
of
this
grant
request.
Then
you
just
you
finalize
it
and
you're
you're
on
your
way
in
oauth.
This
is
equivalent
roughly
equivalent
to
the
refresh
token
being
no
good
anymore,
because
you're
no
longer
able
to
sort
of
make
modifications
in
the
context
of
that
original
request.
A
A
G
G
You
know
accepted
the
list
of
issues
here
that
are
spelled
out
are
actually
ones
that
at
some
point
in
the
past,
we've
actually
put
into
the
draft
itself
as
references
out
to
make
sure
that
we
don't
forget
to
do
them.
There's
a
whole
section
that
we
want
to
do
on
key
rotation
for
tokens
so
that
clients
can
actually
not
just
have
to
use
the
same
key
over
and
over
again
there's
client
management
and
then
there's
a
bunch
of
work
to
do
in
the
resource
server
draft,
mainly
the
idea
of
token
models.
G
G
Yeah,
I'm
really
excited
about
the
message
signatures
draft.
I
think
it
opens
up
a
lot
of
really
cool
possibilities
and
it
is
one
of
the
options
available
for
signing
things
in
gnab.
So
that's
how
that's
why
it's
related
the
signatures
draft
itself
doesn't
say
anything
about
gnapp,
obviously
or
any
other
higher
level
protocol.
It
is
just
about
http
message
signing
so
yeah.
That's
super
cool,
very
excited
to
see
that
progressing.
G
A
G
A
You
know
some
concrete
ideas
on
how
we
could
actually
do
this,
and
so
these
slides
represent
sort
of
our
early
thinking
of
what
this
would
actually
look
like
in
the
context
of
ganap,
with
the
with
the
way
that
the
protocol
is
structured
and
especially
with
the
clarity
that
that
came
from
doing
all
of
the
state
diagram
the
state
machine
stuff.
This
this
last
major
revision.
A
A
A
Now
initially,
our
naive
thought
was
that
oh,
we
should
be
able
to
do
this
in
kind
of
a
universal
way
across
all
of
the
different
key
proofing
types,
at
least
all
of
the
ones
that
we've
thought
of,
and
we
realized
kind
of
how
dumb
an
idea.
That
is
because
they
all
present
keys
very
very
differently
and
who
knows
what
else
people
are
going
to
come
up
with
for
signing
methods
and
key
binding
mechanisms,
and
I
mean
we
could
see
the
revival
of
token
binding
in
this
space
like
who
knows
like
we.
A
We
can't
predict
that,
so
our
proposal
is
to
actually
allow
different
kinds
of
key
presentation
for
each
different
proofing
type
in
order
to
sort
of
fulfill
a
basic
pattern
to
show
that
you
possess
both
keys
and
can
rotate
it.
And
then-
and
this
would
be-
you
know-
part
of
an
explicit
part
of
the
protocol.
That
says
I
am
rotating
this
key,
and
so
look
for
these
this
this
bit
of
information.
A
A
You
know:
that's
that's
sort
of
a
syntax
and
bike,
shutting
discussion
that
we've
we've
got
to
figure
out
and
we've
got
to
discuss
as
a
working
group,
because
you
want
to
be
able
to
say,
like
hey,
I
am
signaling
that
I'm
doing
a
new
key
here
and
here's
the
information
and
make
sure
that
that's
all
tied
together
and
all
of
that
other
stuff.
This
would
be
a
field
inside
of
the
token
rotation
and
the
token
management
calls
by
the
way,
since
we're
talking
about
changing
keys
for
specific
tokens.
A
A
So
you
sign
the
outer
message
with
the
new
key
and
you
sign
the
new
key
with
the
old
key
that
proves
that
you
actually
have
both
or
held
both
at
one
point,
this
probably
assumes
a
jose
flavored
key
format
can
app
technically
doesn't
make
a
strong
connection
between
the
key
format
and
the
signing
method.
So
you
can
do
hdb
signatures
with
certificates
or
jose
with
certificates
or
signatures
with
jocks.
It
can
app
itself,
doesn't
actually
care,
but
this
rotation
method
kind
of
presumes
a
key
format.
A
A
Mtls
is
definitely
an
interesting
beast,
though,
because
you
can
obviously
really
only
get
away
with
presenting
one
client
certificate
at
a
time,
at
least
as
far
as
I'm
aware,
yarn
might
be
giving
me
a
side
eye
at
this
point
he's
off
camera.
I
can't
tell,
but
the
thing
is
with
most
mtls
deployments,
you're
actually
already
relying
on
external
certificate
management
systems
or
in
pki
or
there's
some
other
certificate
negotiation
thing.
So
rotation
is
mostly
out
of
scope
for
an
mtls
type
thing.
A
That
said,
acme
is
doing
some
interesting
work
with
client
certificate
attestation.
Extensions
kathleen
moriarty,
pointed
us
to
this
proposed
work
in
acme,
so
that's
something
we
might
be
able
to
follow
up
with
the
acme
working
group.
If
there's
something
that
they're
working
on
that,
we
can
leverage
to
say
hey
if
you
need
to
do
programmatic
rotation
with
mtls
go.
Do
this
acme
thing,
and
this
is
how
you
present
it
as
part
of
the
protocol
next
slide,
please.
A
This
raises
some
interesting
questions
specifically.
If
I
have
a
a
token,
that's
bound
to
say
the
detached
jose
method.
Could
I
change
that
to
use
http
signatures
with
a
different
key
this?
This
means
that
it's
that
I'd
be
able
to
change
out,
not
only
the
key
but
how
it's
getting
presented
when
we
were
looking
at
sort
of
the
grand
unified
key
rotation
idea,
which
I
mentioned
we
had
we
we
have
since
walked
away
from
that.
A
But
the
thing
is:
if
we
allow
this
it,
what
does
that
combination
actually
look
like
what
would
the
syntax
look
like
to
change
from
jose
to
huv6,
like?
Are
you
using
http
sig
to
sign
a
header
of
the
jose
object
or
because
it's
in
the
body,
the
jose
object,
is
fine,
and
how
do
you
do
it
in
the
other
direction?
A
Do
you
apply
a
signature
and
then
put
that
into
the
payload
of
a
jose
object?
It
gets.
It
gets
weird
really
really
fast,
and
it
also
opens
the
question
of
somebody
invents
a
new
proofing
method,
which
we
expect
that
to
happen.
You
know
what
does
that
actually
look
like
what
does
that
grid?
Look
like
as
that
m
by
m
grid
of
of
transformations
happens.
What
does
that
look
like
so
the
proposal
is
we
actually
just
keep
this
fixed
so
that
we
can
kind
of
avoid?
A
A
So
this
does
bring
up
a
related
question.
That's
been
brought
up
a
few
times
as
a
use
case
for
kidnap
what,
if
you
want
to
use
a
different
key
for
the
access
token
than
you
when
talking
to
the
rs,
then
what
you
use
when
talking
to
the
as
this
is
something
that
it
seems.
A
lot
of
people
want
to
be
able
to
do
at
least
at
least
in
theory,
but
it
when
you're
separating
these.
It
does
raise
some
tough
questions
of
you
know.
A
You
know
in
this
circumstance,
so
we
this
this
does
need
to
be
nailed
down
and
it
feels
like
it's
going
to
be
very
related
to
the
whole
key
rotation
thing,
because
you're
presenting
multiple
keys
at
the
same
time
and
figuring
out
what
to
do
with
with
each
of
them.
So
this
is
a
separate
issue
from
key
rotation,
but
we
think
it's
all
kind
of
going
to
be
tied
together.
Speaking
of
next
slide,
client
instance
management.
F
A
We've
got
all
of
the
places
that
we
need
to
hang
it.
We
need
to
decide
whether
this
is
something
that
goes
in
the
core,
whether
it's
an
extension
and
whether
this
is
something
that
people
actually
want
to
use
next
slide,
please
all
right!
This
is
fabienne's
part.
So
before
we
move
on
any
questions
on
the
keys,
the
clients,
any
of
those
bits.
C
B
F
C
A
F
B
F
F
But
typically
today
we
would
have
a
registry
that
would
contain
some
some
things
like
judge
sign
just
encrypted,
so
that's
fairly
obvious
and
then
open
the
the
possibility
to
other
types
of
formats
like
macaroons
and
biscuits
or
z-caps,
which
actually
providing
different
types
of
of
features
and
we'll
see
that
in
a
minute
next
slide.
Please.
F
So,
just
to
give
you
an
idea
that
many
other
types
of
token
formats
exist
you've
got
a
link
to
your
podcast
on
the
blog
which
was
done
by
fly.io.
So
it's
not
mine,
it's
just
something
as
a
reference
to
give
you
some
ideas
on
other
types
of
of
of
token
formats,
so
obviously
you
you
get
dirt
inside
them.
F
You've
got
pasito,
which
is
well
some
people
like
it,
some
some
don't
and
so
on
and
you've
got
macaroon
and
biscuits
which
are
described
also
in
in
that
document
and,
of
course
it
gets
into
more
detail.
But
the
idea
is
where
you're
very
used
to
using
jot
it's
obviously
everywhere,
but
in
some
cases
it's
maybe
not
the
the
best
format.
In
some
cases
you
need
those
of
things
and
it's
not.
F
What
we'd
like
to
do
is
to
actually
open
the
possibility
for
evolution
even
in
the
jose
world,
but
then,
of
course,
we
need
to
check
what's
inside
each
type
of
format
and
that's
one
or
so
of
the
reasons
for
discussing
token
models
instead
of
token
formats.
It's
also
to
be
able
to
guide
in
terms
of
information,
that's
inserted
into
into
our
token,
but
not
mandate.
Some
specific
implementations
next
slide,
please.
F
So
what's
the
difference
between
a
format
and
a
model
as
we
as
as
we
understand
it,
the
token
format
is
well
in
our
case,
it's
typically
a
jot,
but
other
formats
exist,
as
we've
seen,
and
the
reasons
why
we
want
to
accommodate
various
formats.
So
the
first
one,
obviously
is
the
productivity
and
I've
put
at
the
end
on
appendix
for
jose
examples.
For
instance,
new
work
items
like
json
proofs
and
well
a
lot.
E
F
But
we
see
that
this
need
for
more
going
on
in
the
space
and
then
we've
got
different
use
cases
so
jot
is
adding
proofs,
probably
and
and
then
you've
got
macaron
and
biscuits
which
have
a
different
way
of
working.
So
it's
abstractive
instead
of
additive
and
for
instance,
you
can
implement
things
which
are
not
available
in
jots
like
attenuation
capabilities.
F
So
an
example
is
maybe
an
I'm
an
administrator
from
for
a
building.
I
actually
give
some
biscuits
or
my
carrots
to
my
employees
and
then
they
can
actually
attenuate
the
token
to
just
limit
it
to
some
part
of
the
building
that
could
be
accessed
by
someone
that's
external,
to
the
building,
that's
external
to
the
company.
That's.
F
D
F
So
in
some
cases
it
can
be
useful
in
some
cases
it's
not.
Obviously
it
just
remains
the
main
useful
token.
Obviously,
but
it
makes
sense
in
some
cases
to
not
mandate
data
specific
format,
so
a
token
model
instead
is
really
information,
that's
typically
shared
by
implementations,
whatever
they
are,
and
so
we
that's
really
the
focus
here
next
slide,
please.
F
So
where
should
we
describe
the
model?
The
first
possibility
in
the
course
pack,
so
in
the
course
pack,
you've
got
the
link
here
to
appendix
c,
which
is
on
the
component
data
orders
and
for
instance,
it's
just
a
note
right
now,
it's
not
written
in
in
the
following
way,
but
for
instance,
we
we
refer
to
to
be
done
for
the
to
be
described.
For
the
token,
so
the
token
has
a
resource
owner.
It
has.
D
F
F
The
second
possibility,
especially
since
the
issue
is,
is
actually
on
the
rs
draft
itself-
is
that
the
errors
draft
might
be
a
better
place
order.
It's
it's
very
open
here.
It's
it's
not
completely
clear,
but
it
could
be
described
here
for
the
model
as
part
of
the
context
of
the
arrest
draft
and
it
it
might
be
a
good
way
to
actually
have
a
link
and
and
the
description
between
the
model
and
the
supported
format.
Since
we,
since
in
the
errors
draft,
we
already
described
the
the
support,
the
ones
which
are
supported.
F
F
F
So,
what's
an
access,
token
value,
that's
important
to
have
in
mind:
that's
really
what
we,
what
we
use
in
the
in
the
course
spec
and
as
a
reminder,
the
access
token
is
really
your
pack
to
the
client,
so
it
the
client
doesn't
need
to
know.
What's
inside
the
token
itself,
you
just
need
to
actually
be
able
to
receive.
C
F
And
then
send
it
to
the
resource
server
and
in
the
course
pack,
so
you've
got
section
3.2.1
on
the
access
token,
where
you
do
find
a
description
on.
What's
value,
that's
required
at
that
point
and
in
the
es
response
we
also
have
a
lot
of
information.
That's
that's
important.
We
have
metadata
on
what
the
value
means.
So
we've
got
a
label.
We've
got
associated
rights,
which
is
actually
an
array.
F
F
Introspection,
so
that's
actually
provided
in
the
rs
draft
in
section
3.3
and
as
a
reminder,
so
that's
already
in
in
the
course
pack
a
token
maybe
appear
or
it
could
be
keybound
and
the
key
the
default
is,
is
that
it
is
keybond
and
and
then
in
the
errors
draft.
You
do
find
some
information
on
how
to
do
token
introspection.
F
F
C
F
F
From
victorio
actually
on
the
jet
profile
for
all
access
tokens,
where
you
do
find
a
header
with
the
type
parameter
that's
available
in
there
and
then
you've
got
claims
an
interesting
note
here,
I'm
not
entirely
sure
it's
it's
a
good
idea,
but
anyway
it's
just
a
personal
opinion.
Here.
You've
got
some
new
inf
values
for
growers,
groups,
entitlements,
etc.
F
E
F
Actually,
the
three
that
are
available
and
then
you've
got
the
best
current
practice
and
there's
a
section
in
there,
which
is
quite
interesting
for
us,
which
is
quote
jot,
confusion
and
the
types
of
mitigations
which
are
available,
especially
if
you
had
a
token
which
was
generated
in
some
context
like
o2.
And
then.
What
would
you
do
if
it
was
actually
sent
over
a.
B
F
To
the
service
so
next
slide,
please
and
now
you
do
find
the
mitigations
which
are
actually
provided
in
the
previous
document.
So
you've
got
four
methods,
and
that
shows
you
some
important
attributes.
So,
of
course,
the
issuer,
the
subject,
that's
something
you
need
to
validate
same
for
the
audience
and
then
there's
some
recommendation
here
on
christina's
lane.
F
F
Well,
which
makes
claims
on
jersey,
method
and
so
on,
but
I
don't
want
to
get
into
that.
It's
just
to
make
sure
that
other
types
of
format
would
be
would
be
possible
in
theory,
at
least
so
they
are
actually
providing
a
they
don't
provide
a
type.
They
do
provide
a
version
which
is
fairly
equivalent
to
having
four
new
jazz
algorithms
in
some
way.
So
there's
a
v3
and
a
v4
and
you've
got
a
local
and
a
public
type
of
algorithm.
F
Which,
supposedly
is
is
a
solution
for
the
alec
methods,
but
actually
you
still
need
to
trust
the
message
to
know
which
arg
is
used,
so
it
doesn't
really
solve
the
main
issue,
since
you
can
still
change
the
algorithm
and
you've
got
the
purpose
which
is
similar
to
the
audience.
So
an
idea
of
audience
makes
sense.
Obviously,
then
you've
got
the
payload
and
then
you've
got
the
footer
and
the
footer,
interestingly,
is,
is
mainly
used
for
key
rotation
in
that
case,
so
it
gets
sets
back
to
the
previous
discussion
on
key
rotation.
F
F
So
here
you've
got
only
one
cryptographic
method
and
you've
got
a
data
log
engine.
So
it's
actually
a
bit
more
advanced
in
terms
of
how
you
actually
process
claims.
It's
not
just
a
schema
it.
It's
actually
got
a
an
engine.
That's
that's
underlying
so
you've
got
blocks,
you've
got
base
types
like
you
can
have
dates
and
and
and
a
lot
of
different
information
there,
and
that.
F
F
Gti
is
also
something
interesting,
not
sure
we
we
we
should
if
we
want
something,
that's
completely
generic
gti
in
some
implementation.
It's
it's
really
linked
to
json.
In
some
cases.
It's
it's
not
the
way
you
want
to
implement
that
from
the
previous
examples,
but
anyway,
that's
the
kind
of
thing
you
would
find
client
is
is
fairly
obvious.
It's
just
a
name
change
between
client
id
and
client.
So
it's
it's
very
trivial
access.
F
Obviously
you
can
embed
that
within
your
payload
part,
but
it's
kind
of
redundant
because
you've
got
that
into
the
answer
from
the
from
the
api
in
in
the
response
part.
So
it
could
be
optional.
You
could
well
first,
it
could
be
something
we
don't
include
or
we
don't
mandate
to
include
it
will
be
optional
or
it
could
be
something
that
we
just
passed
by
reference
as
well.
Just
like
we
do
for
kid,
for
instance,
and
then
we've
got
some
other
questions
like
sub
in
our
in
our
documents.
F
So
is
it
something
we
want
to
to
unfair,
or
do
we
want
to
make
sure
that
we
can
actually
actually
type
the
sub
identifier?
Can
we,
for
instance,
find
there
something
that's
a
phone
number
or
something
else,
or
did
maybe
and
then
we've
got
flags
and
keybounds.
So
we've
we've
discussed
about
kids,
but
that's
the
kind
of
things
do
we
want
to?
F
F
H
E
F
F
E
F
So
it
was
ready
to
give
you
a
broad
summary
of
of
the
of
issue
15,
which
will
be,
I
think,
quite
important,
because
having
a
format
is.
This
is
quite
critical
in
a
slide,
and
I
think
we
we
get
to
the
end
and
that's
the
next
steps.
So
here
it
was
just
a
discussion
because
it's
it's
something
which
will
be
important,
especially
for
implementers.
F
C
F
A
A
B
So
we
did
go
through
what
we
had
scheduled
but-
and
you
know
obviously,
if
there's
anybody
who
wants
to
raise
any
issues
or
talk
about
anything
in
the
presentation
or
that
wasn't
covered
by
the
presentation.
Now
is
the
time
to
step
up
to
the
mic.
While
we
have
you
up
there,
if
you
would
like,
could
you
have
some
some
idea
of
the
timeline
ahead?
I
mean
what
are
we
talking
about
in
terms
of
iterations
before
we're
getting
close
to
our
our
goal?
End
goal
here.
A
I
want
to
say
you
know
six
to
nine
months
or
so
is
that
we've
been
it's
been
a
lot
of
removing
sort
of
the
more
esoteric
features,
like
you
know,
split
token,
and
the
capabilities
array
and
stuff
like
that
stuff.
That
seemed
like
it
would
have
been
a
good
idea,
but
nobody
was
building,
and
so
we've
been
pulling
that
stuff
back
and
so
a
lot
of
what's
been
going
in,
has
been
either
clean
up
of
that
or
a
lot
of
editorial
discussion
within
the
document
itself.
A
A
So
I
would
expect,
probably
by
the
next
ietf
meeting,
we'll,
have
a
draft
that
is
fairly
feature
complete
and
then
from
there
it's
going
to
be
the
work
to
make
sure
that
you
know
the
instructions
for
extensions
are
all
in
place.
All
of
the
ayana
registration
stuff
is
all
in
place,
which
does
does
take
time
and
text,
but
is
less
less
about
changes
in
the
protocol
itself.
D
C
I
Yeah,
so
I
I
guess
to
kind
of
yeah
mike
perek
here
good
to
see
justin
in
this
context,
as
opposed
to
over
in
other
working
groups.
So
you
know,
I
guess
kind
of
two
questions
I
mean
what
is
the
end
goal?
I
know
the
question
was
asked
around
that,
but
is
that?
Are
we
going
after
independent
implementations?
I
B
Well,
I
mean
we
are
obviously
looking
for
us
we're
looking
to
produce
a
couple
of
staff.
At
least
a
couple
of
standards
track
receipts
right
that
is
kind
of
technical
output
to
this
right,
implementation,
wise.
That
is
typically
a
thing.
You
kind
of
incorporate
into
the
idea
process
process
software
like
this
rotation.
B
B
I
G
Come
back
to
this
microphone,
I
am
not
aware
of,
I
know
otto's
keeping
track
of
of,
like
you
know,
keeping
track
of
the
work
going
on,
but
I'm
not
aware
of
any
current
plans
to
go
and
immediately
build
it.
That
said,
I'm
also
not
the
one
that
is
on
the
actual
product
or
map
side
of
things,
so
I
don't
actually
have
that
much
insight
into
it.
So
I'm
mostly
participating
this
as
an
individual
here.
A
Right
so
I
can
say
from
my
experience,
I
know
of
a
couple
of
implementations
that
are
out
there
in
the
wild,
but
they
are
in
kind
of
siloed
spaces,
so
this
is
part
of
a
vast's
verified
dot
me
platform,
but
they're
using
it
within
verified
document.
It's
it's
not
they're,
not
using
it
sort
of
to
connect
across
to
other
implementations,
and
things
like
that
at
this
time
I
know
of
a
couple
of
companies
over
in
sort
of
the
fintech.
F
A
B
G
B
A
Yeah
definitely
for
especially
for
a
protocol
like
gnapp,
where,
like,
if
you
bolt
on
enough
extras,
you
can
do
most
of
what's
in
knapp
with
oauth
2.
it
doesn't.
It
stops
looking
like
oauth
2
after
a
fairly
short
while,
but
you
know
this
is
why
we've
put
the
effort
into
backboarding.
Rich
authorization
requests,
and
you
know
the
whole
pushed
authorization
request.
Concept
is
the
same
as
knapp's.
You
know
intent.
A
Protocol,
so
we
are
definitely
seeing
the
patterns
and
the
at
least
the
people
that
I'm
talking
to
that
have
decided
to
go
with.
Ganap
have
tried
to
it's.
It's
generally
been
they've
tried
to
go,
do
that
stuff
with
olaf
and
then
become
frustrated
with
the
sort
of
the
the
cross
product
of
extensions
and
found
knapp
as
something
that
was
designed
for
that
cross
product
from
from
the
start,
which
was
one
of
our
goals
going
into
this?
Is
you
know,
as
as
a
design?
H
H
We
could
shorten
the
the
with
a
little
bit
more
investment.
Perhaps
we
could
shorten
the
adoption
curve
by
making
sure
that
we
have.
We
have
some
at
least
reference
implementation
and
some
identification
of
interop
and
then
based
on
what
we
were
talking
about
kind
of
here
in
the
line.
I'm
really
excited
to
hear
that
folks
have
adopted
kind
of
the
patterns
and
they
have
some
of
that
early
experience
of
what
worked
and
didn't
work
trying
different
technologies.
I
would
love
to
see
that
brought
here
and
brought
here
kind
of
as
a
presentation.
H
H
Yeah,
I
I
guess-
and
that's
wonderful
and
perhaps
my
finesse
would
be-
let's
bring
that
that
that
I
guess
experience
of
the
hackathon
formally
into
for
lack
of
a
better
term,
the
working
group
proceedings
to
make
sure
that
kind
of
everyone
kind
of
benefits.
From
that
experience,
you
again
great
that
the
running
code
is
happening.
We're
learning
from
that-
let's
just
let's
actually
just
do
a
presentation
or
kind
of
wrap
it
up.
B
A
A
Where
and
how
could
we
scrape
up
the
the
time
and
funding
and
engineering
expertise
needed
to
take
that
platform
and
write
a
bunch
of
gnat
based
tests
for
it,
so
that
people
could
throw
their
implementations
against
that?
I
would
love
to
see
that
I
personally
don't
have
the
bandwidth
to
do
it
on
my
own,
but
I
think
that
that's
that's
something
that
the
community
would
absolutely
benefit
from
and
I'd
love
to
see
us
try.
B
B
E
E
E
E
There
has
to
be
at
least
an
explanation,
and
maybe
that
explanation
could
be
that
we
recommend
using
biscuits
or
macaroons
as
the
authorization
token
formats,
as
was
mentioned
earlier,
in
order
for
there
to
be
an
agent
of
the
user.
That
can
then
process
requests,
or
it
could
be
that
there
are
other
mitigations
to
this
issue
that
we
want
to
discuss
formally
in
the
in
the
document.
Thank
you
that's
my
comment.
G
G
C
B
Actually
do
want
to
control
who
they
trust,
but
doesn't
mean
that
a
human
rights
consideration
section
that
calls
this
out.
It's
not
a
good
idea,
because
the
way
I
know
that
especially
privacy
advocates
work
today
is
that
they
work
through
consumer
organizations,
and
you
know
what
will
happen
if
we
have
that
kind
of
text
that
somebody
might.
B
A
F
A
To
accept
external
information-
that's
not
just
this
user
is
logging
in
and
clicking
the
ok
button.
So
that
is
a
much
more
sort
of
system
level
approach
to
addressing
the
sort
of
the
expansibility
of
the
privacy
and
and
policy
considerations
here
beyond.
Just
you
know
forcing
every
every
rs
to
accept
an
arbitrary,
as
as
its
as
its
connection,
because
I
agree
with
erin
that
previous
systems
have
tried
to
do
that.
Uma
tried
to
do
that.
That
was
the
part
of
the
uma
that
nobody
deployed
all
right.
B
B
I
think
it
would
be
great
if
you
would
have
time
to
put
together
some
text
a
few
lines
for,
for
you
know,
for
the
even
either
privacy
or
even
even
call
it
also
human
human
rights
consideration
section
or
something
like
that,
but
that
that's
a
detail,
but
you
know
that
having
some
sort
of
text
I
think,
would
be
appreciated.
But
I
I
assume
would
be
appreciated
by
the
authors
as
a
contribution.