►
From YouTube: IETF-ACE-20220912-1400
Description
ACE meeting session at IETF
2022/09/12 1400
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
A
Okay,
so
maybe
yeah,
let's
start
now
so
again,
if
you
have
any
anything
to,
if
you
have
anything
to
say,
just
jump
into
the
discussion,
this
is
an
an
inter
meeting
of
ace.
It
is
subjected
of
the
note.
Well,
if
you're
not
aware
of
the
note
well,
we
should
have
had
a
fla
a
slide
on
that,
but
let
me
know
I
see
someone
in
a
queue.
A
A
So,
okay
right,
thank
you.
So
so
I
mean
what
we're
doing
is
a
status
of
the
working
group,
and
there
is
one
presentation
I
think,
which
is
from
marco
he's,
going
he's
going
to
make
an
update
on
the
key
group
com
and
key
group
from
oscar,
and
I
don't
know
if
goran
has
a
prison
intent
to
present
something.
A
A
A
I
mean
the
draft
follows
what
is
being
done
on
cmpv3
with
lamps,
so
but
that's
currently
in
our
in
our
ad
to
handle
that
keygroup
com
is
going
to
be
updated
today
with
marco's
presentation,
but
currently
we
have
the
key
group
column
that
is
submitted
to
the
isg
at
I
mean
at
least
for
quite
a
long
time.
I
think
it's
200
days
something
like
that.
220
and
keegar
primo
score.
B
A
C
Yeah
thanks
daniel,
I
was
just
wanted
to
ask
on
the
cmp
of
co-op
draft.
I
know
it
is
in
the
ad
review,
but
I
haven't
seen
any
any
updates
since
a
while
and
just
wanted
to
to
yeah
check
whether
I
missed
something
or
whether
there
is
still
work
on
going.
I
think
the
current
graph
version
is
outdated
in
the
meantime.
A
Yeah,
so
this
is
actually
we.
I
have
been
trying
to
reach
the
authors.
They
were
telling
us
that
they
they
were.
I
committed
to
submit
an
update,
but
that
was
three
months
ago
I
I
mean.
I
know
paul
asked
me
to
clarify
this
synchronization
with
cmpv3,
but
at
that
point
I
think
the
only
thing
we
were
we
were
trying
to
prevent
is
that
this
draft,
being
ahead
of
tmpv3
for
the
only
concern,
was
just
the
inf
registration
at
some
point.
B
A
C
Yeah,
currently,
it
is
blocking
the
clp
updates
draft
and
there
was
some
things
with
the
ayanna
registration
on
the
well-known
path
to
be
aligned
and
clarified,
based
on
the
ad
review
feedback.
We
did
that
in
some
months
ago
and
in
the
meantime,
cmp
updates,
where
this
is
the
iana
registration
is
done,
is
already
done
and
ready
for
publication,
but
also
waiting
for
a
cmp
updates
to
be
processed.
C
C
A
C
A
Okay,
so
I
take
that
on
my
side,
I
will
try
to
push
for
to
clarify
if
the
update
can
be
published.
I
we
know
I
I'm
planning
by
the
end
of
this
month,
this
month's
being
probably
july
or
june,
so
yeah.
I
will
try
to
make
that
and
worst
case.
I
will
try
to
see
if
we
can
put
you
as
a
co-author,
so
you
can
move
the
draft.
C
A
B
A
C
A
D
Sure
the
previous
version
basically
addressed
the
architectural
change
so
that
we
aligned
better
to
key
group
com
terminal
with
kdc
and
authorization
server.
It
also
handles
the
previous
issues
about
authorization
requests
and
it
was
kind
of
left
there.
Now
I'm
working
to
align
the
document
further
with
keygroup
com,
to
explain
how
we
interface
to
the
kdc
beyond
join
request
and
response.
D
Currently,
the
remit
of
the
document
is
just
explaining
authorization
to
be
able
to
participate
in
a
group
plus
key
requests
and
responses,
but
the
interface
requires
to
understand
how
to
evict
group
members
as
well
as
re-keying,
which
is
not
addressed
in
the
current
document.
So
that's
one
of
the
things
that
I'm
working
on
to
define
and
in
summary,
basically
making
sure
that
we,
the
profile,
addresses
all
the
requests
required
conditions
that
the
profile
needs
to
meet
to
be
able
to
be
considered
as
key
group
com
profile.
D
D
D
A
A
A
F
F
F
A
F
Sure
here
it
is
so.
This
is
a
consolidated
joint
update
of
the
two
drafts,
keeger
komm
and
kyro
kamal
score.
I
submitted
an
update
for
both
of
them
last
week
about
kickercon.
Yes,
it
has
been
in
a
review
since
end
of
last
year.
I
think-
and
I
had
a
few
updates
in
the
queue
for
a
while,
and
I
hesitated
because
I
didn't
want
to
confuse
paul,
but
I
had
the
opportunity
in
philadelphia
to
discuss
about
this
with
daniel
and
paul
and
it
was
fine
to
incorporate
anywhere
anyway.
F
F
Anything
else
was
pretty
much
editorial
and
in
the
queue
since
euron's
review
of
the
other
document,
keyground
oscar,
and
that
was
also
reminded
in
that
mail
and
on
the
first
update
again,
we
were
having
already
the
optional
possibility
to
explicitly
signal
the
semantics
of
scope
in
the
access
token.
Only
where
I
can
remind
that
scope
is
basically
by
string
wrapping
an
array
of
scope
entries,
let's
say
one
per
group
and
then
in
turn,
can
be
relying
on
aif
on
a
more
simple
textual
format.
F
Now
the
old
approach
was
about
having
one
sieber
tag
once
and
for
all,
registered
and
used
to
signal
the
fact
that
we
were
doing
this
kind
of
thing
at
all
and
then
having
basically
another
layer
of
wrapping
where,
together
we
scope,
we
were
transmitting
also
an
integer
to
be
registered
for
the
specific
semantics
of
scope
to
use.
But
then,
at
some
point
we
had
an
alternative
proposal
from
christian
thanks
a
lot.
F
I
said
possibly
register
because
in
most
of
the
cases
I
expect
the
tag
to
be
already
registered
anyway,
because,
especially
if
you
use
aaf
and
define
related
media
type
parameters
for
the
toid
and
the
perm
of
the
specific
data
model
that
is
supposed
to
result
in
the
registration
of
a
content
format
which,
in
turn
as
per
rfc
9277,
will
result
in
the
registration
of
an
associated
seaboard
tag
and
that's
the
silver
tag.
We
would
use
to
signal
that
semantics
of
scope,
so
the
notation
becomes
clear
and
and
the
practical
signaling
becomes
simpler.
F
That
was
update
one
and
as
to
update
two.
I
said
it
was
about
relaxing
the
expected
encoding
of
toid,
especially
if
aaf
is
used
to
describe
scope
entries.
We
were
really
strict
to
expect
uid
to
be
no
matter
what
a
sieber
text
string.
I
relaxed
it
a
bit
in
saying
that.
Well,
that's
indeed
the
case
to
expect
in
case
we
define
an
af
data
model
intended
like
in
this
document
to
cover
the
roles
that
joining
nodes
want
to
have
in
the
group.
F
But
again
nothing
really
changes
practically
for
the
the
main
case.
We
care
the
most
about
joining
nodes
yeah.
I
don't
go
through
this
just
for
the
reference.
This
is
a
list
of
the
editorial
related
updates.
Where
consistent
with
the
number
of
other
documents
and
the
meaning
of
the
parameters,
I
renamed
parameters,
messages
and
some
specific
uri
path,
segments,
okay
and
that
was
keygroup
calm
on
keygram
oscar.
We
actually
had
the
first
revision
already
for
the
july
meeting,
which
was
mostly
about
addressing
the
working
group,
was
called
comments
we
received
from
yoran.
F
Thank
you
very
much
for
that,
and
it
was
mostly
about
restructuring
the
table
of
content
of
the
document
and
I'm
pretty
happy
with
the
current
results.
I
I
think
it
reads
way
better
than
before,
and
also
about
giving
some
clarification
of
what
exactly
peak
from
the
cosi
algorithm
registry
to
refer
to
an
hkdf
algorithm.
F
There
was
also
a
revision
of
the
af
data
model
defined
here
to
work
exactly
as
it
was
supposed
to
work
already
for
the
sake
of
this
document,
meaning
joining
nodes
but
written
in
a
way
that
it
can
be
extended
and,
in
fact,
is
extended
in
the
asgm
admin
document.
Where,
again,
the
same
data
model
is
extended
to
make
it
possible
to
have
some
scope
entries.
F
F
During
the
details.
Details
handshake
message,
rather
than
before
separately,
I
specified
clearly
where
exactly
the
token
should
be
put
in
which
exact
message,
depending
on
using
version
one
two
and
one
three
of
dtls
consistent
with
what
the
dtls
profile
says
and
that's
it
so
to
summarize
on
keyground,
I
have
no
other
pending
actions,
I'm
aware
on,
and
we
wait
for
the
id
review
for
keyboard
commascore,
it's
most
important,
consistent
with
key
group
com.
F
Again,
I
don't
have
pending
actions
here
either,
but
I
just
wonder
if
there
were
more
comments
to
be
expected
from
yorano
or
anyone
other
than
that
yeah
we
mentioned
before
the
need
to
sync
with
core
that
was
suggested
by
francesca
some
time
ago.
It
was
about
requesting
publication
at
the
same
time,
of
three
documents:
kira
kamos
korenas
and
two
documents
in
core.
Where
for
core
group
on
this
is
one
of
those
it's
a
working
group.
F
F
We
have
a
pending
action
for
us
as
authors
to
work
on
a
new
version
anyway,
where
we
plan
to
specify
better
how
response
messages
are
supposed
to
be
a
handle,
so
we
expect
at
least
one
more
revision
on
the
good
side.
That
update
is,
I
believe,
not
supposed
at
all
to
have
any
impact
on
keygroup
common
score
anyway,
and
that
should
be
the
last
slide.
Yes,
thank
you.
D
Sorry,
thank
you,
marco.
This
is
not
a
question
related
to
the
presentation
now,
but
a
general
question
to
the
ace
key
group
com
now
that
I'm
reading
it
in
detail
and
fresh
in
my
memory
in
the
return
response
joint
response,
there
is
a
credits
parameter
and
if
you
have
the
credits
you
have
to
have
peer,
you
must
have
the
peer
roles
and
peer
ids
for
the
specific
profile
for
the
pops
up.
D
There
are
very
distinct
roles
like
pubs
are
only
the
ones
who
have
the
credits,
and
subscribers
can
only
are
the
only
ones
who
would
be
asking.
So
the
peer
roles
is
a
kind
of
a
space-taking
thing
when
the
profile
is
very
clear
when
and
which
roles
could
be
asked
for
so
it
would
be
an
area
of
pop
up
for
the
all
the
keys
received.
D
D
So,
when
you
return
the
response-
and
you
have,
the
credits
parameter
that
I,
the
peer
roles
would
be
only
containing
basically
for
each
of
the
credentials
returned
which
to
me
is
a
space-taking
thing,
because
the
profile
defines
very
well
which
role
is
allowed
to
do
that
anyway.
So
I
was
thinking
whether
there
was
a
reason
behind
making
that
a
must
basically.
F
D
Yeah,
I
can
definitely
see
the
the
role
of
the
ids,
which
makes
a
but
yeah
in
this.
I
guess
I
provided
the
exception
now
in
this
one.
There
cannot
be
anything
else,
but
the
pub
role
anyway
for
this,
and
so
it
will
be
just
sending
redundant
information
in
an
array
that
is
as
long
as
the
publisher
list
for
that
particular
group.
F
Please
send
me
a
mail
describing
this
and
I
will
check
again
the
detail
in
case
well,
I'd
like
to
hear
from
more
people
in
the
working
group
and
if
it's
fine
to
you
to
postpone
possibly
an
update
to
when
processing
the
the
ad
review
just
to
avoid
yet
another
submission.
Only
about
this
around
this
time
interval.
D
F
E
A
A
B
A
F
A
Okay,
yeah
yeah.
No,
no
sure
I
mean
the
shepherd
review,
that's
we.
We
have
to
do
that
to
move
that
forward,
but
I'm
wondering
I
mean
we
can
write
the
shepherd
review
to
move
that
and
let
then
leave
it
to
the
80
to
handle
the
synchronization
with
with
with
core
all
we
can.
I
I
I
am
more
in
favor
or
something
that
is
a
little
bit
more
proactive
and
say:
yeah
core
has
reviewed
the
document,
so
I
was
basically
thinking.
B
A
A
F
E
E
This
profile
instead
is
associating
the
access
rights
to
an
asymmetric,
key
or
or
rather
authentication
credentials,
authentic,
an
authentication,
credential
and
uses
ad
hoc
to
to
authenticate
and
to
derive
a
shared
secret,
which
is
used
to
set
up
our
score.
So
it's
very
much
like
that.
The
atls
profile
is
already
doing
in
case
of
public
keys,
but
it's
using
ad
hoc
and
oscor
instead
of
the
dtls
handshake
and
tls,
and
the
record
layer
protocol.
E
So
the
difference
between
this
new
draft
and
9203
the
oscar
profile
is
that
it
supports
a
more
strict
trust
model
where
you're
using
public
keys
instead
of
shared
secret
keys
and
the
difference
with
the
dtls
profile
is
that
it
supports
a
lower
overhead
compared
with
using
adhoc
instead
of
dtls
for
the
handshake
next
slide.
Please.
E
E
E
E
And
it
supports
the
use
of
authentication
credentials
in
the
same
way
as
ad
hoc,
so
you
can
either
include
them
in
the
access
token
or
you
could
reference
them,
which
is
useful
because
you
could
lower
your
overhead
size
of
the
access
token,
and
it
specifies
a
data
structure
called
ethic
information
which
provides
information
about
the
the
particular
application
profile
of
ethoc.
That's
used
and
like
what
method
is
being
supported
on
his
message
for
being
used
and
so
on,
and
those
that
information
may
be
included
in
the
message
exchange
before
running
it.
E
E
So,
for
example,
instead
of
doing
the
post
to
authorization
info,
you
could
include
the
access
token
in
nethold
message,
one
directly
in
the
external
authorization
data
field,
and
so
that's
one.
It's
one.
One
round
trip
less,
that's
analogous
to
what
is
done
in
the
dtls
profile,
with
the
psk
identity
and
also
it's
incorporating
the
ad
hoc
and
oscor
combi
combined
protocol,
which
is
in
the
core
draft
so
and
and
that
could
be
combined
with
the
access
token
provisioning.
E
E
E
And
yeah,
so
that's
next
steps.
This
is
already
very
detailed.
We
think
this
is
more
or
less
ready
for
for
someone
to
review.
It
is
a
minor
update
on
information
about
support
for
kudos
that
we
might
want
to
add,
but
otherwise
we
don't
have
any
other
proposed
technical
additions,
comments,
questions.
B
A
E
A
A
F
A
Okay
right,
so
I
will
check
with
my
co-chair
and
issue
the
call
for
adoption
and
then
yeah.
That's
that's
why
we
are
so
now
regarding
the
milestone
I'd
like
to
understand,
so
I
I
mean
so
for
core.
I
mean
the
key
group
come.
What
remains
to
be
done
is
ask
for
a
shepherd,
so
I'm
considering
that
people
in
core
are
so
involved
that
the
chairs
will
have
to
to
select
among
the
the
candidates
one
of
the
shepherd
brighter.