►
From YouTube: IETF112-GNAP-20211111-1200
Description
GNAP meeting session at IETF112
2021/11/11 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
A
A
A
A
A
And
in
fact
this
is
the
point
where
traditionally,
we
stop
and
wait
for
a
volunteer
to
take
minutes.
We
cannot
move
forward
without
minutes
and
if
you
want
to
take
minutes,
it's
much
easier
for
everybody.
If
you
take
it
on
hedge
dock,
which
is
what
replaces
etherpad
so
a
collaborative
meeting
note
taker
volunteers,
please.
A
C
C
D
E
E
E
E
E
Are
the
core
protocol
08
and
resource
servers
one
today
we're
going
to
go
over
all
of
the
changes
that
have
happened
since
ietf
111
in
the
core
draft?
That's
two
full
revisions.
We're
going
to
talk
through
about
the
editorial
and
functional
changes.
Excuse
me
in
that
draft
the
rs
draft.
We
actually
have
not
published
a
new
revision
since
111.
E
There
have
been
a
a
handful
of
small
changes
and
some
you
know
some
small
issues
that
have
been
addressed,
but
the
editors
looked
at
the
diff
and
it
wasn't
worth
publishing
a
full
revision
because
there's
not
a
lot
to
talk
about.
There
hasn't
been
a
lot
of
focus
on
the
rs
draft,
yet
more
on
that
when
we
get
to
the
to
the
roadmap.
At
the
end,
we
are
going
to
take
some
time
talking
about
some
formal
security
analysis.
E
E
All
right,
if
you
download
the
the
deck.
These
are
our
clickable
links.
You
can
look
at
the
diffs
between
six
and
eight.
As
I
said
before,
the
resource
server
draft
is
is
the
same
version.
You'll
see
that
most
of
the
differences
are
in
new
sections
that
have
been
added
for
for
trust,
security
and
privacy.
Consideration
sections
there's
other
stuff
peppered
through,
but
that's
the
majority
of
the
text
changes
that
you'll
see
there.
E
You
know
there's
this
specific
issue
that
needs
a
discussion
section
and
so
that
either
went
into
privacy
or
security
considerations.
There
were
a
bunch
that
were
about
the
trust
model
between
different
parties.
Now
that
all
that's
been
added,
we've
been
able
to
close
a
lot
of
those
issues
and
five
issues
closed
on
the
resource
service
draft
as
well
like.
E
I
said,
though
no
new
publication,
but
you
can
see
the
editor's
draft
on
the
resource
server
from
the
github
page,
if
you're
interested
in
seeing
any
of
that
all
right
on
to
the
issues
onto
the
pull
requests
themselves.
So
these
are
all
pull
request.
Numbers,
as
you
can
see.
Most
of
the
most
of
those
pull
requests
are
what
we
would
consider
really
editorial
changes.
E
A
lot
of
them
came
from
folks
in
the
community.
Andreas
and
florian
specifically
have
contributed
a
lot
of
little
changes
where
the
text
was
not
internally
consistent.
Some
things
were
was
referred
to
as
a
flag
in
one
place
and
a
value
in
another
place,
or
there
were
leftovers
in
the
descriptive
text
from
when
the
normative
text
changed
or
leftovers
in
examples
from
when
the
normative
text
changed.
E
So
lots
of
cleanup
there's
probably
still
a
bit
more
to
go,
but
thank
you
so
much
for
for
those
contributions.
They
are
immensely
helpful
for
making
sure
that
the
protocol
actually
makes
sense
and
it
speaks
to
people
really
reading
through
this
document
with
you
know
an
eye
for
fine
details,
which
is
a
really
really
important
thing
for
this
stage
of
the
document.
E
A
handful
of
other
things
were
truly
editorial
stuff.
Either
you
know
typos
or
misspellings
or
formatting,
changes
and
stuff,
like
that
we've
started
to
use
this
configuration
called
editor
config
to
to
hopefully
minimize
the
amount
of
sort
of
spurious
changes
from
from
the
different
editors
and
community
contributors
for
things
like
white
space
changes
and
the
the
one
that's
always
getting,
especially
fabian,
and
I
is
the
extraneous
white
space
at
the
end
of
at
the
end
of
lines.
E
Our
editors
treat
those
differently
our
editing
software
treats
those
differently,
so
we
were
running
into
that
a
lot
until
aaron
added
the
editor
config
controls
there
and
that
will
hopefully
clean
that
up
a
lot
we've
also
added
a
few
contributors
like
I
mentioned
people
that
have
been
putting
in
this
work.
We
are
very
grateful.
E
You
are,
you
know,
definitely
contributing
to
the
specification,
and
I
I
really
want
to
say
that,
even
though
these,
like
all
of
these
pull
requests,
aren't,
like
you
know,
deep
technical
protocol
edits
and
things
like
that.
These
are
all
really
really
important.
You
know
for
the
for
the
text
to
actually
read
consistently
and
read
well
to
somebody
that's
sitting
down
and
using
this.
So,
thank
you
very
much
for
that
and,
finally,
the
release
and
cleanup
commit
for
draft
o8.
E
E
These
are
largely
continuations
as
you'll
see
sort
of
building
on
previous
work
and
making
things
making
the
protocol
itself
more
internally,
consistent
and
making
use
of,
and
taking
advantage
of
aspects
of
the
protocol
that
we
have
now
that
we
didn't
have
in
the
past,
to
you
know,
make
things
make
make
more
sense
to
somebody
hopefully
make
more
sense
to
somebody
sitting
down
and
implementing
it
fabian.
You
want
to
go
ahead
and
talk
about
trust
relationships.
E
E
F
So
it's
a
new
section
section
1.4
and
what
we've
been
adding
is
basically
the
details
on
on
what
each
party
is
actually
doing
and
expecting
from
others
so
detailing
for
each
pair
of
of
relationships
like
end
user
resource
owner
and
user
client
and
user
authorization,
server,
et
cetera,
et
cetera.
So
compared
to
the
last
interim
discussion
that
we
had
for
those
of
you
that
were
present,
we
actually
added
the
end
user
authorization
server,
a
relationship
in
in
the
last
draft
or
eighth.
F
The
general
idea
is,
we
are
actually
using
promise
theory.
So
it's
actually
an
alternative
thresh
model
to
produce
iso
descriptions
which
is
actually
taking
the
description
a
bit
further
in
the
sense
that
you're
actually
describing
what
each
agent
is
promising
to
others
and
you're
building
the
trust
relationship.
Based
on
that.
F
So
that's,
basically
the
part
that
you've
got
here,
so
trust
is
defined
as
an
agent's
expectation
that
the
promise
will
be
kept.
Of
course,
there
can
be
a
lot
of
promises
in
our
protocol,
and
so
what
you
can
do
is
you
can
actually
execute
each
promise
as
as
a
base
in
probability.
So
it's
not.
The
trust
itself
is
not
a
zero
or
or
one
it's
something
that
you're
going
to
build
up
and
that's
actually
more
more
looking
into
reality,
not
in
that
area,
because
it's
not
something.
That's.
F
When
you
look
at
the
entirety
of
the
protocol,
some
parts
may
present
some
vulnerabilities,
especially
if
you
didn't
implement
security
considerations
in
full,
and
so
you
can
actually
have
something
that
you're
going
to
be
able
to
assess
marginally,
and
what
we
want
to
do
is
to
build
a
formal
security
verification
based
on
that
and,
for
instance,
we've
got
some
participation,
that's
planned
for
the
oauth
security
conference
in
at
the
end
of
november,
and
so
you
can
read
through
that.
The
entire
description
is
available
in
in
the
give-up
repository.
E
All
right,
thank
you,
and
the
the
one
last
bit
that
I
I
want
to
point
out
that
fabian
touched
on
is
that
one
of
the
best
things
about
this
theory
is
that
it's
always
about
these
relationships
between
the
different
parties.
It's
not
just
about
the
parties
and
a
lot
of
the
the
early
discussions
about
use.
Cases
in
the
protocol
were
really
about
getting
into
what
those
relationships
are,
how
they're
formed
how
they're
modified
over
time
that
kind
of
stuff.
F
Yeah
something
also
interesting.
Is
we
really
tried
very
hard
not
to
repeat
ourselves
between
what
trust
this
is
about
and
what
security
and
privacy
configurations
are
about.
So
when
we
need
that
into
a
trust
relationship
here
we
actually
describe
what
we
link
to
to
the
parts
which
are
relevant
in
in
the
rest
of
the
documentation
in
the
specification.
E
All
right
so
the
next
come
on.
There
we
go.
The
next
big
section
is
the
security
considerations
which
now
now
counts
to
25
subsections
and,
as
you
would
expect
in
a
protocol
like
this,
that's
security
focused
there's
a
lot
of
different
stuff
to
cover
here
and
I'm
not
going
to
go
into
detail
of
every
single
bit
in
that
section
here
on
today's
call,
but
we
do
ask
the
editors
to
ask
people
to
read
through
this
section,
because
there
probably
needs
to
be
more
subsections.
E
There
probably
needs
to
be
more
aspects
that
need
to
be
covered
about
all
of
these
different
things,
and
the
editors
do
know
that
the
organization
of
that
section
isn't
isn't
the
best
right
now,
I'm
taking
full
blame
for
that.
It's
just
kind
of
a
one
top
level
bucket
at
the
moment
we
are.
We
are
working
on
kind
of
organizing
these
into
into
categories,
and
things
like
that.
E
You
have
to
protect
your
keys
if
you're
sharing
the
keys
that
you're
signing
things
with
with
other
parties,
those
parties
can
sign
for
you
and
you
probably
don't
want
that,
and
and
also
if
you're,
using
bearer
tokens.
There
are
no
signatures
with
it.
So
anybody
who
sees
the
token
is
allowed
to
use
the
token,
regardless
of
the
contents
of
the
token.
So
this
is
the
kind
of
stuff
that
is
obvious
to
a
lot
of
practitioners
in
our
space,
but
still
absolutely
needs
to
be
enumerated.
E
So,
for
example,
if
you're
using
a
bad
pseudo-random
number
generation
in
order
to
generate
some
of
these,
you
know
ephemeral
handles,
like
the
say,
you're
using
a
handle-based
access
token.
You
know
a
reference-based
access
token,
so
no
internal
content
or
structure
somebody
could
try
to
either
guess
or
exhaust
your
access
token
space
if
you're
not
using
a
good,
even
random,
number
generator.
E
We
also
have
a
couple
of
sections
that
point
out
the
ways
that
front
channel
redirects
are
kind
of
inherently
susceptible
to
attacks
like
phishing
attacks
like
session
capture
and
how
aspects
of
gnapp
can
combat
that
when
used
properly
but
still
there
is
this
notion
of
you
are
giving
away
control
of
the
system
to
an
untrusted
party
for
a
bit
and
then
waiting
to
come
back.
So
there's
there
is
inherent
risk
in
that
that
you
need
to
understand
before
you
just
go
start
applying
this.
E
If
you
guys
will
remember
earlier,
in
the
year,
we
had
some
researchers
point
out
a
a
an
authorization
server
mix-up
attack
against
canap
and
the
mitigation
for
that
is
the
interaction
hash
in
the
front
channel,
and
so
we've
got
text.
Now
that
describes
why
it's
important
to
check
that
hash
and
all
of
the
signatures
on
all
of
the
various
messages.
E
Along
with
the
keys
like,
I
said,
exactly,
these
need
to
be
binned
and
I'm
like
editing
the
bins
in
my
head
as
I'm
going
through.
Even
this
list,
the
pre-registering,
your
keys,
solves
some
problems
but
creates
other
problems.
So
just
because
you
know
a
key
ahead
of
time,
especially
client
instances
key
ahead
of
time
doesn't
mean
that
you
can
necessarily
always
trust
it
to
not
have
been
exfiltrated
and
copied
and
charity.
It
just
moves
the
the
focus
of
that
trust,
which
is
something
that's
part
of
the.
E
E
There
have
been
attacks
against
xml
dc
against
saml
against
jose,
and
if
you
are
working
with
those
assertions
that
use
those
technologies,
then
you
are
susceptible
to
those
attacks
as
well.
So
somebody
could
do
a
you
know,
an
ex
an
xml
fork
bomb
attack
against
you,
if
they're
just
trying
to
get
you
to
parse
a
saml
assertion
and
you're
doing
it
naively.
E
So
there's
there's
other
details.
There's
there's
other
security
considerations
in
there
the
editors
ask
that
everybody
please
go
read
through
those
read
through
them
thoroughly.
We
have
tried
to
add
forward-facing
links
to
the
rest
of
the
document
where
appropriate,
so
so,
where
we
have
a
normative
discussion
about
something
it'll
say
see:
section
12.6
for
discussion
of
different
attacks
or
you
know
or
whatever.
If
there
are
other
places
that
we
can
add
those
links.
E
E
Oh,
we
don't
have
a
slide.
Thank
you
yarn.
So
the
oauth
security
workshop
is
an
online
event.
That's
happening
in
a
couple
of
weeks.
I
shut
down
my
calendar,
so
it
wouldn't
pop
up,
but
if
somebody
has
the
date,
this
is
a
free
online
event.
I
will
be
presenting
sort
of
the
the
core
structure
of
gnapp
as
a
protocol
fabian's
going
to
be
presenting
formal
security
analysis.
E
You
know
a
lot
of
the
trust
and
security
modeling
of
knapp.
There
there's
also
going
to
be
a
lot
of
discussion
on
oauth
and
open
id
connect
and
related
protocols.
So
it
is
a
free
event.
It's
happening
in
a
couple
of
weeks.
You
know
if
you
can
make
it
please
do.
This
is
a
place
where
a
lot
of
very
in-depth
sort
of
gloves
off
discussion
happens
in
terms
of
like
well.
You
know,
if
you
do
things
this
way,
then
it's
going
to
fall
apart.
So
how
do
we?
E
How
do
we
make
sure
this
bit
doesn't
doesn't
actually
fall
apart?
An
app
is
in
a
really
good
position
to
be
kind
of
part
of
this
community.
Now
this
is
the
first
time
that
can
apple
is
that
can
app
is
formally
part
of
the
oauth
security
workshop
agenda
and
so
we're
in
a
really
good
position
for
this
now,
because,
while
the
core
protocol
is
fairly
stable,
we're
not
yet
final,
so
we
can
still
tweak
things.
We
can
still
fix
things.
E
E
E
We
were
we,
we
are
lucky
in
the
itf
to
have
rfc
6973
that
actually
lays
out
topics
and
sort
of
major
categories
to
analyze
specification
and
just
like
the
security
considerations.
These
are
all
things
that
you
need
to
be
aware
of
that.
This
is
something
that
could
happen.
Sometimes
it's
it
turns
out.
This
is
actually
something
that
you
want.
Sometimes
it's
something
that
you
might
not
have
realized
could
happen.
E
So
we
laid
out
that
type
of
information,
the
the
data
that
you're
storing.
You
know
the
shared
references
because
of
all
the
identity
stuff
that
that
can
be
added
into
gnapp
the
references
to
to
user
information.
So
an
opaque
identifier
from
an
as
if
that's
reused,
across
multiple
systems
and
that's
actually
disclosing
more
information
than
then
you
might
expect
it
to.
You
might
not
expect
two
different
resource
servers
or
two
different
domains
to
know
that
you're,
the
same
user.
E
One
of
the
ones
that
that
shows
up-
and
this
is
this-
is
also
going
to
be
part
of
the
security
considerations-
that
if
a
client
uses
the
same
key
to
talk
to
the
authorization
server
and
every
resource
server,
then
all
of
those
resource
servers.
Even
if
they
don't
know
any
information
about
about
the
user.
They're
just
they're
just
serving
some
non-user
related
stuff.
Those
resource
servers
would
be
able
to
correlate
hey,
I'm
seeing
the
same
key
used
for
signature
that
you're
seeing
so
this
is
probably
the
same
person.
E
This
is
this
is
the
same
piece
of
software,
and
that
might
not
be
something
that
that
the
client
actually
wants.
The
client
might
actually
want
to
hide
that
from
those
different
systems,
gnapp
allows
that
hiding,
but
a
developer
might
not
realize
that
when
they're
sitting
down
and
they
might
take
the
easy
path
of
just
using
the
same
key
everywhere,
the
same
identifier
everywhere,
all
the
same
sort
of
other
information
across
all
of
these
different
systems.
E
And
so
that's
why
it's
important
to
really
call
all
of
these
out
for
implementers
to
be
able
to
make
those
decisions
as
they
go
forward
all
right.
So
that's
it
for
the
major
sort
of
trust,
security
and
privacy
considerations
sections
I.
I
will
pause
before
we
get
into
the
more
detailed
stuff.
If
anybody
has
questions
about
these
major
sections
because,
as
I
said
before,
these
are
these
are
the
major
new
sections
to
to
the
document.
A
All
right,
or
maybe
I
will
ask
so
just
to
get
everybody
on
the
same
page.
We
obviously
have
two
protocols.
You
talked
about
security
and
privacy,
consideration
two
drafts.
We,
you
talked
about
security
and
privacy
considerations
in
one
of
the
drafts,
the
core
protocol.
Can
you
speak
to
how
it
relates
to
the
other
one.
E
E
That
might
be
something
you
actually
want
your
authorization
server
to
know
in
order
to
protect
the
users
and
protect
the
environment.
That
is
its
job,
but
it
might
also
be
something
that
you
want
to
mask
in
some
fashion
and
or
or
avoid
entirely
by
not
using
token
introspection
by
using
a
structure
token.
Instead,
there
are
also
going
there
are
also
security
considerations
for,
if
you're,
using
a
structure
token,
what
goes
in
a
structure
token
versus
what
you
don't
return.
E
E
Fantastic
all
right,
so
symmetric
cryptography.
We
had
we
had
a
lot
of
discussion
back
and
forth
in
github
and
a
bit
on
the
list
about
this
and
what
it
boils
down
to
the
way
that
we
have
it
right
now
is
that
it
is
allowed,
but
it
is
restricted.
A
lot
of
the
reason
that
it's
allowed
is
that
the
underlying
crypto
methods
allow
for
symmetric
cryptography.
E
So
it's
a
little.
It
would
be
awkward
at
best
and
silly
at
worst,
for
gnap
to
to
attempt
to
disallow
something
like
that.
What
we
do
disallow,
though,
is
using
gnat
for
symmetric
key
distribution,
so
knapp's
mechanisms
for
introducing
keys
by
value
are
only
allowed
to
be
used
for
for
public
private
key
crypto.
E
You
can
do
things
like
use
a
key
escrowing
service
to
actually
do
all
of
the
crypto
for
you,
so
that
your
code
never
actually
sees
the
key,
and
you
are
locked
out
to
only
do
verification,
for
example,
and
you
never
actually
see
the
key
for
that,
and
what
we
wanted
to
make
sure
was
that
there
are
ways
for
people
to
do
this
to
not
do
it
naively
and
not
approach
this
in
a
way
that
that
leads
people
to
believe.
Oh
symmetric
is
easier.
E
Therefore
I'll
just
do
that
everywhere,
and
we
wanted
to
get
away
from
defaulting
to
shared
secrets
in
the
way
that
oauth2
does
now
oauth2
defaults,
not
only
to
shared
secrets
but
shared
bearer
secrets,
which
is
even
worse,
but
so
we're
at
least
we're
at
least
away
from
that.
However,
there
are
some
big
drawbacks
to
using
symmetric
crypto,
but
there
are
enough
compelling
use
cases
where
it
would
be
useful
to
do
that.
E
The
editors
are
very
interested
to
see
how
something
like
hpke
hk,
the
hybrid
key
thing
from
cfc
cfrg,
wow
alphabet
soup.
Sorry,
the
the
hybrid
key
hybrid
public,
key
encryption
hpke
there,
it
is-
could
be
used
as
a
key
derivation
mechanism
inside
of
knapp
and
how
that
could
be
potentially
signaled
on
top
of
the
existing
crypto
methods,
because
that's
really
a
key
agreement
method.
E
Thank
you
all
right.
The
next
thing
that
we
changed
is
we
used
to
have
this
thing
called
a
user
handle,
and
the
idea
with
this
is
that
this
was
a
special
piece
of
information
that
the
client
instance
had
that
it
could
send
to
the
as
to
say,
hey.
As
far
as
I
know,
this
is
the
same
user
that
has
been
here
in
the
past.
E
What
we
have
now
is
a
way
to
exchange
opaque
identifiers
using
the
the
subject,
identifier,
format
from
the
security
events
working
group,
these
opaque
identifiers
we
realized
a
bit
ago-
give
us
all
of
the
power
of
this,
of
this
special
user
handle
construct
that
we
had
had
previously,
but
without
inventing
something
new.
So
what
we
ended
up
doing
was
we
took
out
that
part
of
the
protocol
but
didn't
actually
lose
any
of
the
functionality
of
being
of
allowing
the
client
to
say
hey.
E
As
far
as
I
know,
it's
the
same
user,
because
now
the
client
can
be
told
this
user
has
this
identifier
according
to
me,
the
as
and
the
client
can
just
echo
back
hi
as
as
far
as
I
know,
it's
the
same
person
now
the
as
can
take
that
and
as
with
anything
in
the
in
the
user
section
of
the
of
the
request.
It
can
either
trust
that
the
client
is
probably
telling
the
truth
there
and
the
client's
probably
correct,
or
it
can
say.
E
I
don't
believe
you
and
I
need
to
talk
to
the
user
myself
and
that's
where
the
whole
interaction
thing
falls
through.
And
but
this
is.
This
is
just
one
of
the
ways
that
we've
been
able
to
kind
of
shrink
the
protocol
a
bit
without
shrinking
what
it's
capable
of
doing.
We've
been
able,
if
you,
if
you've,
been
watching
the
changes
of
the
protocol
over
the
last
six
to
nine
months,
or
so
you
you've,
probably
seen.
We've
been
doing
a
lot
of
that.
E
Part
of
that
is
that
we
now
removed
there
was
this
whole
handle
discussion,
because
the
original
id
that
I
had
called
xyz
had
all
sorts
of
different
handles
for
all
sorts
of
different
things,
so
this
user
handle
is
now
this
opaque
identifier
about
about
the
subject,
the
subject
identifier,
the
resource
handle
that
now
is
information
that
comes
from
the
resource
server
and
that's
something
that's
covered
by
the
resource
server
draft.
Now.
The
last
thing
that
we
have
is
also
no
longer
called
handle.
E
It's
the
client
instance
identifier,
and
so
we're
actually
wondering.
Could
we
even
simplify
that
we
have
an
open
issue
for
trying
to
figure
out
dynamic,
client
registration
management
over
time
and
that
kind
of
stuff?
This
is
really
where
this
type
of
instance,
identifier,
really
comes
to
play.
As
a
reminder,
this
is
an
identifier
that
the
client
can
use
in
lieu
of
presenting
its
key
by
value
and
all
of
its
sort
of
display
information
by
value
that
the
as
can
dereference.
E
However,
it
likes
to
figure
out
that
this
is
the
piece
of
software
or
the
instance
of
software.
That's
calling
me
right
now,
so
we
have
a
way
for
that
to
be
provisioned
dynamically
sort
of
built
into
gnab,
but
could
that
actually
be
leveraged?
To
do
things
like
allow
the
client
to
update
itself
over
time,
allow
the
client
to
rotate
its
keys
over
time,
we'll
get
to
that
in
just
a
moment.
So
we
think
that
there's
there's
more,
that
we
can
do
with
this.
E
I
think
it's
not
personal,
I'm
honestly,
just
really
bad
with
names
and
colleagues
were
we're
doing
analysis
of
of
gnapp
in
light
of
a
lot
of
analysis,
taking
basically
applying
a
lot
of
analysis.
That's
been
done
to
oauth
and
related
protocols,
and
so
with
this
they
have
figured
out
that
there
are
some
ways
to
exploit
knapp
that
are
that
do
carry
over
from
oauth.
E
This
shouldn't
be
particularly
surprising,
there's
a
lot
of
there's
a
lot
of
similarities,
and
so
now
it's
our
job
as
a
working
group
to
figure
out
what
our
mitigations
for
these
are
going
to
be,
and
before
I
go
into
this,
I
want
to
remind
everybody
that
the
mitigation
could
can
be
a
change
in
the
protocol.
It
can
be
a
behavior
recommendation.
You
know,
don't
do
this
bad
thing
that
leads
to
this
bad
situation,
or
it
could
just
be
a
heads
up
if
you're
going
to
use
this
option.
E
The
preconditions
for
this
attack
are
that
the
client
instance
is
talking
to
is
able
to
talk
to
two
authorization
servers
which
in
geneapp
is
not
crazy,
given
sort
of
the
dynamic
first
nature
of
the
protocol,
but
the
client
has
decided
to
use
the
same
keys
when
talking
to
both
authorization
servers
again.
This
is
a
pretty
reasonable,
naive
implementation
of
a
client
instance.
You
generate
one
key
and
just
use
that
everywhere.
E
E
We
saw
this
in
various
flavors
of
mix-up
attack
in
against
openid
connect,
where
somebody
points
to
the
token
endpoint
of
the
attacker
server
and
the
user
info
endpoint
of
of
the
legitimate
server,
for
example-
and
the
interesting
thing
here
is
that
this
attack
actually
works
for
keybound
access
tokens.
It
doesn't
assume
bearer
tokens.
E
What
happens
is
that
the
attacker
manages
to
get
a
hold
of
a
keybound
access
token,
but
not
the
keys.
For
that
token,
and
then
they
replay
that
token
to
the
client
to
the
same
client
from
their
own
authorization
server
in
order
to
in
order
to
trick
the
client
into
using
that
token,
with
the
key
at
the
honest
authors
at
the
honest
resource
server
for
the
attacker
right,
this
makes
a
little
bit
more
sense
in
a
diagram.
E
The
access
token
here
probably
represents
an
end
user.
That
is
not
the
attacker,
but
the
attacker
has
control
over
the
client
instance
in
this
case.
So
this
client
instance
is
probably
something
that
talks
to
multiple
users
as
well,
something
like
a
web
server
or
something
like
that,
where
it's
using
the
same
key
to
talk
to
multiple
asses,
so
the
attacker
goes
and
pokes.
The
client
instance
and
says:
go
talk
to
my
compromised
as
and
the
client
instance
does
so,
and
it
makes
it
makes
its
request.
E
And
then
the
attacker's
ask
says:
hey
use
this
access
token,
with
your
key.
The
trick
is
that
that
access
token
is
the
token
that
the
attacker
stole
from
somebody
else's
account.
Now
the
attacker
can't
use
it
on
their
own.
They
don't
have
the
keys
to
just
start
using
it,
so
they
need
to
trick
the
client
instance
to
use
it
for
them.
E
So
now
that
now
the
attacker
has
a
client
instance
in
it.
That's
in
a
state
where
it's
got
the
stolen
access,
token
that
it's
going
to
use
with
its
own
keys,
and
then
it's
going
to
use
that
at
the
resource
server
to
get
stuff
representing
whatever
that
access
token
was
good
for
that
the
attacker
doesn't
actually
have
access
to
now.
Remember
the
attacker
controls
the
this
as
in
the
red
over
on
the
right.
So
you
know
they're
not
getting.
E
You
know,
they're
they're
not
really
being
prompted
for
approval
and
all
of
this
other
stuff,
it's
it's
their
server
and
it's
spitting
out
the
stolen
access
token.
That
then,
is
getting
used
on
the
resource,
which
is
then
releasing
that,
in
the
context
of
of
the
client
instance
that
the
attacker
controls
right.
So
this
is
a
problem.
The
editors
have
looked
through
this
and
talked
talked
with
us
a
bit
about
this
with
the
researchers,
and
these
are
the
proposed
mitigations.
E
We're
not
now
to
be
clear.
We're
not
saying
do
all
of
these,
but
these
are
possible
things
that
we
can
do
now.
The
client
could
send
an
identifier
to
the
resource
server.
That
says.
Not
only
is
this
the
token
this
is
the
authorization
server
that
I
got
it
from.
This
is
the
mitigation
that
is
proposed
in
the
paper
on
oauth.
E
This
is
a
protocol
change
for
token
presentation.
The
client
does
have
to
track
and
send
more
data
each
time,
and
the
rs
now
actually
has
to
check
these
for
consistency.
So
it
needs
to
know
that
this
is
a
token
and
that
this
came
from
a
specific
authorization
server
and
things
like
that.
That
might
not
always
be
tenable
for
a
given
resource
server,
depending
on
you
know,
network
latencies
and
and
topologies
and
other
things
like
that.
E
The
biggest
downside
to
this
mitigation
is
that
it
is
protocol
change
and
more
moving
parts
that
would
need
to
be
tracked.
The
next
mitigation
would
be
to
tell
the
client
to
use
different
keys
with
every
authorization
server.
This
might
honestly
just
boil
down
to.
This
is
actually
a
best
security
best
practice.
E
This
breaks
this
attack,
because
when
the
client
calls
the
attacker's
ass,
it
uses
a
different
key,
and
so
when
the
resource
server
sees
that
access
token,
it's
going
to
be
checking
it
against
the
key
that
it
was
issued
against
from
the
good
authorization
server
which
the
client
won't
be
using
it'll,
be
using
a
different
key
to
sign
that,
and
so
the
resource
server
will
just
naturally
reject
this.
This
is
something
that
is
mostly
security.
Consideration
could
even
be
normative
text.
E
E
A
E
Thank
you,
and,
and
just
just
as
a
side
note,
just
as
we
did
with
the
the
mix-up
attack
that
was
previously
discussed
here
in
the
working
group
once
this
is
a
you
know.
Once
this
is
a
published
paper,
we
will
gladly
add
it
as
a
an
informative
reference
in
the
document
and
link
to
it
from
the
security
consideration
sections
all
right.
E
Next
up
is
just
an
http,
weirdness
mechanical
attack,
it's
it's
known
against
oauth2
and
is
already
being
incorporated
to
oauth
2.1.
So
we
honestly
just
just
need
to
do
this
if
you're
using
an
http
307,
there
are
cases
where
it
will
cause
a
post
that
was
sent
with
a
307
being
sent
back
to
be
reposted
to
the
page
that
you're
sent
to
the
page
that
you're
redirected
to
and
depending
on
how
you've
implemented
your
site.
E
E
So
we
need
to
be
stricter
about
which
http
things
are
allowed
to
be
used
on
all
of
the
redirect
based
systems,
and
we
need
security
considerations
on
that.
Florian's
already
submitted
some
text
for
part
of
this.
We
need
to
add
the
normative
discussion
for
this
as
well,
and
the
editors
need
to
review
that
pr
to
make
sure
that
all
of
that
is
in
all
of
that
is
in
the
right
place,
pretty
straightforward
attack
and
mitigation.
E
A
G
Yes,
hi.
I
have
a
question
on
the
second
mitigation
that
you
explained
on
page
17,
so
that
was
to
basically
use
a
different
key
for
each
a
s
and
how
would
that
work
when
using
mtls,
for
example,
because
that's
basically
on
the
tls
deck
right?
So
that
would
mean
that
that
the
client
would
need
a
domain
for
each
as
right.
E
E
It's
it's
harder
if
you're
doing
mtls,
but
not
impossible,
because
one
of
the
things
with
mtls
as
it
works
in
canap,
is
that
you
don't
necessarily
have
to
use
a
ca
to
to
verify
the
certificate
at
the
rs,
because,
ultimately,
all
that
the
rs
cares
about
is
that
the
certificate
that's
used
is
the
certificate,
that's
being
that's
being
presented
alongside
the
token
right?
Is
the
certificate
that's
supposed
to
be
used
with
the
token?
E
Thank
you
for
that,
because
it
is
possible,
but
mostly
if
you're,
using
self-signed
certificates,
if
you're
in
an
ecosystem,
whereby
the
client
has
a
registered
certificate
or
has
a
pre-registered
key
that
all
asses
will
will
know
which
happens
in
a
bunch
and
a
lot
of
different
ecosystems,
then
you
know
you're
not
going
to
necessarily
be
able
to
do
this.
This
mitigation
and,
and
that
does
need
to
be
called
out.
E
E
E
The
biggest
thing
is
that
we're
going
to
continue
processing
the
issue
backlog.
We
went
through
these
issues
and
realized
that
there
once
again
were
a
couple
of
sort
of
major
categories
that
would
each
take
care
of
sort
of
a
you
know
a
a
chunk
of
issues
at
once,
and
a
lot
of
these
are
stuff.
That's
been
sitting
around
for
a
long
time,
and
it's
just.
E
We
just
need
to
make
a
decision,
have
a
discussion
and
move
forward
or
have
a
discussion,
make
a
decision
and
move
forward.
That's
probably
a
better
order,
and
we
just
in
a
lot
of
cases.
It's
the
issue
is
just
like.
Should
we
do
a
or
b
we
need
to
just
decide
a
or
b
or
figure
out,
if
there's
a
c
out
there
and
I'm
going
to
go
through
all
of
these
all
of
these
now
so
ellen
by
the
way,
please
go.
Look
at
the
issue.
E
E
Does
it?
Does
it
have
a
specific
semantics
applied
to
it
if
it
is
allowed
and
we
need
to
kind
of
come
down
on
what
makes
sense
and
what
doesn't,
because
right
now,
we've
got
this
kind
of
large
there's
a
request,
object,
there's
a
response,
object
and
stuff
can
just
kind
of
show
up,
and
that
leads
that
type
of
definition
leads
to
weird
corner
cases
where
you
end
up
with
combinations
of
things
that
you
didn't
anticipate
and
we
want
to
make
sure
that
we
don't
have
those
as
much
as
is
possible.
E
For
example,
are
you
allowed
to
send
the
client
object
on
a
continuation
request?
What
does
that
mean?
Does
that
mean
that
you
are
changing
the
display
text?
You
are
swapping
out
one
client
for
another
that
shouldn't
be
allowed,
but
what
is
what
does
it
mean
to
even
send
this?
So
should
this
actually
be
disallowed
when
you
get
back
an
interaction
reference
from
the
interaction
finish
method,
are
you
allowed
to
send
that
multiple
times
or
is
that
a
one-time
use
or
is
that
the
client
can
only
send
it
once?
E
The
interaction
start
methods
right
now
kind
of
say
that
you're
only
supposed
to
do
it
once,
but
that
needs
to
be
made
a
lot
clearer
right.
We've
got
probable
answers
to
most
of
these
kinds
of
things.
What
we're
going
to
do
is
we're
encouraging
people
to
go
through
the
issue.
Tracker
we're
going
to
go
through
these
and
propose
text
to
close
them
and
get
discussion
on
sort
of
what
closing
it
in
this
in
a
particular
direction,
actually
means
and
move
it
forward.
E
So
these
will
be
protocol
changes,
but
more
so
making
the
protocol
more
tightly
defined.
To
say
that
this
is
what
you're
allowed
to
do
in
this.
In
this
instance,
key
rotation.
It
keeps
coming
up
in
all
of
these
conversations.
We
don't
have
a
solution
for
it
yet,
except
that
we
do
have
feedback
from
the
working
group
that
this
is
something
that
we
want
to
do.
E
One
thing
that's
been
kind
of
hanging
us
up
is
that
the
editors
have
been
kind
of
waiting
or
trying
to
figure
out.
If
there
was
this
like
one
grand
unified
scheme
of
key
rotation,
we
think
that
there
might
not
actually
be
that
it
might
be
simply
tied
to
the
different
presentation
mechanisms
such
that
with
http
sig.
E
E
E
We
want
to
be
able
to
to
leverage
that
as
much
as
we
can,
and
so
we
will
propose
text
for
these
over
over
the
next
couple
of
months,
as
we
can
in
order
to
to
kind
of
get
what
that
actually
looks
like
this.
This
does
also
touch
on
this
same
area
as
before
of
how
do
you
even
rotate
keys,
if
you're
doing
mtls,
you
might
just
be
doing
pki,
but
if
you're
doing
self-signed
certs?
E
How
are
you
even
gonna
be
able
to
do
that?
We're
not
sure
yet,
but
we're
gonna,
or
maybe
that's
something
you
just
you're
not
able
to
do
in
that
case,
if
you're
using
that
mechanism,
that's
a
trade-off
that
you
can't
dynamically
rotate
unless
there's
a
clever
way
to
do
this
that
we
haven't
figured
out
yet
anyway,
we're
going
to
be
proposing
text
for
for
discussion
on
that.
Look
for
pull
requests
for
that.
C
My
thought
on
this:
isn't
it's
just
to
hit
on
the
the
key
problem.
Have
you
looked
at
acme
and
I
I
actually
have
a
client
draft
to
do
code
signing
certificates,
but
it
establishes
different
authentication
mechanisms.
The
authors
of
six
store,
so
it's
being
used
for
code.
Signing
certificates
are
looking
to
add
open
identity
into
my
client
draft,
and
so
there
might
be.
While
your
solution
is
not
the
same,
there
might
be
enough
ties
that
we
could
do
something
for
the
fast
issuance
of
certificate,
so
basically
they
reissue.
C
The
goal
for
them
is
to
have
certificates
that
last
a
few
seconds
so
that
in
their
instance,
yes-
and
they
use
a
transparency
log
which
is
already
present
in
acme,
so
their
goal
is
to
have
code
signing
certificates
that
are
used
once
right
and
so
there
there
could
be
some
ties
here.
So
I
can
definitely
hook
you
into
that
and
I
actually
had
already
said
to
them
if
they
needed
review
on
the
open
identity
pieces,
that
I
knew
somebody
which
I
meant
a
lot
of
you
on
this
list.
E
Yes,
and
I'm
I'm
guessing,
that
is
the
draft
that
you
emailed
me
about
about.
The
code
asked
me
to
review.
I
haven't
read
the
draft
yet,
but
I
I
thank
you
for
that.
I
had
I
had
not
made
the
acne
connection
to
mtls.
That
is
a
really
really
good
idea.
So,
if,
as
as
much
as
we
can
point
to
existing
tools
existing
structures,
we
should
do
so
here.
We
should
not
be
inventing
special
stuff
inside
of
inside
of
canap.
So
thank
you.
E
C
E
E
We
will
we'll
definitely
dig
into
that
for
the
mtls
and
really
just
the
certificate
case
in
general,
great
idea,
but
this
is
exactly
the
kind
of
thing
that
this
is
why
we
want
to
go
in
this
direction
of
having
a
different
mechanism,
that's
tied
to
the
presentation
type
to
the
key
presentation
type,
because
it
allows
us
to
do
things
like
this
to
say,
like
oh
you're
doing
mtls,
then
you
know
you've
got
different
considerations.
You've
got
different
tools
that
are
available
that
aren't
elsewhere.
E
E
People
have
argued
that
everything
is
optional,
but
one
of
the
key
design
differences
with
knapp
is
that
it
is
built
around
this
whole
negotiation
aspect,
so
you
negotiate
sort
of
the
parameters
of
the
transaction
at
runtime
or
you're
able
to
negotiate
that
at
runtime.
By
saying
like
this
is
what
I
can
do.
This
is
what
you
can
do,
and
then
you
figure
out
the
overlap,
and
sometimes
there
is
no
overlap,
and
the
answer
is
no,
but
we
need
to
answer
beyond
that
sort
of
core
negotiation
piece.
E
So
is
an
authorization
server
required
to
always
provide
continuation,
or
you
know,
is
capable
of
providing
continuation
of
the
grant
request,
for
example,
is
a
client
instance
required
to
do
a
be
able
to
do
a
an
http
message,
signature
as
a
baseline,
even
if
the
as
can
support
other
things.
You
know
what
are
the
kinds
of
things
that
the
two
people
building
map
that
are
from
sort
of
different
spaces?
E
E
There
is
one
one
possibility
here
that
I
know
leif
with
his
saml
profiles.
Background
is
gonna.
Love
is
that
maybe
we
have
what
we
call
gnap
interoperability
profiles,
so
we
have
the
redirect
based
web
application
profile
of
gnapp.
That
says,
do
http
signatures
use
the
redirect
authenti
our
interaction
start
and
stop
methods,
and
you
know
things
like
that.
We
already
kind
of
described
these
kinds
of
profiles
in
the
examples
in
gennapp.
E
So
the
question
here
is
not
really
the
just
whether
or
not
we
talk
about
these.
It's,
whether
or
not
we
kind
of
formalize
these
and
say
that
when
you're
doing
this,
if
you
declare
you
are
this
type
of
gnap
client
application,
this
is
the
kind
of
support
that
you
want.
Open.
Id
connect
has
had
a
reasonable
amount
of
success,
doing
this
with
its
different
client
profiles.
So
maybe
that's
something
that
we
can
leverage
here.
A
E
A
E
E
C
C
But
then
you
have
to
check
that
you
know
centrally
managed
profile.
Misc
went
the
other
direction
and
it
has
much
higher
adoption
where
it
has
a
really
slim
core
and
then
individual
groups
can
create
their
own
extension
points
and
that
has
a
much
higher
success
rate
in
terms
of
adoption.
So
just
just
a
consideration
point
you
know,
and-
and
that
goes
along
with
the
theme
of
you-
simplifying
and
using
additional
additional
constructs
right
going
more
the
direction
that
mist
went.
E
I
thought
I
had
hurt
someone
else
all
right,
so
mti
leads
us
to
very
naturally
to
extensions.
There's
been
some
stuff
that
we've
pulled
out
of
the
core
over
the
last
year
said
that
you
know
this
is
really
better
fit.
As
an
extension,
people
are
going
to
invent
things
that
we
haven't
thought
of
here
in
this
working
group.
We've
left
a
lot
of
spots
of
the
protocol,
which
could
be
extended,
but
we
don't
really
have
discussion
in
the
document
about
the
right
way
to
extend
all
of
these
different
pieces.
E
So
this
goes
beyond
the
fact
that
we
just
we
need
to
write
the
iana
registry
section
for
a
bunch
of
these
bits,
but
we
need
to.
We
also
need
to
consider
how
things
can
be
extended.
So,
for
example,
we
anticipate
that
adding
a
new
field
in
the
request
and
in
the
response
is
something
that
people
are
probably
going
to
want
to
do
that.
Those
are
really
natural
places
to
put
things.
So
what
are
the
requirements
for
doing
that?
Like
you
know,
is
it?
E
Do
we
give
guidance
to
say
this
should
be
orthogonal
to
other
functionality?
That's
already
in
there.
It
can't
override
something
that's
in
another
field,
but
how
do
we
actually
talk
about
that?
Another
thing,
that's
possible.
Is
that
defining
a
different
data
type
for
an
existing
field,
so,
for
example,
this
is
a
terrible
straw.
Man
example,
but,
for
example,
say
somebody
wants
to
define
behavior
for
sending
a
boolean
value
for
the
access
token
field.
In
a
request.
E
I
don't
know
what
that
would
mean,
but
let's
say
we
have
an
extension
that
does
right
now.
The
access
token
value
is
defined
as
either
an
object
or
an
array
of
objects.
So
what
is
it?
What
does
it
mean
when
you
get
a
different
data
type
there?
Do
we
even
allow
extensions
to
do
that,
or
do
we
lock
down
and
say
existing
fields
and
existing
data
types?
This
is
everything
that's
defined.
E
We
need
to.
We
need
to
decide
that
if
you
don't
know
an
extension,
are
you
allowed
to
ignore
it?
This
seems
to
be
reasonable
until
you
realize
that
some
of
these
extensions
are
going
to
be
security
focused
and
therefore
it's
actually
dangerous.
If
you
don't
know
the
extension
and
and
follow
it,
but
if
you,
if
we
do
have
logic
that
says
an
unknown
extension,
is
ignored
that
actually
influences
how
extensions
get
written
such
that
you
know,
the
security
properties
do
actually
get
added
in
sort
of
the
right.
E
There
are
lots
of
different
things
that
are
sort
of
other
natural
extension
points,
so
the
end
user
claims
so
the
the
subject
types,
for
example,
the
access
data
types.
These
are
things
that
we've
discussed,
that
there
is
already
text
in
there
for,
but
we
need
to.
We
probably
need
to
expand
the
discussion
on
all
of
these,
and
probably
one
of
the
one
of
the
hairiest
bits
is
the
whole
interaction
method
and
specifically
the
combinatorics
of
the
start
and
finish
methods.
E
Can
I
define
another
thing
inside
that
interaction
block
beyond
start
and
finish
and
hints?
You
know
because
I
feel,
like
my
extension
needs
to
go,
do
something
else.
That's
not
one
of
those
things.
Do
we
allow
that,
or
is
that
part
locked
down
all
of
these?
The
editors
think
that
we
have
an
idea
of
what
the
right
answer
ought
to
be
for
a
lot
of
these
kinds
of
things
that
all
needs
to
get
written
down
and,
and
the
working
group
needs
to
discuss
what
we
really
want
to
do
here.
E
So,
as
with
the
other
things,
the
editors
are
going
to
be
proposing
text
proposing
discussion
on
that
text
and
figure
out.
If
that's
the
direction
we
want
to
go
or
if
we
want
to
do
something
else,
all
right,
jose
is
used
in
exactly
two
sections
in
the
draft
right
now:
they're
both
key
proofing
mechanisms,
there's
the
detached
your
ws
header
and
the
attached
jws
header,
which
you
use
when
you
have
a
request
body
and
you
use
the
detached
jws
header
when
you
don't
have
a
request
body,
so
they
really
do
stick
together.
E
These
are
the
only
jose
dependencies
in
canapcore,
so
we
brought
this
up
during
the
key
proofing
discussion
a
while
back.
Should
these
really
be
used,
should
these
really
be
their
own
spec,
and
could
these
even
possibly
be
used
outside
of
canap?
You
know
these.
These
are
these
key
proofing.
Mechanisms
are
things
that
are
general
use.
You
know
we
didn't
invent
http
signing
we're
using
that
draft
from
the
http
working
group.
E
This
is
something
that
was
kind
of
invented
in
an
earlier
version
of
xyz
that
got
pulled
into
into
xyz
and
axoth
that
got
pulled
into
canap,
and
so
should
this
be
pulled
out
into
its
own
thing
as
extensions
for
key
mechanisms,
and
if
so
is
that
in
the
cap
working
group
is
that
its
own
own
draft?
Is
it
something
we
adopt?
Is
it
something
we
just
let
exist
out
there?
E
That's
something
we
need
to
decide
back.
When
we
had
the
key
the
keyproofing
method
discussion,
there
was
not
a
strong
feeling
to
keep
it
or
to
remove
it.
So
the
editors
took
the
more
conservative
approach
of
leaving
it
in
there
for
now.
In
order
to
have
this
future
discussion
now
that
now
that
the
rest
has
settled
more.
C
E
Yep.
Thank
you
for
that
kathleen
to
be
clear,
the
http
message
signing
and
mtls
keyproofing
mechanisms
are
staying
in
court.
There
was.
There
was
really
strong
support
for
that,
so
those
two
are
absolutely
staying
all
of
that
discussion.
All
of
that
is
there
and
those
may
even
end
up
being
what's
mandatory
to
implement.
The
question
is
just
about
the
two
jose
based
mechanisms
and
not
the
not
the
key
proofing
in
general.
C
So
I
guess
if
you
have
the
actual
function
in
another
draft,
but
it's
called
out
in
the
core
draft
that
it's
mandatory
but
then
you're
creating
a
dependency
on
that
other
draft
right.
So
I
think
that
would
be
the
question,
but
I
do
think
it's
important
to
keep
it
in
the
core
draft,
either
by
reference
as
it
being
required
that
it's
there
okay
and
then
you
have
the
dependency
on
publication.
E
E
C
E
E
So
you
always
have
to
use
one
of
a
secure,
keyproofing
mechanism
and
message
signing
mechanism,
and
there
was
the
editors
believe
that
there
was
consensus
to
keep
http
signing
as
a
an
object
level.
You
know
sort
of
message,
level,
security,
protection
and
mtls
as
a
socket
level
protection
and
as
sort
of
the
two
core
options,
and
so
the
jose
pieces
are
a
different
way
to
do
message:
level
protection.
They
have
some
pretty
major
drawbacks,
but
they
do
work.
E
And
so
the
question
is
whether
we
keep
these
these
bits,
specifically
in
core,
as
as
options
or
they
live
in
their
own
draft.
So
we
can
take
this
discussion
back
onto
the
list
because
we
we
want
feedback
of
what
people
plan
to
use,
what
what
people
actually
plan
to
do
with
this
kind
of
stuff,
and
this
this
is
also
going
to
help
the
the
mti
discussion
as
well.
E
B
E
All
right,
thank
you.
Obviously,
this
needs
a
lot
more
discussion,
so
we
will.
We
will
pull
that
into
the
list.
Fabian
has
proposed,
at
least
in
the
editors
meetings,
that
we've
write
up.
What
this
jose
draft
would
actually
look
like
and
present
that
as
as
an
id
just
so
that
people
could
see
like
okay,
if
we
take
this
out,
this
is
the
part
that
would
be
there,
and
this
is
how
we
might
reference
it.
E
But
again,
the
the
mti
discussion
is
absolutely
entwined
with
this
all
right
and
then
almost
to
the
end
here,
the
resource
server
draft
still
definitely
needs
a
lot
of
work.
As
we
start
wrapping
up
these
major
pieces-
and
you
know
sort
of
pare
down
the
issues
on
the
core
draft.
We
are
going
to
be
turning
our
focus
to
the
resource
server
draft.
One
of
the
biggest
pieces
of
this
is
going
to
be
a
token
model,
not
a
token
format,
but
a
token
model
that
could
be
represented
in
token
formats.
E
If
you
wanted
to
have
a
formatted
token,
if
you
wanted
to
have
a
reference
based
token,
that
would
obviously
still
be
possible
and
the
access
token
itself
would
still
remain
opaque
to
the
client
inside
the
nap
just
like
it
is
in
omaha,
but
it's
a
lot.
This
is
just
a
short
way
of
saying
we
know
there's
a
lot
of
work
to
do
on
the
rs
draft.
E
Still
all
right
implementation
status
has
grown
a
little
bit
in
the
last
couple
of
months,
but
there's
still
a
lot
of
a
lot
of
people
kind
of
poking
around
at
the
edges
of
this.
For
both
sort
of
the
core
stuff
and
the
stuff
around
the
dependencies,
we
will
still
at
some
point
add
an
implementation
status
section
to
the
draft.
We
haven't
done
that
yet,
but
we
also
as
as
we
kind
of
predicted
back
in
the
summer.
E
E
All
right
well,
so
we
know
that
there's
a
lot
of
new
stuff
in
the
draft
there's
a
lot
of
new
text
in
the
draft.
Please
read
through
that.
Please
continue
to
help
improve
that
and
thank
you
again
to
everybody
who
has
been
doing
so
so
far,
so
I
I
think
we
might
be
good
to
move
on
to
the
next
section.
Then.
H
A
A
D
D
A
A
H
Today,
the
resource
owner
is
working
in
collaboration
with
the
authorization
server
and
it's
a
case
of
capability-based
access
control.
Now,
when
the
resource
owner
is
working
in
collaboration
with
the
resource
server,
it's
a
case
of
attribute
exactly
so.
That
makes
a
big
difference
between
the
two
models,
because
in
the
model
from
drive
8
the
second
case,
our
attributes
back
access
control
is
not
supported.
H
I
took
a
recent
reason
because
there
was
a
proposal
for
amending
a
relation
from
european
union
that
was
posted
in
june
this
year,
and
the
proposal
considers
a
qualified
trust
service
for
the
provision
of
electronic
attestation
attribute
translated
into
our
wording.
It
will
mean
access
control
that
access
token,
that
control
contains
end
user
attributes,
and
this
end
user
attributes
may
come
from
multiple
sources,
which
means
from
multiples
authorization
server
and
the
core
protocol
should
define
two
fields
in
access
token,
to
distinguish
very
easily
between
rights
and
attributes.
H
H
Now,
in
order
to
support
attributes
well,
we
should
allow
rs
to
indicate
which
attribute
types
and
in
some
cases
attribute
values
should
be
included
into
the
access
token.
In
order
to
allow
given
operation
on
a
given
protected
resource.
This
can
be
done
using
an
http
option
request
to
allow
an
user
which
rs
plurals
are
appropriate
for
each
attribute
type
to
allow
an
user
to
know
the
reason
why
this
attributes
type
should
be
disclosed,
of
course,
in
their
preferred
language.
H
This
is
your
call
user
notice,
of
course,
allow
end
user
to
accept
or
deny
fetching
those
attribute
types
using
the
preferred
language.
This
is
called
user
choice
and
consent,
of
course,
to
allow
a
client
to
request
to
more
or
to
one
or
more
is
such
attribute
types
and
something
which
is
interesting
in
terms
of
privacy
to
allow
client
to
hide
to
the
as
the
identity
of
the
rs.
H
Some
rs
some
as
may
be
too
curious
to
know
which
rs
are
being
accessed
by
their
user,
and
this
is
possible
using
an
unsigned
part
of
the
access
token,
as
he
said
they
proposed
on
the
mailing
list
more
than
one
year
ago,
but
still
not
incorporated
into
the
document,
because,
currently,
as
long
as
you
support
capabilities,
you
must
disclose
the
identity
of
the
rs.
But
when
you
support
attributes,
you
don't
necessarily
need
to
disclose
the
identity
of
the
rs.
H
And
finally,
the
following
privacy:
property
should
be
supported:
user
notice,
user
choice,
user
consent,
and
there
is
a
third
one
that
some
people
do
not
like,
because
they
want
access
token
to
be
opaque.
But
transparency
means
that
the
end
user
or
the
client
working
on
behalf
of
the
end
user
must
be
able
to
verify
that
what
has
been
requested
is
really
what
has
been
obtained
and
for
that.
The
analysis
of
the
access
token
is
needed.
H
Now
draft
8
make
a
general
assumption
that
an
end
user
and
arrow
are
the
same
entity.
However,
there
is
a
note
that
say:
pinup
makes
no
general
exception
that
they
are
well.
Unfortunately,
the
note
is
incorrect
when
you
look
at
section
1,
5,
1,
1,
5,
2
and
all
other
section
from
1
5.
There
is
not
a
single
example
where
the
end
user
is
not
also
the
arrow
and
when
the
ro
is
an
automatic
process,
so
this
will
need
to
be
corrected
next,
one.
H
Now
trust
relationship
in
draft
8,
section
1
4,
is
supposed
to
be
about
trust
relationship,
but
in
fact
it
is
not.
It
is
based
on
the
promised
theory,
which
is
a
300
pages
document.
Where
you
can
read
that
the
promises
stated
intention.
Each
agent
defines
its
own
valuation
function
of
promise
given
or
received.
H
H
In
the
iit
community.
Trust
is
a
binary
combination.
It's
one
or
zero:
either
you
trust
something
or
you
don't
trust
and
we
should
not
mix
trust
relationship
with
preliminarities.
Of
course,
there
are
availabilities
in
a
system,
but
trust
are
remains
the
same
well
section.
One
four
is
failing
to
indicate
relationship
relationship
that
any
exists
between
client
instance
and
auto
application,
server,
authorization,
server,
sorry
and
end
user
and
alteration
server,
so
the
trace
relationship
condition
are
not
complete
and
those
that
are
described
are
incorrect.
H
H
How
may
nas
be
confident
that
the
legitimate
user
is
using
a
given
given
client
instance?
This
is
also
less
left
undefined.
Now
you
can
find
an
interesting
sentence
on
page
five
of
the
draft.
The
end
user
operating
the
software
may
the
world
is
important,
may
interact
with
the
trojan
server
to
authenticate,
provide
consent
and
authorize
the
request.
H
Hence
the
draft
does
not
require
an
user
to
authenticate
well,
a
thing
that
I
just
remarked
on
the
flyer
is
that
draft
8
will
be
enabled
to
comply
with
a
directive
from
the
european
union,
which
is
about
the
payment
service
directive
or
ps
d2,
which
requires
multi-factor
authentication
and
how
that's
this
shall
be
supported
or
may
be.
Supported
is
fully
left
undefined.
H
There
is
a
section
called
protection
of
client
instance,
key
material,
section,
12
3,
and
that
section
in
fact,
is
not
addressing
the
protection
of
this
key
instance
immaterial
anyway.
Such
a
protection
cannot
be
guaranteed.
Even
if
you
use
a
hardware
security
module
to
protect
the
private
private
key.
You
cannot
access
the
value
to
the
private
key,
but
you
can
still
use
that
private
key.
So
as
soon
as
two
client
instances
collaborate
the
security
foundation
of
the
drive
f
collapse,
a
solution
resistant
to
client
collaborative
attacks
is
needed
and
is
possible
next
slide.
H
Well,
it
is
in
fact
unfortunate
that
such
solution
is
negated
in
draft
8..
This
was
new
text
that
was
added,
and
it
is
said,
however,
note
that
the
lack
of
inclusion
of
a
user
identifier
in
an
access
token
may
be
a
risk
if
there
is
a
concern
that
two
users
may
voluntary
share
access.
Token
fine,
then,
since
that
is
the
solution
since,
on
the
contrary,
the
inclusion
of
the
user
identifier
in
an
access
token
is
able
to
prevent,
to
end
user
or
to
client
to
voluntary
share
access
token
between
them.
H
Now
there
are
two
concepts
to
be
considered
before
diving
into
the
fielder.
In
fact,
you
can,
for
example,
want
to
access
your
bank
account
and
when
you
do
that,
you
are
accessing
what
I
call
a
long-term
user
account.
You
want
some
data
to
be
kept
by
the
bank
about
you
when
you
unlock
and
when
you
reload
again.
H
On
the
contrary,
you
may
use
short-term
user
account.
An
example.
Is
you
make
a
transaction
without
the
creation
of
a
user
account
and
when
the
session
is
closed,
when
you
got
your
ticket,
maybe
send
on
your
email
address,
the
rs
will
not
maintain
any
information
about
that
temporary
user
account.
It
is
closed
next
slide.
H
The
first
type
is
the
best
one,
because
it
is
able
to
prevent
correlation
of
end
user
between
rs,
and
it
is
also
able
to
prevent
the
authorization
server
to
know
the
identity
of
the
rs
that
the
the
way
to
do
that.
However,
to
do
that,
you
need
a
hardware
security
module,
no
a
secure
element
from
the
end
user.
H
H
H
H
H
Now
I
propose
a
modify
model
where
both
attributes
and
capabilities
should
be
supported
where
end
user
shall
authenticate
to
the
as
where
trust
relationships
are
clear
and
understandable
and
where,
in
order
to
defeat
collaborative
attack,
access
token
should
be
protected
using
the
byd
mechanism
and
in
order
to
protect
the
impersonation
access.
Token
should
be
protected
using
mutual
cls
with
fml
client
key
pairs,
and
that's
it.
F
Yes,
it's
just
to
say
that
all
these
different
issues
have
been
discussed
at
length
on
the
github
repository
and
so
of
course,
if
there
are
some
criticisms
to
to
reuse
and
implement
into
the
draft,
we're
very
open
to
that.
But
most
of
the
comments
that
this
has
made
have
already
been
answered
and
we've
provided
actually
the
rational
for
rejecting
those.
So,
of
course
we
we
are
very
open
to
more
discussion
from
from
other
people
in
the
working
group,
but
so
far
I
think
it's
pretty
clear.