►
From YouTube: IETF110-ACE-20210312-1600
Description
ACE meeting session at IETF110
2021/03/12 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
This
is
the
authentication
and
authorization
for
constraint,
environment,
ace,
working
group
meeting
the
last
session
of
this
ietf.
A
I
suppose
we
can
start
right
now,
so
why
you
can
read
the
note.
Well,
I'm
gonna
ask
if
we
can
have
a
javascribe
a
minute
ticker.
A
This
time
you
don't
have
to
fill
the
blue
sheets
because
it's
automatically
done
for
you,
I'm
gonna,
put
in
the
chat
the
link
to
the
kodi.
A
Does
everyone
knows
how
to
use
the
interface
so
now
that
I'm
sharing
my
screen,
I
can,
if
you
want
to
speak,
you
have
to
press
on
this
audio
button.
A
Yeah,
thank
you
christian.
Can
we
have
anyone
helping
christian
one
or
two.
A
C
Sure
I
am
not
aware
of
the
like
the
entire
process,
so
I
believe
I
have
to
take
the
notes
on
ethernet.
A
C
A
That's
exactly
what
we're
trying
to
to
to
do.
It's
exactly,
and
so
anyone
please
help
christian
and
and
moyet.
That's
welcome.
A
A
Okay,
so
now
we
can
start
the
session,
so
no
no
questions
related
to
the
not
well.
The
good
news
is
that
we
have
a
new
chair
and
let
me
introduce
you
logan
so
logan
do
you
want
to
say
something
to
the
working
group.
A
So
we
will
go
through
the
working
group
status
and
we
we
have
a
few
presentation.
Well,
most
of
them.
You
already
know
looking
at
the
session
material,
so
let's
jump
quickly
to
the
working
group
status.
So
we
have
a
still
one
draft
that
is
in
publishing
publication
queue.
It's
basically
looking
for
a
reference,
so
there
is
nothing
you
can
do
it's
going
to
happen
soon,
because
it's
a
dtls
reference.
A
We
have
sent
a
few
drafts
in
the
isg,
so
that's
the
oauth
auth
the
framework,
the
perms,
the
profiles
and
the
dtls
authorized.
So
oscar
profiles
and
dts
profiles.
A
A
The
only
question
I
have
regarding
this
draft
is
that
how
a
line
it
is
with
the
updated
text
to
the
framework-
and
I
mean
to
be
clear-
it's
it's
nothing
that
needs
to
be
changed.
It's
just
regarding
how
specific
the
profile
is
regarding
the
specification
of
the
protocol
to
be
used
to
be
recommended
for
use
between
the
client
and
the
es
and
the
client
and
the
rs.
A
So
I
I
think
well,
the
text
could
mention
as
but
I'm
just
waiting
for
maybe
sigm
to
to
check
that.
So
we
can
do
that
on
the
yeah.
That's
not
a
problem,
okay,
so
I'll!
Let
you
do
the
update
and
whatever
you
think
is
useful.
We
have
one
draft
that
is
in
working
group.
Last
call
it's
the
aif
draft,
so
I
don't
know
if
casting
you
want
to
say
a
few
words
on
that.
A
And
then
so,
this
draft
is
going
to
be
reviewed
by
logan
is
going
to
be
the
shepherd
for
that
draft.
So
I
hope
that
by
the
end
of
the
month
that's
going
to
be
shipped
to
ben,
so
we
have
two
new
drafts
that
have
been
adopted,
so
the
I'm
going
to
call
them
cmtv,
cmpv2
and
heap
draft,
so
those
are
going
to
be
presented
and
we
still
have.
I
mean
I'm
just
mentioning
that
in
in
my
opinion,
the
working
group
is
now
being
focused
on
shipping.
A
The
group
com,
those
two
group
com
drafts,
the
new
adopted
draft
and
pub
sub
profiles.
So
these
are
to
me
the
draft
that
we
should
focus
on.
A
I
well
I'd
like
to
save
time,
so
maybe
we're
not
going
to
go
through
the
milestones,
but
I
think
we're
pretty
good
for
now.
In
the
milestones
we
do
have
some
interim
meetings
so
because
it
has
been
believed
that
it's
helpful
to
move
the
work
forward.
So
it's
one
per
month,
as
we
discussed
during
the
last
interim
meeting.
A
One
thing
I'd
like
two
notes,
I'd
like
to
to
raise
to
the
working
group.
The
first
one
is
our
relations
with
all
the
working
group.
I
mean
the
oauth
and
the
gene
app
or
ignab.
A
I
just
want
to
make
sure
that
we
we
are
not
evolving
on
our
own
and
that
we
keep
as
much
as
possible
touch
with
those
working
group.
So
yeah
I
would
be
interested
to
know.
Maybe
you
can
do
a
plus
in
the
chat
if
you
are
following
or
attending
a
dose
working
group.
A
So,
as
you
can
see
on
the
screen,
I
provided
on
the
kodi
various
ways
to
to
to
to
do
that,
so
it's
not
mandatory
and
so
on.
But
if
you
can
do
that,
please
have
to
keep
that
in
mind.
So
I
don't
see
any
plus
in
the
chat.
So
I
don't
know
how
to
interpret
that.
If
that's
no
one
is
really
following
oauth
or
nap,
but
yeah,
that's
something!
A
Okay,
so,
okay,
that's
good!
We
have.
We
have
at
least
one
which
we
should
have
more
okay.
Now,
let's
move
to
the
presentation,
then,
as
anyone
to
does
anyone
wants
to
say.
A
C
Hello,
so
this
is
mohit,
so
me
and
my
colleague
sarah
we
are
working
on
this
draft
for
using
cmp
over
a
c
over
co-op
transport.
So
so
so
let
me
just
give
you
some
background
so
daniel.
Can
you
please
move
to
the
next
slide.
C
Okay,
so
so,
basically
in
in
the
lamps
working
group,
there
has
been
some
work
going
on
improving
the
cmp
protocol
and
there
are
currently
three
drafts
which
are
under
process,
and
I
think
one
of
the
main
focus
there
is
to
use
cmp
for
industrial
and
iot
devices.
And
for
for
that,
I
think
for
the
constraint.
Devices
cmp
can
be
used
more
efficiently
over
coap
transport
instead
of
the
traditional
http
or
https
transport,
which
is
over
tcp,
and
it
takes
lot
of
memory
and
cpu.
C
C
C
We
can
very
easily
transport
cmp
messages
over
coap
and
I
think
some
people
are
doing
that
also-
and
this
draft
is
just
setting
up
guidelines
for
how
to
use
cuap
transport
for
for
cmp
transactions
and
in
in
general,
there
is
a
rfc
6712,
which
is
for
cmp
or
http,
and
this
draft
follows
mostly
whatever
is
done
in
that
rfc,
so
yeah
next
slide.
Please.
C
Yeah
so
so
these
are
some
of
the
key
features
that
we
have
our
key
things
that
we
have
defined
in
this
draft.
So
one
so
first
one
is
service
discovery.
How
earth
or
iot
device
will
discover
the
other
entities
for
cmp
entities
in
the
network.
C
So
so
there
could
be
like
fixed
urls,
which
they
can
poll
and
see.
If
there
is
any
server
there
and
then
then
we
have
defined
the
coap
uri
formats,
which
is
basically
just
use,
coap
or
cuaps
column,
slash
slash
instead
of
http
or
https
colon,
slash,
slash,
and
then
then
we
have
this
coap
request
and
response
format.
C
So
this
kind
of
defines
a
new
new
content
type
for
cmp
data
in
in
the
coap
coap
messages,
and
the
other
thing
that
we
have
defined
is
the
block
transfer
mode
to
avoid
ip
fragmentation
of
the
of
those
of
the
of
the
coap
packets
that
are
carrying
cmp
messages.
C
And
then
this
draft
also
talks
about
how
we
can
use
dtls
for
co
aps
and,
and
then
one
of
the
other
features
which
came
up
during
discussions
was
if
we
can
use
coap
to
http
or
https
proxy
and
that
that
can
kind
of
help
integrating
this
new
transport
with
existing
infrastructure
without
much
changes
so
yeah.
So
these
are
the
main
things
that
we
are
covering
in
this
draft
yeah.
So
so
I
would
like
to
have
some
feedback
from
the
group
so
so
far
I
think
I
have
not
received.
C
I
have
only
received
comments
from,
I
think
two,
two
or
three
people,
so
so
please
go
through
this
and
see
if
there
is
something
we
can
improve
or
something
that
I
missed-
yeah
yeah,
so
yeah,
I
I
can
take
any
questions
now.
I
think
this
was
just
the
introduction.
B
Well,
that's
why
I
just
raised
my
hand,
so
when
you
use
proxies
together
with
dtls,
then
the
proxy
is
is
in
a
position
where
it
actually
can
influence
the
read
and
influence
the
data,
so
the
proxy
could
do
in
middle
person.
C
Yeah
we
I
I
have
so
so.
Basically
I
have
I
have
certain.
Basically,
I
I
have
captured
that
use
case
that
the
proxy
that
if
there
is
a
dtls
proxy
in
the
path,
so
the
the
mitm
certificate
of
the
proxy
should
be
trusted
by
the
by
the
end
by
the
iot
devices
or
end
entities.
Basically,
and-
and
the
other
thing
that
I
suggested
was
that
ras
could
be,
or
whatever
is
the
closest
cmp
other
entity,
basically
ras
or
c
is
which
are
which
are
like
the
next
stop.
C
C
Yes,
so,
okay,
so
so
there
is
one
more
use
case
of
proxies.
Basically,
if
you
are
sending
everything
over
udp,
so
it's
it's
very
suspectible
to
a
lot
of
udp
based
ddos
attacks,
so
somebody
can
send
any
random
packet
from
any
ip
right.
So
so,
if
let's
say
ras
are
only
like
this
proxy
can
help
mitigate
that.
Also,
basically,
you
can
have.
A
Any
other
question
I
see
in
the
chat,
so
the
text
says
client
should
be
configured
to
trust,
to
see
a
certificate
used
by
proxy
to
sign
the
main
in
the
middle
certificate
for
certificate
chain
validation.
B
Well,
I
not
only
need
to
trust
the
certificate.
Trusting
a
certificate
means
that
I
believe
that
the
name
given
in
the
certificate
has
the
public
key.
I
actually
have
to
trust
the
the
device,
the
the
component,
that
is
doing
the
proxy
so
having
a
signed
certificate
from
some
ca.
I
trust
doesn't
mean
that
the
proxy
itself
is
trustworthy.
C
So
so
proxy,
so
if,
if
we
are
using
so
so,
the
idea
is
the
proxy
should
be.
Maybe
let's
say
let's
say
we-
we
have
a
cmp
server
running
some
end
entity
or
some
ra
or
ca
right,
so
they
can
be
somewhere
on
a
public
network
and
proxy
could
be
at
the
edge
of
the
network
where
you
have
all
the
iot
devices,
for
example
in
the
in
the
local
network
and
before
the
things
go
out
to
the
the
public
network
or
the
internet.
C
So
this
proxy
can
be
there
at
the
gateway
which
is
managed
by
the
maybe
so
so
there
are
two
type
of
deployments
right,
so
one
type
of
deployment
is
this
proxy
could
be
managed
by
the
by
the
entity
who
is
who
is?
Who
is
the
ca
or
ra
right?
So
so?
In
that
case,
the
end
entities
will
be
trusting
that
certificate.
The
other
option
is,
someone
can
have
a
proxy
sitting
at
the
edge
of
their
network
and
everything
that
is
going
to
ra
or
ca.
C
B
B
E
So
I
guess
to
jump
in
just
real,
quick
preston.
You
know
that
there's
a
dedicated,
extended
key
usage
value
for
the
cmcra
that
can
go
in
the
certificate
so
like.
If
you
trust
the
ca
at
all,
like
the
route
ca,
your
trust
anchor,
then
you
trust
them
to
only
sign
that
eku
when
it's
held
by
an
entity
that
you
should
trust
to
perform
that
role.
C
You
but,
but
I
think
the
other
point
that
you
said
is
is
also
correct-
that
cmp
doesn't
need
to
depend
upon
the
external,
like
the
dtls,
to
protect
the
integrity
or
the
privacy.
Basically,
it
can
use
its
own
its
own
mechanism
to
to
establish
the
trust.
C
So
this
this
is
just
to
hide
the
data
from
from
the
people
or
the
devices
who
are
in
the
path
like
what
is
going
on.
B
Okay,
if
you
could
make
this
very
clear
the
document,
so
then
that
when
I
read
it,
I
understand
that
that
would
be
great.
A
Any
comments
I'm
saying
known,
I'm
wondering
if
ben
wants
to
repeat
I
mean:
did
you
catch?
What
ben
mentioned.
A
Okay
right,
so,
let's
move
to
the
next
presentation
thanks
muay.
A
F
F
Talk
about
the
concept
and
different
use
use
cases,
since
this
was
an
important
issue
when
adopting
the
document
we're
going
to
try
to
to
clarify
this
aspect,
and
then
we
can
check
with
the
current
state
of
the
document
and
what
are
we
trying
to
achieve
here
and
what
we
understand
are
the
issues
that
we
need
to
consider
moving
forward
from
from
this
this
version.
F
So
here's
basically
the
main
concept,
the
main
idea
of
co-op.
If
so
we
have
it,
that
is
a
technology
that
allows
us
to
perform
authentication
with
different
methods.
This
was
one
of
the
main
reasons
why
we
chose
to
develop
this
because,
since
in
iot,
we
have
a
lot
of
devices
with
different
different
characteristics.
We
have
different
types
of
networks.
We
we
may
need
to
have
also
different
ways
of
providing
authentication
to
these
devices,
so
we
we
can
do
that
with.
If
and
since
it
needs
an
if
lower
layer.
F
We
chose
to
to
look
at
craft
to
fulfill
this
this
this
role
and
we
saw
it
as
a
rigorous
fit.
So,
basically,
the
idea
is
that
we
have
a
device
that
tries
to
join
a
security
domain
and
that
is
managed
by
a
controller
and
it
can
have
the
bootstrap
service
exposed,
as
we
can
see
here
in
the
image
by
means
of
the
co-op.
If
exchange
with
the
controller,
then
this
this,
if
exchange
that
is
contained
within
quad,
goes
optionally
to
a
standard,
surprise
server,
which.
E
F
E
F
F
F
The
more
the
most
important
in
this
case
is
how
does
equality
fits
in
ace,
so
we
understand
that
cooperate
can
be
used
to
perform
the
the
process
and
the
decline
in
registration
and
therefore
material
to
establish
different
security
associations
and
once
the
iot
device
belongs
to
the
security
domain
of
the
of
the
controller
in
this
case
could
be
collocated
with
the
authorization
server
it
can
act
as
a
client
within
the
age
framework,
maybe
to
query
another
iot
device.
That
in
this
case,
is
a
resource
server.
F
F
So
another
use
case
that
that
are
typically
seen
along
with
with
it
is
for
network
access
just
to
to
being
able
to
authenticate
to
allow
traffic
through
an
award
entity
that
is
in
charge
of
allowing
the
traffic
through
to
the
internet
or
doing
packet
forwarding.
F
Get
access
to
the
network
and
the
internet,
but
maybe
we
have
also
another
services
that
need
authentication,
so
we
could
also
leverage
a
graphic
for
this
for
this
objective.
If
we
go
please
to
the
next
slide
in
this.
In
this
context,
this
can
be
done
in
different
ways,
so
we
can
have
a
scenario
where
we
have
a
multi-domain
case
where
I'm
trying
to
join
a
security
domain.
F
That
is
not
from
my
organization
and
through
the
use
of
triple
infrastructures,
different
devices,
the
mines,
sorry
devices
from
different
domains
can
join
under
the
the
controller
domain
and
act
as
transporting
entities
and
exchange
information
through
the
controller.
In
this
case,
we
also
have
a
case
where
we
have
a
single
domain
and
using
a
triple
infrastructure
where,
for
instance,
we
have
an
organization
that
has
several
buildings
or
different
campuses
or
whatever
everything
is
managed
in
their
a
single
organization,
but
we
might
be
able
to
give
some
flexibility
by
using
this
triple
a
infrastructure.
E
F
The
server
within
the
controller
and
centralize,
in
this
case
all
the
credentials
and
operate
seamlessly,
so
in
any
of
these
cases
for
the
iot
device,
it's
it
is
transparent
to
to
this
device
how
it
is
done.
So
I
think
we
think
this
is
also
another
of
the
advantages
of
of
using
this
co-op
if
schema.
So,
if
we
go
to
the
next
slide,
please
here
is
actually
the
current
flow
of
operation
of
graph
e,
how
it
works
currently
is
we
have
the
first
message
that
it
is
a
trigger
message
that
is
actually
optional.
F
F
Nonetheless,
even
though
we
choose
to
use
oscor
for
securing
this
specific
service,
we
are
able
also,
with
the
key
material
that
we
derive
from
the
ip
authentication
to
establish
further
security
associations.
F
If
they
are
needed
for
other
services,
for
instance,
we
could
we
could
establish
a
dps
connection
or
any
other
security
exchange
that
we
should
establish
if
needed
and
well
in
this
case,
we
are
assuming
that,
where
using
several
characteristics
of
co-op
that
are
out
of
our
control
in
some
cases,
that's
part
of
the
discussion
in
the
next
slide.
If
we
can
move
forward,
please
so
in
this
design,
we
put
a
new
option.
F
That
is
a
signal
function
to
provide
a
order,
delivery
for
the
messages
of
it,
but
if
we
are
able
to
influence
in
some
way
the
the
co-op
engine,
if.
E
F
F
In
this
case,
this
would
be
possible
based
on
the
fact
that
we
are
assuming
that
this
initial
phase,
the
bootstrapping
faces
done
before
anything
or
any
any
any
other
transaction.
So
we
could
do
that.
We
would
not
have
any
anything
else
in
parallel.
F
We
we
could,
in
this
case,
also
not
use
the
second
option
if
we
can
use
the
message
id
in
a
piggyback
exchange
and
we
don't
have-
and
we
do
not
have
any
other
parallel
transactions
to
assure
the
the
order
in
which
the
messages
are
exchanged,
in
any
case
being
an
ip
exchange,
it
is
already
assumed
to
be
in
lockstep,
so
we
should
not
have
any
issues
if
we
can
proceed
with
this
kind
of
optimizations.
F
If
we
are
assuming
that
we
have
a
club
engine
that
we
can
influence
in
some
way
in
any.
In
any
case,
the
initial
design
is
done,
assuming
that
we
don't
have
any
control
over
the
clap
engine.
I
think
that's
all
for
now,
if
you
have
any
questions.
G
Well,
I
gotta
admit
I
haven't
read
the
draft
yet,
but
that's
that
kind
of
control
is
something
that's
usually
recommended
for
in,
in
the
sense
that
you
can.
You
can
make
those
recommendations
to
implementation
so
that
they
can
be
more
efficient,
but
they
can't
expect
other
implementations
to
make
the
same
optimizations.
F
Okay,
so
we
should
go
you're,
saying
which
it
was
with
the
assumption
that
we
cannot
influence
the
the
co-op
engine
and
we
should
do
it
independently
of
that
right.
G
A
So
I
can
see
on
the
chat
a
comment
from
muhit,
so
I'm
gonna
read
it:
can
we
not
have
bullets
in
abstract?
The
inner
section
is
incorrect.
It
should
request
ayanna
to
assign
a
value
for
co-app
as
a
lower
layer
in
the
eep
registry.
F
Thank
you
mohit.
Yes,
these
are
also
part
of
the
optimizations
that
we
all
have
in
mind.
But,
as
you
say,
we
we
should
do
some
more
riches
research
in
this
sense
because
we
may
use,
as
you
say,
the
message
id.
F
If
we
have
some
some
control
over
them
and
they
are
monotonically
increased,
then
we
we
could
in
some
sense
substitute
this
the
values
for
the.
If
request
and
response
id,
the
the
sequence
numbers
in
this
in
the
message
could
be
also
integrated
with
the
co-op
value.
So
thank
you
very
much
mohit
for
this
point.
That
is
something
that
we
looked
for,
but
we
we
actually
didn't,
define
it
yet.
But
thank.
E
F
A
So
maybe
a
clarification
question:
if
you
want
to
optimize
those
two:
are
you
gonna?
Are
you
going
which,
which
is
the
protocol
you
you?
You
are
going
to
left
unchanged.
F
Thing
is
that
I
think
club
should
not
be
changed.
We
should
be
able
to
leverage
the
numbers
in
co-op
or
create
some
sort
of
adaptation
in
the
in
the
crap
application
to
send
to
the
if
the
state
machine,
the
values
that
it
is
expecting.
So
I
think
we
should
we.
We
should
try
to
avoid
modifying
the
if
state
machine
as
much
as
possible
to
keep
it
standard.
F
A
F
A
Yeah,
so
I
think
muay
said
he
adds
something
to
the
chat
is
I
am
guessing
that
you
can't
easily
change
control
either
of
the
implementations.
A
E
F
Yeah,
that's
that's
why
why
I
asked
if
we
should
look
at
the
possibility
of
influencing
over
the
co-op
engine?
So
if
we
can
choose
our
token
and
we
can
choose
also
to
monitor
monotonically
increase
the
message
id
once
it
is,
the
first
is
chosen,
then
we
can
do
all
these
optimizations
fairly
easily.
I
think
we
can
also
do
it
do
them.
F
We
have
a
little
bit
more
of
experimentation
and
burdening
the
co-op
application
so
to
speak.
So
we
would
need
to
to
add
all
this
logic
in
charge
of
adapting
what
is
getting
from
the
co-op
layer
to
goes
and
what
it
goes
to
the
hip
layer.
To
date,
the
steady
machine,
the
crap
application
should
be
in
charge
of
managing
all
this
complexity,
and
I
think
it
might
be
interesting
to
look
for
if
that
is
possible,
and
how
much
can
we
achieve
giving
this
this
intelligence
to
the
to
the
co-op
application?
B
I
think
the
the
the
main
reason
to
use
squab
is
that
that
this
is
a
protocol
that
has
been
implemented,
and
if
you
make
demands
on
the
corp
implementation
that
are
not
usually
met
by
implementations,
then
then
you
don't
win,
but
what
you
actually
can
do
is
is
use
properties
of
co-op.
B
So,
for
instance,
you
know
that
there
is
some
some
detection
of
duplicate
messages
and
so
on,
and
you
can
use
these
properties
as
opposed
to
to
trying
to
influence
the
actual
header
fields
and
giving
them
different,
meaning
that
that's
not
going
to
work
very
well.
F
Okay,
so
yeah
we,
we
should
look
for
the
inherit
characteristics
of
of
co-op
without
any
demands
over
the
co-op
engine
and
try
to
do
the
modifications
on
our
optimizations,
assuming
that
we
we
are
getting
a
standard
co-op
and
we
don't
have
any
knowledge
of
what
are
we
going
to
get
in
terms
of
token
or
or
message
id
order,
randomization,
etc.
Okay,
thank
you.
A
H
Can
you
hear
me?
Yes,
okay,
okay,
so
this
is
rafa
from
university
of
murcia
authoring.
This
idea
as
well.
So
regarding
your
questions,
obviously
the
main
reason
of
using
the
sequence
number
option
is
because
if
you
check
the
flow
of
for
exchanges
they
packets,
we
need
to
keep
the
that
sequence.
H
So
then
we
thought.
Okay,
let's
include
this
this
option,
so
we
can
assume
that
co-op
as
a
protocol
can
use
any
message
id
it
wants
or
token
value
whatever.
So
we
are
abstract
our
application
for
for
from
the
implementation
so
and
that's
why
we
included
that
because
we
wanted
to
if
you
check
the
flow.
As
I
said,
then
you
need
this
log
step
protocol.
Then
you
need
one
message
and
wait.
Wait
for
that
sequence!
Number!
H
When
you
send
a
sequence
number,
you
wait
for
the
the
the
number
back
in
the
answer.
Then
we
also
thought
okay.
If
there's,
there
is
any
way
to
get
rid
of
the
sequence
number
option.
If
you
are
using
some
kind
of
mix
of
a
message
id
or
token
values.
That's
some!
That's
our
our
main
question.
H
So
if
we
can
do
that
as
dan
mentioned,
if
we
can,
from
an
application
part
to
say
to
the
club
engine
okay,
I
would
like
to
set-
or
this
message
id
or
this
token
value
we
can
get-
can
we
get
get
rid
of
the
sequence
number?
That
was
our
question.
H
That
is
the
question
is
in
the
in
the
slide,
but
at
the
beginning,
just
in
case
we
included
the
sequence
number,
that's
we
have
a
requirement
and
the
requirement
is:
is
there
thanks
to
the
sequence
number
option
so,
but
we
have
an
open
question:
if
okay,
let's
see
if
we
can
or
let's
discuss
if
we
can
get
rid
of
that
observed
option,
that
was.
That
was
a
question.
A
E
So
I
I'm
not
100.
I
just
want
to
note
that
the
state
machine
is
pretty
sensitive
or
finicky,
and
so
even
slight
modifications
to
the
eep
state
machine
can
cause
security
problems.
F
What
I
said
why
I
said
that
I
I
would
like
to
keep
the
the
heat
machine
if
state
machine
out
of
the
modifications-
and
if
we
are
trying
to
do,
is
to
optimize
the
bytes
sent
of
the
network
and
we
are
going
to
send
to
reuse
or
do
a
mapping
between
the
message
id
that
is
sent
in
co-op
and
the
message
and
the
in
the
and
the
sequence
id
that
we
need
to
send
to
the
itmas
to
the
ipstade
machine.
For
that.
If
message
that
is
being
implied,
that
burden
should
fall
into
the
co-op
application.
F
A
H
Yes,
the
guardians
regarding
ben's
question:
in
my
point
of
view,
there
is
no
need
to
change
any
ips
state
machine.
I
mean
the
if,
if
standard,
it's
clears
about
the
requirements
that
we
need
to
implement
in
a
hip,
lower
layer
and
in
this
case
co-op
is
acting
as
a
global
layer.
H
So
I
wouldn't
go
for
any
kind
of
optimization.
Looking
at
the
ebsta
machine,
the
invention
machine.
Is
there
it's
standardized?
We
have
the
implementation,
it's
already
well
known
and
it's
working
and
it
requires
something
from
the
eblower
layer
and
one
of
the
things
is
and
that's
why
we
have
the
sequence
number
option.
So
in
that
sense,
regarding
ben's
concern,
I'd
say
there
is
no
need
at
all
to
change
anything
in
ebay,
state
machine.
I
wouldn't
go
that
way.
Of
course,
we.
H
A
Yeah,
so
if
we
look
at
the
architecture,
you
have
the
co-op
layer
and
you
have
the
hip
layer.
Thus
we
don't
really
want
to
change
them
much,
but
you
might
have
a
compression
layer
in
between
that
might
takes.
A
When
you
receive
packet,
you
might
take
some
parameters
from
the
co-app
and
generate
those
expand
those
to
the
heap
so
that
when
the
the
uncompressed
packet
it
hits
the
it
software
it's
it
doesn't
it
doesn't
change
at
all.
Is
that
how
it's
going
to
be
architectured.
E
F
F
Be
the
idea
yes
daniel
to
to
to
do
this,
this
little
compression
part
inside
the
the
co-op
application,
if,
if
at
all
possible,
yes,.
A
Okay,
so
just
one
comment:
if
we
look
at
compression
there
is,
there
is
some
something
that
is
called
chic,
so
it
might
at
some
so
you're
aware
of
that.
A
F
Also
another
one
of
the
or
places
where
we
are
looking
at
to
to
optimize
grab
it
further,
even
maybe
to
another
use
cases.
We
actually
tried
this
this
graph
eep
on
lp1
networks
and
it
seems
to
work
without
any
compression.
A
Okay,
good,
so
we
can
also
think
of
splitting
the
work
I
mean
uncompressed
and
then
not
everything
needs
to
be
in
the
same
document.
So
just
to
let.
F
A
Know
so,
thank
you
very
much
for
this
presentation.
Thank
you.
I'm
just
checking.
We
have
no
additional
questions
comments.
Checking
in
this
chat,
I
don't
see
much
so
I
propose
we
go
to
the
pub
sub
profile
with
signum.
I
Okay,
this
is
just
a
quick
update.
This
profile
is,
it
was
proposed
by
francesco
palombini
and
I
was
invited
to
add
information
about
the
mqtt
case.
So
before
we
push
a
new
update
on
this
document,
I
decided
to
bring
a
few
points
to
the
working
group
to
help
us
decide.
I
So
we
restructured
the
documents
to
explain
both
co-app
and
mqtt
solutions.
The
mqtt
solution
is
very
similar
to
the
co-app
case.
The
main
difference
is
that
in
the
mqtt
client
for
the
mqtt
clients,
we
don't
separate
the
publisher
subscriber
role
that
much.
We
assume
that
each
client
can
have
both
type
of
responsibilities
and
we
also
authorize
the
subscriber
clients,
which
will
become
a
little
bit
more
clear
in
the
next
slides.
I
The
things
that
we
we
would
need
to
do
is
a
bit
more
clarification
on
the
scope
parameter,
which
is
at
the
moment,
described
as
strings,
and
it
should
acknowledge
that
it's
aif
as
well,
especially
for
mqtt,
which
expects
that
format
in
the
scope
and
then
resolve
the
discussion
points
which
I
will
bring
in
the
next
slide.
I
The
current
architecture
assumes
there
are
two
as
entities
as1
and
as2,
which
is
the
as2,
is
separated
to
do
a
joint
functionality
of
both
as
and
a
key
distribution
center.
I
The
way
that
the
as1
works
it
gives
tokens
out
for
publisher
to
be
able
to
publish
topics
to
broker
and
as2,
basically
creates
the
security
context
for
publishers
and
subscribers
to
get
the
keys
to
protect
the
messages,
basically
publish
the
topics
or
so
the
way
that
it
is
described.
The
main
advantage
is
that
the
subscriber
doesn't
need
to
get
another
token,
to
authorize
to
the
broker
as
long
as
it
can
get
keys
from
the
as2,
and
then
it
can
do
it
in
one
shot.
It
just
can
do
authorize
and
join
in
one
shot.
I
I
The
proposed
change
is
basically
treating
as
a
single
as
if
the
application
desires
it,
it
can
be
divided
into
as1
and
as2,
and
it's
not
expected
by
default,
but
as
desired.
How
to
synchronize
those
as's.
I
I
So
it
can
provide
a
more
simpler
explanation
of
how
things
could
be
set
up
in
terms
of,
and
it
also
makes
things
a
little
bit
easier
for
published
subscriber
clients
both
being
authorized
against
the
broker.
But
in
that
case
the
subscriber
needs
to
get
the
token
and
then
approach
the
kdc
to
get
the
keys.
It
cannot
do
in
its
one
shot,
so
that
can
be
considered
as
a
cone.
I
The
tokens
that
they
receive
from
the
ais
can
be
multiple
audience
and
can
be
used
towards
kdc
and
broker,
or
we
might
think
of
other
structures
if
you
know
assigning
multiple
tokens
and
etc.
If
the
work
group
desires
it
next
slide,
so
this
issue
actually
has
been
discussed
in
the
working
group
list.
It
was
brought
up
by
me
and
I
also
noticed
that
jim
brought
it
up
earlier
in
his
review
of
the
text.
I
So
the
point
that
he
also
mentioned
was
that
as1
and
as2
are
independent,
appliers
of
access
control,
logic
and
they
should
be
coordinated,
and
the
counterpoint
which
was
raised
by
francesca
was
that
they
do
have
separated
functions
and
it's
up
to
the
application
to
decide
how
to
coordinate
them.
And
then,
when
jim
raised
like
what
happens
when
a
token
has
been
revoked
in
one,
how
that?
How
does
that
get
synchronized
again?
The
counterpoint
was
that
the
revocation
is
a
working
group
level
solution.
I
I
guess
the
one
thing
that
we
would
like
to
have
clarification
on
is
whether,
as
coordination
or
as
policy
synchronization
is
an
application,
specific
problem
or
a
problem
that
needs
to
be
resolved
in
the
document
in
this
document.
So
that's
one
question
and
when
discussing
with
francesca
we're
fine
with
either,
but
we
need
to
have
a
clear
decision
on
this.
I
Slide-
and
the
second
discussion
point
is
about
handling
multiple
group
joinings,
so
the
way
that
the
pub
sub
uses
the
group
com
is
that
the
topic
names
are
used
as
group
names,
and
this
is
this
is
slightly
different
in
mqtt
case
as
mqttk
is,
when
the
topics
are
topic
filters
and
the
way
that
mqtt
organizes
the
topic.
Trees
is
that
it
is
a
topic
tree
and
in
the
kdc.
I
The
different
sections
of
this
tree
might
be
keyed
differently.
So
if
this
is
not
transparent
to
the
client-
and
I
will
describe
in
the
slide
the
case
when
it
is
not
transparent
to
the
client-
is
that
the
client
might
be
asking
for
a
topic
filter
and
it
might
find
itself
in
two
cases.
The
first
case.
It's
it's
topic.
Filter
is
a
subset
of
that
keyed
section.
So
it
can.
It
gains
access
to
the
to
keys
that
kind
of
apply
to
a
larger
set.
I
This
is
not
an
issue
because
we
authorize
both
publishers
and
subscribers
at
the
broker
level,
so
they
would
not
be
able
to
ever
get
publish
or
subscribe
permissions
at
the
broker
to
gain
access
to
any
of
those
messages.
Anyway,
so
this
is
kind
of
a
handled
case,
but
it
is
just
showing
why
we
need
subscriber
authorization
at
the
broker
for
mqtt
case
the
second
option.
I
The
second
case
that
the
client
can
find
itself
is
that
it's
a
topic
request,
spends
multiple
groups
and
that's
kind
of
something
that
is
not
inherently
handled
at
the
moment
being
able
to
join
multiple
groups
in
one
shot
and
there
might
be
solutions
thought
around
it,
but
this
needs
a
bit
of
more
clarification,
so
the
first
question
would
be:
would
the
client
be
expected
to
know
how
topics
are
keyed
or
groups
are
created
at
the
kdc?
I
That's
it,
and
once
these
discussion
points
are
resolved,
we
would
be
good
to
move
forward
and
submit
another
version.
A
The
and
that
the
sig
name
has
been
raising
I'm
wondering
if
anyone
has
any
thoughts
on.
A
A
So
does
anyone
so
I
understand
anyone.
There
is
not
anyone
disagreeing
with
that.
Do
we
have
anyone
strongly
agreeing
with
that
or
we.
A
A
Well,
so
I
think
we
we're
gonna
wait
for
the
next
version
and
well
at
least
so.
A
Yeah,
that's
that's
how
I
see
the
things.
I
A
I
don't
I
I'm
and
I'm
just
one
I
I'm
I'm
a
little
bit
unsure
about
the
second
issue,
so
I'm
just
wondering
if
folks
in
group,
com
or.
I
Now
it
is
more
an
issue
of
whether
I
have
the
right
tools
to
work
around
this,
and
one
can
say
that
the
way
that
the
groups
are
created.
I
Can
you
hear
me
now
yeah?
Okay,
I
think
the
the
first
issue
is
that
the
topic
filters
might
suggest
multiple
groups
which
the
client
may
not
be
aware
of
which
groups
do
they
correspond
to.
Basically,
so
it's
more
about
handling
multiple
groups
and
joining
multiple
groups
with
a
single
topic
filter-
and
this
is
only
an
mqtt
issue-
I'm
not
too
sure
how
co-app
is
trying
to
get
permission
for
multiple
resources,
but
in
the
mqtt
case
you
can
refer
to
multiple
resources
by
using
these
wildcards.
I
I
I
Yes,
that
is
true.
That
is
true.
The
you
know,
if
the,
if
the,
if
the
client
gets
access
to
those
topics
by
another
channel
than
the
broker,
they
can
read
it.
That
is
true,
but
this
is
again
an
issue
of
how
things
are
grouped
and
how
they
are
keyed
and
whether
client
requests
need
to
be
exact
versus
a
subset
or
superset.
I
I
I
guess
we
can
solve
this
at
the
application
layer
and
not
have
any
flexibility,
and
if
that's
the
suggestion
by
the
group,
I
would
follow
it.
You
know
they.
There
is
a
clear
application,
specific
requirement
of
how
topics
are
grouped
and
you
have
to
get
the
exact
group
membership
to
be
able
to
reach
and
write
to
any
part
of
that.
I
J
Yeah,
mostly
a
question
at
the
beginning,
I
suppose
the
answer
is
no,
but
just
to
be
sure
does
this
require
any
adaptation
change
in
the
ascii
group,
calm
document,
because
because
this
is
an
application
profile
of
that
one
right.
I
Yeah,
no,
that
that's
what
I
am
trying
to
avoid
by
using
the
existing
existing
apis
provided
by
the
by
the
group
com,
I'm
just
trying
to
figure
out
what
is
the
best
way
to
address
this,
either
by
being
too
strict
at
the
application
and
making
the
clients
request
exact
groups
with
those
exact
topic
filters,
so
there's
no
asking
for
a
subset
of
a
group
or
a
superset
of
a
group
or
multiple
groups,
or
if
we
are
being
flexible,
then
I'm
thinking
about
how
to
provide
that
flexibility
without
affecting
security
or
by
asking
joining
multiple
groups
using
the
existing
group
com
features.
J
Right,
hopefully,
a
feedback
about
that
keygroup,
comma
score
works
in
a
slightly
different
way,
I
suppose
easier
than
what
you're
facing
now,
because
the
idea
is
to
join
one
group
at
a
time,
but
we
are
talking
about
security
groups
there.
So
the
moment
you
join
it,
you
get
the
key
material
for
that
group
and
that
security
group
only
right.
J
So
even
if
a
token
can
grant
you
access
to
multiple
groups,
you
do
the
join
one
security
group
at
the
time
and
again,
the
key
material
is
exclusive
for
that
security
group,
the
I
guess
the
coupling
you're
talking
about
within
security
groups
and
other,
I
would
say,
application
level
groups
like
like
topics,
that's
something
that
we've
been
doing
in
core
by
the
way
in
a
way
that
we
define
as
separate
things,
security
groups
and
application
groups,
and
you
can
have
a
one
too
many
or
made
many
mapping
so
not
sure
if
it
helps
just
just
wanted
to
raise
it.
J
I
I
think
that
is
that
is
a
that
looks
like
a
promising
approach
to
do
as
well
having
a
security
group
and
have
the
and
then
you
said,
one-to-many
mapping
right
so.
J
Essentially,
you
may
have
the
case
where
multiple
application
groups
use
a
same
security
group,
which
would
mean
you
get
one
bunch
of
keys
that
you
will
use
in
any
of
those
application
groups,
and
this
is
the
the
easy
safe
case.
The
other
way
around
is
more
tricky
when
you
have
one
application
group
using
one
of
possible
many
security
groups,
and
if
you
do
that,
you
may
have
some
reasons
for
that.
We
documented
it's
a
bit
more
tricky.
J
I
Sorry,
I
just
had
to
reconnect
it's,
but
I
could
hear
you
all
that
time.
I
think
it
is
a
promising
way
to
look
at
it
and
see
whether
conceptually
security
groups
and
application
groups
can
be
separated
and
it
serves
the
different
purposes
that
the
mqtt
clients
are
trying
to
protect
the
messages
when
they
are
submitting
to
multiple
topics,
for
instance
where
subscribing
to
multiple
topics.
Yes,
thank
you
very
much
for
that
link
and
I'll
look,
and
that
could
be
very
helpful.
A
A
So,
let's
move
to
the
next
presentation,
so
so
for
all
those
three
drafts
that
have
been
proposed,
I
see
that
the
cmpv2
is
pretty
close
to
to
be
ready.
So
maybe
maybe
we
can
plan
that
for
the
next
interim
meetings
for
the
other
two,
I
see
that
we
we
may
go
for
through
more
updates,
so
yeah
for
the
next
interim
meeting.
I'd
like
that,
we
can
continue
that
conversation
on
the
progress.
A
J
That's
mine,
oh,
you
meant
the
grouposcar
profile
before
yeah
sure
that's
possibly
for
later
keygroup,
I
guess
is
the.
J
Next,
thank
you,
daniel
right,
hello,
everyone.
This
is
an
update
of
the
ac
group
com
document,
of
which,
by
the
way,
the
pub
sub
document
presented
before
is
one
of
the
application
profiles
next
slide,
please
so
yeah
just
to
recap,
I
guess
you've
seen
that
many
times,
but
the
idea
is
to
have
one
kdc
deployed
that
can
be
accessed
in
principle
as
a
resource
server
bearing
the
ownership
of
an
of
an
issued
access
token
for
a
client
when
they
intend
to
issue
the
request
to
join.
J
A
group
of
some
kind
depends
on
the
application
process,
specifically
the
finding
that
and
retrieving
in
the
joining
response,
the
key
material
that
has
to
be
used
once
a
group
member
and
then
the
particular
details
on
the
exact
key
material.
It's
encoding
how
it's
used
with
wall
security
protocol,
that's
up
to
the
particular
application
profile
to
be
defined
for
for
this
document,
and
here
the
biggest
thing.
J
Yeah
there
have
been
a
lot
of
updates
actually
in
this
version,
considering
feedback
already
from
the
november
meeting,
and
discussions
in
two
of
the
past
a's
into
him.
So
most
was
about
closing
the
raised
open
points.
J
J
The
first
non-editorial
thing
is
the
last
point
here
that
was
discussed
some
of
the
interim
following
some
comments.
We
we
had
found
a
possible
reason
why
a
group
member
can
observe
its
own
well
dedicated
personal
resource
at
the
kbc.
J
It
has
the
advantage
at
the
moment,
for
whatever
reason
that
node
is
evicted
from
the
group
is
just
automatically
because
of
the
way
observe
work
get
a
notification
of
being
evicted.
So
it's
just
a
convenient
way
for
the
kdc
to
inform
of
the
happened,
eviction
and
so,
first
of
all,
that's
what's
actually
defined
and
following
some
recommendations
from
the
group,
we've
also
included
some
totally
non-prescriptive
text,
just
as
an
undercase
recommendation.
J
Oh
by
the
way,
if
you
want
to
to
avoid
multiple
notifications,
telling
you
almost
the
same
thing
from
different
resources,
you're,
possibly
observing
at
the
kdc,
you
may
want
to
use
together
observation
and
the
no
response
feature
of
of
co-op.
But
since
we
know
that
there's
not
much
known
support
of
observe
and
no
response
used
together,
this
is
just
included
there
as
as
a
free
suggestion
with
no
prescriptive
intention
at
all
building
all
the
feedback
we
got
at
least
okay
and
next
slide.
Please.
J
J
J
I
want
the
the
public
keys
over
the
groups
and
it
allows
you
to
specify
some
kind
of
filtering,
because
perhaps
you
don't
you
don't
want
all
of
them
now.
The
filtering
was
already
based
on
the
roles
of
some
of
the
group
members
that
they
have
in
the
group
and
on
their
non-identifiers.
J
So
first
so
good
with
the
first
one
on
the
roles,
but
the
second
one
on
the
ids
was
in
previous
versions,
considered
considered
only
in
an
inclusive
way.
So
you
you
could
indicate
the
ideas
of
which
you
want.
The
public
is
back
and
we
discuss
the
possibility
instead
to
help
ourselves
with
inclusion
of
one
additional
boolean
flag
at
the
beginning
of
this
parameter,
so
that
if
the
value
is
true,
the
ids
filter
is
used
as
it
was
used
so
far,
inclusive
or
a
false.
J
It's
exclusive,
like
I
want
the
public
keys
of
other
group
members
as
long
as
it's
not
from
this
exact
node
ids,
perhaps
cause
I've
been
in
the
group
for
a
long.
While
I
already
have
the
public
use
of
those
ids.
I
need
the
public
keys
of
any
other
nodes
that
joined
after
my
my
last
public
key
retrieval,
so
basically,
one
more
flag
in
the
structure
parameter,
if
true
same
as
always,
if
false
exclusive
ids
filter.
J
So,
as
I
said,
this
is
used
in
two
occasions.
One
is
the
journal
request
and
well
that
was
pretty
trivial
to
adapt,
because
we
were
already
saying
all
the
way.
You
cannot
really
use
any
id
filtering
at
that
point
in
time.
So
you
can
see
the
the
final
inner
array
is
empty.
So
for
consistency
with
the
overall
format,
we
are
proposing
well,
the
flag
is
set
to
true,
and
that
was
pretty
easy
to
address
next
slide.
Please.
J
Yeah,
when
considering
the
other
case
well,
the
parameter
is
used
in
a
in
a
fetch
request
to
the
sub
resource
of
the
kdc
to
retrieve
public
keys
of
our
group
members.
Things
started
to
become
tricky,
as
I
was
really
writing
this
down
and
eventually,
when
I
implemented
that
in
the
in
the
application
profile
for
for
grupo
score,
and
I
nailed
down
this
these
five
cases
and
they
are
sorted
ironically,
in
an
increasing
order
of
complexity.
J
J
The
second
case
you
want
to
filter
only
by
node
identifiers,
okay,
so
the
the
first
inner
array
is
empty
in
the
second
one
you
have
no
identifiers,
and
the
boolean
is
true,
say
you
want
to
to
filter
in
an
exclusive
way
based
on
node
identifiers
well
same
as
above.
Just
the
flag
is
false.
J
It
becomes
tricky
when
you
want
to
filter
both
on
roles
and
node
identifiers.
At
the
same
time,
I
had
to
come
up
with
something
that
that
I
could
code
and
run
so
I
I
ended
up
with
this.
If
I
specify
both
and
I
indicate
the
flag
as
true,
it
means
I'm
fine,
with
whatever
matches
with
the
roles
I
indicate
and
or
any
of
the
sender,
ids
sorry
node
ids.
J
So,
first
of
all
I
would
like
some
feedback
on
is
this
finite?
Am
I
missing
any
hazel
together
and,
on
the
other
end,
to
reassure
yes,
it's
still
possible
to
retrieve
just
all
current
public
keys
in
the
group
talking
to
this
resource,
just
sending
a
get
request,
rather
than
a
fetch
request.
J
J
Well,
that's
one
possible
interpretation,
totally
arbitrary
from
my
side.
I
I
believe
it
made
sense,
but
of
course
other
interpretations
might
be
better.
A
J
A
Yeah,
I
I
think
we
need
a
pen
too
and
two
and
and
some
time
to
to
look
at
all
those
combinations.
So
it's
good
to
have
more
homework
for
the
working
group.
J
Yeah,
okay,
next
slide,
please
right!
This
was
also
another
thing
discussed
at
the
interim
and
we
we
had
an
agreement
also
to
to
address
this
most
likely.
We
consider
a
case
where
the
keys
in
the
group
are
practically
coded
as
cosy
keys,
but
in
general
we
are
admitting
possible
different
encoders
that
will
will
have
to
be
signaled
properly.
J
Of
course,
the
nice
thing,
of
course,
the
keys
is
that
they
embed
as
an
inner
parameter,
the
node
identifier
of
the
group,
which
in
fact
we
are
using
if
we
use
exactly
cos
keys
since
we
are
open
for
other
formats.
J
One
day,
someone
may
want
to
use
a
different
key
encoding
that
does
not
provide
internally
a
parameter,
an
element
that
can
be
used
right
away
to
encode
the
node
identifier,
and
in
that
case,
though,
the
node
identifier
is
an
information
still
to
be
provided
to
the
joining
node.
Somehow
so
to
handle
this
case,
where
the
used
coding
for
the
keys
does
not
allow
to
specify
the
node
identifier,
we
have
defined
a
separate,
well
floating,
parameter
to
be
included
separately
in
the
joining
response.
J
A
J
Okay,
so
basically
you'd
be
good
and
useful
to
use
this
new
parameter
even
in
case
cozy
keys
are
used
if
understand
correctly,.
E
J
A
So
do
we
conclude
on
that
or.
A
J
I
think
we,
I
think
we
discussed
already,
that
having
this
parameter
was
useful
anyway
to
to
accommodate
any
possible
future.
Encoding
of
public
is
really
not
admitting
doing
this
at
all
and,
of
course,
it's
an
optional
parameter
that
you're
not
going
to
use.
If
you
don't
really
need
it,
but
at
least
it's
available.
J
J
So
it
was
easy
to
to
agree
on
returning
for
zero
zero
in
in
the
particular
case
of
well,
the
payload
is
just
not
as
expected
as
just
a
multiform
request
compared
to
the
expectation
when
we
started
to
discuss
about
a
situation
where
it
seemed
good
to
return
five
zero,
three
well,
five,
zero
three
percent
was
good,
but
I
think
karsten
also
added.
J
It
can
also
mean
anything,
so
you
may
want
to
add
something
more
than
than
just
the
the
error
code
to
clarify
what
actually
happens,
and
the
suggestion
was
to
look
at
the
problem
details
document
in
core
now.
J
I
started
that
and
tried
to
find
the
balance
between
within
that
proposal
and
what
has
already
been
doing
in
in
ace
looking,
especially
at
the
errors
that
the
authorization
server
can
return
that
essentially
can
indicate
an
integer
indicating
an
error
type
and
then
an
optional
text
string
to
possible
possibly
give
more
more
explanations
and
that
developed
into
producing
a
list
of
possible
error
types
that
I
would
say
already
apply
in
general
in
this
key
group
com
document,
even
before
thinking
of
any
specific
application
profile-
and
I
could
think
of
this-
seven
error
types
summarized
here.
J
Fortunately,
we
are
already
defining
a
content
format
here.
Application
is
group
com,
placebo
that
we
are
using
overall
in
the
document
and
in
the
process
so
essentially
building
on
that
and
for
most
of
the
error
responses,
it
is
actually
possible
very
easily
to
return
and
it's
it's
meaningful
and
feasible
for
most
of
them
to
return
one
of
these
integers,
giving
more
more
information
already
to
the
client
and
hopefully,
optionally,
also
an
additional
texturing
with
with
more
details.
J
A
Well,
as
you
mentioned
since
we,
we
have
this
ace
group
com
plus
c
board,
we're
not
squatting
any
any
good
point,
so
any
other
feedback.
J
J
Yeah
thanks-
and
this
is
the
the
last
point
that
we
discussed
in
in
both
past
interims
and
it's
the
only
open
issue
left
on
github.
Actually,
I
prefer
really
not
to
close
it
and
come
back
to
you
today.
First
just
to
recap,
this
is
a
broader
thing.
J
The
client
simply
posts
an
access
token
at
the
kdc.
It's
a
pack
for
the
client
and
and
in
the
token,
that
the
kbc
can
eventually
access
a
scope
is
just
a
c
or
by
string,
and
that
can
mean
many
different
things
can
have
a
format
and
the
semantics
that
can
really
depend
on
the
application
or
the
application
profile.
J
A
problem
is
that
exactly
that
point
in
time
where
the
kvc
receives
the
token
it
has
to
to
know
how
to
parse
and
and
interpret
the
receiver
by
string
encoding
the
scope,
so
it
has
to
know
kind
of
in
advance
or
have
a
kind
of
hint
of
what
semantics
to
consider
to
parse
to
pass
scope.
J
We
got
an
early
feedback
from
ben
that
it
seemed
correct
to
consider
these
kind
of
things
more
than
others
to
have
overall
a
cleaner
way
out,
possibly
involving
registrations.
In
fact.
J
Which
is
essentially
a
revised
version
of
the
only
point
I
I
had
time
to
go
through
at
the
latest
interior.
That
does
seem
to
be
okay,
at
least
for
for
the
attendees
at
the
time.
J
So
the
idea,
of
course,
is
to
start
from
the
original
scope,
as
the
authorization
server
is
supposed
to
to
produce.
I
just
encoded
as
a
symbol
by
string
but
optionally,
the
the
authorization
server
as
the
possibility,
in
the
access
token
to
specified
a
scope
in
an
an
extended
format,
and
I
would
just
highlight
it
now
in
the
latest
submitted
version
of
the
draft
following
feedback
from
kirsten
that
that
this
is
yeah
pretty
general.
The
applicability
of
this
is
not
limited
to
this
document.
J
It
can
be
just
taken
and
reused
in
any
other
application,
or
application
profile
is,
as
I
understood,
especially
from
you,
daniel
that
it's
all
in
all
appropriate
to
have
this
in
this
document.
As
long
as
it's
a
very
well
recognizable
section,
and
now
it
isn't
in
the
document
body,
but
the
mechanics
of
the
proposal
are
the
same
and
and
starting
from
the
vanilla
scope
as
it
should
be.
J
Without
any
of
this,
which
means
the
the
the
green
box,
you
can
see
that
also
a
register
in
integer
indicating
the
the
exact
semantics
to
be
used
to
parse
to
periscope
and
that's
the
yellow
box.
Then
you
build
a
cbr
sequence,
putting
together
the
integer
indicating
the
semantics
and
scope,
and
then
you
drop
the
sequence
into
symbol
by
string
that
you
tag,
because,
unfortunately,
the
end
of
the
day
scope
in
the
token
is
to
be
a
silver
buy
string.
J
So
the
price
for
this
is
one
single
cbor
tag
registered
just
to
say
this
is
an
extended
format,
scope
and
then
you
can
register
integers
to
indicate
the
semantics
used
to
encode
the
scope
and
they'll
solve
the
problem
at
the
kdc
when
we're
receiving
the
token,
because
other
than
simple
cases
where
well
one
semantics
only
supported
for
one
particular
application,
only
the
kdc
can
have
an
explicit
hint
or
how
to
progress
in
processing.
J
J
Okay,
so
I
suppose
they
will
mean
for
your
document
registering
a
particular
integer
corresponding
to
the
semantics.
You
have
in
mind.
I
I
Sorry,
I
I
just
wanted
to
clarify
that.
Indeed,
we
use
a
iaif
as
well
in
mqtt
to
to
describe
the
scope
and-
and
this
scope
I
think,
is
very
much
important
in
the
pub
sub
document
as
well
when
communicating
the
permissions
to
the
kdc.
J
And
by
the
way,
in
a
particular
application
profile
like
the
pops
up
profile,
you
may
want
to
indicate
that
your
kdc,
sorry,
your
authorization
server,
is
strongly
recommended
to
use
this
just
in
case
to
avoid
confusion
or
or
the
kdc,
not
knowing
what
to
do
later
on.
Unless
you,
you
know
very
well
that
that's
the
only
kind
of
application
your
case
is
running.
J
B
J
J
Probably
the
only
tricky
thing
to
handle
here
is
avoiding
squatting
of
semantics.
I
mean
we
don't
want
the
two
identical
semantics
accidentally
consumed
two
code
end
points,
while
the
the
second
to
arrive
semantics
can
just
realize.
Oh
I'm
just
the
same
as
an
old
one,
that's
actually
the
integer.
I
I
should
use
here.
E
So
I
tried
turning
on
my
microphone
early.
I
don't
know
if
that
helps
christian,
but
I
mostly
just
wanted
to
clarify
that
sort
of
the
the
actual
explicit
tag
is
kind
of
the
key
part
here,
and
so
I
wanted
to
ask:
are
there
any
cases
where
you
would
want
to
use
or
be
able
to
use
this
extended
scope
format
without
the
explicit
tag.
J
J
I
can't
think
of
any.
I
can't
exclude
it
either,
so
that
would
save
the
tag
on
the
wire,
but
it's
probably
overall
harder
to
manage
right.
Doesn't
it.
G
J
Yeah,
the
tag
is
just
telling
you
pass
this
as
a
sequence
of
two
elements
which
will
tell
you
what
this
is
exactly
about.
J
It's
probably
related
to
the
question
from
ben
you'd
work.
If
you
know
in
advance
it
is
always-
or
it
is
never
an
extended
format-
scope
which
is
probably
harder
to
to.
J
J
Okay,
my
interpretation
that
this
is
overall
aligned
with
the
original
proposal
and
and
addressing
the
the
small
open
points
that
that
remain
around
it
and
yeah.
I
heard
it's
especially
useful
also
for
another
one
of
the
professors
of
this
yeah.
If
there
are
no
more
comments
or
objections,
I
I
think
I
can
actually
close
the
issue.
A
Looks
to
me,
we
have
pretty
much
discussed
that
we
had
pretty
much
discussion
on
those
so
and
I
I'm
focused
on
your
on
your
slides
but
yeah.
It
seems
to
me
that
it's
pretty
much
ready
to
be
closed.
A
J
Yes,
next
slide,
please,
but
I
think
we
are
done
yeah.
I
think
the
document
is
overall
in
a
pretty
stable
shape.
Also
editorially
and
my
plan
was
to
consider
open
points
and
more
feedback
from
today
address
them
and
then
consider
consider
possibly
moving
to
a
working,
robust
call
or
if
there
are
no
feedback
from
today.
J
Possibly
considering
a
working
group
last
call
because
I
don't
have
any
open
issues
remaining
from
my
site.
A
So,
just
to
be
clear,
I
mean
you
describe
the
current
version.
A
A
I
am
client
yeah,
I
I
think
we
can
start
a
working
group
last
call-
and
I
prefer
to
to
to
extend
the
working
group
last
call
then
to
delay
starting
the
working
group
less
goal.
A
So
my
plan
is
to
start
working
with
classical
next
week
if
everyone,
if
anyone
objects,
no
yeah,
so
I
will
do
that.
A
J
That's
the
next
presentation
I
I
can
imagine
you
like
at
some
point
later
on
to
ship
them
together,
yeah.
A
J
Yeah.
Thank
you.
This
is
an
update
of
another
of
the
application
profiles
of
the
previously
presented
draft
targeting
grouposcore
a
security
protocol
next
slide.
Please.
J
Right
now,
you're
familiar
with
the
workflow,
the
the
different
details
are
just
that
the
client
intends
to
join
exactly
an
oscar
group
where
communications
are
are
protected
with
group
of
score.
J
So
in
this
case
the
kdc
is
specifically
the
group
manager
used
in
group
score
and
treating
the
the
related
specific
key
material
for
group
score
after
getting
the
key
material
with
the
joining
response.
Once
in
the
group
group
score
communication
can
happen.
The
scope
of
this
document
is
limited
only
for
this
key
provisioning
and
other
operations
at
the
group
manager.
For
for
the
group
members,
it
doesn't
consider
access
controlled
resources
at
group
members.
It
doesn't
consider
communication
itself
because
that's
about
group
of
score
next
slide.
Please.
J
Okay,
the
updates
in
these
versions
are
mostly
related
to
the
updates
in
keygroup.com
that
we
saw
before
and
to
the
group
of
score
document
in
core
that
we
also
had
before
the
the
last
cutoff
so
relatively
easy
things.
We
adapted
the
get
pub
key
parameter
semantics
that
we
saw
before
with
the
additional,
including
exclusive
filtering
based
on
node
ids.
J
I
also
already
implemented
that
extension
in
my
implementation
of
the
group
manager.
It
works
fine
and
helped
me
nailing
down
those
five
cases
following
what
started
in
ace,
keyground
column,
with
the
new
error,
error
types
and
so
on.
The
error
handling
overall,
was
also
improved
here
already,
using
the
error
types
defined
in
integro
com
that
I
presented
before.
J
There
is
one
more
error,
type
that
I
had
to
introduce
here
where,
where
I
can
start
thinking
in
terms
of
group,
currently
not
active,
which
is
something
like
for
an
administrator
and
defined
in
yet
another
document,
but
that
was
still
a
reason
to
to
register
one
more
error
type
and
there
are
additional
error
situations
regarding
the
particular
error
type,
which
is
returned
that
came
up
in
this
document
rather
than
before,
for
instance,
where
a
node
tries
to
perform
some
operations
where
the
group
is
in
fact
not
active
or
operations
that
don't
make
sense
or
are
not
allowed
with
the
current
role
in
the
group
or
the
unfortunate
case
where
a
new
center
id
has
to
be
issued.
J
J
Yeah
and
still
an
alignment
with
kickr
com,
as
I
mentioned
before,
we're
replying
to
carson
yeah.
This
document
is
also
its
reasons
to
optionally
use,
an
explicit
indication
for
for
scope,
semantics,
just
in
case
the
group
manager
is
running
in
in
in
a
kdc.
That
overall
is
supporting
also
other
services
and
other
applications
and
when
receiving
an
access,
token
scope
can
be
related
to
any
of
those,
and
that
kind
of
hint
would
be
helpful
to
this
ambiguity.
J
Otherwise
it
was
mostly
about
editorial
improvements
around
the
points
discussed
in
the
previous
presentation.
Other
aspects
are
related
to
recent
updates
in
the
group
score
document
of
core.
Instead,
where
we
have
introduced
the
possibility
for
the
group
manager
to
to
do
some
recycling
of
the
sender
ids
of
the
group
members
as
long
as
that
doesn't
happen
under
the
same
group
identifier
so
before
it
was
forbid,
then
altogether
and
the
group
manager
described,
the
air
was
aligned
with
that.
J
Also,
there
was
a
revision
of
the
group
score
document
related
to
mechanisms
and
policies
to
enforce
synchronization
of
sequence
numbers
among
the
group
members,
and
we
noticed
that
two
of
them
were
just
a
moot
or
not
really
relevant.
We
removed
them,
meaning
them
they
had
to
disappear.
Also
from
this
document
where
they
were
considered
and-
and
they
were
coming
up
again
with
registered
code
points,
so
removing
mood
things
next
slide.
Please.
J
Yeah,
when
revising
this
document
and
again
related
to
recent
revisions,
the
gripple
score,
I
noted
that
we
still
have
a
redundancy
here
that
we
we
used
to
have
in
group
score
and
that
we
removed-
and
this
is
related
to
the
capabilities
of
algorithms
and
of
key
types
in
cozy
following
the
corresponding
iana
registries.
J
Basically,
in
group
score,
we
have
two
data
structures
to
protect
the
messages
and
to
describe
the
security
context
where
we
we
describe
how
the
group
works
so
which
algorithm
it
uses
and
the
properties
of
that
algorithm
and
of
the
keys
that
it
uses,
and
there
was
any
information,
the
capabilities
of
the
key
type
that
was
repeated
twice,
so
it
was
just
redundancy
and
we
removed
that
repetition
wherever
we
could
in
group
score.
J
Okay,
I
didn't
do
that
yet
in
this
document,
but
I
think
you'd
be
good
to
to
do
that
just
as
well,
and
it
affects
three
points
of
these
documents.
J
The
first
two
points
belong
to
the
preliminary
exchange
between
the
joining
node
and
the
group
manager
during
the
the
token
post
and
response
where
the
journey
node
can
can
get
early
hints
on
how
the
group
works
and,
and
especially
the
the
algorithms
it
uses.
So
there's
a
summary
here.
J
So
the
proposal
is
to
essentially
shift
to
the
new
content
column,
where
all
the
information
would
remain,
of
course
available,
but
no
redundancy
anymore,
and
it
would
be
also
much
better
aligned
with
the
group
of
score
document,
meaning
it
becomes
easier,
faster
and
and
harder
to
make
confusion
about
in
this
document
when
getting
the
material
from
the
group
manager
and
building
your
score
context.
J
And
by
the
way,
yes,
so
we
are
defining
these
details
here,
so
this
does
doesn't
touch.
Keygroup
com
at
all
doesn't
actually
have
a
prophecy.
No,
no,
it's
really
specific
of
of
grupo
score
and
I
think
you'd
be
other
than
killing
the
redundancy
you'd
be
also
an
alignment
with
what
we
did
in
the
in
the
court
document.
A
J
Great
with
pleasure,
okay
next
slide,
which
should
be
the
last
one.
I
think
next
steps,
it's
mostly
aligned
with
upcoming
things
that
were
discussed
already
this
week
again
in
the
in
the
group
score
document.
Well,
one
is
the
one
I've
just
mentioned,
killing
the
redundancy
on
on
the
repeated
information
on
the
key
type
capabilities
last
week
and
again
during
the
core
meeting
on
the
meeting
on
monday
this
week,
we
also
discussed
that
we
can
do
something
even
better
and
admitting
recycling
also
group
ids
other
than
all
sender
ids.
J
That
has
a
number
of
advantages.
We
know
how
to
do
that
in
group
score
that
was
discussed
already.
That
requires
a
little
bit
of
additional
logic
on
the
group
manager
itself,
which
should
mean
some
more
steps
to
take
internally,
not
on
the
wire
for
the
group
manager
to
to
make
this
this
possible
as
secure.
J
So,
of
course,
I'd
have
to
revise
the
parts
where
I
describe
what
happens
at
the
group
manager
right
upon
a
new
members
joining,
so
that
then
this
becomes
practically
available
to
do
in
the
group
like
intended
for
for
the
group
score
document
and
third,
that
will
not
happen
exactly
next
week,
but
I'm
pretty
sure
in
the
coming
months
we
got
an
early
comment
from
from
ben
on
the
grouposcore
document.
J
In
fact,
in
the
core
mailing
list
about
a
particular
usage
of
keys,
we
are
doing
in
in
group
score,
so
basically,
identity
keys
are
using
for
for
two
possible
reasons.
At
the
same
time,
one
is
signing
and
one
is
running,
defeatment
to
derive
further
keys
for
a
more
efficient
pairwise
mode
and
ben's
concern
was
about
this
actual
double
usage,
about
which
you
have
to
provide
very
solid
proof
of
not
breaking
security.
J
We
are
actually
working
on
on.
Such
a
proof
seems
it's
going
good
and
we
should
be
able
to
come
up
with
something
in
the
in
the
coming
couple
of
months,
so
they
will
probably
will
solve
everything
with
no
need
to
touch
this
document
at
all
about
that,
but
just
to
be
on
the
safe
side.
J
In
any
case,
the
alternative
would
be
to
not
go
for
one
same
identity,
key
used
for
both
reasons,
but
to
go
for
two
different
keys
used,
one
for
signing
and
one
for
defeatment,
so
that
would
mean
storing
two
keys
but
first
of
all
provisioning
them,
and
I
believe
that
additional
provisioning
of
additional
keys
would
have
to
happen
in
this
document.
J
In
fact,
so
that
would
mean
extending
the
the
join
request
response
exchange
to
provide
additional
keys
of
which
to
prove
possession
of
the
corresponding
private
part.
J
So
I
I
believe
we
will
not
need
to
do
that,
because
I
I'm
confident
we
can
go
definitely
for
option
a,
but
just
to
not
exclude
anything
at
the
moment,
not
to
mention
that
as
long
as
kingrootcom
is
not
really
stable,
I
mean
past
a
working
group
was
called
comments
revision
because
of
what
I
changed
there.
I
will
have
to
sing
to
change
something
here
too.
J
So
so
that's
also
an
answer
to
your
previous
question
that
possibly
this
document
will
end
up
being
ready
for
requesting
publication
one
or
two
rounds
after
the
previous
one.
A
J
A
No,
but
on
this,
but
I
mean
the
ex
group
com
key,
this
one
is-
can
be
moved
without
the
profile.
A
A
J
A
Okay,
yeah
yeah
sure,
so
I
I
I
I
think
we're
gonna.
I
mean
I
think
we
are
at
the
end
of
the
decision
now,
so
we
might
not
have
time
to
to
do
the
other
presentations,
but
I
do
see
that
we
have
pretty
quite
a
lot
of
work
to
do
in
the
meantime
of
the
next
interim
meeting.
A
So
I'd
like
to
thank
everyone
for
this
very
productive
session
and
I'm
glad
to
to
see
all
this
piece
of
work
being
moved
forward,
I'm
wondering
if
anyone
wants
to
say
something
to
close
the
session,
maybe
logan
or
ben.
You
want
to
add
something.
E
E
D
Session
at
itf,
and
also
the
interior
meetings.
A
Okay,
so
I
think
we
can
enter
the
meeting
and
thank
you
everyone
for
for
that
session
and
see
you
see
you
in
a
few
weeks.