►
From YouTube: IETF-GNAP-20220120-1600
Description
GNAP meeting session at IETF
2022/01/20 1600
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
A
B
So
I
just
wanted
to
note
that
I
had
a
meeting
with
annabelle
last
friday
and
I
did
mention
to
her
the
the
second
event
subjects
draft,
so
I
I'm
also
trying
to
poke
her
to
get
that
over
the
over
the
finish
line.
I
know
she's
been
very
busy
with
real
day
job
stuff,
but
yeah,
so
hopefully
that
doesn't
take
too
much
to
get
it
over
the
line.
I've
been
keeping
an
eye
on
that
as
well.
B
A
C
B
B
B
2022-01,
I
forgot
to
change
the
title
slide.
I
got
the
date
on
the
bottom
right,
at
least
though,
so
this
is
the
right
presentation,
I'm
just
lazy
with
my
slide
deck.
So
today,
we've
got
four
main
topics
that
we're
going
to
be
going
through,
updates
to
the
drafts
talk
about
sort
of
what
our
current
process
is,
what
the
editors
have
been
doing
over
over
the
last
few
weeks
since
the
last
ietf
and
what
we're
what
we're
working
on
from
there.
B
B
B
It
wasn't
worth
publishing
a
new
draft
trying
to
get
a
new
draft
crammed
through
in
time
for
people
to
be
able
to
read
it
for
ahead
of
this
interim,
but
you
can
see
the
editor's
copy
up
on
github.
So
if
you
go
to
the
github
repository
for
the
core
draft
and
also
for
the
rs
draft,
you
can
click
through
to
have
a
live
rendered
version
of
whatever
is
on
the
current
main
branch
in
the
repository
so
yeah
what's
changed
here,
we've
got
a
bunch
of
new
security
considerations.
B
These
are
things
that
we
had
talked
about
during
the
last
meeting.
So
we've
got
stuff
like
the
the
cuckoo
token
attack,
which
is
a
really
interesting
sort
of
multi-layered
attack
where
you
can
convince
a
client
to
replay
a
token
under
some
really
replay
a
keybound
token
at
that,
under
some
really
sort
of
specific
circumstances,
also,
some
stuff
about
redirects
and
some
some
bits
about
server,
side,
request,
forgery
and
a
few
other
things
like
that.
B
All
of
those
security
considerations
have
gone
in
with
no
real
changes
to
the
actual
protocol.
So
these
aren't
necessarily
things
that
are
attacks
against
the
protocol
itself,
but
attacks
against
deployment
choices
that
the
protocol
does
allow,
and
a
lot
of
these
are
just
because
it's
going
on
the
web,
and
so
people
are
going
to
deploy
it.
B
B
We
think
that
there
there
should
be
plenty
of
stuff
in
there
by
then
and
more
on
that
when
I
talk
about
sort
of
what
we've
been
up
to,
but
in
the
meantime
please
go
check
out
the
editor's
copy
in
github
and
also
please
continue
to
follow
the
pull
requests
whenever
we
have
a
new
pull
request.
That's
not
just
a
simple
like
typo
fix
kind
of
thing.
B
We
do
try
to
let
the
list
know
and
let
people
go
poke
at
it
and
read
it
ahead
of
time
before
we
merge
it
all
right
yeah.
So
these
were
the
two
security
considerations
that
that
I
had
just
mentioned.
Those
are
in
there
there's
some
new
ones
that
are
pending,
merge
right
now,
they'll
probably
be
merged.
I
think
they're
actually
due
to
be
merged.
Today.
B
D
B
B
B
But
what
the
editors
realized
when
we
were
when
we
were
looking
at
this
and
looking
at
the
feedback,
the
what's
really
what's
really
going
on
in
the
protocol.
What
the
protocol
is
actually
allowing
is
that
you're
talking
about
two
very
different
kinds
of
things,
with
slightly
different
results,
so
the
first
of
that
is
token
rotation.
B
So,
if
you're
going
to
the
token
management
api
specifically
for
a
single
access
token,
the
whole
idea
of
this
is
to
say
I
want
a
brand
new
access
token,
with
all
of
the
same
rights.
Give
me
something
that
is
an
exact
copy
of
this
and
throw
away
the
old
one.
If
you
can.
The
caveat
here
is
that,
of
course,
if
you're,
using
a
structured,
stateless
access
token,
then
you're
probably
going
to
have
some
other
considerations
for
trying
to
revoke
this.
While
it's
in
flight,
there
are
methods
to
do
that.
B
All
of
that
is
outside
the
scope
of
ganap
core,
possibly
a
topic
for
knapp
rs,
but
that's
a
separate
discussion
later
on.
The
main
point
here,
though,
is
that
when
the
client
is
saying
rotate
a
token,
it's
saying
I
want
to
replace
this
token
that
I
am
sending
to
you
with
something
that
does
the
same
things
just
as
well.
B
A
grant
update,
however,
is
saying
that
I
want
to
get
a
brand
new
access
token,
possibly
with
new
characteristics.
I
might
be
requesting
something:
that's
downscoped,
I
might
be
something
requesting
something
with
more
access
rights.
I
might
be
trying
to
bind
it
to
a
different
key,
which
is
a
whole
branch.
B
But
ultimately,
what
you're
doing
here
is
saying
that,
in
the
context
of
this
existing
grant
that
you're
allowing
me
to
continually
update,
I
want
a
brand
new
access
token
that
does
the
kinds
of
things
that
I'm
asking
for
for
this
grant.
So
this
is
the
main
difference
between
these
two
functionalities.
There
is
still
a
lot
of
overlap
because
a
a
client
that's
dealing
with
an
expired
access,
token
could
choose
to
either
rotate
the
existing
expired
one
or
go
talk
to
the
grant
and
get
a
brand
new
one.
B
B
Is
not
this
didn't
end
up
having
any
real
protocol
changes,
just
our
description
of
what
the
intent
is
for
different
parts
of
the
protocol
that
were
already
there
and
hopefully,
as
we
continue
to
fry
refine
this
kind
of
text,
we
can
start
to
really
lock
this
down
and
make
it
a
very
deterministic
decision
of
I'm
here
in
the
system.
This
is
a
thing
that
I
need
to
do,
or
somebody
made
this
specific
request.
What
am
I
supposed
to
be
able
to
do
with
that?
B
A
Can
I
bulge
in
with
a
question
I'll,
do
it
at
the
end?
Yes,
yeah
go
ahead
so
on
token
rotation,
making
sure
that
the
semantics
is
actual
revocation
and
the
old
token
cannot
be
used
is
difficult
in
a
cluster.
We
all
know
that
it's
it's
a
typical
problem.
Now
the
the
normal
use
case
is
I'm
five
minutes
before
the
expiration.
A
Of
my
token,
I
know
that
I
will
go
and
and
get
a
new
one.
We
call
it
rotation,
but
I
really
don't.
Nobody
cares
if
the
old
token
is
still
useful
for
the
next
five
minutes,
that's
fine
and
then
there
are
very
special
cases
where
I
may
have
logged
out
changed
my
password,
whatever
it's
policy
dependent-
and
I
really
really
want
to
revoke
my
token
so
should
we
actually
have
two
separate
solutions
or
make
it
optional
or
actually
think
about
this
explicitly.
B
B
A
B
A
B
B
So
the
I
think,
what's
important
is
that
the
is
that
the
it
sets
the
expectation
for
what
this
action
means
and
the
as
is
going
to
try
and
you
know,
try
and
do
the
best
that
it
can
with
that.
So,
if
the
as
is
not
able
to
to
actually
revoke
the
token
itself,
for
you
know
whatever
deployment
reason
necessary,
then
the
then
the
client,
the
client
kind
of,
doesn't
care
because
it's
done
it's
its
job.
It's
not
expecting
to
be
able
to
use
that
access
token
again,
once
it's
been.
A
E
Yes,
I
believe
that
revocation
should
be
separated
from
token
rotation,
because
in
some
cases
it
will
be
supported.
In
some
cases
it
won't
be
supported,
and
if
you
do
that
separation,
then
token
rotation
is
a
creation
of
a
new
access.
Token
and
grant
update
is
a
creational
new
access
token,
so
the
two
functions
are
similar.
E
B
B
Okay,
I
think
we're
good
sorry
about
this
all
right
so
right
now
the
editors
are
working
through
the
existing
issue.
Backlog
we've
got
a
lot
of
stuff
that
kind
of
got
sifted
away
right
now
for
a
while,
because
of
some,
you
know
other
larger
discussions,
but
we've
actually
gone
through
all
of
the
issues
and
have
started
talking
about
kind
of
what
exactly
we
want
to
do
about
each
of
these
as
we
go.
B
It's
it's
slow,
tedious
progress,
because
we
want
to
make
sure
that
when
we
come
to
the
working
group
with
a
way
to
address
these
issues,
we
have
something
that
is
at
least
a
plausible
solution.
Even
if
that
solution
is
the
editors
think
that
this
idea,
you
know
shouldn't
be
implemented,
or
you
know,
and
so
we're
proposing
this
just
get
closed.
B
We
want
to
be
able
to
bring
that
back
to
the
working
group
with
our
justification
or
rationale
for
for
doing
that
in
order
to
make
sure
that
it's
it's
clear
kind
of
where
we're
coming
from
and
so
that
the
group
can
weigh
in
with
consensus
on
that.
We
also,
as
always,
welcome
people
to
jump
into
the
issue.
Tracker,
if
there
is
something
that
is
being
discussed,
that
you
think
needs
to
be
addressed,
then
do
so.
B
I
will
caveat,
say
please.
If,
if
a
decision
has
been
made,
please
do
not
open
duplicate
issues,
especially
just
because
the
group
did
not
decide
in
a
way
that
you
agree
with.
This
is
why
we
are
a
working
group,
not
everybody's,
going
to
get
their
way
so,
for
example,
the
just
as
a
concrete
example
of
that
the
token
rotation
thing.
B
So
I
I
realized
earlier
this
week
when
I
was
working
on
my
code,
my
my
own
implementation
of
canal,
that
I
had
actually
implemented
a
data
model
that
doesn't
quite
actually
fit
with
what
the
spec
is
now
saying,
but
I
will,
as
an
implementer,
bring
that
forward.
You
know
change
the
code
to
update
that
regardless
you
will
see
a
a
series
of
pull
requests
and
issue
actions
and
stuff,
as
the
editors
are
still
meeting
regularly
and
still
making
progress
on
the
core
draft.
B
I
know
aaron's
been
working
on
some
php
stuff.
There's
a
python,
client
and
laths
group
has
a
python
authorization
server
floating
around.
I
don't
know
if
that
code's
available
yet,
but
the
whole
idea
with
this
hackathon
with
knapp's
take
on
this
hackathon
is
that
you
know
this
is
a
multi-party
network
protocol.
B
B
On
top
of
that,
and
if
people
have
other
stuff
to
bring
in
that's
great
single
keybound
access
tokens.
So
we're
not
dealing
with
bearer
tokens.
We're
not
because
that
part's
easy
we're,
also
not
dealing
with
multiple
access
tokens
right
now,
because
that
part's
a
little
bit
harder.
Arbitrary
access
rights,
we're
not
looking
to
actually
go
into
and
filter
all
of
the
different
resource,
access
stuff
that
you'd
be
doing
in
a
real
system
and
we're
targeting
dynamic
clients
and
keys.
B
So
you
just
show
up
with
a
key
and
just
start
using
it
without
having
to
pre-register
things.
With
all
of
this
in
mind,
we
want
to
encourage
people
to
use
other
parameters.
Other
signature
methods
other
token
methods,
because
we
will
have
an
incomplete
matrix
of
a
feature
of
the
other
features
covered.
So
if
you
bring
your
code,
that
does
other
stuff,
in
addition
to
these
interoperability
sort
of
baseline
parameters,
that's
great,
and
the
other
reason
for
doing
this
is
that
this
is
hopefully
going.
B
A
B
There
is
a
hackathon
mailing
list
and
there
will
be
announcements
that
go
out
to
the
to
the
general
ietf
about
the
projects
in
the
hackathon
as
well,
but
I
will
start
an
implementations,
email
thread
and
people
can
chime
in
on
that
thread
or
just
write
to
the
list
on
your
own
another.
Another
side
effect
of
this
hackathon
is
that
we
will
have
a
a
listing
of
implementations
in
the
in
the
spec.
B
The
draft
spec
itself,
that's
a
section
that
we
have
yet
to
add
during
development,
and
the
editors
are
hoping
that
we
will
actually
be
able
to
have
both
the
mti
and
implementation
status
sections
as
a
fallout
from
these
activities
at
ietf113,
right
cool,
so
just
resetting
the
screen
here,
close
enough
so
going
forward.
These
are
not
things
that
we're
targeting
right
now,
but
these
are
something
that
we
think
will
really
really
help.
B
The
community
here
is
development
of
a
conformance
test
suite
there's
the
open
foundation
conformance
suite,
which
is
a
an
open
source
java
based
conforming
suite
that's
designed
to
test
protocols
like
gnat.
It
was
originally
designed
for
oauth
2
profiles
and
is
currently
being
used
for
a
lot
of
open
id
connect
related
stuff.
There's
a
lot
of
really
good
features
in
there.
B
So
it's
there's
a
lot
of
engineering
work
to
make
to
make
the
to
make
an
app
modules
for
that,
but
I
personally
think
that's
going
to
be
a
really
useful
thing
when
we
can
get
there.
We
also
would
love
to
see
support
and
extensions
for
open
api
and
async
api
and
these
other
api
dis,
formal
api
description,
language
systems
that
are
out
there,
so
that
people
that
are
developing
an
api
can
just
say.
B
So
almost
done
next
steps
within
the
group.
You
know
I'm
just
gonna
leave
this
here
there.
There
is
a
formal
security
analysis
in
progress
which
has
already
brought
to
light
a
few
security
considerations
and
some
really
really
interesting
attacks
that
that
the
group
didn't
see
on
its
own.
So
we
definitely
want
to
see
that
continue
and.
B
The
goal
is
to
actually
automate
that
analysis
and
testing,
as,
as
is
my
understanding,
we
need
to
continue
to
outreach
other
communities
we
have
dmitry
presenting
today
on
some
work,
that's
being
done
in
w3c.
That
may
or
may
not
have
overlap
with
with
this,
but
you
know
it'll
be
really
interesting
to
have
that
conversation,
and,
of
course
you
know,
in
addition
to
continued
work
on
the
core
draft,
we
do
need
to
get
back
to
the
resource
service
draft.
It
in
fact
did
just
expire.
B
That
doesn't
mean
that
we
forgot
about
it.
It
just
means
that
we've
been
we've
been
focused
on
the
core
draft
for
a
bit.
Now
there
are
a
lot
of
good
discussions
that
need
to
happen.
There
are
things
like
a
token
model.
Things
like
introduction
of
the
rs
to
the
as
in
a
dynamic
way,
things
like
if
you
have
an
rs
that
speaks
to
multiple
as's,
one
of
the
ramifications
for
that
for
trusting
tokens
and
for
dispatching
requests.
B
Things
like
if
an
rs
wants
to
introduce
new
resource
access
sets.
What
does
that
look
like
which
again
plays
into
the
token
model?
This
is
all
stuff
that
isn't
necessarily
exposed
to
the
client,
at
least
as
its
role
in
the
system,
but
it's
stuff-
that's
still
important
for
for
deployments
to
be
able
to
answer
and
do
so
in
an
interoperable
way,
and
there
will
of
course
be
a
lot
of
unique
security
and
privacy
considerations
in
the
rs
draft
as
well.
B
F
F
I
want
to
present
the
use
case,
which
I
think
could
be
useful
to
nap,
and
I
want
to
see
if
there's
any
alignment
there
if
we
can
meet
that
use
case
with
gnapp,
if
we
can
start
talking
about
inner
interoperability
between
app
and
vc
api.
So
how?
Let's
see
here's
here's
my
link
to
the
slides
externally
and
let's
see
how
do
I
ask
how
do
I
present
the
slides
like.
F
F
F
F
F
In
the
verifiable
credentials
world,
specifically
in
the
education
corner
of
our
fiber
credentials,
so
I'm
one
of
the
project
leads
for
an
open
source.
Digital
credential
wallets
for
universities,
that's
edgy
wallet
by
dcc,
so
one
thing
that
came
up
is
we
had
expiring
credentials
and
we
needed
to
refresh
them
this.
This
is
gonna
sound,
familiar
to
you
with
nap,
because
there's
the.
F
Refreshing
tokens
part
of
the
spec
and
we'll
talk
about
that
in
a
second,
so
that
was
that
was
issue
number
one.
We
needed
to
send
an
existing
token,
plus
some
prerequisites,
plus
some
additional
credentials
and
get
back
a
new
version
of
the
credential
for
expiration,
so
those
those
first
use
case.
Second,
one
was
we
needed
to
issue
a
credential
and
the
issuer
the
as
needed.
F
So
we
we
did
some
research
into
the
prior
art.
We
looked
at
oidc
for
verifiable
presentations.
We
looked
at
psyop,
we
looked
at
gnapp
as
well
as
diff's,
wacky,
presentation
exchange
and
did
come,
and
at
the
time
there
was
none
of
the
protocols
that
we
looked
at
had
the
notion
of
so
obviously
most
of
the
protocols,
including
knapp,
have
the
notion
of
requesting
access,
whether
it's
an
access
to
a
resource
or
requesting
the
issuing
of
a
credential.
F
There's
that
all
the
protocols
have
the
notion
of
a
request
response.
What
I
didn't
see
was
a
multi-step
request
and
then
the
issuer
or
the
authorization
server
says
in
order
for
me
to
fulfill
the
request.
I
need
the
following
prerequisites,
but
I
did,
I
did
see
in
the
gnap
spec
the
interact
and
the
continuation
properties,
the
notion
of
all
right,
so
I
I,
the
authorization
server
received
this
request
and
here's
what
you
need.
C
F
F
F
So
as
you're
probably
thinking
okay,
so
how?
How
can
we
handle
this
with
nap?
So
we
do
have
the
notion
of
we.
We
do
have
in
gnab,
spec,
the
refreshing,
expired
access,
token
or
rotating
the
access.
Token
and
justin
talked
a
bit
about
the
difference
between
issuing
a
new
one
or
refreshing,
an
old
one,
and
so
on
earlier
in
this
call.
So
we
have
this
access
token
manage
endpoint,
where
the
client
knows
how
to
get
a
new
one,
especially
essentially,
similarly
in
the
ver
in
w3c,
verifiable
credentials
land.
F
F
F
F
B
So,
first
thanks
dimitri.
This
was
this
was
a
really
great
write-up
and
this
actually
aligns
really
well
with
the
token
rotation
discussion
that
that
I
was
talking
about
before,
because
if
you
actually
go
back
yarn,
if
you
could
go
back,
I
think
it's
two
slides
when
we
start
talking
about
the
can.
We
add
prerequisites
yeah
right
there,
because
what
I
think
it
actually
fits
a
little
bit
better
to
given
our
sort
of
clarified
model
here.
The
clarified
semantics
is
actually
more
of
a
grant
update.
So
it's
like.
B
You
know,
because
that's
where
you
send
the,
if
you're
doing
a
redirect,
that's
where
you
send
the
interact
hash
if
you're
doing
something
like
in
early
early
early
versions,
we
had
a
stub
for
did.
Com
encoded
did
com
messages
like
that's
where
you
would
send
the
encoded
didcom
message
as
justin
encoded
json
parameter.
So
it's
it's
not
exactly
the
same
as
rotating
an
access
token,
it's
updating
the
grant
and
what
you're
being
issued
is
not
an
access
token,
but
you're
being
issued.
Something
else,
you're
being
issued.
B
Already
like
very
much
in
the
kidnap
world.
In
the
vc
world,
you
have
an
existing
api
that
is
looking
to
kind
of
bootstrap,
its
its
trust
and
its
access
rights,
or
at
least
that's
that's,
my
understanding
of
where,
where
the
bridge
needs
to
come
here,
because
in
the
vc
api
world,
if
I
make
that
request
to
the
issuer
and
the
issuer
issuer's
fine
with
everything,
it's
just
going
to
give
me
back
the
the
vc
and
I'm
not
going
to
have
to
do
anything
else,
I'm
not
going
to
have
to
consider
anything
else
right.
B
Is
that
is
there
a
way
and
does
it
make
sense
to
allow
a
an
api
like
the
vc
api
to
kind
of
almost
start
a
gnap
flow
in
the
middle
for
its
own
purposes,
and
at
that
point,
is
that
is
that
doing
gnap
or
is
it
doing
vc
api
security
model
that
looks
a
lot
looks
and
feels
a
lot
like
an
app,
and
I
I'm
not
sure
what
exactly
the
answer
is
for
that.
But
that's
that
that
potential
connection.
B
F
Thank
you
thanks
justin
yeah
great
questions.
I
do
really
think
that
gnapp
and
vc
api
can
be
very
complimentary.
So
for
one
vc
api
requires
access
tokens,
it
requires
authorization
for
their
issue
and
verified
calls
and
getting
that
authorization
getting
those
access.
Tokens
is
out
of
band
and
gnap
is
one
of
the
mechanisms
that
we
look
to
for
for
setting
up
that
initial
bootstrapping.
C
Hear
me
I
I
would
train,
I
would
try
to
frame
this
question
in
terms
of
delegation
if
at
all
possible,
because
that
is
the
intent
and
it
is
also
the
issue
from
a
human
rights
perspective
that
I've
tried
to
raise
in
some
of
the
w3c
context,
particularly
the
vc
api,
and
I
don't
know
if
that's
a
clarifying
thing
or
if
it's
a
confusing
thing.
But
if
we
introduced
because
you
have
an
authentication
component,
you
call
it
the
right.
You
have
an
authentication
component
to
the
flow
you
described.
C
A
B
I
just
wanted
to
respond
really
quick
to
dimitri's
question
about
whether
gnap
could
be
used
for
issuing
vcs.
One
of
the
things
that
has
been
talked
about
from
the
very
beginning
is
that
open
id
connect
taught
us
that
delegation
protocols,
like
oauth,
can
be
used
to
issue
things
in
addition
to
or
beside
access
tokens.
I
see
absolutely
no
reason
why
you
wouldn't,
potentially
in
cases
want
to
also
issue
vcs.
B
B
However,
you
want
like
that
that
type
of
flexibility
was
intentionally
built
into
knapp's
interact
model
like
there's
a
re
there's.
The
very,
very
good
reason
why
the
start
method
is
is
a
list
and
those
and
that
list
of
items
can
be
potentially
parameterized
like
we
want
people
to
be
able
to
say,
like
you
know,
you
could
go
to
a
web
page
or
you
could
send
me
this
message
or
you
can
just
prove
this
crypto
problem
or
whatever
other
types
of
things.
People
want
to
come
up
with.
B
That
is
a
really
important
extension
point.
So
to
me,
it
makes
a
lot
of
sense
for
that
to
be
able
to
go
back
and
forth.
I
don't
speak
for
the
group,
but
I
would
not
expect
this
group
to
do
the
definitions
of
how
vcs
fit
to
ganap.
That
seems
a
better
fit
for
the
vc
community,
because
the
heavier
lift
is
going
to
be
on
that
side
to
make
sure
that
the
vcs
all
of
the
normative
language
around
processing
and
issuing
the
vcs
is,
is
followed
appropriately.
B
But
that's
not
to
say
that
you
know
as
dimitri
and
I
both
know
there
are
and
adrian
as
well.
There
aren't
a
lot
of
people
that
are
in
both
of
these
communities
that
would
be
interested
in
in
seeing
how
those
fit
together,
but
can
app
as
it
stands.
Right
now
has
already
has
mechanisms
for
direct
issuance
of
what
we
call
subject:
information
which
per
our
charter,
we're
limiting
to
identifiers
and
assertions.