►
From YouTube: ACE WG Interim Meeting, 2020-05-18
Description
ACE WG Interim Meeting, 2020-05-18
B
B
B
E
Yeah,
basically,
if
we
have
addressed
the
latest
comments
from
been
and
uploaded,
the
version
10,
which
includes
all
of
the
comments
except
for
the
topic
that
has
been
raised
by
Francesca
and
one
of
the
comments
were
been
included.
Some
additional
references
explicitly
a
talk
from
ATF
hundred
for
I
think
in
a
sock
working
group
which
I
have
to
follow
up
to
see
whether
or
not
we
have
to
write
something
in
there.
But
everything
else
has
been
addressed
by
us.
B
B
A
D
D
D
Thank
you
that's
better,
so
this
is,
as
most
of
you
have
probably
seen
in
the
main
list,
the
update
of
access
rights
thread.
The
link
is
here
in
the
first
slide
next
slide,
but
first
before
talking
about
that,
I
wanted
to
give
a
short
summary
of
what's
the
status
of
the
oscar
profile
document
right
now.
So
yes,
they
know
if
you
could
go
back
to
the
slides
and
slide
number
two.
D
So
right
now
we
have
submitted
version
10,
which
answered
been
dense
review
and
we
also
have
a
pull
request,
which
is
version.
11
is
not
not
submitted
yet
but
aims
at
answering
ocf
comments
and
address
bands.
Re
review
so
includes
includes
also
the
bands
for
requests
and
also
there
were
two
left
over
a
github
issues
from
Jim
which
we
dug
into
and
what
is
still
missing.
So
we
we
think
that
once
this
poor
request
will
be
merged
and
version
submitted
version
11,
and
it
will
only
missing
two
points
in
the
oscar
profile.
A
D
D
D
And
this
token,
together
with
the
nonce
s,
is
used
to
derive
the
security
context
and
the
security
context
is
used
to
protect
requests
or
responses
with
the
score
and
whenever
the
client
wants
to
do,
an
update
of
its
own
access
rights
then
sends
the
post
token
to
das
gets
a
second
token
and
then
the
product,
the
procedure
is
the
same.
So
another
security
context
is
derived
as
different
security
context,
which
is
linked
to
the
second
token
and
the
first
hope
and
in
the
first
security
context,
are
removed.
D
D
So
we
have
a
proposal
which
I
try
to
formulate
in
the
email
which
is
to
mandate
at
the
access
token
to
update
the
access
rights
must
be
sent
over
the
secure.
So
we
propose
that
this
is
done
both
in
aw
scorn
and
the
TLS
profile
Jim
assumed
that
that
was
already
the
case
for
the
DTLS
profile.
I
have
looked
at
the
details
profile,
but
it
was
not
explicitly
said
so.
So
if
it
is
the
case,
it
would
be
good
to
have
it
explicitly
written.
D
D
So
this
is
what
the
proposal
would
look
like.
It's
much
simpler.
The
security
context
is
derived
the
first
time
that
token
is
received
from
the
client
and
then
once
the
token
two
is
retrieved
from
the
authorization
server
that
is
posted
over
the
secure
Channel
in
the
case
of
a
score
protected
with
all
score
in
the
case
of
the
TLS,
overly
TLS
channel,
and
then
no
need
to
read,
arrive
security
context
next
slide.
D
Yes,
so
I
sent
this
in
the
mailing
list
and
I
got
a
couple
of
responses.
I
I've
seen
some
responses
today,
which
are
not
included
in
the
slides,
because
these
were
already
posted,
but
Ludwig
seems
to
say
that,
yes,
that
it
should
be
sent
over
secure,
Channel
and
that
it's
not
necessary
to
separate
the
two
endpoints
Ricardo
Marco
as
ace
oscar
profile.
D
Implementers
has
said
that,
yes,
that
one
is
doable
even
without
the
point.
One
point
two
one
point:
B
and
Michael
has
had
some
consideration
about
access
rights
of
the
token
and
the
updated
token,
and
then
then
mid
note
about
possibility
of
collision
of
key
ID.
So
to
talk
about
pee
and
yes,
in
fact,
we
should
talk
about
security
associations
and
not
key
identifiers.
G
A
question
about
the
last
point
from
been
there:
why
is
there
problem
with
collisions
of
eid
is
if
this
is
the?
This
is
a
we
assume
there
is
a
given
authorization
server
associated
to
this
token,
and
this
channel
is
associated
to
this.
The
secure
channel
is
associated
to
the
token
which,
in
turn,
is
associated
to
an
authorization
server,
and
the
authorization
server
should
not
sit,
should
have
unique
identifiers.
A
F
Right
and
I
think
I
was
also
remembering
in
some
of
the
previous
document
in
a
review.
I
had
to
be
educated
about
how
the
key
ID
is
not
necessarily
globally
unique
and
is
potentially
scoped
based
on
who
is
receiving
value,
or
maybe
it
was
who's
sending
still
pretty
early
for
me
in
the
morning.
I
just
wanted
to
make
sure
that
there
was
no
risk
of
issues
in
case
of
collisions
because
even
the
same,
a
s
can
issue
a
duplicate,
key
ID
for
the
same
key
or
for
a
different
key.
A
G
G
C
So
I
find
one
be
needlessly
complicated,
I
mean
what
are
you
doing?
You're
submitting
a
token?
Ok,
it's
an
update,
but
that's
just
some
internal
processes
and
you're
creating
a
whole
new
endpoint
with
a
lot
of
logic,
behind
that
where
we
could
just
use
the
existing
endpoint
to
submit
the
token,
because
that's
on
the
rest
level,
that's
the
only
thing
that
you're
doing
you're
sending
in
a
new
token.
Yes,
internally,
that
it's
an
update
of
token
or
that
it's
just
a
completely
new
token.
That
is
something
that
you
can
process
internally.
D
So
we
need
to
know
if
this
resource
is
protected
or
unprotected
before
we
know
what
processing
we're
gonna
do
in
this
resource
and
please,
like
Oscar
implementers,
can
correct
me
if
I'm
wrong,
but
I
thought
that,
because,
in
the
case
of
the
update
of
access
rights,
if
we
mandate
that
this
endpoint
must
be
must
be
accessed
via
protected
request,
we
only
know
if
you're
doing
an
update
later
on
and
we
don't
square.
You
already
done,
do
score
verification.
D
Your
you
have
already
verified
your
score
message.
You
already
passed
the
Oscar
layer
before
you
know.
Is
this
protected
or
unprotected?
So
the
point
is
that
okay,
so
you
can
have
some
processing
saying
this
is
a
update
of
access
rights.
So
you
should
verify
your
score,
but
how
do
you
go
back
to
the
layer
to
the
office
core
layer
and
say:
ok
now,
do
the
oscar
processing
I
don't
know
if
I'm,
clear.
D
So,
ok
again
so
the
authorization
info
endpoint
is
usually
unprotected
and
there
is
some
processing
that
is
defined
where
once
you
receive
that
request
with
the
token
you
verify
the
token
and
then
you
generate
the
nonce
etcetera,
you
derived
the
security
context
in
case
you
are
now
Monday
mandating
that
if
this
is
an
update
of
an
access
token,
this
this
request
must
be
sent
protected.
The
post
post
authorization
info.
This
means
that
you
first
have
to
check
that
this
is
an
update
of
access
right.
So
you
have
to
check
that
these
contains
token
that.
D
D
And
that's
that's
yes
and
I
reported
that
feedback
and
that.
But
this
is
why
I
said
that
it
would
be
simpler,
because
if
you
have
two
resources
you
can
just
say
this
resource
must
be
accessed
protected
and
if
I
receive
any
message,
this
unprotected
I
will
reject
it.
You
saw
the
resource
can
be
accessed
unprotected
I,
don't
care
so
Jim,
for
example,
in
your
implementation.
If
you
receive
a
message-
and
there
is
a
different
Oh
score
processing
based
on
the
content
of
the
message,
can
you
do
that?
D
So
so
what
you're
saying
is
that
you
process
the
Oscar
layer
and
then
you,
you
process,
the
the
actual
I,
don't
know
like
coop
a
slayer,
and
at
that
point
you
might
at
that
point
you
can
see
if
that
request
was
an
update
or
an
actual
post
soakin
for
the
first
time,
and
but
at
that
point
you
know,
can
you
retrieve
the
information?
This
was
Oscar
protected
and
if
it
wasn't,
can
you
respond
with
a
4-1
error
message
if
it
was
supposed
to
be
any
decent?
D
A
D
Okay
mm-hmm,
so
that's
not
a
problem
for
your
implementation,
either
I,
just
I
was
just
assuming
that
yeah.
Maybe
you
can
see
why
to
me
that
sounded
complicated,
because
that
I
assume
that
in
law
school
a
year
was
more
separated
from
the
coop
and
if
request
was
to
be
rejected,
it
would
be
rejected
at
the
Oscar
lair.
D
Without
all
score,
so
what
would
happen
is
that,
for
example,
you
receive
a
request,
we
don't
know
score
option,
and
this
is
supposed
to
be
a
post
token.
For
the
first
time
you
should
accept
unprotected
requests,
so
you
should
even
possibly
discard
that
was
corruption,
because
you
don't
you're,
not
you
don't
want
it
to
be
protected.
D
So
a
client
could
could
try
to
post
a
sorry
to
deny
not
updates
of
access
right
to
deny
just
post
okay.
If
a
client
is
trying
to
post
a
token
and
the
middle
man
adds
a
non
score
option
with
garbage
in
the
option-
and
this
goes
through
Oscar
processing
and
it
fails
because
it's
garbage
it's
actually
yeah.
D
D
G
D
A
D
D
D
D
D
C
D
D
D
D
G
D
D
So
there
is
the
general
concept
of
update
of
access
rights
done
over
the
secure
channel,
and
then
there
is
implementing
it
in
the
profiles
which
we
can
do
and
I
think
we
will
do
unless
I
hear
any
objection,
its
I
mean
it
seems
logical
that
we
will
do
it
in
the
profiles
anyway.
It's
just
does
this
need
to
be
in
the
framework
as
well
and
I
definitely
see
Ludwig's
point.
This
is
coming
last
minute
like
this,
but
again
this
is
when
I,
when
I
saw
this.
G
A
C
B
F
D
Status
of
the
document
I
did
want
to
bring
this
up
at
this
point
because
it's
not
yet
published
and
because
I
thought
this
is,
it
would
be
good
to
have
it
in
there.
So
if
we
can
get
it
in
there,
I
would
be
happy.
Then,
if
we,
if
we
don't
at
least
I
brought
it
up
and
I,
don't
think
it's
a
big
enough
change
that
he
would
require
a
lot
of
effort
to
put
it
or.
D
C
Opinion
on
that,
as
well
and
I'm,
fine
with
your
opinion,
Francisca,
but
I
would
like
to
be
that
to
be
confirmed
if
it's,
if
it's
just
me
putting
in
the
work
right
it.
That's
not.
My
problem
I
can
do
that,
but
if
it's
then
waiting
for
the
nextel
chats
having
questions
in
the
tell
chats
answering
those
questions,
then
we're
speaking
another
three
months
before
the
documents
moves
on,
and
that
is
really
what
I
want
to
avoid.
F
D
So,
just
to
clarify
it
this,
what
I
was
talking
about
now
was,
and
it
seemed
to
me
that
I
mean
the
chairs
can
call
the
consensus.
But
what
I've
heard
is
that
there
is
pretty
much
consensus
about
not
doing
a
different
end
point,
so
the
change
that
I
was
talking
about
that
would
be
small,
in
my
opinion,
was
only
about
saying
that
up
the
update
of
access
rights
must
be
done
over
a
secure
channel.
That
is,
did
the
whole
the
whole
part
about.
D
F
C
C
C
The
update
of
access
rights,
what
I
would
admit
it
was.
C
A
B
Mike,
what
is
unclear
to
me
is
suppose
we
don't
change
what
would
be
the
problem
of
having
a
separate
document.
That's
handled
it.
D
Is
there
is
no
problem?
What
I
would
say
like
this?
This
came
from
analyzing
the
profile
oscar
profile
noticing.
Oh,
there
is
something
missing
and
then
thinking
about
it
and
realizing
okay.
Maybe
this
is
also
missing
from
the
Detailers
profile
and
if
it
is
missing
from
both
profiles,
is
it
something
that
should
be
higher
level
Monday
today,
rather
than
at
the
profile
level
at
the
framework
level?
But
if
we
don't
do
it
at
the
framework
level,
I'm
also
happy
to
have
it
in
the
profile.
D
D
B
D
I
D
Think
this
is
similar
to
what
Michael
Richardson
in
his
mail
was
he's
replied
to
my
email
was
talking
about,
but
no
token
one
is
not
expired
in
this
case
and
token
two
has
a
different
set
of
access
rights.
It
can
be
a
super
set
or
it
can
be
it
disjoint
said
we
don't
talk
about
that
at
all,
but
the
idea
is
that
token
two
is
going
to
replace
token
one.
D
I
I
Feel
so
you
coming
completely
through
a
different
type
of
protocol
in
PT.
Serial
indicates
with
a
token
during
a
session
so
and
that
session
is
secure.
So
we
don't
have
the
additional
security
requirement
and
then,
if
anything
is
submitted
to
offset
info,
we
assume
we
treat
it
as
a
new
token
and
validate
it.
Basically,
so
I
think
we
don't
differentiate,
which
will
mean
the
first
access
to
the
outside
info
versus
the
second
access
to
the
outside
info.
I
I
I
Also
infer
any
valid
token
already
exists
for
the
client.
It
will
be
just
rewriting
that
and
in
the
next
connection,
validation
of
the
token
will
happen
so
from
a
framework
perspective.
I
think
our
profile
does
not
need
specification
from
the
framework
that
this
needs
to
happen
in
a
secure
Channel,
but
this
is
I
know
that
any
kind
of
different
then
the
but.
D
I
D
What
what
I
was
yes
and
I
think
that
the
TLS
profile
also,
does
this
post
token
post
authorization
info
over
secure
channel
and
what
I
was
suggesting
is
that
the
framework
mandates
that
the
post
was
relation
info
is
done
over
secure
channel?
So
what
your,
if
I,
understand
correctly
you're
saying
we
already.
C
D
I
The
yeah
it
would
already
comply,
comply
with
that
and
then
what
I'm
trying
to
say
is
that
if
the
session
disconnects
and
the
client
now
wants
to
submit
a
new
token
to
outside
info,
it
goes
through
there
and
and
it
just
submits
it
as
a
new
token,
it
doesn't
try
to
tell
the
RS
as
the
continuation
of
my
previous
token.
This
is
not
the
first
time
I'm
connecting
you.
It
doesn't
communicate
that
we
haven't
thought
about
that
option
and
I,
don't
see
why
it
would
necessary
to
communicate
to
the
RS.
D
D
C
D
G
G
It's
this
point
about
ident
eyeing
the
Rs
point
to
be
identifying
that
this
is
8
in
the
sense
that
this
is
this
access.
Token
is
related
to
these
other
access
token,
so
we
had
several
ideas
there.
That
was
one
key
identifier
and
also
verifying
the
key
and
Jim
brought
up
the
an
identifier
explicitly
in
the
simple
web
token.
Do
we
have
any
way
forward
on
those
options.
D
D
D
J
D
D
D
D
So
since
ITF
107
version,
six
was
submitted,
May
eleventh
based
on
Jim's
review,
and
there
was
some
discussion
at
E
ITF
107
virtual,
then
the
PR
was
merged
and
all
issues
were
closed
next
slide.
Please
so
I
spent
some
time
to
reorganize
the
to
do
list.
So
this
is
what
our
to-do
list
looks
like.
So
the
highlighted
yellow
are
the
ones
that
we
were
discussing
or
that
are
left,
and
then
there
is
a
lot
that
has
been
done,
but
we
actually
never
had
the
chance
to
answer
mails.
D
So
we
actually
included
all
the
points
and
made
sure
that
we
did,
but
we
have
a
lot
of,
for
example,
Jim
reviews
of
version
five
and
three
and
two
have
not
been
answered
in
the
mailing
list,
but
this
is
just
to
say
that,
yes,
we
have
answered
them
in
the
document.
We
actually
probably
should
answer
them.
We
can
do
that,
but
at
this
point
some
of
these
reviews
are
so
old
that
I,
don't
know
Jim.
If
you
want
us
to
spend
time
to
actually
answer
that
email.
D
D
C
D
Yes,
so,
let's
start
with
the
most
recent
I
believe
mail.
So
this
is
some
points
left
from
Jim's
review
of
draft
version.
Number
four
I
added
link,
so
it's
easier
to
see
where
I'm
taking
this
from.
So
this
first
point
open
point
is:
should
we
try
and
harmonize
the
scope
format
here
with
either
the
form
and
I'm
in
mqtt
or
with
the
one
that
cast
and
once
proposed?
The
most
multiplicity
of
conformance
is
going
to
become
a
problem
at
some
point.
C
C
D
In
the
eighth
key
group
right
now,
we
don't
specify
the
format
of
I
mean
we
specify
scope
as
see
bore
containing
roles
and
topic
or
group
identifier,
but
we
don't
say
what
these
roles
and
group
identifiers
are
supposed
to
look
like.
So
it's
it's
different
from
what
I
don't
really
know
what
Carson's
proposal
was.
D
A
A
A
B
I
Format
is
one
thing
that
we
should
be
able
to
differentiate
between
the
actions,
the
resources,
the
action,
the
resources
that
the
actions
are
done
on.
Basically,
that's
why
we
basically
created
that
format
and
recommended
the
ease
of
it.
So
if
there
is
a
stronger
scoping
format,
I
would
be
happy
to
look
into
that
as
well.
If
it
applies
to
us
I'm.
A
K
K
D
D
A
D
D
How
does
one
enforce
the
mass
not
for
the
resource
name
of
ACE
group
and
the
mass?
Not
that
this
is
referring
to
is
in
the
when
the
interface
is
defined?
The
ACE
Group
resource
is
defined
as
follows.
This
resource
is
fixed
and
indicates
that
this
specification
is
used.
Other
applications
that
run
on
KDC
on
a
KDC
implementing
the
specification
must
not
use
the
same
resource
I,
don't
know
how
how
this
can
be
enforced,
but
I
think
that
this
needs
to
be
here
or.
D
D
D
J
F
A
D
A
A
D
D
D
What
so,
basically
the
gid
part
takes
the
value
of
the
group
identifier,
so
it's
different
for
different
groups
and
the
node
part
takes
the
value
of
the
node
identifier.
So
it's
different
for
different
nodes
in
the
same
group,
but
not
having
that
text
string,
nodes
between
group,
ID
and
node
I'm,
not
sure
that
that
helps,
because
if
you
have
coalition's
you
would
have
collisions
anyway.
If
you
have
nodes
right.
A
D
D
Okay,
okay,
so
you
collisions
with
not
with
the
other
nodes,
okay
with
the
other
endpoints,
their
gene
ID.
Okay,
now
I
understand
yeah.
That
makes
sense
we'll
do
that.
It
makes
it
a
bit
longer,
but
I
guess
it's
fine.
D
Okay
sure
that
works
okay
next
point
should
a
client
be
able
to
ask
for
a
previous
set
of
key
material.
Consider
the
case
of
client
having
key
material
and
missing,
update
n,
plus
one
and
getting
update
n
plus
two.
The
client
then
gets
a
message
encrypted
to
update
and
plus
one.
He
never
saw
the
material
and
thus
cannot
decrypt
the
message.
D
D
So
I'm
just
gonna
read
it
skip
the
first
part
of
the
email.
The
one
case
that
I
have
not
been
able
to
get
a
good
handle
on
is
as
follows.
The
KDC
purse
is
keys
and
keys
in
a
database.
The
kid
is
he
at
some
point
crashes
and
then
restarts
so
the
KDC
rolled
the
epic
and
the
key
material
on
restart,
or
should
he
just
load
the
current
key
material
and
continue
with
it?
A
client
tries
to
join,
would
be
unable
to
do
so.
D
I
guess
you
meant
Jim,
while
the
KDC
is
is
offline
because
the
KDC
does
not
respond
so
that
would
not
force
a
rollover.
A
client
a
tries
to
do
a
renewal
because
of
IV
exhaustion
would
be
unable
to
do
so
and
would
have
to
go
quiet
until
the
KDC
restarts
I
guess
because
becomes
alive,
and
that
would
not
force
a
rollover.
A
client
tries
to
do
a
leave
would
not
be
able
to
tell
the
KDC
that
this
is
the
one
case
that
having
the
KDC
do.
The
rollover
of
the
keys
would
make
sense.
D
D
D
That
makes
sense
yeah,
because
you're
also
like
assuming
here
in
this
mail
that
key
rollover
is
done
with
observe,
and
that
might
not
be
the
case.
That
is
not
the
only
way
that
we
we
define
like
exchanges
with
the
KDC,
so
it
might
not
be
possible,
but
also
it
might
be
possible
yeah
okay,
so
we
will
give
it
a
shot
that
will
try
to
write
some
text
next
slide.
A
Yeah,
basically,
the
observe
mandates
that
you
do
not
send
out
and
observe
notification
more
than
once
a
second
more
than
once
one
per
second.
So
if
you
roll
the
keys
over
faster
than
that,
then
you
start
having
a
problem
that
the
observe
documents
saved,
that
you
don't
send
out
notifications.
So
people
will
not
get
those
those
key
rollover.
Events
mm-hmm.
D
F
F
A
D
A
A
D
D
B
Okay,
so
I
think
we
can.
We
will
close
the
meeting
I
just
want
to
let
you
know
that
we
do
have
another
interim
meeting
slained
if
I
can
find
the
slide.
So
it's
next
month,
yeah
so
see
you
next
month.
I
hope
we
could
discuss
the
next
versions
of
each
of
those
draft
next
months
and
maybe
having
some
of
those
sent
to
the
IET.
So
maybe
Jim
do
you
want
to
say
something
before
we
close
now
I'm.