►
From YouTube: IETF-ACE-20230123-1400
Description
ACE meeting session at IETF
2023/01/23 1400
https://datatracker.ietf.org/meeting//proceedings/
C
I
guess
so
so:
okay,
so
I
restart.
So
we
have
the
not
well,
and
we
do
have
the
agenda
bashing
I'm
wondering
if
anyone
is
willing
to
take
notes
or
and
why
Logan
handled
the
brush
of
volunteers
I'm
also
asking
if
anyone
has
anything
he
wants
to
mention
on
the
agenda,
I
think
I,
see
and
Drake
so
and
Drake
is
probably
asking
for
something
with
a
CMP.
C
No
was
it
the
CMP?
Well,
the
CMP
draft
I
I
think
in
eight
foreign.
C
Just
be
very
brief,
on
the
notes:
I
mean
we
don't
need
to
have
everything
just
the
main
point.
Maybe
so,
let's
start
so
CMP
the
CMP
draft,
I
I,
think
yeah.
We
were
expecting
a
response
from
to
the
security
directorate
from
muhit
and
I.
Think,
indeed
it
so
now,
it's
really
in
the
hand
of
Paul.
C
This
is
my
my
I
mean
Paul.
Has
everything
to
to
do
a
ITF
last
call
I'm
wondering
if
there
are
any
actions
that
that
the
working
group
is
expected
to
do
all
the
chairs
and
Drake?
Do
you
have
any
expectation
from
us.
D
No,
no
special
expectations
so
just
wanted
to
give
a
quick
background.
I
think
Mohit
responded
to
Paul's
comments
and
yeah
said
he
will
submit
an
update
of
the
draft
I.
Think
Paul
is
waiting
for
that
that
update,
if,
if
I
got
it
correct.
D
It
is
a
normative
reference
in
two
of
my
documents,
which
are
in
the
RFC
editors
queue
and
as
this
is
the
last
dependency
that
is
open,
of
course,
I'm
interested
in
yeah.
Getting
the
document
approved
and
I
feel
like
it
is,
it
is
ready
and
it
is
ready
for
more
than
half
a
year
or
already
so.
Yeah
I
would
appreciate
things
moving.
C
Forward
so,
as
you
mentioned,
I
saw
an
email
from
ruite
on
the
mailing
list,
but
I
think
he
was
responding
to
Valerie's
comment,
but
I
don't
see
the
new
version
on
the
data
tracker,
so
I
will
try
to
follow
up
with
that.
C
I,
don't
think
he
submitted
a
new
version,
so
probably
address
that,
but
yeah
I
will
try
to
to
send
an
email
to
to
respond
to
mui,
to
say,
probably,
is
waiting
a
response
from
Valerie
to
publish
it
but
I
I'm
going
to
to
say
we
would
like
a
a
new
version
to
be
published.
I.
Take
that
on
my
on
my
site,
any
any
other
comments.
No,
so
maybe
let's
move
to
the
pub
sub
profile.
E
Hi,
unfortunately,
I
haven't
progressed
it
beyond
the
previous
meeting,
but
I
received
an
email
from
Marco
that
there
will
be
some
changes
to
co-op
pops
up
in
core
yeah.
So
it's
the
same
as
I
last
reported.
F
As
we
speak
actually
working
on
the
core
Pub
sub
document
and
progressing
it
I
conference
again,
that
I
can
help,
especially
on
the
security
side.
So
if
you
want
to
have
a
chat
about
that,
one
of
this
week's-
let's
do
that,
but
I
am
not
directly
on
the
core
Pub
sub
document.
E
Thank
you.
Yes,
I
have
both
your
emails,
so
I'll
take
a
look
where
the
updates
are
planned
and
then
raise
any
comments,
concerns
or
questions
I
have.
C
C
Okay,
right,
okay,
great!
What
timeline
do
we
expect
is
that
next
month
or
in
the
next
two
months,
it's
it
I
mean.
C
So
perfect,
and
as
soon
as
you
need
the
help
just
contact
us
s,
meaning
anyone
that
can
help
will.
C
Okay
right
so
now,
I
think
we
are
leaving
the
floor
to
Marco.
F
Sure,
on
revoke
token
notification,
well
I
started
working
on
it
for
the
next
revision.
You
can
already
see
some
relatively
small
updates
on
the
GitHub,
but
big
things
are
still
to
come.
I
confirm
I,
expect
a
version
for
the
cutoff,
hopefully
to
be
ready
for
a
working
group.
Last
call
after
that,
so
around
itf116.
C
C
C
F
D
F
Right
now,
I've
just
asked
permission
to
share.
You
don't
even
see.
B
F
Okay,
so
this
is
an
update
on
the
GM
admin
document
and,
to
recap,
this
document
considers
the
the
group
manager
supported
of
the
group
of
score
protocol
and
defines
a
restful
interface
at
the
group
manager
for
administrators
so
that
they
can
create
or
configure
Delete
the
the
Oscar
groups
run
by
that
group
manager
and
right
now
and
for
a
while.
F
Actually,
the
document
can
be
used,
considering
a
link
format
and
playing
c-bar
or
otherwise
Coral
and
the
organization
of
the
interface
and
the
management
resources
that
the
group
manager
is
pretty
simple.
There's
a
single
instance
of
a
group
collection
resource
and
for
each
existing
old
school
groups.
At
the
group
manager.
There
is
one
child
resource,
a
group
configuration
resource,
including
as
its
representation,
a
description
of
how
the
group
works
and
is
configured.
F
So
it's
pretty
clear
that
the
the
administrator
responsible
for
the
group
management
acts
as
Ace
client.
Here,
the
group
manager
is
the
resource
server
and,
of
course,
we
have
an
authorization
server
responsible,
mostly
for
issuing
access.
Token
yeah.
F
This
View,
at
the
glance,
should
further
clarify
the
administrator
can
specifically
interact
with
the
group
collection
resource
in
the
first
place
to
to
retrieve
the
list
of
existing
Oscar
groups,
both
online
or
to
create
a
new
one
with
a
post,
and
when
that
happens,
that
results
in
creating
a
new
child
resource
for
the
corresponding
group
configuration
and
after
that,
that
group
configuration
resource
can
be
accessed
in
order
to
retrieve
the
configuration
of
the
group
all
together
or
selectively,
to
update
the
configuration
all
together
or
or
selectively,
or
to
delete
the
group
all
together
right.
F
The
last
version
was
presented
almost
one
year
ago
in
Vienna,
where
a
lot
of
feedback
and
good
comments
came
up
and
I
think
what
we
have
now
actually
addresses
all
those
comments
that
we
discussed
in
Vienna.
But
we
basically
have
two
more
versions
since
then,
one
for
the
July
cutoff
and
one
for
the
November
cutoff.
F
So
I'll
just
go
through
the
major
changes
that
happened
since
March
last
year,
foreign,
so
the
the
update
from
versions
five
to
version
six,
and
especially
what
in
this
slide,
has
been
the
major
update.
F
We
have
been
used
aif
for
a
while
also
in
this
document,
to
model
the
permissions
intended
for
administrators,
but
before
Vienna
last
year
we
used
to
have
a
separate,
dedicated
AF
data
model
defined
and
used
in
this
document,
and
especially
based
on
input
and
discussions.
We
had
we
Christian.
F
We
realized
that
it
is
actually
sufficient
to
have
one
single
AF
data
model,
which
is
already
defined
in
the
other
document
Oscar,
which
instead
focuses
on
on
the
group
members,
so
starting
from
from
that
data
model
defined
in
kicker
Commodore
in
the
interest
of
group
members
that,
as
a
model,
is
now
just
inherited
and
extended
in
this
document,
also
to
express,
as
as
we
mean
here,
permissions
for
administrators.
F
So
overall
we
still
have
a
scope,
encoding
information
with
aaf
in
terms
of
scope
entries
as
a
pair
of
identifier
and
permission
set.
Now
the
permission
set
hasn't
changed.
It's
really
about
using
Flags
to
indicate
what
an
administrator
can
do
on
a
certain
group
or
set
of
groups,
and
also
the
the
specific
operations
have
not
changed.
But
we
have
changed
the
to
ID
identifier.
It
used
to
be
a
Simple
Text
string,
indicating
a
group
name
pattern
now
following
again
suggestions,
especially
from
Christian.
Now
the
tid
can
be
three
different
things.
F
If
it's
a
simple
text
string,
it
indicates
exactly
one
group
name
as
a
literal
if
it's
the
simple
value.
True,
it's
a
wild
card,
so
whatever
name
Works,
but
since
we
still
want
to
enable
group
name
patterns
as
well.
You
can
do
that
by
tagging,
any
symbol
item
that
we
expect
to
tag
specifically
text
string
practically
and
with
the
tag
that
would
indicate
the
semantics
of
that
pattern.
For
example,
you
can
go
for
the
already
existing
tag,
indicating
that
you
are
expressing
a
pattern
using
a
regular
expression
so
to
recover.
F
Now
we
we
have
a
single
AF
data
model,
aligned
with
the
one
defined
in
keywords,
Com
or
score-
that
you
can
also
use
to
specify
permissions
for
administrators
and
there's
also
a
nice
side
thing
for
every
permission
expressed
for
administrators.
The
least
significant
bit
into
perm
is
always
one
while
for
scope,
entries
related
for
group
members
again
in
the
same
data
model,
the
least
significant
bit
in
the
perm
is
always
zero.
F
So
you
can
quickly
distinguish
the
two
different
types
of
scope
entries
by
means
of
that
bit,
which
means
that
you
can
issue
a
single
access
token,
granting
to
the
same
Ace
client,
of
course,
permissions
to
act
under
the
same
group
manager
as
administrators
for
some
group
and
as
group
member
for
for
others,
which
is
pretty
efficient.
F
Okay,
that
said,
we
had
to
revise
a
bit
some
details
in
the
interaction
between
the
parties
mostly
considered
what
I
issued
in
the
previous
slide,
and
we
also
considered
all
the
operations
exported
by
the
group
manager
for
administrator,
and
we
categorized
them
as
mandatory
as
optional
to
support,
and
this
is
in
the
same
exact
spirit
that
we
considered
from
comments
from
joran
I.
Think
on
previous
reviews
of
the
key
groups.
Come
at
your
documents
on
providing
this
categorization.
That
now
is
happening.
F
Here
too,
we
added
one
more
parameter
that
the
administrator
can
specify
when
creating
a
new
group
as
a
requesting.
The
group
manager
provided
that
the
group
manager
supports
this
all
together
to
perform
a
recycling
of
group,
identifiers,
Integrated,
Health,
School
Group,
which
is
an
optional
feature,
defining
Groupon
score.
And
finally,
we
used
to
have
a
quite
a
long
amount
of
text
in
the
document
body
describing
how
the
authorization
server
was
supposed
to
check
the
token
request
from
the
ace
client
against
related
access
policies.
In
case
a
group
name,
pattern
was
involved.
F
F
Okay-
and
that
was
around
July
after
that
one
more
revision
happened
and
there
the
major
update,
was
about
aligning
the
the
use
of
an
optional
feature
already
defined
in
the
key
group
com
document,
but
in
principle
available
for
any
application
or
profile
of
Ace.
F
It
is
now
possible
to
optionally
tag
the
scope
claim
in
an
access
token,
to
to
give
up
front
and
explicit
indication
to
the
resource
server
about
the
semantics
considered.
In
that
token,
and
we
used
to
do
that
in
in
a
certain
way
again
out
of
suggestions
from
from
Christian
that
changed
and
just
focusing
on
the
new
way.
Now
you
can
simply
tag
the
the
sieber
by
string
transport
in
the
scope,
with
the
tag
indicating
the
semantics
used
for
that
scope.
F
So
this
may
have
the
downside
of
impressible
opening
for
many
registration
of
civil
attacks,
but
there
should
be
plenty
of
available
space
for
that,
and
on
top
of
that,
thanks
to
the
work
done
in
the
file
magic
RFC
mentioned
here
often,
you
may
not
even
need
to
do
the
registration
explicitly
and
including
in
this
case
we
are
just
going
to
build
on
on
a
silver
tag
that
is
going
to
be
automatically
registered
out
of
the
registration
of
a
co-op
content
format
related
to
the
defined
AF
data
model.
F
We
also
Define
one
more
error
code
to
be
included
in
in
a
response
payload
from
the
group
manager
and
like
we
did
for
other
code,
we
gave
guidelines
for
the
administrators
on
how
to
react
in
case
that
error
comes
back
and
yeah
again
aligned
with
what
happened
in
the
previous
revision
for
operations.
We
considered
parameters
in
this
iteration,
classifying
those
as
mandatory
or
optional
to
support
again
following
feedback
from
joran
and
then,
of
course,
the
editorial
and
Diana
related
fixes
that
that
can
never
miss.
That
should
be
also
stable.
F
Now,
so
that's
where
we
are-
and
this
is
the
next
steps
I
can
imagine
and
a
roadmap
if
you
want
to
so
thinking.
F
Also
in
terms
of
priority,
we
have
in
mind
to
add
some
more
text
giving
guidelines
on
how
multiple
administrators
for
a
same
Oscar
group
can
coexist,
which
is
functionally
possible,
but
I
think
it's
worth
giving
some
more
guidelines,
for
example,
about
informing
primary
administrator
about
what
other
second
class
administrators
might
have
done
on
a
certain
lawsuit
group,
and
we
need
to
extend
the
security
consideration
that
right
now
are
really
limited
to
one
paragraph.
F
Only
if
we
move
forward
it's
about
points
related
to
to
Coral.
So
as
I
mentioned,
this
can
work
either
with
a
link
format
and
playing
C
board
or
with
coral.
Instead,
with
reference
to
the
coral
part,
I
found
a
few
things
that
required
to
be
clarified
a
bit
better.
F
Also,
in
the
examples
are
a
bit
too
tears
and
I'd
really
like
now
to
convert
all
the
examples
we
give
for
Coral
to
use,
not
the
obsolete
textual
notation
like
they
do
right
now,
but
rather
the
expected
notation
with
the
additional
use
of
a
packed
Seaboard.
That
should
really
be
the
norm
now.
I
think
so,
as
I
mentioned,
I
I
plan,
I
hope
for
for
the
cutoff
to
be
able
to
address
points
one
and
two
fully
and
points
three
and
four
as
much
as
I
can.
F
But
then
there
is
point
five
that
I
wanted
to
start
to
race
today
and
I
hope
we
can
reach
consensus
about
that
at
the
next
ITF
meeting.
It's
something
I
I
mentioned
in
the
past
to
Daniel
already.
F
F
F
Where
document
one
would
be
what
we
have
today,
after
removing
all
the
parts
related
to
Coral
and
that's
the
document
that
we
can
finalize
during
this
year
and
ship
document
2
instead
would
be
a
new
awfully
working
group
document
from
the
start,
as
the
result
of
the
split,
including
the
pulse
related
to
Coral
and,
of
course,
building
a
sort
of
a
textual
framework
around
it,
so
that
it's
a
readable
document
that,
in
due
time,
would
probably
update
this
document
as
an
RFC.
F
We
can
put
document
to
in
a
freezer
and
resurrect
it
when
Coral
is
done
or
cause
to
be
done.
So
we
don't
need
to
take
a
decision
now
I
believe,
but
I
just
wanted
to
start
raising
this,
with
the
hope
that
we
can
take
a
decision
in
the
March
meeting.
But
of
course
any
feedback
anytime
is
welcome,
and
this
is
my
last
slide.
I
think
thank
you.
C
I
think
it's.
We
should
take
a
decision
as
early
as
possible,
so
I'm
wondering
if
I
I
thought
we
we
already
took
a
decision.
So
no.
F
C
C
So
I
suspect
we
will
have
to
to
have
an
email
on
that,
especially
the
the
thing
I
I
was
a
little
bit
worried
is
that
if,
in
two
years
you
come
with
a
document,
we
need
to
be
able
to
to
show
some
evidence
that
we
or
we
agreed
that
a
coral
specific
document
needs
to
be
adopted.
So
is
there
anyone
thinking
that
we
should
do
otherwise?
C
So
the
current
question
is
with
that
document:
does
that?
Does
it
sound
reasonable
to
everyone
that
we
do
not
provide
examples
in
Coral,
but
we
stay
with
what
we
have
and
then,
when
Coral
is
stabilized,
we
do
update.
We
do
a
maybe
a
beats
document
or
something
with
a
coral,
or
should
we
wait
for
coral
and
we
don't
have
any
idea
on
when
curl
is
going
to
be
finalized,
so
any
anyone
has
any
strong
feelings.
G
Are
you
around
here,
I
think
this
is
a
this
is
straightforward
and
I
I.
Don't
have
any
any
objection
here.
So
so,
please
split
out
the
coral
related
parts
for
now
and
I.
Don't
have
a
strong
opinion.
How
how
we
handled
that
when
it
when
Coral
is
available
so
but
I
think
the
important
thing
is
that
we
progress
this.
F
Yeah
Daniel
I
I
was
explicitly
proposing
a
document
too
to
be
submitted
and
put
in
the
freezer
just
to
have
it
as
a
placeholder
to
not
forget
about
this
and
bring
it
up
again
and
progress
it
in
due
time.
C
Yeah,
okay,
so
I
I
think
I
am
going
to
to
send
an
email
saying
this
is
a
we
decided
to
split
that
document,
and
and
and
can
you
send
the
document
for
that
as
early
as
possible?
So
we
can
I
mean
maybe
today
so
that
we
can
combine
the
call
for
adoption
with
that
one
or.
F
The
the
split
is
not
at
all
straightforward.
That's.
F
In
mind
intentionally,
the
coral
parts
now
are
really
Blended.
Okay,.
F
I
I
wanted
to
address
points
3M
for
anyway,
it
will
benefit
for
the
future,
but
then
it
will
take
some
effort
to
do
a
split
in
a
clean
way.
So
that's
why
I.
F
D
C
F
C
Yeah
yeah
yeah,
no
I
I
mean
that's,
but
just
so
so
so
we
have
a
something
that
we
can
reference
in
the
in
a
later
discussion,
probably
probably
when
it's
going
to
be
called
for
adoption
or
revived.
You
know
you
never
know.
F
On
this
other
detail,
you
also
mentioned
before,
of
course,
it's
up
to
you
and
log
on
to
decide
if
we
have
to
go
through
a
separate
adoption
call.
What
I
saw
as
presidents
in
other
working
groups
is
that
if
it's
about
splitting
some,
especially
very
Advanced
working
group
document,
the
resulting
new
document
is
submitted
from
the
start
as
a
working
group
document.
F
A
C
Yeah
I
I
mean
for
more
transparency,
I
think
I
mean,
of
course,
anyone
opposing
to
that
needs
to
have
strong
arguments,
but
yeah
it's
more
to
to
give
a
period
for
anyone
saying
its
opinion.
So
I
don't
want
that
to
I
I
I
I
I.
Don't
see
that
as
a
huge
constraint
and
I
think
we
I
I,
I,
I
I.
Think
two
weeks
is
fine
and
everyone
is
going
to
be
aware
of
of
what
we're
doing
it's
more
to.
C
D
C
Yeah
yeah,
no,
no!
No,
but
that's
that's
fine
I
mean.
C
I'm
I'm
hearing
nuns,
so
maybe
we
can
move
to
key
group
come
Oscar
now
Israel.
C
F
A
G
A
Latest
Monday
next
week,
so
in
one
week's
time.
C
Okay,
so
that's
good
I
mean
I
mean
Paul
was
suggesting
to
have
some
another
quote
for
adoption,
for
the
two
documents,
I
I
think
I
mean
I
had
the
impression
that
very
few
people
were
thinking
it.
C
It
was
a
good
idea,
but
I
don't
know
if
Paul
has
changed
his
mind
so
we'll
we
will
have
to
check
that,
but
has
anyone
anything
to
say
regarding
that
that
we
should
carry
to
Paul
or
is
anyone
thinking
it's
a
good
idea,
or
it
is
something
we
should
do.
F
Yeah
I
I,
don't
remember
Paul
asking
for
that
in
the
mail
exchange
you
started
with
him
Daniel
you
mentioned
the
need
or
not
need
for
a
working
group
plus
call
actually
and
yeah.
That
came
as
a
surprise
to
me.
I
I,
don't
know
if
that's
needed,
I,
don't
think
so.
C
Yeah
same
for
me,
so,
okay,
so
well,
I
mean
what
I
have
in
mind.
Is
that
once
we
ship
that
to
Paul
he's
going
to
maybe
maybe
trigger
a
last
call
for
both
of
the
documents
and
then
those
documents
I
do
not
need
any
actions
within
the
working
group.
That's
my
that's.
How
I
think,
but
we'll
see
how
it
goes
so,
yeah
Ricard!
As
soon
as
we
get
it,
we
probably
have
more
information
on
what's
poorly
thinking,
yep,
and
that
would
be
good.
C
So
so
as
soon
as
we
have,
we
can
ship
that
to
Paul
and
get
get
his
reactions.
Yep.
F
From
my
side,
as
soon
as
I
get
the
the
review
from
record,
I
can
yeah
take
it
into
account
for
an
extra
Vision
that
is
already
incorporating
in
the
editor
scorpion
GitHub
sounds
more
fixes,
so
I
I
suppose
we
ship
the
the
upcoming
next
revision.
E
C
Yeah
sure,
but
Rico
did
you
find
anything
that
needs
to
be
I
mean
strong
things
that
need
to
be.
That
makes
the
revision
being
a
no.
A
That,
well,
nothing
I,
don't
have
the
well
I
found
some
I.
Don't
have
the
the
I
didn't
prepare
any
like
stuff
for
this
meeting,
but
I
like
if
you
ask
anything,
maybe
or
no
it's
nothing.
That
would
like
mean
a
some
kind
of
significant
large
amount
of
work
for
revision
that
I
that
I
would
see.
You
know,
okay,.
C
So
that's
great
so
Marco
I
think
when,
when
we
have
this
Shepherd
I
mean
it's
try
to
address
those
as
soon
as
possible
so
that
we
can
ship
that
to
Paul
I'd
like
to
have
that
by
the
end
of
the
month.
So
that
I
mean
you
don't
get
overload
with
the
next
ITF
and
that
if
there
is
anything
that
that
can
be
discussed,
we
can
use
I
mean
the
the
time
before
the
ITF
and
then
eventually
have
a
meeting
a
discussion
during
the
ITF.
C
Maybe
so
so
that's
a
that's!
How
I
see
things.
C
Okay,
go
ahead
next
presentation,
garon.
C
Okay,
now
I
see
your
Grand
screen
so
I'm
going
to
provide
you
the
screen
right.
G
Can
you
see
the
slides,
yep
yep?
Okay,
so
this
I
I
asked
to
to
give
some
some
input
here.
Ask
for
some
input
here,
because
this
there's
been
some
commands
and
we
have
started
to
think
about
the
next
Updates
this.
There
is
no
change
since,
since
this
was
adopted,
this
is
still
the
zero
zero
profile
of
the
ad
hook
postcode
profile.
G
G
G
Apologies
I
a
little
bit
confused
here.
We
are
again
so
here
is
a
simplified
sketch
of
of
the
state
diagram,
and
so,
if
you
need
as
a
client
here,
you
need
new
access
right,
starting
at
the
top,
then
you
would
client
would
contact
the
as
the
authorization
server
with
post
slash
token
and
get
back
some
access
related
information
from
the
As,
and
this
is
a
vague
formulation
because
we
are
not
we're
meeting
token
provisioning
in
this
figure
here.
G
So
the
token
can
reach
the
the
client
and
the
RS
in
different
ways,
and
if,
if
this
is
the
first
time
so
there
is
no
Oscar
called
context
valid
or
no
ethoc
session
Valley,
then
you
would
go
straight
ahead
and
run
ad
hoc,
which
is
the
bottom
box
here
in
the
middle,
and
then
you
would
derive
the
Oscar
context
and
that's
a
I
mean
this
procedure.
We
could
of
course
apply
all
the
time,
but
it's
not
very
optimal,
because
then
you
would
need
to
run
ad
hoc
more
than
necessary.
G
So,
for
example,
if
you
have
now
an
established
ad
hoc
Oscar
context
with
an
Associated
access
token,
and
you
want
to
update
the
access
right,
so
you
start
again
from
the
top
here
and
you
get
to
know
new
access,
token
or
access
related
info,
and
it's
then
there
is
a
valid,
all
score
context.
G
Well,
then,
you
can
basically
go
to
the
right
there
to
the
the
upper
right
blue
box,
where
you
just
post
the
that
token
using
unprotected
good
old
school
and
you're
done
or
the
case
that
Oscar
context
is
not
valid,
but
the
adult
session
is
valid.
Then
you
can
run
a
procedure
which
is
similar
to
to
the
core
the
old
score
profile,
where
you
include
the
token
and
a
couple
of
nonsense
and
you
use
the
other
key
update
with
those
nonsense
and
derive
yourself
context.
G
So
that's
one
that's
so
this
I
mean
this
in
this.
The
general
question
here
is
basically
or
these
options.
Are
it's
fine
to
have
this
this
set
of
options
here,
or
should
we
go
for
even
simpler
state
diagram,
and
this
is
again
already
simplified
as
it
is.
So
that's
that's
an
open
question
for
for
the
working
group
and
we
come
back
to
some
comments
from
Christian
in
the
next
slide.
G
That's
the
final
comment
here
is
that
if,
if
you
need
a
new
oscore
security
context
now
now
on
the
left
side,
then
if
you
had
Kudos
implemented,
then
you
could
just
run
that
and
that's
completely
independent
of
of
the
the
access
token
really.
So
that's
an
alternative
flow
as
well,
and
if
you
don't
have
Kudos
available,
then
you
would
need
to
to
either
use
Ado
key
update
or
rerun
yeah.
G
Okay,
so
then
we
had
some
comments
from
Christian
along
these
lines,
so,
for
example,
the
when
we
do
the
token
provisioning
so
that
we
have
two
options
for
this.
We
have
the
post
authorization
info,
which
is
the
client
in
a
separate
flow
client
and
rs,
or
we
can
use
the
external
authorization
data
of
ad
hoc,
which
means
it's
in
line
with
with
analog.
This
is
similar
to
the
dtls
profile
that
there
are
two
different
flows
for
token
provisioning,
so
I
think
that.
G
G
If
it's,
if
we
have
support
in
the
RS
for
post,
slash
authorization
info
well,
then
we
for
updated
rights.
Well
then,
we
might
as
well
use
it
for
initial
rights.
G
Another
comment
on
the
same
line
is:
if
we
need
a
to
have
multiple
ways
of
running
adult
and
oscore.
So
you
know
there
is
this
independent
flows
where
you
first
run
ad
hook,
then
all
score
or
there
is
this
combined
request
where
you
include
ad
hoc
message,
3
and
Osco
request.
Well
adult
message:
3
within
the
Osco
request
and
the
question
is:
can
we
use
that
all
the
time
do
we
need
to
have
these?
G
These
double
close
these
alternatives-
and
my
answer
here
is
I-
haven't
really
confirmed
this
with
everyone
so
but
I
think
this
is.
The
answer
is
no
here
we
could.
G
Oh,
it
says,
exclude
this
option,
that's
not
very
well
formulated
it.
We
could
just
settle
for
the
combined
request,
for
example,
to
have
that
as
the
the
only
option
and
any
comment
on
that.
G
So
if,
in
terms
of
examples,
there
is
in
the
at
the
end
in
the
appendices
of
the
draft,
there
are
examples
of
doing
either
the
combined
request
or
or
doing
the
separate.
So
those
are
spelled
out
in
detail
and
the
question
is:
do
we
really
need
two
votes,
or
can
we
say
that?
Can
we
recommend
one
or
should
we
mandate
one.
F
Marco
here,
I
was
raising
my
hand.
It
probably
depends
on
on
the
resource
servers
supporting
the
combined
request
in
the
first
place.
So
if
there
is
no
support,
it's
really
way
better
to
go
for
it,
and
it
should
happen
that
way.
F
G
F
G
Yep,
so
that
that's
a
good
good,
summary
and
I
wonder
what
we
actually
go
for
here.
What
what
is
preferred
here
is
it
that
we
have
the
different
options:
I,
I'm,
just
I'm,
just
afraid
and
I-
think
that's
sort
of
Christian's
comments
here
that
we
we
get
too
many
options.
Maybe
it's
better
to
require
more
I
mean
this
is
not
requiring
more
in
terms
of
in
terms
of
Power
of
the
of
the
device.
It's
not
it's
not
requiring
additional
computational
power
or
processing
power
or
or
battery
power.
G
Okay,
so
if
there
are
any
more
comments
that
later
after
this
meeting,
that's
very
welcome
otherwise
I
think
we
will.
As
authors
will
we
will
come
with
the
proposal
for
the
next
meeting
and
the
second
third
comment
here
and
also
along
the
same
line,
was
the
negotiation
of
there?
Are
certain
parameters
being
negotiated
foreign
and
that's
that's
also
flexible
flexibility
which
we
can
have
or
we
can
take
out
in
the
in
the
in
the
interest
of
making
the
protocol
simpler
and.
D
G
F
Just
looking
for
the
onions
button
yeah
and
it's
not
fully
a
negotiation,
that
information
comes
from
the
authorization
server
and
is
given
to
to
the
ace
client
based
on
a
better
early
knowledge
that
the
authorization
server
has
of
the
resource
server
and
then
the
client
would
just
stick
to
that
as
learned
from
the
authorization
server
while
the
resource
server
knows
already.
B
F
G
F
G
G
Okay,
so
we've
raised
these
questions
now
and
in
the
absence
of
other
input
we
will.
We
will
try
to
make
a
voice
proposal
here
going
forward.
G
Then
we
have
some
some
new
features
for
which
is
relevant
not
only
for
the
adult
profile,
but
it's
some
of
them
are
included
in
the
other
profile
and
I'd
like
to
mention
them
and
and
ask
for
what
people
think
if
we
should
just
keep
them
in
the
adult
profile
or
make
them
generally
available.
G
So
one
is
the
alternative
flow
for
Access
token
provisioning.
So,
instead
of
the
client
uploading
the
access
token,
there
has
been
a
request
to
allow
the
authorization
server
to
upload
it
to
the
to
the
resource
server.
So
this
is
the
post,
slash
authorization
info
and
that's
an
unprotected
request.
So
it
really
doesn't
matter
from
the
RS
point
of
view
where
it
comes
from,
because
it
will
anyway
need
to
handle
the
denial
of
service
aspects
and
verify
the
access
token.
G
So
this
is
described
in
the
other
profile,
but
maybe
generalized
to
the
ace
frame
and
that's
something
that
we
might
want
to
split
out
of
the
document.
If,
if
that's,
we
I
think
that
from
the
author's
side,
we
think
this
is
a
good
idea,
because
it
certainly
makes
sense
in
other
profiles
as
well,
but
we're
happy
to
get
input
on
that
now
or
later
any
spontaneous
input
here.
G
G
But
as
we
see,
there
is
also
for,
for
various
good
reasons,
the
use
of
certificates
in
in
iot
deployments,
and
that
is
something
that
we
include
now
in
the
adoc
profile.
But
it's
not
included
in
the
details
and
TLS
profiles.
G
So
that's
something
we
may
want
to
generalize
as
well,
and
then
we
have
a
third
type
of
generalization
or
a
general
property,
which
is
a
request
from
from
a
partner
to
use
the
to
use
an
access
code
token
for
multiple
devices,
so
for
multiple
orises
I
should
say
so.
If
you
request
an
act,
you
want
to
be
able
to
check
out
an
access
token
and
use
that
in
say
you
have
a
number
of
identical
devices
that
you
you
want
to
access
and
you
don't
want
to
have
an
access
token
for
each
of
those
devices.
G
So
what
we'd
like
to
do
is
to
introduce
a
new
claim
to
allow
multiple
viruses
and
that
there
are
different
variants
of
that
either
we
we
use,
we
Define
a
new
one,
say
RSC
and
F2,
and
you
claim
which
contains
multiple
public
keys
or
we
could
have
another
setting
where
we
Define
a
a
trusted
issuer
of
credentials.
G
G
So
that's
that's
an
option
which
is
not
yet
described
anywhere.
It's
applicable
to
all
the
profiles
which
are
using
asymmetric
keys,
and
one
option
is
that
we
just
included
in
the
adult
profile
for
the
time
being
or
that
we
make
it
separate
draft.
G
G
G
Yes,
that
that's
I
mean
yes,
that's
a
consideration,
and
they
I
mean
you.
You
would
know,
since
this
is
asymmetric,
so
you
would
do
you
would
still
do
individual
authentication
of
each
smoke
detector.
So
so
you
would
be
able
to
see
if
I'm
talking
to
single
or
if
I'm
talking
to
multiple
and
you
would
be
able
to
identify
those
and
to
make
a
record
out
these
are
the
updated
smoke
detectors.
G
G
B
We're
adding
adding
indirection
may
make
sense,
but
yeah
I
think
you
do
have
to
come
up
with
a
use
case
where
this
actually
makes
sense
to
to
explain
this.
But.
G
No,
this
is
not
better,
but
this
is
about
the
information
that's
provided
from
the
as
so
the
AES.
So
there
are.
There
are
three
options
here:
the
a
either
the
as
is
issuing
one
token
per
smoke.
Detector
right,
that's
option
one.
The
second
option
is
that
it
issues
one
single
token
and
then
the
RS
info,
the
information
about
the
RS,
contains
a
list
of
each
and
every
public
key
of
the
RSS
and
then
the
third
option.
G
There
is
a
single
access
token
and
the
single
key
is
the
key
of
the
trusted
issuers,
and
then
you
don't
need
to
to
know
each
and
every
one.
You
need
to
just
trust
that
the
issue
has
issued
certificates
only
to
those
smoke
detectors
or
with
some
other
provisioning,
some
other
attribute.
So
you
can
be
sure
that
this
is
a
relevant
smoke
detector.
For
me
to
configure.
B
G
Yes,
so
let's
say
it's
the
manufacturer
that
has
issued
a
credential,
so
there's
a
public
key
certificate
of
which
is
signed
by
the
manufacturer,
and
that
is
that
is
the
so.
The
manufacture,
public,
ca,
key
included
in.
G
G
Yeah,
thank
you
so
yeah.
Let
me
give
you
a
better
example.
It's
basically,
let's
say
that
the
operator
that
you
have
he
issued
local
certificates
for
for
each
device
by
a
certain
CA,
and
then
you
might
have
also
have
when
you
do
that
you
have
some
in
that
certificate.
There
is
some
some
property
that
makes
you
identify
this
class
of
devices.
G
Then
then
you
would
have
control,
over
of
which,
which
are
are
allowed
to
to
be
updated,
but
I
think
I
think
you
have
a
good
question
there
mccarstan
this
needs
to
be
clarified.
Indeed,
I
think
that
the
first
two
cases
are
probably
straightforward.
The
third
one
was
a
little
bit
short
from
the
hip
when
I
made
the
slides,
I
need
to
think
a
little
bit
more
or
or
we
all,
but
then
come
since
you
were
bold
enough
to
make
a
question.
G
B
F
G
F
And
before
you,
you
touch
certificates,
a
lot
about
indicating
the
identity
of
a
specific
resource
server,
but
in
if
you
want
to
use
what
we
use
today.
Yes,
because
it
is
I,
don't
think
you
have
a
common
quality
parameter
to
indicate
the
identity
of
the
other
side.
So
probably
we
would
need
to
look
into
how
to
extend
that
too.
B
G
A
A
G
A
Subscribe
yeah
new
feature
phrase
and
then
describe
how
it
impacts.
The
individual
profiles
could
be
a
start
at
least
yep.
G
Okay,
yeah,
that's
that's
it
from
my
side.
We
need
to
resolve
the
comments
that
we
we
raised
here,
we're
going
from
and
from
Christian
and.
A
G
Are
strongly
considering
how
to
reduce
the
the
different
Alternatives
in
in
the
addo
Costco
profile,
we'd
like
to
have
a
new
version
ready
before
the
Oklahoma
meeting
and
more
comments
are,
of
course
welcome.
C
Okay,
so
I
think
we've
reached
the
end
of
the
meeting,
so
I
think
the
mitching
is
a
drone
and
see
you
next
meeting.