►
From YouTube: OAUTH WG Interim Meeting, 2020-04-13
Description
OAUTH WG Interim Meeting, 2020-04-13
B
So
I'm,
assuming
you
guys,
can't
see
my
slides
what
I'm
sharing
yes,
we
can.
Okay,
okay,
welcome
everyone,
so
this
is
our
second
of
inter
meeting
so
that
this
is
the
note.
Well
as
a
reminder.
This
applies
here
to
note
taker
Jared.
Thank
you
thank
you
for
for
taking
the
notes
for
us
it's
time
to
I
appreciate
that,
don't
that
last
time
that
was
great,
so
the
meeting
today
will
be
a
focused
on
enesta,
Jordan
and
job
profile
for
access
tokens.
B
But
as
a
reminder,
we
still
have
four
more
meetings
to
go,
and
this
is
the
full
list
here
so
and
we
will
be
meeting
every
Monday,
the
next
four
Monday's.
So
this
say
the
agenda
for
the
meeting
today
is
nested
jot
and
a
profile
for
access
tokens
and
I
will
get
started.
So
hopefully
it
will
be
my
presentation
first
before
I
start
any
any
comments,
questions
any
agenda,
Bashan.
B
So
then
that
concept
that
defined
that
RFC
has
some
limitation
and
that
limitation
is
related
to
the
fact
that
the
enclosing
jot
the
alkyl
jot
doesn't
have
its
own
claims.
It's
it
only
contains
that
the
enclosed
job,
so
the
goal
of
this
simple
Draft
is
really
to
extend
that
scope,
meaning
that
we
want
the
own,
also
the
enclosing
job
to
have
its
own
claims
beside
that,
whatever
the
nested
jot
itself.
B
So
there
are
three
three
use
cases
that
I
think
we've
talked
about,
two
of
them
in
the
past,
and
we
add
another
one
that
was
talked
about
this
in
a
second,
so
the
first
one
is
a
native
app
use
case.
In
this
case,
we
have
a
native
app
app
that
needs
access
to
two
different
services
at
telephony
service,
controlled
by
an
authorization
server
and
a
non
telephony
service
that
is
controlled
by
an
open
ID
provider
and
the
native
app
is
aware
of
the
authorization
server.
B
Only
it's
not
aware
of
that
open
ID
provider
so
that
the
flow
starts
with
the
native
app
launching
a
browser
user
to
authenticate
itself.
The
browser
calls
the
authorization
server
which
redirects
it
to
the
open
IDM
provider,
the
user
authenticates
and
a
code
is
provided.
That
code
will
be
then
move
provided
to
the
native
app.
The
native
app
will
then
use
that
code
to
contact
the
authorization
server
will,
which
will
then
exchange
that
author,
a
code
for
a
token
from
the
oppy
provider
and
then
create
its
own
token
and
and
embed
that
OB
token.
B
Inside
that
the
token
provided
by
the
authorized
server
and
then
send
it
back
to
to
the
application.
The
application
will
be
able
to
validate
the
outer
token,
which
was
provided
by
the
authorization
server
and
then
act
upon
it
and
be
able
to
extract
nested
token
act
upon
it,
so
that
the
second
use
case
is
a
stayer
use
case
if
you're
from
with
stairs
this
is
a
mechanism
to
address
robo
calls
and
problems
with
the
incoming
calls
that
you
can
fake
that
number
of
sales,
a
call
so
in
the
flow.
B
A
If
I'm,
going
back
to
the
use
case,
I
think
you
should
mention
to
focus
on
a
call
who
are
not
familiar
with
this
type
of
work,
that
this
is
a
quite
important
development
to
fight
against
robo
calls
an
idea
referred
to
like
a
broker
calls
showed
up
in
in
telemarketing,
but
also
in
in
SWAT
in
swatting.
These
are
emergency
calls
that
are
placed
sort
of
fraudulent
emergency
calls,
and
so
and
so,
and
they
happened,
the
group
decided
to
use
chat
abilities,
so
trade
abilities
have
found
their
way
into
other
domains
as
well.
B
Was
this
was
based
in
exactly
on
that
draft,
and
it's
and
I
think
that
draft
is
called
pal
succession
for
the
event
it
calls
right.
I
was
trying
to
get
them
to
use
the
kind
of
this
no
mechanism,
but
it
was
a
little
bit
too
late,
because
I
think
that
the
draft
is
already
in
with
is
G,
so
so
we'll
see
I.
It
might
be
too
late
for
that,
but
yeah.
But
anyway
it's
it's
based
on
exactly
that.
That
use
that's
the
use
case
that
I'm
describing
here
right.
B
Okay,
thank
you
so
that
the
third
use
case
is
that
somebody
from
the
open
source
project
called
the
network
service
mesh
they're
working
on
on
a
project,
that's
similar
to
that
trying
to
emulate
what
service
meshes
is
doing.
But
it's
for
layer,
two
and
they're
free,
if
you're
familiar
with
Sto,
so
they're
trying
to
do
something
like
sto
but
for
lower
layers.
So
in
in
their
case
they
have
a
bunch
of
intermediaries
and
those
NSM
messages
will
pass
through
those
intermediary
a
multiple
of
those
intermediaries.
B
B
E
E
What
I'm
not
clear
on
is
the
the
value
of
defining
a
specific
claim
that
that
says
essential
that
that
really
is
just
stating
the
type
of
its
value
that
you
know
that
the
the
end
jot
claim
is
is
the
only
thing
that
tells
me
is
that
the
value
of
this
claim
is
a
nested
jot,
but
it
doesn't
tell
me
anything
about
what
that
value
means
or
what
what
it
represents,
which
is
not
really.
What
we
use
claims
for
right,
like
is
the
is,
is
describing
the
value
you
know
the
nature
of
the
value.
E
E
If
there's,
if
there's
it
needs
to
kind
of
formalize,
some
semantics
around
or
syntax
around
how
you
should
embed
a
jaw
as
the
value
of
a
claim,
then
you
know
maybe
that's
something
we
could
talk
about.
Maybe
there's
room
for
for
a
standard
or
a
BCP
there,
but
I
don't
see
the
value
of
just
a
stock
and
jaw
nested
jot
claim
itself.
So.
G
G
C
I'm
sorry,
so
you
gonna
pile
on
a
little
bit
to
what
was
a
pair
with
new
I
run
through
these
one
would
be
to
the
differentiation
between
Carnot
and
Esther
than
something
else,
because
nested
was
designed
for
a
very
different
sort
of
purpose,
allowing
for
a
signed
and
encrypted
jobs
together
and
the
name
better
for
better
or
worse.
The
name
has
taken
on
that
connotation
along
the
same
lines.
I
think
it
might
be
appropriate
to
call
that
a
limitation
as
you've
been
describing
it
so
much
as
just
the
reality
of
how
that
particular
construct
works.
C
C
C
C
One
area
that
I'm
really
struggling
with
the
need
for
as
well
as
the
way
it's
been
done
is
the
content
type
here,
for
example,
like
the
the
passport
diverted
piece
that
you
mentioned
as
a
use
case,
they
don't
they
don't
use
any
kind
of
content
type
to
to
distinguish
the
actual
of
the
jaw
itself.
One
real-world
case
it's
not
needed
and
just
in
general
I
struggle
with.
C
Why
why
you
would
need
a
content
type
to
indicate
particular
claim
content
in
the
claims
themselves,
like
we
don't
have
a
content
type
to
indicate
that
there's
a
sub
or
audience
or
other
various
sort
of
components
of
it.
In
fact,
I,
don't
think,
there's
even
a
content
type
just
say
this
is
a
claim
set
itself.
B
Only
reason
I
provided
this
is
that
in
that
nest,
because
I
use
the
nested
concept
and
the
Nesta
chart,
it
has
that
that
definition
that
the
the
payload
will
contain
only
the
nested
jawed.
This
was
meant
to
say:
hey,
the
payload
will
have
the
nested
shot,
but
it
will
have
its
own
claims
to,
but
and
if
we,
if
we
move
to
a
different
name,
that
we
might
not
need
this,
but
but
yeah,
it's
open
for
discussion
note
on
exactly
how
to
do
that.
I'm,
not
I'm,
not
stuck
on
on
a
specific
way.
C
Use
you
understand
that
there's
a
nested
jaw
virtue
of
encountering
the
nested
jawed
clan,
so
I,
I,
guess
I
would
say
if
we
do
proceed
with
this
at
all
or
even
in
the
draft
itself.
I,
don't
think
that
content
types
necessary
and
only
maybe
potentially
confuses
the
issue.
So
there's
supposed
to
be
a
media-type,
so
yeah.
B
A
H
Claims
as
far
as
presentations
are
concerned-
and
we
need
have
some
form
of
claim,
aggregation
and
yet
have
some
tracing
of
separated,
separated
claims.
So
this
gives
us
basically
what
we
want
for
the
you
know
for
the
mobile
driver's
license.
I
do
share
some
concerns
over
the
naming
of
this,
and
and
do
we
need
a
separate
thing
on
this,
but
I
think
the
use
case
goes.
E
Yeah
so
yeah
regarding
the
the
naming,
the
guy
yeah
I
agree
with
the
concerns
are
in
racer
one
I,
an
idea
I
want
to
throw
out
for
that
if,
if
this
work
moves
forward,
one
way
to
think
of
this
is
this:
we
are
if
we
were
describing
this
outer
jot
itself,
it's
playing
an
envelope
role.
So
maybe
that's
that's
a
way
to
think
about
the
naming
here
as
describing
you
know,
not
ya,
know
the
nested
jot
term
kind
of
refers
to
the
thing
inside.
E
But
if
we
want
to
describe
what
the
thing
outside
is
it's
really?
It's
not
a
nested
jot.
It's
an
envelope
around
some
payload.
That
is
a
job,
so
food
for
thought.
There
Tony,
I'm,
curious
on
and
the
use
cases
you
you
just
raise
since
you're
saying
you
see
a
need
for
this
I'm
wondering
what
what
you
see.
That's
missing
today
in
terms
of
you
know,
being
able
to
embed
a
jot
within
a
jot
as
a
claim
and
just.
E
H
B
E
B
H
E
E
Is
it
the
case
really
that
there's
kind
of
a
a
general
problem
to
solve
of
how
we
relate
this
outer
jots
claims
to
the
energy
aughts
claims,
or
is
there
so
much
variation
between
use
cases
there
that
it's
really
best
to
leave
that
to
individual
drafts
to
sort
out
as
they
need?
That's
yeah
I'd
like
to
see
some
clarity
there
in
order
to
I
guess
justify
having
a
spec
specifically
for
this.
I
This
Jared
can
I
jump
in
and
are
you
saying
like
a
refers
to
so
theoretically,
what
does
the
nested
or
the
the
child
have
to
be
included,
or
can
it
just
be
a
reference
to
and
then,
if
you
need
that
parent
jot,
you
go,
look
it
up.
That's
an
extra
load
on
you
know
call,
but
do
we
always
need
all
the
jots
included
in
the
single
payload
and.
B
E
D
B
G
I
wanted
to
support
the
comment,
but
I
don't
think
the
content
type
is
in
fact
the
content
type.
It's
normally
something
that
would
apply
to
the
whole
where
this
is
odd
and
then
it's
saying
that
it's
talking
about
the
value
of
one
of
the
claims
being
present
I
would
just
delete
the
content
type
and
the
question
is:
do
we
have
a
generic
and
closed
claim,
or
do
we
do
was
aggregated
claims
to
Anna's
passport?
G
Does
claims
that
also
have
a
semantic
meaning
where
the
shots
as
values-
and
you
know,
I-
certainly
support
Toni's
mobile
driver's
license
use
case.
Do
you
question
whether
the
mobile
driver's
license
spec
doesn't
want
to
define
its
own
claim
saying
it's
enclosed
jawed,
as
this
particular
meaning
supposed
to
just
there
is
an
enclosed,
John
I'm,
not
presenting
an
answer.
I'm
just
asking
a
question.
J
Like
a
chain
and
a
and
you'd
have
a
block
kind
of
feature,
I
don't
know
if
there's
a
use
kick,
but
that
would
be
one
of
the
big
differences
and
I.
Don't
know
that
a
trouble,
but
that
was
just
one
of
them
by
the
term.
It
was
the
suggestion
that
you
describe
reference
that,
as
you
were,
going
through
network
layer
to
layer
might
be
adding
another
wrap
around
to
the
previous
to
the
original
chip
and
adding
a
new
layer
they
later
pulled
apart
in
analog
ii.
B
A
A
B
L
F
L
L
We
also
created
a
mechanism
for
advertising
keys
issue
is
all
the
things
that
I'm
typically
used
for
validating
availability,
and
we
establish
the
rules
of
engagements
for
retrieving
Wolski's
and
using
them,
and
we
also
defined
a
detailed
steps
that
they
can
be
used
for
validating.
They
claims
that
we
defined
as
required
and
therefore
are
checking
signatures.
We
added
detailed
security
and
privacy
considerations,
given
that,
although
these
spec
doesn't
add
anything
that
could
not
be
done
before,
we
do
have
a
more
information
in
respect
to
the
baseline
of
case.
L
Any
particular
we
know
about
the
JWT
is
a
format
that
is
visible
from
the
requester,
and
so
there
are.
Some
considerations
needs
to
be
done
in
here
and
also
given
what
we
explicitly
call
out
some
identity
information.
Of
course
we
need
to
specify
something
in
term
of
privacy
right
now.
There
is
a
very
strong
correlation
between
the
way
in
which
the
token
is
requested
and
the
values
might
end
up
making
being
issued.
This
is
one
of
the
open
matters,
and
so
I
won't
go
into
the
details
here,
but
anyway,
this
is
a
quick
summary.
L
Hopefully
all
of
you
guys
were
already
familiar
with
this,
so
it
just
wasted
your
time.
Then
we
should
a
last
call
on
March
23rd
and
it
was
on
that
1:04
and
that
triggers
a
number
of
really
good
good
reviews
and
suggestions,
the
heroes
here,
Annabelle,
George,
Erin
and
others.
Thank
you
guys
for
your
very
detailed
reviews
and
your
suggestions
in
Brian
before
them.
L
I
clarify
the
fact
when
any
of
the
very
different
steps
in
the
token
validation
phase,
we
need
to
go
for
equality.
Token
Annabelle
made
an
excellent
point
with
was
already
done
on
the
call
on
other
spec
comments
about
the
fact
that
it's
pointless,
we
use
the
different
keys
for
signing
a
token,
an
access
tokens
even
factor
we
don't
have
a
mechanism
for
declaring
which
key
is
used
for
which
flavor
of
token,
and
so
the
resource
amber,
cannot
really
distinguish
between
will
still
and
so
compromising
any
other
keys
in.
L
There
is
enough
to
compromise
everything
else,
so
we
clarified
that
and
then
oh
yeah
I
just
lifted
verbatim.
They
almost
were
very,
very
different
stats
from
alternative
conduct,
which
are
the
numbers,
but,
as
it
turns
out,
those
numbers
were
just
for
layout
purposes.
There
was
no
security,
intent
behind
them,
and
so
those
have
been
turned
in
released.
So
when
people
don't
think
like
they
must
follow
the
sequence
in
term
of
normative
changes.
L
I
add
the
seventh
step
in
there,
which
again
was
coming
from
day,
ie
token
validation,
36,
and
it
was
confusing
and
also
it
created
the
problem
because
we
were
just
saying
well,
you
got
to
really
fennec
8,
but
we
weren't
really
from
money
any
mechanism
for
telling
the
client,
but
we
need
to
authenticate,
and
so
by
eliminating
that
entry
we
came
to
two
birds
with
one
stone.
We
no
longer
either
confuse
accept
which
over-index
on
the
off
time
and
that
sues
other
of
reception
information,
and
we
don't
have
a
bit
problem
of
defining
that
mechanism.
L
I
think
we
should,
as
a
working
group,
refinement
mechanism,
but
these
packages
of
revised
plans
and
also
negative
us
an
enormous
amount
of
cleanup,
like
really
really
lots
of
typos
improper
abbreviations.
So
big
a
cleanup
thanks
again
for
people
to
get
feedback.
The
open
questions,
the
first
easy
one
is,
should
meet
and
actually
for
all
of
them.
I
have
slides,
so
don't
jump
on
it
too
quickly.
For
the
first
one
is
a
simple
like
generate
the
jadibooti
I-I-I-t.
Some
people
think
it
should
be
required.
L
Number
of
resources
might
end
up
in
the
bins,
and
there
are
some
people
don't
like
how
strict
marries
and
so
I'll
give
you
a
quick
interested
occasion
of
why
that
is
the
case,
and
then
we
can
see
what
we
can
do
about
I'm
open
to
relax
the
language,
but
I
just
wanted
to
do
a
last-ditch
attempt,
and
then
we
got
two
recent
comments.
One
it
badly
fact
that
apparently
profile
doesn't
define
enough
of
a
profile,
and
so
here
I
asked.
L
Basically,
what
is
missing
if
there
is
something
which
is
missing
in
term
of
defining
the
layout
and
the
other
part
is
I,
get
general
considerations
about
fallacy.
I
put
it
in
quotes
because
it's
a
catch-all
term,
so
we
must
further
adieu.
Let
me
go
give
my
first
one,
and
here
the
matter
is
easy.
Should
we
switch
positive,
those
guys
from
recommended,
if
you
require
them.
L
A
E
Annabel
Backman
I
jumped
in
to
the
queue
in
the
midst
of
this
slight
discussion,
I
totally
support
making
jti
and
IIT
required
a
hundred
percent.
This
is
a
good
opportunity
for
that.
I
see
any
reason
why
you
eight
and
a
s
would
not
be
able
to
include
them
and
they
provide
significant
value
for
minimal
cost.
B
H
K
N
L
N
L
L
For
example,
all
the
Scopes
are
fair
to
only
one
resource
and
the
reason
I
like
it
just
to
show
graphically
what
the
base
security
considerations
say
is
to
prevent
a
situation
between
here.
Here
you
have
two
api's
and
puffy
eyes,
declare
scots
and
if
you
have
them
multiple
resources
in
their
quest
say
that
I
asked
for
both
envoys
api's
and
save
activities.
One
common
claim
became
a
common
scope
between
those.
Then
you
would
end
up
in
a
situation
in
which
your
token
will
be
ambiguous.
L
Let's
say
vector
you
wouldn't
know,
whoever
its
scope
read
apply,
swap
if
you
have
a
fresh
API
of
a
second
API
you
both
now
we
had
a
long
discussion
in
this.
In
there
sorry,
my
English
is
not
great.
Today
we
have
a
long
discussion
on
the
list
about
mitigations,
and
it's
true
that
potentially
you
can
do
scope
stuffing
like
you
can
have.
Instead
of
read,
you
could
have
a
scope
which
is
clearly
referring.
L
You
want
a
particular
API,
the
complication
there
is
that
when
you
are
running
a
system
where
you
have
many
many
many
many
potential
API
is
like
an
alternate
system
and
similar,
then
typically,
the
identifiers
that
you
end
up
using
being
pretty
much
and
then
adding
scopes
that
Dain
identifiers
of
a
naive
brute
force
solution
is
just
hard.
Let's
say
that
you
have
really
a
lot
of
stuff.
You
end
up
with
tokens
that
are
very
large
and
defining
in
mechanism
in
here
for
tying
scopes.
L
Who
are
sources
like
little
tables
I
think
it
goes
well
beyond
the
scope
of
the
internal
profile.
Let's
say
that,
of
course,
I
didn't
poll
all
the
possible
systems,
but
of
all
the
innate
abilities
which
I
observed
in
the
wild.
No
one
had
anything
even
remotely
to
match
the
level
of
sophistication.
So
that's
why
today
we
have
that
language.
Now,
as
I
mentioned
earlier,
this
is
not
a
hue
and
willing
to
die
on.
So,
if
you
guys
are
compact
in
pushing
back
and
saying
you
know,
this
thing
is
too
restrictive.
L
Just
turn
it
into
a
security
consideration
in
which
you
warn
people
against
the
possibility
of
these
scope.
Confusion
then
I'll
do
it
as
long
as
there
is
enough
out
it's
a
popular
support
for
that,
but
I
think
it's
a
lost
opportunity,
because
I
observe
so
much
abuse
of
a
scope,
software
and
I
think
if
we
would
have
given
a
bit
more
guidance,
then
we
could
have
made
people
develop
system
with
sharra,
but
anyway,
I
am
starting
to
ramble,
so
I'll
just
open
for
your
comments.
L
E
E
E
I
think
there's
there's
a
lot
of
different
ways:
I
list
some
of
them
on
the
list.
People
can
look
at
the
mail
archive
for
that
for
where
you
may
have
multiple
resources
and
multiple
scopes
or
multiple
resources
and
no
scopes,
etc,
etc.
A
lot
of
use
cases
that
are
where
that,
where
we
should
be
able
to
use
John
access
tokens
for
those-
and
we
have
to
remember-
as
we
look
at
examples
out
there
in
the
wild
that
if
you're
just
looking
at
the
people
using
John
access
tokens
today,
that's
only
a
subset
right.
E
L
E
L
Missus
good
feedback
and
I
agree,
of
course,
with
a
spirit
like
a
detective
needs
to
be
as
as
as
broadly
useful
as
possible,
and
I
also
give
you
the
spirit,
you're
saying
don't
issue
a
token,
if
doing
so
would
lead
to
ambiguity
the
thing
that
I'm
always
a
bit
concerned
is
a
living
exercise
to
the
reader
or
like
they're,
not
Sandra.
I,
see
like
these
speck
margin
is
too
small
to
contain
their
actual
guidance,
so
you
figure
it
out
when
it's
ambiguous
or
not
in
an
ideal
world.
L
That
would
work
but
like
a
lot
of
people
around
allons
episodes,
and
so
the
attempt
event
I
was
doing
here
was
like
and
admittedly,
you're
right.
I
was
order
indexing
on
my
own
personal
experience
in
running
such
a
service
and
typical
mistakes
with
people
who
are
doing
so
I'm
perfectly
open
to
change
the
language
to
state
like
a
rather
than
depicting
one
particular
scenario
where
dissidents
just
saying
here
is
an
outcome
that
you
don't
want
to
ever
produce
and
then
add
a
bit
of
details
in
their
security
consideration.
That's
my
that's
my
current
position.
Yeah.
E
I
think
the
reality
is
that,
like
the
a
s
has
to
be
doing
this
anyway,
right
like
if
the
a
s
is
getting
a
request
that
has
multiple
resources
and
multiple
scopes
in
it,
they
better
understand
how
to
interpret
that
in
order
to
properly
you
know,
present
consent.
And
what-
and
maybe
their
use
case
doesn't
doesn't
need
that.
E
But,
generally
speaking,
like
the
a
s
better
understand,
what
is
it's
being
asked
to
grant
authorization
for
right
so
so
I
think
to
some
extent
that
that
there,
the
work
is
already
on
their
plate,
but
we
can't
help
them
with
security
considerations
there.
The
the
one
last
point
I'll
make
you
talk
about,
missed
opportunity,
I.
Think
the
real
opportunity
for
this
work
is
what
we'll
talk
about
in
the
next
meeting
and
that's
rich
authorization,
requests
I.
E
Think
that's
our
opportunity
to
provide
the
strongly
semantic
way
to
specify
what
you're
accessing
or
what
you're,
what
you're
requesting
authorization
for
from
which
you
know,
endpoints
at
etc,
and
at
that
point
we
probably
are
going
to
want
to
be
able
to
support
multiple
resources
in
John
access
tokens.
And
so,
if
you
have
language
here
that
prohibits
that,
then
you
know:
how
does
how
does
that
work
going
forward?
Good.
E
L
O
O
D
So
again,
yes,
thank
you,
Vittorio
and
I
guess,
because
I
wanted
to
echo
a
little
bit.
Annabelle's
point
in
regards
to
there
probably
are
a
lot
of
other
deployment
mechanisms
that
weren't
seen
in
the
sense
of
like
here's,
the
public
people
who
are
using
JWT
for
an
access
token,
and
so
there
are
probably
valid
deployment
models
that
don't
use.
You
know
the
exact
mechanisms
here:
I
don't
have
a
problem
with
using
recommended
language,
as
opposed
to
required
for
some
of
these
things
either.
D
If
we
want
to
sort
of
like
say
it
put
a
little
bit
of
a
here's,
a
recommended
way
to
approach
scopes
right
to
help
people
who
are
doing
it
for
the
very
first
time,
I
do
think
whether
it's
raw
or
some
other
best
practice.
There
is
a
lot
of
value
to
describing
here's
a
set
of
models
for
how
to
deal
with
scopes
and
resources
and
audiences
that
are,
you
know,
deemed
to
be
best
practice
models,
and
that
would
be
a
whole
separate
dock
right.
D
That
would
be
a
more
along
the
best
practice
kind
of
a
thing
where
we
could
then
dig
into
the
the
relationships
between
these
things
and
how
do
people
do
it?
The
right
way,
I
just
feel
like
right
now,
we'd
be
we'd,
either
be
forcing
people
to
create
values
that
are
pretty
much
meaningless
in
order
to
meet
the
requirements
of
the
spec.
D
D
L
You
George,
yes,
that's
right,
I,
also,
really
like
a
mention
of
the
fact
that
if
we
really
want
to
go
after
practices,
perhaps
these
days,
there
is
some
document.
Why
don't
we
have
a
room
to
explore?
Was
the
relationships
as
opposed
to
just
somewhat
try
to
smuggle
it
in
here
where
the
plan
possibly
documented,
is
different.
Thank
you.
L
Anyone
else
very
exciting,
so
summary
I'm
going
to
go
back
to
our
fantastic
swag
I'm,
going
to
look
at
some
of
the
suggested
language
and
I'm
going
to
do
an
update
and
that
a
long
line
so
what
we
just
said,
which
is
ever
going
to
order
commanded
or
adjust
having
in
the
security
consideration
something.
Okay,
thank
you,
okay,
so
they
are
they're
matter
that
we
had
was
the
fact
vector
Danny's
in
particular,
mentioned
that
they
are
profile
layout.
L
Okay,
define
strange
what
respect
doesn't
provide
a
profile
layout,
and
actually
my
impression
is
that
we
do
that's
a
vector.
We
define
the
planes
that
carry
the
information
that
you
need
to
carry,
and
then
we
just
give
guidance
about
how
people
can
extend
it
in
the
way
that
makes
sense
for
that
scenario,
but
even
so
they
here,
my
person
is
I,
think
that
we
do
have
a
layout
and
I.
Don't
think
that
we
can
make
it
more
defined.
At
this
point
there
are
specific
concepts
that
are
missing.
L
Let's
say
that
I
don't
think
it
makes
sense
to
tell
people,
you
can't
add
your
own
claims,
for
example,
or
making
everything
mandatory
like.
Where
are
some
things
that
are
optional
for
good
reasons,
because
we
don't
think
that
they
should
always
be
used.
So,
basically,
the
question
is:
is
there
anything
missing
from
the
current
layout
that
we
should
add.
C
C
L
So
here
is
a
very
easy
one.
One
issue
which
is
I
escaped
one
idea,
and
so
some
of
the
argument
went
in
clarifying
of
time
am
RACR
happened
before
the
last
call,
whether
some
of
that
was
actually
including
feedback
from
you
and
from
Annabelle,
and
what
happened
was
vector
a
lot
all
the
things
that
were
inside
the
description
was
of
each
claim
was
actually
placed
forward
in
the
first
paragraph
and
then
basically,
each
description
were
basically
echoing
it
with
a
slightly
different
language.
L
L
B
P
First
of
all,
I
observed
that
there
was
problem
with
properties
which
are
called
traceability
and
that
the
minimization
and
basically
the
protocol
has
been
described,
is
unable
to
support
these
three
privacy
properties
asked
I
started
with
an
traceability
where,
basically,
the
alteration
server
is
able
to
know
exactly
where
the
token
will
be
used
and
then
is
able
to
act
as
Big
Brother.
The
second
point
is
that,
in
fact,
there
are
two
parameters
that
are
mandatory:
sub
and
client.
P
Id
and
I
sent
an
email
just
a
quarter
of
just
before
this
meeting
never
go
since
these
two
parameters
are
required,
it's
impossible
to
support
that
a
minimization,
and
then
you
have
the
problem.
That
servers
can
link
tokens
from
different
clients,
which
is
not
very
good
when
you
want
to
support
privacy.
So
basically,
my
observation
is
that
the
current
profile
is
unable
to
support
good
privacy
principle,
and
this
should
be
indicated
in
the
privacy
consideration
section
and
another
detail
which
there
is
a
must
not
in
the
privacy
consideration
section.
B
L
Points
I
think
I
need
to
mention
was
four
points
on.
They
are
not
no
lecture
on
the
privacy.
Principles
of
a
general
point
is
I.
Don't
think
that
here
we
are
adding
anything
that
isn't
already
in
off
and
so
I,
don't
think
about
the
placing
goals
for
this
particular
spec
Vitara,
somewhat
higher
or
different
than
the
entire
framework
is
appropriate
from
the
point
of
view
of
knowing,
where
the
token
is
going.
L
Let's
see
six
seven
five
zero
explicitly
say
that
it's
important
for
my
first
different
server
to
include
the
identity
of
intended
recipient,
typical,
single
source,
server
or
Lisa-
very
sort
servers.
In
the
token,
so
here
we
are
following
best
practices
that
are
described
by
an
RFC
in
using
tokens.
The
fact
that
these
tokens
as
a
particular
format,
doesn't
change.
They
go
to
the
token,
in
my
opinion-
and
this
same
goes
for
source
indicators
for
what
concern
they
connect
the
collusion
with
the
sub.
L
There
are
other
mechanisms
that
are
not
about
the
convey
presence
of
a
sub,
but
the
content,
so
you
can
use
the
VP
ID.
You
can
use
the
direct
identifiers
if
you
want
to
prevent
api's
from
correlating
different
tokens.
It's
just
a
matter.
What
they
are
for,
Egyptian
servant
decides
to
place
in
the
sub
and
sub
doesn't
have
to
be
same
for
ATI
one
in
API
for
what
concern
with
a
client
inspecting
the
content
of
the
access
token.
It's
just
that
a
architectural
mistake.
L
Let's
say
that
the
fact
that
I'm
using
each
of
the
blue
doesn't
change
anything
in
term
of
how
the
information
flows
between
graphitization
server
and
the
resource
server.
The
access
token
remains
say:
an
artifact
meant
to
gain
access
to
MERIS
own
server.
The
content
is
a
matter
between
a
verse
or
servant
and
they
are
physician
server
and
even
if
I
can
look
inside
we're
talking,
there
is
no
guarantee
that
I
will
keep
being
able
to
look,
but
I
will
understand
what
I
see
that
what
I
see
is
in
a
format
that
I
can
pass.