►
From YouTube: IETF109-ACE-20201118-0500
Description
ACE meeting session at IETF109
2020/11/18 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
Hi
everyone
can
you
hear
me
well.
A
Okay,
good,
so
I
suppose
you,
you
see
the
screens
pretty
well
and
it
looks
weird
well.
It
looks
like
you're.
We
are
now
in
the
eighth
session
for
the
itf
109,
so
I
propose
we
start.
A
So
in
case
you
have
never
seen
the
not
wells.
Please
note
that
this
meeting
is
under
the
note.
Well,
so
take
the
time
to
read
those,
and
if
you
have
any
questions,
please
feel
free
to
contact
me
or
any
other
person.
A
Before
we
start
this
meeting,
I
would
like
I
mean
you,
you
notice
that
I
have
the
only
chair
now
opening
this
meeting
and
I
would
like
that.
We
we
for
at
least
one
minute.
We
we
just
think
a
little
bit
of
jim
shot
that
passed
away
recently
and
leave
us.
C
Thank
you
danielle,
and
it's
indeed
quite
a
loss
to
us
all
to
lost
jim
jim,
really
was
quite
an
exceptional
individual,
and
that
extends,
of
course,
to
the
breadth
of
his
enrollment
in
the
itf.
C
He's
been
involved
in
quite
a
lot
of
things
and
of
course
he
predates
me.
I've
only
been
in
the
itf
for
about
eight
years
and
when
I
came
in,
he
was
already
an
old
hand,
but
he
was
definitely
always
willing
to
offer
advice
even
to
young
fresh
faces
like
I
was
at
the
time
I
do
know
his
hands
were
on
many
of
the
foundational
rfcs
for
things
like
cms
or
some
of
the
crypto
algorithms,
and
I
came
to
rely
on
him
for
for
pique's
questions.
C
I
did
get
to
work
with
him
pretty
closely
during
my
own
time
as
co-chair
of
ace,
and
he
was
sort
of
a
mentor
to
me
during
that
time.
C
C
I'm
still
not
sure
I
got
a
full
view
of
what
he
did
for
the
itf,
because
I'm
sure
there
are
things
that
he
did
that
I
don't
know
about,
but
I
can
definitely
say
that
his
his
efforts
were
not
limited
to
just
the
security
area.
They
were
not
limited
to
a
class
of
technology.
He
really
was
quite
well-rounded.
C
C
He
was
just
so
incredibly
selfless
and
generous
in
his
time
and
his
expertise.
I
certainly
relied
on
him
for
many
things.
I
know
others
did
as
well,
and
you
know
it's
sort
of
strange
to
think
that
he
was
just
so
selfless
and
so
helpful
that
the
only
time
that
he
really
felt
the
need
to
say
no,
I
can't
help
you
right
now
was
actually
at
the
winery
during
the
pressing
season.
C
It
was
just
too
busy
at
the
winery,
so
he
couldn't
do
with
the
itf
stuff,
but
when
that
season
was
over,
of
course,
he
was
back
to
being
our
gym
and
helping
us
out
and
getting
things
into
place.
So
I
can
say
I
will
listen
very
much.
I
know
that
we
all
will
thank
you,
jim.
A
Okay,
I
propose
that,
for
we
we
have,
we
observe
one
minute
of
silence
and
then
we
will
start
this
meeting.
A
A
You
so
let's
move
to
the
agenda,
we
probably
need
a
mini
ticker.
A
I
can
try
to
do
the
javascript
while
presenting
we.
Don't
you
don't
need
to
sign
the
blue
sheets,
but
do
do
we
have
a
minute
taker.
A
A
It
would
be
good
we
we
have
someone,
volunteering
for
taking
the
minutes.
A
A
Okay,
thank
you,
girl,
I'm
just
putting
the
link
to
the
minutes
so
so
yeah.
So
we
have
a
few
drafts
to
be
presented
that
are
working
progress
that
you
know
presented.
A
We
have
the
charter
to
be
discussed
and
we
also
have
new
topics
and
before
we
start
the
presentation,
I'd
like
to
do
a
little
bit
of
status
regarding
the
the
current
drafts,
so
we
have
still
one
draft,
which
is
the
ace
co-op
east
that
is
in
the
rfc,
editor
queue.
There
is
a
missing
reference.
A
If
I
remember
correctly,
that's
the
dtls
1.3,
but
it's
soon
to
be
published
this
one.
So
I
think
we
are.
I
mean
this
one
is
I
mean
this
draft
is
going
to
be
published
quite
soon.
A
Would
say
we
also
have
a
few
bunch
of
documents
waiting
for
ifg
approval
to
be
sent
to
the
rfc
editor
one,
which
is
the
dhl,
is
authorized.
I
I
believe
this
one
is,
is
pretty
much
ready
to
be
sent.
We
had
just
a
yesterday
or
today,
depending
on
time
zone.
The
last
version
of
oauth
earth
drafts
that
addressed
all
the
comments
we've
received.
It
was
in
working
with
last
call
and
we
have
also
the
oauth
param
that
is
being
waiting
for
some
time.
A
Also
to
me,
all
those
drafts
seems
ready
and
we
have
the
last
one
that
needs
to
be
complete
is
the
os
gopro
5
that
has
just
been
updated.
A
There
is
a
working
group
last
call
on
it,
but
as
far
as
I
know,
I
haven't
seen
any
reviews
for
now,
so
it
would
be
really
appreciated
that
we
got
reviews
to
avoid
the
draft
to
be
moved
forward
and
then
be
called
back
for
subsequent
changes.
A
So
I
am
encouraging
encouraging
the
co-author
and
additional
persons
to
review
this
draft
before
we
can
submit
it
to
the
ahd.
We
are
waiting
for
the
security
direct
review,
so
we
expect
at
least
one
review,
but
we
would
like
more
anyone
planning
to
review
that
document.
A
E
And
also
hi
francesca.
I
just
wanted
to
say
that
looking
at
the
diff
for
whoever
has
already
reviewed
it
should
be
enough,
but
diff
is
not
huge.
So
the
review
shouldn't
take
long.
A
Time
yeah,
so
the
diff
is
is
is
one
thing,
but
it
would
be
good
that
we
can
ensure
the
the
document
is
current
and
all
that,
so
I
would
not
discourage
anyone
to
review
the
full
document.
A
Okay,
so
I
think
yeah,
and
so
we
also
have
documents
in
progress.
So
I
want
is
the
aif,
so
I
don't
know
if
casten
wants
to
say
a
few
words
on
this.
A
C
A
Okay,
so
captain
as
soon
as
it's
fixed,
please
show
up.
A
So
we
have
the
group
com
drafts
that
are
going
to
be
presented
and
we
also
have
the
pub
subs.
So
we
have
the
mqtt
tls
profile,
so
I
am
not
sure
sign
them
is
attending
the
meeting.
A
But
so
I
don't
see
her.
A
So
if
she's-
not
here,
I
can't
I
can't
do
the
the
statutes
of
that
document.
We
had
a
working
group
last
goal,
all
comments
have
been
addressed
and
what
remains
to
be
addressed
is
really
to
look
at
the
needs.
A
There
are
some
versions
of
draft
that
raise
some
warnings
and
basically
the
there
are
some
informative
documents
in
the
normative
section.
So
it's
it's
really
really
ready
to
be
sent
to
the
asg.
A
F
I
don't
see
you
so
there
are
error
messages
coming
from
mute
echo
which
are
going
away
before
you
have
a
chance
to
read
them,
so
you
have
no
idea
what's
going
on
anyway,
so
aaf
essentially
has
been
stable
for
for
half
a
decade
until
we
recently
added
the
the
idea
of
inheritance
to
it.
F
So
I
think
people
haven't
really
looked
at
inheritance,
a
lot
and
maybe
people
haven't
implemented
inheritance
yet
in
the
various
protocols.
So
I
think
it
would
be
useful
to
get
some
feedback
about
that.
Of
course,
we
can
finish
this
draft
without
inheritance,
but
it
sounded
like,
like
a
good
way
to
solve
various
problems
that
we
were
having
with
post
actions.
A
So
basically,
your
comment
is
that
you're,
looking
for
for
review
of
the
current
version
of
the
document,
okay,.
E
So
that
has
gone
to
yeah.
I
have
been
prioritizing
the
oscar
profile
and
the
and
and
the
ac
group
com
stuff,
which
is
why
it
hasn't
been
update,
updated,
but
it's
still
missing
sections
in
the
document
about
mqtt.
So
that's
why
that
that's
what's
missing
right
now,
though?
E
A
Okay,
okay,
good,
so
I
propose
that
we
start
the
presentation,
maybe
francesca
we
may
start
with
the
group
communication.
I
think
that
I
think
that's
the
first
one.
E
E
E
For
a
group
member
to
join
a
group
and
it
uses
the
ace
framework
in
the
first
part
of
the
exchange,
documentation,
request,
response
and
a
token
post,
and
then
it
defines
other
operations
between
the
client
and
the
kdc,
which
means
key
distribution
center
to
join
the
group.
So
in
this
in
this
figure,
it's
only
about
the
group
joining
request,
a
response,
but
there
is
more
operations
that
are
defined
yes
and
after
that
the
the
client
can
do
secure
group
communication.
E
E
Since
itf
108,
a
lot
has
happened.
We
have
submitted
version
nine
based
on
a
follow-up
review
from
jim,
which
we
discussed
at
itf
on
108
and
close
24
issues.
If
I'm
not
wrong
and
then
also
christian
gave
us
a
review.
Thank
you
for
that
christian
and
we
have
vanapu
requested
to
be
the
next
version
version
10,
based
on
that,
based
on
that
review,
and
you
can
see
the
details
in
the
github
next
slide.
Please.
E
E
We
try
to
remove
as
much
as
possible
text
that
was
duplicated
from
either
the
ace
framework
or
from
other
sections
of
the
document,
and
then
there
was
some
minor
changes
with
or
yeah
modify
the
error
code.
If
a
client
is
not
a
member
of
the
group
and
is
trying
to
access
resources
that
are
dedicated
members
from
four
zero
zero,
that
quest.
E
Bunch
of
clarifications
that
we
made
so
today
I
want
to
talk
about
one
issue
next
slide.
Thank
you,
one
issue
that
is
about
the
scope
encoding,
and
this
came
from
a
comment
from
christian
again,
thank
you,
and
while
we
were
talking
about
this,
we
realized.
E
So
the
client
sends
a
post
token
to
the
kdc
and
the
scope
is
encoded.
E
The
scope,
in
the
token,
is
encoded
as
a
sieber,
byte
string,
and
the
question
is:
how
does
the
kdc
know
what
what
is
the
actual
format
of
scope
because,
for
example,
in
our
ascii
group
com
document,
it's
a
siebel
byte
string,
but
it's
actually
cbr
array,
wrapped
in
a
seaboard
by
stream.
E
E
Dealing
two
or
three
possible
solutions,
so
the
first
solution
is
to
solve
this
locally,
so
to
prefix
the
scope
with
a
byte,
and
this
byte
will
indicate
which
application
profile
of
ace
is
being
used
and
to
make
this
effective.
This
needs
to
be
agreed,
of
course,
between
a
resource,
server
and
authorization
server,
and
if
the
same
scope
is
reused
for
several
resource
servers,
they
need
to
sync
this.
This
value
of
this
byte
for
like
for
each
application
profile
with
the
authorization
server.
E
This
has
the
drawback
that
the
this
will
be
longer:
prefix,
local
or
locally
agreed
prefix,
maybe
only
one
byte.
It
depends
on
how
big
of
a
seaboard
tag
we
would
go
for
so
for
now
we
only
can
see
that
we
would
register
a
keyboard
tag
for
only
for
the
ask
group
oscar
profile,
because
this
is
not
the
only
application
profile
we
have
and
but
later
on,
we
would
have
one
for
each
application
profile.
Encoding
and
the
question
is:
is:
is
it
too
much
to
have
one
keyboard
tag
for
each
application
profile?
E
E
E
I
wanted
to
point
out
that
these
solutions
are
not
in
they
could
be
used
in
parallel,
so
we
could
describe
both
in
our
document,
so
we
could
reach
the
tag
and,
at
the
same
time
describing
appendix
how
either
a
prefix
or
a
tag
could
be
used
and
then,
depending
on
the
applications,
the
the
implementer
might
want
to
use
one
or
the
other,
but
it
would
give
them
the
opportunity
to
to
choose
so
I
I
don't
know
if
this
was
clear.
A
E
In
some
cases
you
might
not
need
to
to
to
even
indicate
encoding
of
a
scope,
because
you
already
know
you're
only
using
that
at
that
type
of
yeah,
but
I'm
asking
the
working
group
to
give
if
they
have
an
idea,
an
opinion.
F
F
Yeah,
I
I
don't
think
I
understand
the
problem
yet,
but
there
is
a
word
on
this
slide.
That
makes
me
nervous
at
least
the
first
time
it
occurs.
It's
about
same
so
how?
F
How
do
the
various
parties
find
out
that
that
some
scope
is
the
same?
I
think
this
is
the
whole
problem
we
are
talking
about
and
well,
if,
if
you
negotiate
a
namespace,
you
essentially
need
to
have
had
a
namespace
in
place
already
to
enable
that
negotiation
right.
F
E
F
E
E
E
E
C
Yeah
just
to
jump
in
in
the
audio,
this
is
ben
kadek
again,
so
my
understanding
is
that
the
sort
of
knowing
what
the
email
and
offline
access
and
what
not
mean
that's,
definitely
out
of
scope
for
for
this
document,
and
certainly
in
the
oauth
world,
you
just
have
like
an
out
of
band
agreement
as
to
what
those
mean
and
so
we're
talking
about
the
other
one.
E
Well,
that's
the
thing
in
the
ace
world,
you
kind
of.
E
E
C
So
I'm
not
sure
if
this
is
exactly
the
question
that
kirsten
was
trying
to
raise.
But
you
know
when
you're
in
the
scenario
where
you
have
some
things
that
are
already
agreed
to
out
of
band
and
then
you're
talking
about.
Do,
I
need
to
add
a
inbound
mechanism
to
disambiguate
something
else
you
have
to
ask
yourself.
C
Is
this
something
else
that
I'm
trying
to
disambiguate
something
that
could
be
agreed
out
of
band
as
well,
because
I
already
have
this
out-of-band
mechanism
and
my
understanding
is
that
the
answer
is
no,
that
we
do
need
an
inband
mechanism
here,
because
the
sort
of
knowing
what
email
means
that
we
say
is
is
out
of
band.
That's
like
a
universal
constant
in
some
sense,
and
the
particular
encoding
used
by
the
different
profiles
is
something
that
can
change
and
you
won't
know
a
priori.
C
E
Yeah
and
daniel,
if
you
could
go
back
one
slide
just
to
go
on
the
slide
on
the
issue
itself,
rather
than
the
solution.
Yeah
that
that's
the.
What
you
said
then,
is
that
this
happens
when
the
client
send
the
post
token
and
the
the
kdc
or
resource
doesn't
have
other
information
about
what
application
profile.
E
Yeah,
but
I
don't
know
if
anybody
else
or
so
we
talked
about
this
in
a
side
meeting
with
christine
and
marco.
I
don't
know
if
they
want
to
add
anything.
If
I
missed
something
or
anybody
else
has
opinions
or
even
if
you
have
opinions.
F
About
I
need
to
think
about
this,
some
more
because
I'm
not
entirely
sure
what
the
various
uniqueness
requirements
here
are
and
what
what
the
consequence
of
not
achieving
uniqueness
actually
are
and
what
the
attack
vectors
are
and
so
on.
So
I
think
I
have
to
take
this
offline,
but
generally
registering
sibo
takes
is
is
something
that
you
can
easily
do
registering
one
byte
c
bar
takes
well.
There
are
only
so
many
of
them.
E
E
We
wouldn't
we
would
go
for
one
by
the
plus
one
meant
it's
probably
one
more
byte
than
the
prefix,
which
is
at
least
one
byte.
So
it's
two
bytes
and
then
you're
in
the
queue
as
well.
E
E
We'll
try
to
to
write
down
this
problem
with
cristiano
marco
and
and
send
it
to
the
mailing
list
to
see
if
we
can
get
more
discussion.
A
I
see
one
one
advantage
of
prefix
is
the
the
length
one
bite.
E
A
But
is
that
something
that
is
really
important
or
can
we
can?
Can
we
leave
with
two
bytes
or.
E
The
the
length
here
is
not
okay,.
A
G
E
Case
it's
more
about
what
is
simpler
for
or
what
is
more
convenient
for
implementers
in
some
cases,
as
I
said
in
some
cases,
you
don't
even
need
to
have
an
indication
of
what
scope
you're
using
because
maybe
you're
only
using
one
application
profile.
You
have
already
communicated
with
that
with
the
aes.
E
So
it
might
not
be
hinted,
but
in
some
other
case
you
might
need
it
and
it
might
be
one
or
the
other.
A
I
think
so
one
coming
from
then
on
the
driver
and
well
that's
easy
to
say
after
I
had
the
same
intuition
that
might
be
using
sibor
might
be
cleaner
than
a
bite.
Do
you
have
any.
E
Yeah,
in
some
cases,
it
might
not
be
necessary
to
to
use
keyboard
tags.
It's
yeah,
okay,
but
I
I
will
try
to
summarize
this
issue
or
the
problem
statement
and
and
get
the
discussion
in
the
main
list.
E
And
then
to
the
last
slide
plan
forward,
so
I
guess
the
first
point
should
be
talk
about
more
about
this
scope,
encoding
problem
and
solution.
We
have
some
other
minor
clarification
to
do.
We
want
to
submit
definitely
submit
a
new
version
before
we
can
think
about
moving
forward
to
working
group.
Let's
go.
A
I'm
seeing
no
one
so
be
ready
to
review
that
document.
Soon
I
mean
version
11.
when
when
do
you
think
you
you're,
are
you
planning
to
submit
version
11
before
the
end
of
the
year.
A
B
This
is
an
update
of
an
application
profile
of
ace
building
on
ac
group
con
that
francesca
presented
to
enable
authorized
joining
two
oscar
groups
next
slide.
Please.
B
Right
just
as
a
quick
recap
here,
I
know
they're
interested
in
joining
another
group
contacts
and
authorization
server
to
get
an
access
token,
as
an
evidence
of
being
authorized
to
be
a
group
member
with
a
particular
role
or
a
set
of
roles.
The
token
is
posted
and
what
follows
is
joining
request,
joining
response
exchange,
and
especially
the
the
ace
client
here,
gets
in
return.
B
The
key
material
needed
later
on
in
the
group
to
communicate
with
other
group
members,
and
the
focus
is
really
about
that
getting
authorization
to
get
into
the
group
and
get
the
group
key
material.
Other
things
like
communication
in
the
group
or
accessing
resources
of
group
members
or
autoscope
of
this
document,
their
cover
somewhere
else
next
slide.
B
Please,
okay,
some
updates
in
this
version
too,
aligning
with
keygroup
com.
We
have
also
had
the
renaming
of
the
main
resource
path-
the
group
manager
from
group
squared
to
this
group
to
keep
it
more
general
anyway,
and
following
also
new
content
and
requirements
introduced
in
hq
com.
B
We
have
also
provided
a
summary
of
the
methods
intended
to
be
to
be
used
by
a
node
at
every
resource
or
some
resource
and
depending
on
that
exact
type
of
node,
so
member
or
not
member,
yet
and
depending
on
the
exact
roles
it
has
or
can
have
in
the
group.
B
So
it's
summarized
also
in
in
this
table
extracted
from
the
draft
in
the
previous
version
already
we
we
introduced
one
more
operation
on
the
very
root
resource,
ace
group
where
the
payload
is
the
current
group
id
of
the
group
and,
what's
return,
is
the
invariant
group
name
for
that
group
useful
for
other
operations,
and
we
realized
in
kirkum
already
that
that's
something
useful
not
only
for
group
members
but
in
general
for
other
possible
roles
like
the
verifier
here,
a
if
really
missing
possible
making
operations
and
a
change
of
group
id
values.
B
This
is
useful
for
verifiers
too,
to
have
an
idea.
Oh
it's
again
about
that
group
with
that
name
and
continue
getting
public
keys
for
verifying
signatures
of
flying
messages,
and
just
as
a
reminder
here,
we
are
considering
scope
as
encoded
building
on
an
aif
data
format
with
a
find
already
in
the
previous
version
right.
B
There
are
also
some
updates
in
the
in
the
main
parameter
of
the
joining
response
transporting
the
the
key
material
to
a
new
joining
member.
We
used
to
have
a
client
id
parameter
borrowed
by
the
oscar
security
context,
object
and
that
parameter
was
removed
from
that
object.
Definition
in
the
last
update
of
your
score
profile,
so
we
simply
have
to
rename
that
parameter
as
group
center
id
now
also
registered
as
a
new
element
of
that
object,
but
all
in
all
keeping
the
same
meaning.
B
So
the
idea
here
is
to
provide
the
sender
id
assigned
to
this
journey
node
as
a
group
member
also,
since
in
the
group
score
document
now
we
have
the
pairwise
mode
just
stable.
We
have
added
here
two
additional
parameters
again
for
the
joining
response.
In
case
the
pairwise
mode
is
supported
at
all.
B
In
the
group,
of
course,
to
describe
what
algorithms
and
parameters
are
used
when
the
pairwise
mode
has
to
be
used
to
communicate
in
the
group
and
default
values,
just
like
for
other
parameters
are
also
defined
in
the
corresponding
section
and
the
moment
we
have
introduced
these
parameters
explicitly
signaling
the
pairwise
mode
and
how
it
is
supposed
to
work.
We
didn't
need
anymore,
separate
policy
to
tell
that
the
group
can
rely
on
that
mode
as
well.
B
Write
some
clarifications
also
on
on
the
requiem
process.
It
can
happen.
We
say
the
rate
that
the
group
member
can
request
for
a
new
sender
id
from
the
group
manager
for
a
number
of
reasons.
In
that
case,
it's
up
to
the
group
manager
to
decide
what
to
do
exactly.
It
can
just
provide
a
new
sender
id
or
instead
rekey
the
whole
group,
or
do
both
so
the
this
possible
set
of
alternatives
have
been
clarified.
B
Also,
we
we
have
tried
to
align
the
bit
better.
The
group
manager
described
here
with
requirements
and
and
no
reassignment
policies
already
stated
in
the
group
score
document
or
the
non-recycling
of
sender,
ids
and
group
ids,
there's
been
a
discussion
also
earlier
this
week
about
this
exact
point
at
the
core
meeting.
So
something
is
going
to
be
updated
in
the
group
score
document.
B
It
will
be
reflected
here
when
it
comes
to
these
details
and
finally,
we
we
had
a
resource
type
registration
for
this
joining
resource
that
can
be
contacted
by
joining
notes
to
access.
The
group
that
used
to
be
registered
in
another
document
in
in
the
co-working
group
and
the
actual
registration
was
in
fact
moved
here
and
well.
The
resource
type
can,
for
instance,
be
useful
for
the
sake
of
discovering
joining
resources,
just
sending
a
request
to
well
known,
for
instance,
next
slide,
please
yeah.
As
a
next
step.
B
I
expect
at
least
one
more
iteration
to
to
align
this
document
with
with
the
plan
changes
in
ace
giga.com
and
with
some
things.
I
also
mentioned
before
in
the
in
the
group
score
document,
for
instance,
about
no
recycling
policies
of
ids,
we've
been
continuing
working
on
implementation
and
the
whole
interface
of
the
group
manager
is
almost
complete.
I
think
only
only
three
operations
are
missing.
We
plan
to
have
some
tests.
B
I
can
take
how
peter
van
der
stock
and
crystal
announces,
especially
in
the
near
future,
so
possibly
after
that
next
version
this
should
be
close
to
be
considered.
I
hope
for
a
working,
robust
call.
B
B
B
Yeah
this
one
yeah,
thank
you
so
yeah.
This
is
another
interface
we
are
describing
at
the
very
same
group
manager.
This
document
was
adopted
following
the
previous
itf
meeting
next
slide.
Please
all
right.
While
in
the
previous
presentation
we
focused
on
the
interface
for
joni
nodes
to
access
the
group
and
get
the
key
material.
B
This
interface
on
the
group
manager
is
instead
intended
for
an
administrator
user
that
can
create,
configure
or
delete
oscar
groups
before
they
can
start
being
operated
and
overall,
it's
following
a
high
level
resource
pattern,
very
similar
to
the
one
intended
for
the
co-ops
of
broker
and
right
now
we
are
supporting
operational
message:
exchanges,
both
in
link
format
and
simple
payload
or
or
instead
in
coral
with
examples
for
for
both
cases.
B
So,
overall,
for
the
sake
of
this
interface,
the
group
manager
has
one
single
instance
of
a
group
collection
resource
at
the
path
say,
slash
manage
essentially
including
the
the
list
of
existing
oscar
groups
and
then
for
each
existing
oscar
group.
One
group
configuration
resource
in
fact
mentioned
in
that
list
and
each
group
configuration
resource
can
be
accessed
as
at
slash,
manage
slash
well,
the
name
of
the
group,
and
it
includes
the
the
current
configuration
for
the
adult
score
group
here.
B
So
on
the
left,
you
can
see
the
the
possible
operation
on
the
root
single
group
collection
resource.
What
we
have
today
is
a
post,
a
center,
the
group
collision
resource
to
create
a
new
group.
In
fact-
and
already
at
this
point
in
time,
it's
possible
to
provide
a
configuration
for
that
group,
otherwise
default
values
apply
and
when
a
group
is
created,
that
practical
mean
two
things.
B
B
According
to
the
interface
of
the
previously
presented
document,
issuing,
instead
get
request
to
this
group
collection
resource,
it's
possible
to
get
the
the
full
list
of
existing
of
core
groups
and
well
actually
the
links
to
the
corresponding
reconfiguration
resources
as
child
resources.
B
B
Instead,
just
focusing
on
one
instance
here,
operations
on
the
group
configuration
resources,
you
can
send
a
get
to
retrieve
the
the
full
configuration
for
that
group,
so
all
the
parameters
and
values
describing
it
at
the
moment,
and
now
we
have
also
introduced
fetch
in
this
update
to
retrieve
only
part
of
the
configuration,
so
only
parameters
expressed
in
the
fetch
request.
B
Right
now
we
can
modern
update,
I
should
say,
override
all
together.
The
current
configuration
of
the
group
brutally,
with
a
put
we
have
plans
to
introduce
patch
also
for
a
selective
update
and
issuing
a
delete
to
this
resource.
Instead,
we
just
destroy
the
group,
so
of
course,
there's
no
safe
operations
have
a
side
effect
on
the
group
and
the
group
members
that
we
are
also
describing
in
the
document
next
slide.
Please
right
in
this
particular
update
related
to
what
I
mentioned
before,
also
for
the
other
document.
B
Now
that
the
pairwise
mod
of
group
score
is
stable,
we
have
already
introduced
configuration
parameters
here
concerning
the
support
for
the
pairwise
mode
in
the
group,
so
essentially
a
flag
telling
the
group
manager,
if
that
mod
is
supported
or
not,
and
well,
if
it
is
more
detailed
parameters
describing
the
algorithms
and
its
parameters
to
be
used
for
the
sake
of
the
pairwise
mode
and
default
values
to
possibly
applied
are
not
defined
here
they
are
defined
in
the
previous
application
profile.
B
I
are
presented
where
we
decided
to
collect
all
default
values
to
to
consider.
B
As
I
mentioned,
we
have
also
introduced
the
the
fetch
method
for
the
group
configuration
resources
that
we
are
supporting
already,
both
in
the
sieber
and
in
the
choral
case.
So
this
is
about
retrieving
just
part
of
the
configuration,
so
only
parameters
indicated
in
the
fetch,
payload
and
the
values.
B
B
Please
right.
We
have
also
clarified
this
point
who
take
the
final
decision
on
the
invariant
once
then,
once
established
group
name,
so
we
still
have
the
possibility
for
the
administrator
asking
to
create
a
group
to
specify
an
intended
group
name,
but
then
the
final
decision
remains
on
the
group
manager
that
picks
up
a
final
group
name
also
returned
to
the
administrator
in
the
response,
and
it
seems
to
be
the
best
way
and
as
also
suggested
by
by
christian,
I
think
at
the
discussion
at
the
previous
meeting.
B
This
is
good
because
the
administrator
can
have
more
constraints
than
sorry.
The
group
manager
can
have
more
constraints
than
the
administrator
can
even
imagine
about
going
for
a
feasible
group
name.
So
it's
good.
The
group
manager
takes
a
final
word
on
this.
B
Also,
we,
we
actually
have
extended
the
registration
procedure,
which
practically
means
extending
the
the
the
creation
of
a
new
group
request
message
so
that
the
administrator
indicates
the
group
manager
also
the
names
of
the
application
groups
using
this
security
and
oscar
group,
and
this
essentially
aligns
also
operations
following
this
draft.
B
For
instance,
the
registration
of
the
security
group
in
in
objects
like
resource
directory
so
simplifying
discovery
of
this
security
group
and
links
for
john
8
to
other
nodes.
It
was
also
something
already
suggesting
in
a
discussion
in
core
related
to
coral
and
choral
forms,
but
essentially
makes
the
group
manager
aware
of
the
application
groups
that
are
using
or
are
going
to
use
the
security
group
next
slide.
Please
that
also
clarifies
this
a
bit
more
yeah
following
the
creation
of
a
security
group
here
and
now
that
the
group
manager
has
more
information.
B
The
group
manager
or
the
administrator
can
in
fact
proceed
registering
the
link
to
join
the
security
group.
To
separate
entities
like,
for
instance,
the
the
resource
directory
and
now
it's
much
better
that
the
group
manager
knows
also
the
the
names
of
the
application
groups
involved,
and
they
are
in
fact
used
as,
for
instance,
target
attributes
in
a
particular
approach.
We're
describing
for
for
doing
this
in
another
core
document.
B
We
also
give
overall
guidelines
about
this
process,
and
we
we
do
recommend
that
the
group
manager
really
does
that,
because
it's
it's
the
one
most
likely
to
to
remain
up-to-date
on
possible
changes
related
to
the
oscar
group
or
even
its
own
address
and
uri.
They
would
require
a
refresh
on
what
registered
in
the
resources
directory.
B
Otherwise,
in
principle,
the
administrator
would
be
also
in
a
position
to
do
those
same
registrations
and
speaking,
which
we
have
also
refined
just
the
name
of
a
previously
registered
resource
type
for
the
group
collection,
resource
and
we've
also
added
the
registration
of
the
resource
type
for
the
group
configuration
resource
as
well
in
the
ayana
registration
section.
B
Next
and
final
slide.
I
guess
please:
okay,
yeah,
summarize
new
interface
on
the
group
manager
for
administrators
to
create,
configure
and
delete
the
oscar
groups.
We
have
quite
a
good
set
of
operations
already
to
be
continued
and
finalized.
We
have
full
support
already
for
link
format
and
sieber
or
coral
operations
and
messages
as
immediateness
steps.
B
We
want
to
introduce
the
patch
method
to
selectively
update
only
part
of
the
group
configuration
for
an
unscore
group
we
like
to
to
focus
also
on
defining
better
format
of
scope
again
using
aif,
and
there
was
early
discussion
at
the
academ
of
the
previous
itf
meeting,
in
fact
to
to
express
scope
in
terms
of
patterns
of
group
names
that
can
be
created
and
possibly
configured.
B
This
would
open
the
way
also
to
allow
some
actions,
not
necessarily
all
of
them,
also
to
other
administrators
coming
in
later
on
also
different
from
the
exact
administrator
that
did
create
the
group
and
also
expanding
on
a
previous
discussion
of
choral
forms
that
I
mentioned.
Also
in
the
previous
slide.
B
We
can
give
some
more
guidelines
when
coral
is
used
in
the
response
to
the
administrator
following
the
registration,
especially
in
case
something
went
wrong
to
guide
the
administrator
on.
What's
the
correct
way
to
proceed
for
correct
group
creation
in
times,
for
instance,
of
message,
format
and
api,
and
that
should
be
all
from
my
side.
Thank
you.
A
Thank
you
any
questions,
christian.
D
I've
seen
in
in
this
document,
but
also
in
many
other
ace
documents,
so
this
might
be
more
general,
a
lot
of
resources
that
are
given
with
in
the
document
with
basically
with
a
path
that
starts
with
slash.
So
how
is
very
generally
best
practice
190
about
uri,
namespace
ownership
and
path
ownership
treat
it
here.
How
is
this
managed
entry
point
supposed
to
be
discovered?
D
Is
this
a
fixed
path
that
might
be
considered
for
being
a
well-known
path,
so
this
this
applies
here
with
slash
manage,
but
probably
also
applies
to
the
the
group.
Probably
everything
else
we've
seen
today.
B
As
far
as
I
know,
we've
been
following
the
the
wording
already
from
the
ace
framework
about
this
is
a
default
example,
or
not
even
default,
actually
just
an
example.
Your
implementation
can
go
for
something
else,
and
we've
been
trying
to
use
resource
types
to
help
discovery
and
well.
The
framework
two
versions
ago,
I
think,
introduced
also
a
resource
type
for
one
of
its
resources
to
support
discovery.
D
I'll
look
through
the
document
with
with
the
focus
on
this,
but
if,
if
slash,
if
this
is
a
discovered
entry
point,
it's
it's
probably
okay,
so
I
think
there's
a
there's,
a
rough
preference
for
things
that
don't
give
that
static
structure
at
all.
But
if
this
but
kind
of,
if,
if
the
structure
is
given
under
the
an
entry
point,
it's
probably
okay.
D
C
To
jump
in
this
has
been
kirakos
sadie
again.
I
think
the
intent
is
that
in
the
document
we
refer
to
like
a
name
of
the
endpoint,
a
descriptive
name,
and
maybe
the
slides
were
not
as
careful
about
using
the
descriptive
name
instead
of
slash
name,
but
I
think
the
documents
tend
to
be
more
careful
about
that.
A
No
checking
the
driver.
No,
so
I
guess
now
we
move
to
the
chateau
discussion.
C
Yes,
the
clock
we
have
just
under
an
hour
left
so
yeah.
C
We
can
of
course
discuss
the
charter
as
being
a
little
bit
more
important,
because,
depending
on
how
the
charter
goes,
we
may
or
may
not
be
able
to
do
the
new
topics.
A
Yeah,
so
let's
kick
up
the
discussion
as
anyone
I
mean:
do
you?
Can
you
read
the
charter
now,
if
you
haven't
read
it
and
see
how
you
agree
with
the
suggestions.
A
A
G
Hi,
I
was
distracted
by
the
buff
as
well,
but
I'm
reading
this
I
read
it
before
so
the
last
part
about
est
tl
esp
est
co-app.
Well,
so
that's
done
it's
in
the
rfc
editor's
queue
you
could.
I
think,
at
this
point
strike
it
from
the
charter,
except
for
the
question
about
someone
would
like
to
do
cmp
now
and
I
always
thought
it
was
weird
to
do
this
in
this
group
in
the
first
place.
G
G
I
Yes,
can
you
hear
me?
Oh
okay,
this
is
euron,
so
so
this
yes,
what
is
done
is
est
over
co-op
s,
but
what
is
not
done
is
est
protected
by
oscor
and
ad
hoc.
So
that's.
I
think
the
reason
why
this
paragraph
still
could
stay
in
the
draft
in
the
charter.
A
So
my
question
is,
maybe,
to
I
mean
to
michael
and
and
gurren
profile
is
profile
not
specific
enough,
and
you
would
prefer
clearly
mentioning
oscar.
G
I
So
this
is
your
own.
I
I
I
disagree
with
the
change
here.
I
I
propose
this
paragraph
because
we're
done
with
one
part
of
the
est
profiling,
but
we
are
not
part
done
with
the
other
part,
so
remind
you
about
the
ace
interim.
If
this
was
discussed
on
the
mailing
list,
there
was
an
ace
interim
in
three
years
ago,
where
we
discussed
different
profiles
of
the
est
protocol,
and
one
is
done,
but
the
other
is
not.
So
that's
why
I
proposed
a
charter
text
which
included
both
to
illustrate
that
we
have.
I
G
I
J
A
Okay,
so
I
am
hearing
that
everyone
agrees
with
the
text
now.
The
thing
is
that
I
I
would
like
to,
but
I
mean
this
is
my
personal
opinion
I
would
like
to.
I
mean
the
current
charter
does
not
mention
cmp
and
east
profile,
so
I
am
wondering
I
would
like
to
avoid
to
have
that
discussion
again
and
again.
A
So
I'm
wondering
if
we
can
agree
on
whether
a
is
part
of
that
work
as
well
as
est.
C
So
I
guess
we're
not
not
seeing
too
many
more
other
comments
queued
up
so
sounds
like
we
should
declare
victory
and
go
ahead
and
confirm
this
on
the
list
yeah.
So.
A
But
my
question
was:
I
mean
we
had
some
discussions
between
the
east
profiles
and
cm.
I
mean
a
bit
mostly
cmpv2
and
is
profile,
and
I
mean
none
of
those
appear
in
the
charter.
A
C
C
This
would
be
an
okay
place
to
do
such
work
provided
there's
justification
for
actually
doing
it.
We
don't
want
to
develop
certificate,
enrollment
protocols
just
for
the
fun
of
it.
After
all,.
A
Yeah
yeah,
my
purpose
was
just
to
avoid
another
discussion.
A
Okay,
so
is
the
current
text
proposed
by
enrique
fine
too.
A
So
my
understanding
is
that
the
current
text,
with
all
the
the
I
mean,
is
that
everyone
is
fine
with
that.
A
Anyone
having
any
comment,
it's
the
time
to
say
it.
We
will
confirm
that
to
the
mailing
list
anyway,
but
I'm
hearing
everyone
is
fine.
So
thank
you
very
much
and
we
can
move
to
the
next.
A
B
B
Great.
Thank
you
thanks.
This
is
a
new
proposed
transport
profile
base
to
use
grupo
score
as
security
protocol
to
access
resources
of
group
members
of
an
oscar
group
in
an
authorized.
H
B
So
why
are
we
doing
this?
There
are
use
cases
where
you
want
to
have
a
good
communication
and
you
want
to
secure
it,
for
instance
with
a
group
of
score
and
on
the
communication
side
we
are
fine
and
we
have
solution
to
enforce
access
control,
to
access
the
group
and
get
the
key
material
to
use
group
score
in
the
group.
B
That's
essentially
what
we
saw
in
the
previous
presentation
today
we
argued
as
a
separate
domain
to
cover
in
terms
of
us
of
access
control,
though,
if
you,
if
you
use
simply
the
document
we
saw
before
and
you
are
authorized
to
get
into
the
group,
you
do
that
and
you
get
the
key
material
for
very
simple
use
cases.
This
is
just
fine
and
you
don't
need
to
do
anything
more,
in
particular
for
the
sake
of
access
control
once
in
the
group.
B
Essentially,
you
can
think
that
being
in
the
group
and
and
having
the
keys
and
essentially
having
access
to
the
messages
gives
also
you
access
to
any
resource
at
any
member
of
the
group
with
any
method,
and
again
this
can
be
fine
in
some
application.
B
We
just
argue
that
it's
not
fine
in
general,
where
you
may
want
to
have
different
clients,
authorized
to
do
different
things
at
different
group
members
to
con
to
be
considered
as
resource
servers.
Essentially,
you
have
different
classes
of
access
rights
for
different
clients
and
sure
one
can
try
to
address
this.
Just
creating
several
security
group
groups,
one
for
each
class
of
access
rights,
but
they
would
complicate
management
of
groups
and
key
material
considerably,
especially
in
case
classes
of
access
rights,
change
over
time,
requiring
change
of
group
and
possibly
rekeying.
B
Please
so
just
to
give
examples.
The
first
one
is
really
a
toy
example:
a
simple
home
automation,
application,
for
example,
when
you
may
want
to
have
some
clients,
like
kids,
only
able
to
check
the
status
of
a
lock
while
parents
are
instead
fined
to
both
check
and
change
the
status
of
the
lock
or
or
even
a
more
simple
detail.
You
may
want
locks
to
to
act,
only
resource
servers
and
not
to
start
opening
and
closing
each
other.
B
B
So
you
may
have
some
clients
intended
only
for
low
privilege
operations,
another
class
of
clients
for
doing
both
low
and
high
privilege
level
of
operation,
and
some
clients
only
are
supposed
to
change
the
minimum
required
level
of
operation
at
a
given
time.
B
B
Right
so,
as
I
mentioned
before,
we
see
two
different
domains
of
access
control.
Here,
one
is
about
being
authorized
to
get
into
the
group
and
get
the
keys
which
practically
means
having
access
to
to
the
messages.
That's
fine
and
that's
covered
with
other
works.
B
We
also
saw
today
the
second
domain
that
we
argue
should
be
addressed
separately
instead
in
general,
is
about
ones
in
the
group
having
authorized
access
with
fine
grain
access
control
at
the
recesses
of
other
group
members
and,
of
course,
one
can
think
of
using
ace
and
the
access
tokens
for
that.
So
you
need
a
profile.
Well,
the
current
profiles
around
don't
cover
access
control
with
secure
group
communication
in
in
the
domain.
I
I'm
really
addressing
here.
B
The
closest
thing
we
can
have
is
the
score
profile,
but
of
course
it
considers
the
oscore
protocol,
not
group
of
scores,
so
it
doesn't
really
target
a
group
communication,
so
it
seems
we
are
missing
a
transport
profile
with
fine
grain
access
control
and
supporting
secure
communication
practically
with
the
group
score
protocol
next
slide.
Please.
B
And
that's
essentially
the
proposal
of
this
document,
so
it
describes
a
new
transport
profile
using
grouposcore
a
security
protocol
between
the
client
and
resource
servers,
as
already
members
of
the
group
and
I'll
come
back
to
this
point,
but
we
have
try
to
clarify
in
as
best
as
possible
the
timeline
here
in
the
document.
So
the
client
and
resource
servers
consider
here
are
already
group
members.
The
joining
happened
first
for
both
of
them,
according
to
the
approach
of
the
document
presented
earlier
today.
B
B
B
The
resource
server
can
can
achieve
proof
of
group
membership,
so
to
say
so,
it
can
actually
check
that
the
client
is
indeed
a
member
of
that
oscar
group
and
there's
also
mutual
authentication.
That
is,
of
course,
achieved
only
when
a
full
exchange
is
completed
liking
the
escort
profile
by
the
way
next
slide.
Please
so.
C
This
up
check,
please
just
do
the
updates,
or
do
you
also
plan
to
do
the
protocol
overview.
B
Updates,
mostly,
I
would
say,
okay
cool
thanks.
Please
continue
yeah
yeah,
a
number
of
dates
updates
have
been
included
in
this
latest
version.
As
I
mentioned,
we
clarified
the
timeline
that
was
mostly
requested
by
ben
actually
in
the
singapore
meeting
last
year.
So
this
is
really
about
something
for
nodes
that
are
already
group
members.
The
join
have
to
have
to
has
to
happen
first,
then,
we
have
considerably
simplified
the
the
profile
and
the
workflow
of
the
protocol
itself,
thanks
to
input
from
joran.
B
So
now
the
document
really
focuses
on
the
grupo
score
protocol
only
for
secure
communication
between
clients
and
servers
and
the
the
public
key
that
the
client
uses
in
the
group
is
in
fact
used
as
a
proof
of
possession
key
and
that
simplifies
the
workflow
overall
and
also
the
message
format
and
their
processing.
B
Still
we
added
an
appendix,
including
what
used
to
be
the
original
version
of
this
profile
and
considering
both
oscor
and
group
score
and
security
protocol.
So,
in
addition
to
that,
you
would
also
have
the
possibility
to
establish
a
pairwise
or
security
context
between
a
client
and
the
resource
server.
B
C
B
But
this
is
the
core
of
the
proposal,
essentially
so
so
checking
this
at
a
high
level.
A
client
is
interested
to
to
access
with
fine
grain
access
control
resources
at
two
group
members
rs1.
There
is
two
here:
it
gets
a
token
for
rs1.
Just
some
of
the
new
informations
I
did
here
are
also
in
the
slide.
So
first
token
is
received
and
posted
and
confirmed
next
slide.
Please
yeah
the
same
happens
to
get
a
token
for
rstu,
also
posted
to
rsdu
next
slide.
B
Please
yeah
and
following
that,
the
client
can
send
a
request
in
group
score
in
this
example,
over
multicast
and
in
group
mode
received
by
the
two
resource
servers.
They
each
reply
with
one
response
in
group
score
that
can
be
either
groupon
or
payouts
mode,
and
I
said
before,
for
either
mode
proof
of
possession
is
achieved
at
the
resource
server,
either
by
directly
verifying
a
counter
signature
or
decrypting.
The
message
in
the
first
place,
using
a
pairwise
key
derived
out
of
the
asymmetric
keys
of
the
two
nodes.
B
Next
slide,
please
yeah.
It's
a
new
transfer
profile
base
to
bring
fingering
access
control
as
per
ace
security
protocol,
and
we
still
have
an
appendix
describing
an
old
version
with
both
all
scoring
group
score
and
security
protocol.
So
these
changes
incorporated
mostly
comments
from
from
ben
and
joran
and
as
next
step,
we
would
like
to
give
guidelines
on
how
even
the
main
mode
with
the
group
of
score
only
the
client
can
possibly
go
separately
for
an
execution
of
the
oscar
profile,
as
is
in
case.
A
A
So
because
we
are
somehow
running
out
of
time,
I
propose
that
we
move
to
the
next
presentation,
which
is.
A
I
I
I
This
is
a
as
I
mentioned
in
the
charter
discussion,
a
way
to
do
certificate,
enrollment
protected
with
ad
hoc
and
oscore,
and
it
builds
on
on
other
drafts.
I
Now
we
already
mentioned
today
cms
and
cmc,
which
jim
shard
worked
on,
and
we
have
the
enrollment
of
secure
transport
and
then
the
draft
which
is
soon
for
publication,
the
esd
co-op
s,
draft,
protecting
esd
payloads
over
dtls
and
co-op,
and
this
draft
is
closely
following
that
draft,
but
replacing
dtls
with
that
hopkins
low
score.
Next,
like
this.
I
We
have
the
est
request,
response
messages
which
are
the
same
and
we
replace
the
security
or
complement
security
with
security
on
co-op
or
http
layer
and
then
running
over
various
transports.
Next
slide.
E
I
It's
section
by
section
copying
stuff
from
from
ust
or
referencing
the
corpus
profile
of
sd
yeah.
You
see
here,
discovery
the
functions,
the
payload
formats,
measured
findings,
response
codes
and
the
delayed
responses
which
is
defined
in
that
draft
introduced
in
that
graph,
and
then
fragmentation
next
slide.
I
And
another
feature
with
with
with
all
score
is
that
we
don't
need
to
make
any
assumptions
on
the
co-op
http
proxy.
I
So
you
need
to
proxy
the
enrollment
request
and
with
the
use
of
oscore
you
don't
need
to
do
anything
est
related
in
the
proxy,
so
you
could
actually
just
just
pass
it
on
and
then
you
could
get
end-to-end
security
and
that's
the
next
slide
last
slide
is
next
steps.
We
need
to
complete
the
additions
on
on
the
the
new
est
function,
submit
a
new
version.
I
C
I
I
Volunteers
michael
says:
I'm
in,
I
think
I'm
involved
already
he's
not
formally
on
warsaw,
but
but
yes,
yes,
michael,
has
been
in
the
discussion
for
a
while
as
well.
A
C
Let's
just
see
if
people
can
type
that
in
jabber,
I
don't
think
we
should
try
and
get
the
the
live
audio
for
that.
A
I
Okay,
thank
you.
So
here
is
another
draft
making
use
of
of
ad
hoc
and
the
lightweight
properties
of
ad
hoc.
In
this
case,
this
is
a
way
to
combine
authorization
and
authentication
in
a
lightweight
manner.
I
So
these
are
my
co-authors
and
please
take
the
next
slide.
I
So
I
I
can
easily
spend
more
than
10
minutes
here,
but
I
suppose
I
won't,
since
ben
ben
has
asked
this
to
be
a
little
bit
more
restrictive
on
time.
This
there's
a
lot
of
arrows
and
colors
in.
I
In
the
first
slides
so
I'll
try
to.
A
Just
to
let
you
know,
we
have
one
more
presentation,
which
is
for
the
revoked
token
notification,
which
is
10-15
minutes.
So
you
have
roughly
10-15
minutes.
I
Okay,
I'll
I'll
try
to
make
it
into
or
I
will
make
into
10..
So
this
the
setting
here
is
the
device
joined
the
on,
say,
the
onboarding
of
a
device
in
a
network
which
has
been
described
in
different
contexts.
I
Enrollment
over
secure
transport
has
as
one
description
we
have
the
and
there
are
many
other
settings
and
in
you
have
typically
a
number
of
faces
in
this
procedure.
There
is
an
authentication
phase.
I
There
is
an
authorization
phase
which
can
happen
in
parallel,
but
sometimes
in
sequence,
and
it
might
involve
a
trusted
party
like
the
authorization
server
and
then
there
might
be
as
an
est
and
enrollment
phase
where
you
enroll
in
local
certificate,
with
the
network
you're
joining,
and
the
problem
statement
is
about
this
doing
things
in
sequence,
which
inc
adds
latency
and
you
said
past
the
same
data
in
different
phases,
and
also
that
you
don't
always
make
use
of
the
fact
that
you
have
may
have
an
the
internet
behind
that
behind
the
authenticator
in
this
case,
so
you
don't
need
to
pass
so
much
data,
really
all
the
constraints
next
slide.
I
First,
so
we
have
the
blue,
the
red
and
the
black
face
here
and
in
the
next
slide
we
see
that
we
can
combine
them
actually
in
a
more
more
efficient
way.
So
this
is
just
an
example.
I
Yes,
thank
you.
Okay,
so,
as
I
was
saying,
the
try
to
say
is
that
there
is
an
option
to
make
these
faces
more
more
parallel,
parallel
in
parallel,
and
that's
the
scope
of
of
this.
I
This
presentation,
so
here
here,
is
a
slide
showing
how
different
different
components
can
be
different
drafts
can
be
used
to
make
this
more
efficient.
In
the
we
see,
we
see
the
ad
hoc
exchange,
the
blue
messages,
and
we
see
the
enrollment,
the
black
box
and
the
black
messages.
That
was,
that
was
previous
draft,
and
this
described
here
in
this
session.
I
I
So
it's
actually
the
question:
how
can
we
make
authorization
in
parallel
to
authentication
in
a
lightweight
way,
and
in
this
case
we
are
using
the
adword
protocol
and
we
carry
authorization
related
information
in
the
auxiliary
data,
that's
between
it's
all
over
the
constrained
link,
and
then
we
have
an
exchange
in
the
backend
with
the
with
the
trusted
third
party,
the
authorization
server,
and
in
this
way
we
can
reuse
the
data,
public
keys
and
identifiers
in
the
authentication
protocol
for
the
authorization
process,
which
makes
it
more
lightweight
and
we
can
transfer
credentials
over
the
unconstrained
link
instead
of
the
constraint
next
slide.
I
I
So
there
are
more
arrows
and
colors.
So
what
if
you
look
at
the
assumptions?
It's
basically,
we
introduced
the?
I
I
We
do
have
a
trust
relationship
between
the
device
and
the
trusted
third
party.
That's
exactly
what
we're
using
here:
authorization
server!
It
could
be
in
the
brewski
case.
It's
the
manufacturer,
authorization
service,
or
it
could
be
some
other
some
other
trusted
third
party
and
v,
and
w
only
have
sort
of
a
web-based
trust
so
that
they
could
look
up
and
have
some
implicit
trust
anchors
and
they
could
verify
their
yes
certificates.
I
So
as
the
adword
protocol
runs,
the
device
will
get
the
public
key
of
of
the
authenticator
and
at
that
point,
with
the
help
of
the
voucher,
it
can
authenticate
and
authorize
the
the
network
and
the
third
message
the
device
is
supposed
to
pass
its
credential
or
identify
the
credential
to
to
the
authenticator.
I
I
G
I
Also,
so
sorry,
yes,
it's
not
so
so
there
is
a
joint
proxy,
which
essentially
is
the
first
point
of
contact
with
the
network.
That's
that's
somewhere
on
the
constrained
link.
I
I
I
I
So
if
you
compare
the
if
we
map
the
authenticator
to
the
client,
the
device
to
the
constrain
device
to
the
resource
server
and
the
authorization
server
to
the
authorization
server,
we
get
something
like
this.
And
if
you
look
at
the
assumptions
it
seems
to
to
match
what
the
assumptions
are
are
for
ace.
I
The
rs
provides
information
about
location
of
the
aes
to
c
that's
the
as
request
creation
hints
the
rs
and
the
as,
on
the
other
hand,
they
have
a
strong
cross
relationship
in
this
case,
sharing
by
the
rs
having
the
public
key
of
aes
and
the
as
can
can
can
look
up
information
about
the
rs
and
provide
that
to
the
client,
whereas
the
relationship
between
the
client
and
the
authorization
server
is
is
not
strictly
specified
in
in
the
ace
framework
and
the
one
way
of
resolving.
That
is
some
sort
of
web-based
trust.
I
So
so
the
assumptions
map
match
and
also
the
protocol
can
can
be
made
to
match
fairly
fairly
well,
so
the
as
request
creation
hints
typically
are
in
response
to
a
request
from
a
client.
In
this
case
there
is
no
prior
request,
so
it's
basically
just
preemptively.
I
Providing
this
information
to
the
client,
which
can
then
post
a
token
containing
posts
to
slash
token
containing
this
information
provided
by
the
device
and
the
authorization
server,
can
respond
with
access
information,
in
this
case
the
certificate
of
the
rs
and
also
an
access
token,
which
is
in
this
case
it's
the
voucher
and
that's
passed
by
back
to
the
to
to
the
device.
I
I
So
I'm
wrapping
up
this
two
more
slides.
This
is
just
so.
There
was
a
lot
of
arrows
in
the
in
the
previous
pictures.
The
actual
content
of
the
draft,
which
is
it's
of
course,
work
in
progress,
still,
is
that
we
we
produce
two
new
auxiliary
data
types
for
ad
hoc,
which
contains
this
information
that
needs
to
be
carried
between
client
and
and
authenticator
between
device
and
authenticator.
Sorry-
and
there
is
what
michael
called
an
ultra-constrained
voucher
matching
the
brisket
terminology,
which
is
just
a
mac
of
this.
I
This
data
that
comes
from
from
the
authentication,
server
authorization
service,
sorry
and
then
with
the
exchange
of
data
between
the
authenticator
and
authorization
server,
which
is
independent
of
transport.
But
there
is
an
ace
map
being
described
in
this
draft
and
then
some
security
processing
next
slide.
I
There
are
plans
definitely
to
implement.
I
don't
know
if
michael
want
to
say
more
what
what
exists
and
what
does
not
exist
and
ben
also
commented
that
rfc
yeah,
the
voucher
rfc
can
be
useful
for
more
than
just
versky,
and
if
someone
wants
to
say
anything
about
that,
that
would
be
great.
Maybe
michael
is
the
right
person
here
bear
in
mind
now,
michael
that
I've
already
taken
all
the
time
for
this
presentation.
I
Yeah,
okay!
So
yes
to
answer
all
the
yes
there
is.
There
is
implementation
plans
here
and
please
we
can
talk
about
that
offline.
I
can
send
more
information.
A
B
Yes,
thank
you
again,
final
presentation.
This
work
was
presented
last
time
at
the
june
interim
we
had.
I
think
the
problem
we
are
addressing
is
that
access
tokens
can
be
revoked
before
their
intended
expiration
time
for
a
number
of
reasons,
clients
and
resource
service
compromised.
The
policies
of
their
outcome
have
changed
or
da's
profile
to
use
with.
B
That
token
has
changed
and
we
are
trying
to
address
the
problem
of
let
both
the
client
and
the
resource
server
know
about
such
early
revoked
tokens,
and
for
that
we
are
defining
one
resource
and
related
interface
at
the
authorization
server.
B
So
there
we
keep
one
single
docker,
revocation
list,
where
we
include
identifiers
of
revoked
tokens
that
are
not
expired
yet
and
not
identifiers
in
the
sense
of
the
existing
ctis,
but
more
hashes
of
those
tokens
to
put
it
simple
and
then
both
the
client
and
the
resource
servers
can
can
retrieve
that
list
or
get
and
observe
that
list
to
receive
automatic
notifications
in
case
anything
changes
and
to
be
precise
here,
the
client
and
the
resource
server
and
can
obtain
from
the
authorization
server
only
the
part
of
that
list
that
really
pertains
themselves.
B
So,
for
example,
a
client
can
get
only
this
kind
of
information
for
the
tokens
it
has
received
in
the
first
place,
and
this
complement
the
already
available,
of
course
token
introspection,
editorization
server
and
it
doesn't
require
at
all
any
new
endpoint
on
the
client
or
there
is
a
server
next
slide.
Please.
B
Right,
as
I
mentioned,
the
identifiers
we
use
for
tokens
here
are
harshest
computing,
just
following
the
binary
format
of
6920,
so
naming
things
with
hashes,
I
think
the
exact
resource
and
authorization
server,
then,
is
essentially
a
simple
array,
including
a
list
of
token
ashes.
B
B
Really,
the
client
and
resource
server
will
get
the
exact
url
to
that
trl
resource
at
the
authorization
server
and
then,
as
I
said,
they
can
send
requests
for
the
pertaining
portion
of
that
list
or
observe
it
for
for
changes,
but
we
are
actually
admitting
a
special
requester
like
an
administrator
that
can
in
fact
get
back
the
full
content
of
that
list.
So
right
now
we
have
two
different
modes
of
operations
in
in
full
query
mode.
You
can
get
back.
B
In
fact,
all
the
pertaining
portion
of
the
list
and
and
the
related
token
ash
is
included
there
in
this
query
mode.
You
can
instead
get
back
a
set
of
most
recent
updates
that
happened
to
that
part
of
the
list
pertaining
to
you,
and
we
have
recently
improved
that
based
on
feedback.
We
got
next
slide.
Please.
B
So
since
version
one
that
that
was
presented,
in
fact
in
the
june
interim
now,
we
are
in
in
version
three.
The
the
latest
version
especially
addresses
review
comments
from
from
karsten
posted
on
the
list
after
the
interim
and
comments
we
got
from
from
bain.
Also
during
that
same
interim,
so
we
clarified
even
better
providing
examples.
B
What
we
exactly
take
as
input
for
the
hash
processing
when
computing,
the
token
ash,
considering
the
case
where
the
token
has
been
transported
in
sieber
or
in
json
instead
and
based
especially
on
on
custom
feedback.
We
have
simplified
the
the
interface
and
the
message
format
for
the
div
query
mode.
B
So
now
we
have
a
single
query,
parameter
that
specifies
the
number
of
requested,
most
recent
updates
in
the
response
and
the
response
payload
that
used
to
to
be
based
on
zebra
maps
and
now
is
essentially
an
array.
So
so
the
the
outer
payload,
the
overall
payload
is
an
array,
including
the
different
updates
happen
to
the
list
as
individual
elements
that
are
in
turns
array
and
then
for
each
update.
We
specify
which
token
ashes
have
been
added
or
removed,
especially
for
that
for
that
update
next
slide.
Please.
B
So
other
than
that,
following
a
recommendation
from
men
when
the
registration,
the
initial
registration
happened
at
the
authorization
server
what's
returned,
is
not
only
the
exact
url
to
this
list
resource,
but
also
the
identifier
of
the
exact
hash
algorithm
used
and
we've
also
added
more
interaction.
Examples
we
used
to
have
only
one
in
full
query
mode.
We
we
added
two
in
diff,
query
mode,
also
using
observation.
In
fact,
we
also
added
two
big
appendices.
B
The
first
one
follows
carson's
review
where
he
was
suggesting
to
check
the
series
transfer
pattern
and
well,
it
was
right.
There
was
also
inspiring
and
in
appendix
a
we
described.
How
yeah
the
diff
query
mode
proposed
here
is,
in
fact
an
instance,
an
example
of
usage
of
that
series
transfer
pattern
and
we
define
the
the
alignment
more
in
detail.
B
But
ben
also
had
some
more
comments
again
during
that
interim.
B
B
For
instance,
the
the
last
interaction
happened
some
hours
some
some
days
before,
and
that
should
cover
also
the
case
where
that
point
in
time
is
now
gone
because
it
it
became
stale,
it
just
had
to
be
removed
from
the
aes,
and
that
should
push
the
requester
back
to
to
to
issue
a
new
request
in
in
full
query
mode,
and
this
can
actually
become
a
third
mode
of
its
own
next
slide,
please
yeah!
B
So
we
we
took
that
into
account
and
that's
why
we
introduced
the
new
paint
bixby,
where
we
believe
we
are
in
fact
defining
this
possible
third
mode
of
operation
suggested
by
ben
further
building
on
the
series
transfer
pattern
and,
in
particular,
of
its
cursor
sub
pattern.
B
We
we
have
the
interface
defined,
also
considering
all
observation
as
initial
intention
for
unsolicited
information
of
revoked
tokens,
and
this
latest
version,
as
I
mentioned,
included
especially
review
from
carson
comments
from
ben,
but
further
builds
on
an
earlier
review
on
the
list,
from
trevi
spencer
and
comments
and
discussion
from
jim.
As
immediate
next
step,
we
would
like
to
try
to
move
that
appendix
p
to
the
document
body
as
an
actual
third
mode
of
operation
like
an
enhanced
query
mode
and
all
considering
the
the
current
status
and
the
previous
reviewed.
B
We
we
got
in
the
dress,
we
were
thinking.
This
can
be
considered
for
adoption
call
in
the
working
group.
A
Okay,
thank
you,
marco.
Unless
there
are
any
comments,
I'm
gonna
take
the
two
last
minutes
to
provide
some
next
steps
for
the
working
group.
So
what
I'm
planning
to
do
is
interim
meeting
on
a
monthly
basis
as
we
used
to
do.
I
think
that
was
a
pretty
much
productive.
A
I
mean
we
should
start
focusing
on
finalizing
the
work
that
is
being
in
progress,
so
I
I'm
I
have
in
mind
the
current
working
group
documents
and
the
the
other
track
for
us
is
to
recharge
as
soon
as
possible.
So
I'm
gonna
send
the
the
charter
on
the
mailing
list
and
then
I
think
that's
gonna
be
on
ben's
spot
to
move
that
to
the
isg.
C
So
I
would
just
add
thank
you
to
daniel
for
taking
on
the
full
load
of
cheering
all
by
yourself.
I
am,
as
I
mentioned,
on
the
list
working
to
get
you
a
co-chair
as
soon
as
we
can,
but
I
appreciate
that
you
have
been
keeping
things
running
while
it's
just
in
you,
so
thank
you.