►
From YouTube: IETF102-ACE-20180716-0930
Description
ACE meeting session at IETF102
2018/07/16 0930
https://datatracker.ietf.org/meeting/102/proceedings/
A
All
right,
good
morning
morning
welcome
this.
Is
the
East
working
group
we're
off
to
start
here
is
the
first
session
here
on
Monday
morning
morning
my
name
is
Govinda
Naidu
I
co-chair
with
Jim
Shan.
Why
don't
we
get
started
as
a
reminder
as
an
official
meeting,
but
note
well
applies.
There
are
a
number
of
piece
of
easier
play.
If
you
have
any
questions
by
all
means,
ask
us
or
event
a
new
here
as
we
do.
A
A
Okay,
I
take
that
as
a
no,
so
before
we
dive
into
into
kind
of
some
of
the
specific
presentations.
Let's
talk
status
update,
so
a
couple
things
have
happened
since
we
last
got
together
in
person.
There
was
quite
a
lot
of
robust
activity
at
hackathon
and
we
did
a
working
group
last
call
on
this
possession
kind
of
drop
and
that's
still
in
flight.
There
is
a
request
for
an
early
registration
for
coop
media
type
that
that
the
chairs
are
still
working
on.
A
We
also
met
virtually
for
an
interrupt
event
and,
most
importantly,
kind
of
congrats
to
the
opportunity
to
RFC
8390
to
publish
so
we're
making
kind
of
progress.
Big
picture
wise.
We
are
largely
on
schedule
because
we've
been
updating
the
milestones.
This
is
where
this
is
kind
of
where
we
stand
so
closest
up
for
us
is
getting
the
session
to
session
draft
done
and
some
of
the
three
more
travel.
Are
there
any
reactions
to
what's
happening
in
the
milestones
about
what
we
should,
what
we
should
change
your
calorie
based
on?
What's
there
now.
B
Do
we
still
have
that?
Oh
my
gosh
back
off
good
morning,
Montreal
I
am
Mike
Jones
from
Microsoft
and
I'm
here
to
talk
about
the
proof
of
possession
key
representation
for
support
with
tokens.
B
B
D
Boston
Brahmin,
so
I
have
a
30,000
foot
comment
that
is
not
actionable,
but
it's
still
a
common.
D
So
one
of
the
the
ideas
of
cozy
was
to
use
the
work
that
was
done
by
as
much
as
possible
and
then
at
some
point
we
noticed
a
lot
of
reasons
to
have
some
deviation.
So
that's
why
cozy
is
one
of
exact
copy
of
osseous
original,
and
the
main
reason
is
that
the
domain
of
application-
we
have
a
is
devices,
so
they
have
totally
given
a
pocket
beneath
tape.
I
have
to
make
decisions
based
on
the
data
recap,
so
I
think
that
the
main
difference
between
pacient
forcier
step
in
poultry.
D
D
B
Great
great
points,
I
should
note
that
my
slides
do
oversimplify
the
situation
and
saying
that
it
remains
exactly
parallel.
There's
a
backstory
here,
which
many
of
you
will
remember
from
a
year
ago,
is
that
there
were
actually
two
different
drafts
that
did
essentially
the
same
thing.
I
wrote
an
individual
draft
and
living
and
crew,
including
I,
think
yourself,
Kirsten
as
part
of
the
wasp
profile
for
Ace,
also
did
a
treatment
of
proof
of
possession
keys.
B
E
Later
changed
my
mind,
because
I
didn't
see
a
use
case
which
in
some
sense
not
make
sure
that
there's
the
alignment
begin,
but
of
course
those
with
the
extensions
that
could
be
defined
may
be
if
it's
a
good
use
case
for
a
CWD
who
that's
what
you
could
use
is
also
fun
in
JSON
based
format.
But
I
just
didn't
have
that
use
case
also
be
easier
to.
E
B
So,
let's
see
you
made
two
points
not
respond
to
them.
In
turn,
one
was
the
multiple
keys
representation
and
both
7800
in
our
draft.
Do
you
say
how
you
could
represent
multiple
pop
keys
by
defining
a
new
claim
to
hold
the
additional
key?
It's
the
case
that
any
application,
if
there's
multiple
key,
is
going
to
have
to
have
identifiers
or
ways
to
distinguish
what
the
keys
are
and
so
asking
further
to
be
a
claim
to
represent
the
additional
keys
is
not
a
burden
on
the
application.
B
B
F
I
cannot
say
that
I
felt
that
the
whole
issue
of
preference
by
key
ID
was
adequately
addressed
in
the
document.
I
think
that
there's
a
whole
lot
of
issues
that
it
hasn't
they
haven't
been
thought
about.
There
are
problematic
and
need
to
be
thought
thought
through,
and
documents
are
clearer
than
what
is
in
them
yeah.
B
F
H
H
H
That's
also
one,
but
this
attacker
is
all
using
a
key
B
and
then
me,
the
the
clients,
using
my
token
bound
to
key
a
submits
that
token
to
resource
server
and
the
resource
server
stores
that
and
stored
the
key
identifier,
one
link
to
that
token,
or
rather
the
key
the
true
position
of
that
token,
and
then
comes
the
attacker
having
another
token
lead
to
the
key
identifier,
one
and
somehow
and
that's
the
point
where
I
don't
follow
Jim.
Somehow
it's
tricked
the
resource
server
to
accept
that
token
and
PB.
H
That
is
also
identified
by
a
key
identifier
wall
and
thus
gains
the
access
rights
of
the
first
tool.
That
is
the
problem
that
I
am
stood
from.
Tim's
argument
and
I.
Don't
see
this
last
step,
how
this
is
supposed
to
happen,
how
the
attacker
treats
the
resource
server
to
accept
a
second
key,
linked
to
the
same
key
identifier
of
a
key
that
there
is
a
server
already
knows:
I,
don't
think
that's
happening,
or
if
it's
happening,
then
you
have
a
very,
very
bad
resource
available
right.
B
B
E
This
is
honest,
I
think,
but
look
they
said
this
document,
the
CWT
popped
open,
it's
very
limited
in
its
functionality.
That's.
E
May
be
used
in
a
in
a
non
hall
space
context,
so
it's
really
just
about
putting
the
key
having
a
structure
to
put
the
key
in
there.
Nothing
else.
That's
right
and
I
think
the
described
attack
scenario.
I
think
this
is
something
that
should
be
documented.
In
my
opinion,
in
the
is
oral
argument.
I
think
the
athletes
better
because
they're
you
actually
have
an
authorization
server.
E
There
you
have
the
resource
server
in
potentially
multiple
of
them,
so
I
think
it's
just
a
question
of
also
a
document
management
that
I
don't
think
it's
a
so
from
what
the
looping
explained.
I,
don't
think
it's
a
concern
because
the
keys
don't
stand
on
its
own
and
they
actually
tied
to
the
party
issue
in
them.
But
that's
right,
but
still
we've
seen
that
even
simpler
are
cases
that
implementation
can
make
mistakes
so
I
implement
us
can
make
mistakes
so
Stephanie
voiced
by
two
highlighters.
I
This
is
rush
hours
later.
I
came
up
here
to
disagree
with
Holmes
so
because
the
collision
and
the
key
identifier
has
different
consequences
and
different
uses
and
agreed
with
the
OAuth
documents
and
document
those
there.
But
there
should
be
a
warning
in
this
document
that
says,
if
you
use
this
wherever
you're
using
it
talk
about
the
consequences
of
a
TN
in
America,
so.
B
I
A
Got
it
so
I
would
like
to
react,
since
the
next
step
is
for
the
Shepard
review
is
what
you're
proposing
so
I'm
gonna
be
the
shepherd
so
on
Thursday
I
drop
something
on
the
mailing
list,
where
I
try
to
deconflict
all
the
comments
that
came
in
on
it's
going
at
everything.
That
was
in
kind
of
three
and
line
him
up,
and
there
were
a
lot
of
comments,
so
I
may
be
off
by
kind
of
one
or
two,
but
spend
them
staring
out
of
here.
Is
there
were
things
in
three
categories
which
were
I?
A
Think
there
were
things
raised
in
the
working
group
last
call
that
I
could
not
see
you
manifested
in
changes
in
oh
three
on
the
list.
I
have
enumerated.
Those
there
were
also
discussions
of
changes
that
would
be
dropped
in
203.
Then,
when
I
saw
the
text
that
looked
like
it
actually
addressed
the
comments,
but
he
did
not
make
it
into
the
text
and
then
on
the
last
one
was
this
issue
we've
been
talking
about
you're
kind
of
in
a
mic
line,
so
I
think
what
would
really
help
proceed.
A
The
every
three
to
the
next
to
the
next
stage
of
maturity
is,
if
you
could
walk
through
that
list
and
say:
hey
woman,
you
missed
you
missed
this.
This
was
actually
kind
of
close
and
we
get
consensus
growing
news.
They
brought
up
kind
of
the
issue
to
say
yes,
yes,
this
address
is
kind
of
my
issue,
so
I
think
say.
A
Think
that
may
help
us
get
around
canoes
issue.
Is
it
closed?
Is
it
not,
but
if
you
yeah,
but
it
doesn't,
leave
open,
we
do
so
I
think
there's
some
mechanical
things
to
do
with
the
vast
majority
of
those,
but
there
is
still
discussion
required
on
this.
What
do
we
say?
Are
we
adequately
covered
in
the
operational
section
and
about
the
key
onions
right.
B
J
A
K
Okay,
so
I
will
present
the
eesti
of
a
co-op
S
draft,
which
has
been
presented
already
some
time
I'm,
very
grateful
for
all
the
comments
we
got
back
from
the
working
group.
It
just
really
helped
us
feel
you're
helpful.
Thank
you
very
much
so
you're
happy
about
all
this.
This
draft
proposed
a
scope
over
DTLS,
where
the
original
is
tea,
used,
HTTP
and
TLS.
So
I
think
it's
clear.
This
is
meant
for
reduced
resource
devices.
K
Yes,
so
we
have
a
few
major
updates
since
the
idea
for
Mata
one,
the
first
two
I
will
have
some
two
additional
slides
to
talk
about
them
and
the
others
I
just
mention
them.
So
there
isn't
the
case
where
you
may
have
delays.
So
you
asked
for
an
forum
for
some
khufu
that
the
certificate
is
correct
and
then
there
may
be
problems
and
somebody
barehand
has
to
verify
that
things
are
okay,
so
you
may
have
delays
not
of
a
few
milliseconds
but
of
seconds
minutes.
K
So
that
is
the
part
we're
going
to
handle
on
the
other
cards.
We
have
the
multi-part,
payload
I
will
also
say
a
little
bit.
More
involved
is
slides
and
for
which
has
been
and
the
request
for
publications.
Thank
you
very
much,
which
was
nice.
We
have
improved
the
examples,
I
mean
improving
the
text
or
sometimes
ambiguous,
and
we
have
made
that
nicer
and
sometimes
the
payload
was
not
completely
correct.
So
we
handled
that
we
have
in
section
this
parameter
values.
We
promised
it,
and
actually
there
have
been
some
implementations.
K
K
The
word
proxy
was
wrongly
used
when
going
between
HTTP
and
coop
and
the
juice
to
be
has
to
be
versus
trial,
which
is
recognized.
We
have
improved
the
text,
and
that
is
so.
It
looks
much
better
now
and
it
is
more
correct.
The
server
key
generation
last
time
there
were
some
questions
about
it,
whoever
needs
this
etc.
This
I
think
are
now
handled
in
the
text
and
also
the
the
the
way
to
handle
server.
Key
generation
has
been
written
down,
so
thank
you
for
the
comment
there.
How
much
action
has
be
taken.
K
K
We
want
to
have
very
small
and
the
register
if
it
goes
from
the
coop
to
the
HTTP
has
to
remember
all
these
things.
The
observations
which
are
going
on
etcetera,
which
is
a
lot
of
state,
and
we
wanted
to
get
rid
of
that
state.
So
there
has
been
a
new,
much
simpler
way
to
handle
this,
and
so
in
the
current
text.
What
we
do
is
we
do
the
post
and
the
server
recognize
look
here.
K
This
is
going
to
take
some
time
and
it
returns
an
error
and
tells
you
you
wait
so
much
time
and
then,
after
some
time
the
client
he
sends
completely
the
same
payload
again
to
the
server
which
may
be
ready
then,
or
it's
not
ready
and
then
says,
look
here,
error
max-age
and
this
goes
on
until
finally,
the
surface,
ready
or
the
client
gives
up.
It
is
much
simpler,
but
the
disadvantage
is
that
you
sent
again
the
same
payload
again
for
to
in
the
in
the
post.
Any
comments
on
this.
K
Yeah:
okay,
fine
thanks
multi-part
payload
in
the,
for
example,
in
one
of
the
year,
actions
to
surfer
key
generation,
the
return
payload
is
composed
of
two
parts
which,
with
different
media
types,
this
was
not
possible
in
coma
before
thanks
to
the
collaboration,
is
Carsten
and
writing
a
new
draft.
What
we
now
have
that
you
can
have
different
payloads
in
the
in
a
different
movement,
different
media
types
in
the
payloads-
and
we
do
this
by
using
a
sieve
or
array
where
in
the
first
two,
where
do
we
have
pairs?
K
The
first
one
satis
gives
the
content
format
number
and
then
it
gives
the
payload
and
then
the
next
part
in
the
Seabury
content
format
to
payload
to
belonging
there
etc,
and
we
have
worked
it
out
in
the
East
II
coop,
as
example,
for
example.
Here
we
have
a
very
small,
very
have
two
content
formats
for
t,
2
and
0,
and
we
have
a
fairly
short
payload
just
to
show
that
they
might
look
like
we
are
happy.
We
think
this
is
fantastic,
I
mean
the
guys
are
implementing
and
say.
K
K
K
M
K
K
What's
what
I
see
here
is
that
actually
you
may
wait
and
you
have
the
error
max,
is
correct
and
then,
after
the
error
max
you
come
back.
You
get
back
your
results,
but
it
may
well
be
that
the
max
max
H
is
not
correct.
You
want
to
do
the
second
time
and
if,
at
the
end
the
client
says
I
give
up,
because
this
takes
too
long
say
half
a
day.
It
just
gives
up
and
that's
the
end
of
it
was
that
the
question
it's.
K
E
K
E
J
G
K
K
E
So
maybe
I
don't
know
if
there's
a
possibility,
we've
done
an
error
message
if
their
client
requests
for
something
in
feature
like
this
one
and
the
server
then
doesn't
provide
that
functionality.
So
in
that
sense
it
would
still
be
interoperable.
It
would
just
not
work.
I
think
I,
think
that
would
be
good
and
I.
Also
I
still
think
that
the
argument
which
sort
of
led
to
the
introduction
of
that
feature
is
also
a
little
bit
tedious,
because.
G
E
H
H
H
We
had
the
possibility
when
you
were
identifying
profiles
to
identify
them
with
the
long
strings
that
are
the
descriptive
names
of
them.
I
removed
that
possibility,
because
it
didn't
felt,
useful
and
I'm
now
requiring
that
you
use
the
abbreviation
and
you
can
still
use
the
string
identifiers
in
like
descriptive
text
or
or
metadata
or
whatever.
H
Then
there
was
a
comment
by
Jim
that
we
might
need
to
inform
a
resource
server
about
which
public
key
to
use,
if
it
has
several
so
I
allowed.
The
Aris
conf,
which
describes
the
public
key
of
a
reso
server,
parameter
to
come
into
an
introspection
response.
So
when
the
reserve
server
does
an
introspection
on
earth
on
an
access
token,
the
authorization
server
can
inform
it
which
of
its
different
public
keys,
to
use
to
authenticate
to
the
client.
That's
the
idea
of
that
one!
H
The
next
one
is,
if
you
don't
do
enter
spectrum
you
might
still
want
to
have.
You
still
might
still
have
this
scenario,
so
I
also
allowed
this
clay
list
to
be
used
as
a
claim
in
an
access
token,
so
that,
when
processing
the
access
token,
the
resource
server
can
determine
okay
towards
the
client
wielding
this
access
token
I
need
authentication
key.
So
that's
the
bullets.
H
H
E
H
Pre-Empting
my
next
slide,
no
problem,
so
the
next
point
was
review
by
Jim
I.
Think,
mostly
all
these
changes
are
to
review
by
Jim
and
he
pointed
out
that
the
term
we
using
resource
information
was
wrong
to
misunderstandings.
Just
for
those
who
want
to
dwell
delve
in
in
a
bit
of
nostalgia.
We
call
that
client
information
initially,
because
I
was
thinking
it's
information
for
the
client,
then
someone
complained.
Oh,
this
is
miss
understandable.
It
could
be
interpreted
as
information
about
the
client-
oh
great.
No,
we
don't
want
that.
H
So
we
called
it
resource
information
and
then
comes
the
equivalent
argument.
So
Jim
suggested
access
information,
I
implemented
that
change,
because
it's
more
neutral.
You
cannot
like
make
that
argument
anymore
and
I.
Don't
have
a
very
strong
opinion
about
that.
If
someone
wants
to
argue
it
I'm
happy
to
hear,
but
I
changed
that
for
the
moment,
because
Jim's
arguments
has
some
merit.
H
Next
thing
there
was
a
section
about
discovery
of
the
authorization
server.
So
when
a
client
does
an
unauthorized
request
to
resource
er,
it
gets
back
some
discovery
information
and
there
were
some
points
in
that
section
that
weren't
totally
clear.
There
are
still
some
points
left
we
discovered
and
we're
going
to
address
those
as
well.
H
We
removed
some
text.
We
had
about
a
discussion
that
was
unknowingly
year
ago
about
how
constrained
devices
could
measure
time
or
not,
and
there
were
some
texts
saying
that
we
have
this
ongoing
discussion,
which
is
no
longer
true.
We
don't
have
it
anymore,
so
I
removed
that
I
think
the
consensus
at
that
time
was.
We
are
most
likely
to
have
wall
clock
time,
so
we
can
measure
ticks,
but
we
cannot
be
sure
that
we
have
synchronized
clocks
and
then
there
was
a
number
of
editorial
changes,
mostly
commas
missing
when
I
wrote
that
hummus
edit.
H
So
thank
you
very
much
Hannes.
There
was
very
a
very
extensive
review
of
the
grammar
and
syntax
in
the
document,
so
that
was
the
last
update.
Since
then,
we've
had
a
review
by
Jim
and
we've
had
to
interrupts.
A
few
issues
were
discovered
which
I
don't
have
on
my
slides,
because
the
interrupt
was
during
the
hackathon
and
I
made
the
slides
on
Thursday
I.
Think
so
here
are
the
discussion
points
before
the
new
discussion
points
that
we
have
come
up
with.
H
First
of
all,
the
key
identified
collisions
I
think
we
already
covered
this
I'm
going
to
skip
that
alignment
with
OAuth.
That
was
what
Hannes
preempted
me
on
telling
these
two
parameters
that
are
pretty
close
to
each
other,
which
are
overlapping
somewhat.
There
is
this
old
of
draft
that
is
expiring
to
the
best
of
my
knowledge,
the
OAuth
PE
was
distribution
graph.
H
You're
supposed
to
use
so
I
think
this
is
merit
to
the
point
that
we
should
discuss
how
to
align
this,
and
until
recently
the
work
in
off
was
dormant,
so
I
pulled
large
parts
of
this
key
distribution
graph
into
the
ACE
framework,
I'm
happy
to
put
then
out
again
if
it
doesn't
delay
the
progress
of
the
escape
work.
So
if
earth
can
move
really
fast
with
that
and
great
less
less
text
in
this
already
pretty
long
framework
document
I'm
all
for
it,
but
I'm
not
convinced
at
the
moment
that
this
is
the
case.
H
H
Yes,
then
there
was
a
discussion
point
burnt
up,
I'm
Mike,
so
what
we're
doing
is
we're
defining
abbreviations
for
for
claim
names
and
parameter
names
and
for
some
common
parameter,
values
and
Mike
was
arguing
that
we
were
using
the
low
digit
byte
numbers
for
this
abbreviation
in
a
wasteful
way.
Now
person
you
can
say:
when
does
the
Seaboard
representation
switch
from
one
bite
to
I?
Think
it's
at
255
or
something
24?
D
H
All
the
parameters
that
are
currently
in
the
framework
are
either
parameters
defined
by
OAuth
or
defined
by
RFC
7800,
and
the
confirmation
draft
that
we
have
Plus
this
profile,
and
ours
called
parameter
that
we
are
defining
so
I'm
absolutely
open
to
discussion,
which
of
those
parameters
are
unimportant
enough
to
merit
a
larger
abbreviation.
We
should
definitely
do
that,
and
then
we
should
select
those
that
get
the
really
small
ones
from
minus
two
plus
24
that
are
the
ones
we
use
a
lot.
D
H
D
H
H
Good
last
point
raised
by
Jim.
We
were
at
some
point
in
the
document
talking
about
this
discovery
of
the
authorization
server
and
we
were
saying
in
a
little
bit
of
nonchalant
way
that
yeah,
if
you
don't,
do
this
unauthorized
request
and
get
back
the
its
information,
you
could
also
look
it
up
in
a
resource
directory.
It
like
this
without
thinking
it
through
to
the
end.
H
D
D
D
H
D
D
H
I've
addressed
this
currently
because
I
addressed
this
comment
to
the
best
of
my
ability
is
to
remove
the
explicit
reference
to
resource
directory.
Since
we
don't
have
anything
there
and
just
state
like
you.
Have
this
unauthorized
request
mechanism
and
you're
allowed
to
use
other
mechanisms
to
inform
the
client
about
the
authorization
server,
and
then
we
can
do
that
with
an
independent
draft
specifying.
D
H
F
D
H
Perhaps
let
me
since
you've,
given
me
the
occasion,
get
a
quick
word
in
about
implementations.
There
is
one
which
I
wrote
for
unconstrained
devices
based
in
Java
based
on
californium
library.
There
is
one
by
Jim
in
c-sharp
I'm,
not
mistaken,
Olaf
from
T
said:
I
is
working
on
a
constraint
limitation.
H
One
I
was
told
I'm
completely
incompetent
in
embedded
programming,
so
I
know
no
big
help
there,
but
they're
very
close
to
being
able
to
provide
that.
So
we
have
a
number
of
implementations
lying
around,
but
more
the
more
the
merrier.
Please
go
ahead,
I
think,
as
there
are
a
number
of
implementations,
the
document
is
in
a
state
where
you
can
implement
meaningful
things
and
I
don't
expect
changes
that
will
totally
break
your
code
to
a
way
where
you
need
to
start
again
from
scratch.
H
H
H
A
A
G
G
Yes,
so
just
one
slide
to
recap
what
this
was
about.
This
is
a
draft
about
joining
secure
group
communication.
Sohow
client
can
become
a
member
of
our
group
and
start
securely
community,
getting
communicating
with
the
group.
So
the
picture
is
the
architecture
that
we
were
using.
So
there
is
the
client
yeah,
yes,
the
key
distribution
center,
which
is
the
node
that
does
the
PD
solution,
and
then
the
group
members
and
the
dispatcher,
so
we
define,
in
this
draft
message,
format
to
authorize
and
distribute
King
material
and
we
make
use
of
the
ACE
framework
and
profiles.
G
What
is
out
of
scope
of
this
draft
is
how
the
group
communication
protection
is
done.
So
what?
What
is
the
mechanism
used
to
protect
the
group
communication
and
in
this,
in
this
version
of
the
draft,
we
have
added
these
revocation
and
renewal
of
key
material,
which
was
very
general
in
the
diversion
before?
Although
the
algorithm,
the
details
are
still
out
of
scope
so
for
status?
Update
of
this
draft
of
this
draft,
we
have
updated
according
to
review
and
discussion
at
IDF
101.
G
So
there
are
some
minor
details
that
have
been
updated,
such
as
the
format
of
some
parameters
like
get
public
keys,
which
is
the
parameter
that
is
sent
to
from
the
client
to
the
key
distribution
center.
To
say,
I
want
the
public
keys
of
these
notes.
So
now
we
have
a
way
to
send
these
either
to
request
all
the
public
keys
of
all
the
members
of
the
group
or
to
request
specific,
a
public
keys,
and
then
we
have
add
an
expiration
parameter.
G
G
Then
the
major
update
in
this
draft
is
about
the
retrieval
of
updated
key
material.
So
just
a
reminder
when
there
is
a
revocation
or
self
removal
of
of
a
node
of
a
member
of
a
group,
these
triggers
rekeying
from
the
key
distribution
center
Center
that
just
sends
the
new
new
key
to
the
current
members
of
the
group.
G
So
as
for
open
issues,
now
with
my
co-author,
we
have
some
questions
for
you
and
so
about
this
part,
specifically
so
to
retrieve
either
the
symmetric
key
or
the
public
keys.
We
use
the
same
format
that
the
client
first
used
when
it
joins
the
group,
which
is
this
key
distribution
request,
and
we
simplify
it
because
we
don't
need
to
send
all
the
parameters
that
we
send
it.
When
we
first
joined
the
group,
we
only
need
to
send
this
scope
or
scope
and
get
public
keys.
G
So
as
of
now,
we
have
defined
this
two
different
requests
to
update
the
key
material,
either
symmetric
or
the
public
keys.
But
as
of
now,
it
is
not
possible
to
combine
these
two
requests,
because
this
is
not
possible
to
differentiate
between
asking
for
both
the
symmetric
keys
and
the
public
keys
or
asking
only
for
the
public
keys.
G
So
we
have
thought
about
it
a
little
bit,
so
we
have
three
choices
right
now
we
came
up
with
a
possibility,
for
so
one
solution
would
be.
If
we
want
to
be
able
to
combine.
These
two
is
to
use
different
end
points.
You
could
have
one
end
point
for
asking
a
symmetric
key.
You
could
have
one
end
point
for
public
and
one
for
both.
G
D
G
I'm
using
the
I'm
using
the
ACE
terminology
now
that
uses
end
point
as
resource
yes,
four
for
four
core
is
resource,
so
this
is
one
choice.
Another
choice
is
to
add
one
additional
parameter
that
could
indicate
yes,
I
also
want
to
ask
for
the
symmetric,
and
you
could
use
that
if
you
want
to
ask
for
both
another
choice
is:
maybe
we
don't
need
to
combine
those
two,
it's
fine.
When
asking
each
one
of
those
separately.
G
F
Is
this
if
I'm
a
little
bit
lost
here,
is
the
symmetric
one
here
asking
for
this
an
updated
symmetric
key
as
opposed
to
when
you're
actually
doing
the
join?
Yes,.
G
G
G
Agreed,
do
you
think
what
do
you
have
a
preference
on
using
one
additional
parameter
in
the
message
itself
or
formatting
differently,
just
to
differentiate
between
I
want
to
up,
because,
as
you
can
see
when,
when
we
do
the
key
distribution
requests
for
the
only
the
symmetric
key
we
use,
we
only
need
to
send
the
scope
and
it's
optional.
Actually,
if
we,
if
we
want
to
ask
for
the
public
keys,
we
do
need
to
send
the
scope
and
get
public
keys.
K
G
You
for
your
comment:
there
is
two
drafts
about
group
communication,
which
is
the
one
I
presented
and
the
one
the
marker
will
present
it's
not.
This
was
this
separation
was
done
following
comments
at
280,
absolute
so,
and
the
first
draft,
which
is
the
one
I
just
presented,
is
the
general
one,
while
the
one
the
marker
will
present
after
me
is
the
the
worm
that
actually
does
the
details
and
specify
everything
yeah.
A
G
This
was
done
also
because
the
general
one,
which
is
the
one
I
just
presented,
can
also
it's
also
valid
for
the
pub/sub.
So
this
is
like
there
is
a
general
one
and
two
applications
of
it.
So
understand
that
there
is
many
drops.
There
is
the
framework
and
then
the
general
profile
and
then
specific
profile.
K
K
G
F
O
O
Yeah,
there's
updates
are
mostly
user
synchronizing.
This
document,
with
the
latest
updated
version
of
Oscar
bromb,
describing
at
how
to
actually
secure
communications
in
the
group,
and
the
document
Francesca
is
just
present
and
describing
the
generic
message
format
to
be
used
for
key
provisioning
for
communication
and,
last
but
not
least,
we
processed
very
helpful
review.
We
got
form
either
under
stopped
right
after
thanks
a
lot
for
that
going
through
the
updates.
O
We
had
to
touch
the
terminology
a
little
bit
already
to
align
it
with
group
of
score
in
the
first
place
would
used
to
be
called
multi
caster.
As
a
group
member
sending
out
requests.
The
group
is
now
simply
request
their
liking
group
of
score
now,
just
not
to
stress
anymore,
specific
multicast
traffic,
but
just
group
traffic.
We
kept
instead
pure
listener
and
listener,
with
the
same
meaning
as
before,
and
now
pure
listener
aligned
with
silent
serving
group
of
school.
O
O
We
had
some
parameters
in
the
messages
exchanged
in
different
phases,
like
the
authorization
request,
we
had
removed
the
parameter
guitar
keys,
because
there's
no
reason
for
the
joining
not
to
tell
explicitly
the
authorization
server
about
its
intercept
of
of
getting
public
keys
of
group
members
later
on
from
the
KDC,
meaning
the
oscar
group
manager
next
slide.
Please.
O
O
So
essentially,
the
journey
node
is
supposed
to
get
the
actual
current
updated
a
group
identifier
from
the
group
manager,
the
resource
server
here
only
upon
joining
and
interacting
with
the
group
manager
through
the
server
ID
parameter
of
the
Casa
key
and
then
there's
something
that
is
right
now
aligned,
but
is
more
of
an
open
point
actually
now.
This
is
consistent
with
the
main
score
document,
where
we
admit
the
group
manager
to
both
be
or
not
be,
depending
on
on
your
setting
the
repository
of
public
key
of
group
members.
O
So
right
now
we
are
contemplating
two
possibilities
consistently
in
Peters
review.
That
was
also
comment
and
personal
I
agree
with
that
that,
for
the
sake
of
this
document,
described
out
to
join
Guinness
core
group
using
ace,
it's
probably
better
also
for
the
sake
of
implementations,
to
consider
only
one
alternative.
So
we
just
go
for
the
group
manager
being
the
repository
of
public
e
and
that's
it
so
I
attend
to
favor
Peters
opinion.
I.
O
Also
wonder
what
the
group
thinks
about
that
and
in
case
we
should
just
limit
the
option
to
the
group
managers:
wrap
off
public
keys
next
slide.
Please-
and
this
is
in
fact
the
last
one,
so
this
update
was
the
result
of
discussions
out
of
ITF
101
Peters
review,
thanks
again
for
that
and
of
course,
alignment
with
the
latest
version
of
oscar
group
calm
and
the
ski
group
con
that
francesca
presented.
So
others
believe
this
is
principal
in
a
good
shape
to
take
a
step
forward
with
option
thanks
a
lot.
O
A
A
Okay,
thanks
Marco
appreciate
it.
Thank
you
all
all
right.
So
next
up
we're
gonna
have
a
more
kind
of
open-ended
discussion.
We
want
to
talk
about
resource
directory
authorization
and
then
we
either
a
person
or
goddess
through
that
conversation,
but
before
we
get
into
that,
we
just
wanted
to
be
up
that
after
this
presentation
is
done.
We're
going
to
ask
some
questions.
Is
this
something
that
should
be
kind
of
examining
very
interesting.
J
K
Used
official
at
the
world,
PDF,
etc.
You
don't
know
about
it.
Yes,
okay,
very
good.
Some
motivation,
this
in
the
resource
directory,
which
we
do
in
the
core
Berger
group.
We
have
not
really
looked
at
security
aspects.
K
So
what
I
wanted
to
propose
here
is
that
we
do
not
do
normative
text
in
the
resource
directory
about
how
security
problems
should
be
solved,
but
actually
it
might
be
well
to
have
an
example.
This
gives
guidelines
and
IDs
how
this
should
be
done,
sis
that
we
are
not
confirmed
that
later
on
with
very
weird
implementations,
which
do
not
actually
solve
the
problem.
K
Ok,
so
we
are
looking
forward
to
a
set
to
discussions
and
if
the
working
group
wants
to
continue
this
work
or
comment
on
it
well,
the
threat
is
a
very
simple
one:
an
endpoint
used
as
a
server.
In
this
case,
let's
just
a
session,
you
endpoint
name
shouldn't.
We
have
two
a
and
B.
This
is
the
very
short
version
of
the
threat,
as
discussed
in
the
resource
directive
is
named
a
1
and
B
1.
K
Suppose
B
is
malicious
and
B
registers
with
name
a1
and
when
a
was
the
rest
of
a1,
the
resource
directory
tell
you
know,
don't
go
and
in
how
much
words
this
is
toast
we
are
very
badly
off,
so
the
idea
is
then
to
suggest
an
authorization
server
and
we
asked
authorization
server.
The
client
who
wants
to
register
ask
the
authorization
server
for
foreign,
a
token
in
which
is
authorized
business
token
to
actually
registers
his
entrance.
K
That's
the
idea
we
the
way
I
construct
example,
is
that
I
will
use
the
application
Sieber
media
format
that
DT
less
is
used
that
the
client
asks
for
that
over.
So
the
a
s
with
sufficient
information
to
do
it
and
I'll
come
back
to
that
further
I'm,
very
happy
for
Stephie
ski
mark,
who
tells
me
that
I
used
a
way
to
express
the
end
points
name
since
she
says
why
don't
you
use
the
scope,
but
other
people
have
other
suggestions
as
understood.
So
what
is
the
client
background
for
the
for?
K
The
footage
for
the
example
I
chose
is
that
it
has
a
certificate
installed,
so
I'm
not
looking
at
public
keys,
etc,
but
well,
there
wasn't
suggested
for
that,
but
then
we
have
to
have
mappings
and
looked
into
the
mappings.
I
got
overwhelmed
and
so
I
keep
it
to
this
as
an
activity.
The
example
is
East
Eco
pass.
That
is
an
extension
of
whisky,
where
we
assume
that
an
device
has
been
installed
is
a
certificate.
What
we
want
to
do
is
that
the
endpoint
name
equals
the
certificate
identifier.
K
So
when
the
endpoint
says
look
here,
I
want
to
register
with
this
endpoint
name.
This
can
be
by
the
server
can
be
a
processor,
for
this
can
be
verified
from
certificate.
I
have
here
an
example
of
a
certificate
to
the
right,
don't
put
too
much
attention
on
it.
The
idea
is
they
care
and
unique
certificate,
identifier,
which
comes
from
the
CN
field
and
the
serial
number
field.
K
K
We
have
three,
so
the
scope
name
suggestion.
So
what
should
be
the
value
of
the
scope,
the
ff3
cases
bomb
is
when
endpoint
registers
itself
services
and
put
name.
We
have
a
third
part,
commissioning
tool
which
actually
registers
and
also
an
EP
name,
and
we
have
an
update
of
registrations
which
is
not
completely
worked
out
in
the
red
in
the
resource
directory.
Yet,
but
it's
coming
down
in
all
of
them.
I
have
the
scope.
I
have
three
different
actions:
mom
is
the
EP
registration
for
the
endpoint
registers
itself.
Long
is
the
commissioning
tool.
K
K
So
the
values
of
the
EP
name
and
the
sector
which
are
suggested
is
that
for
the
EP
name,
we
use
the
certificate
identifier
which
we
take
from
the
certificate
and
the
EP
sector
is
actually
configured
in
the
authorization
server
for
give
a
certificate
identifiers.
So
it
should
be
knowing
that
the
certain
end
point
can
ask
for
this
EP
name
within
this
sector
and.
K
This
end
point
to
register
with
the
unique
name:
fareham
Moto
G
prefer
sexy
and
no
sector
alt,
and
we
have
some
the
cozy
key
and
I
think
those
cows
key
can
actually
be
taken,
probably
from
the
public
key,
which
is
also
stored
in
the
in
the
in
the
certificate,
so
that
you
can
do
actually
verify
that
the
one
who's
asking
for
the
claim
is
actually
also
the
possessor
of
the
this
is
not
I
want
to
see.
I
wanted
to
act
that
as
an
example.
K
L
So
I
wonder
if
I'm
the
only
one
who
thinks
this
is
way
too
complex
for
a
problem
that
we
have
seen
before
in
many
many
places.
So
when
you
do
ipv6
neighbor
discovery,
you
have
the
same
problem
that
you
use
your
MAC
address,
but
here
someone
else
would
come
and
claim
claim
your
MAC
address
and
reduce
register
and
address.
And
what
you
do
is
you
simply
use
a
random
identity
and
even
from
a
privacy
parts
of
you
that
I
would
encourage
using
something.
L
That's
completely
random,
so
I
don't
see
why
you
can't
just
use
the
random
endpoint
name
and
register
it,
and
then
the
next
guy
comes
and
uses
a
completely
random
endpoint
name.
What
issues
do
you
run
into?
What
kind
of
limitations
you
have
on
the
endpoint
name?
Does
it
have
to
be
human,
readable,
humor?
Not
just
a
table
like
I,
don't
see
the
point
boy
it
has
to
go
to
another
party
now
and
say:
can
I
use
this
endpoint
name
get
approved,
then
go
back
and
say:
yes,
you
are
able
to
use
this
endpoint
name.
E
Our
solution,
however,
is
different.
You
are
then
going
back
to
the
to
an
authorization
server
which
then
finds
the
stuff
that
is
in
the
certificate
with
what
is
being
presented
at
the
application
layer.
This
would,
of
course,
be.
Another
possibility
is,
if
you
make
sure
that
they
identify
you
pass
in
Adi,
as
an
endpoint
name
is
equal
to
what
the
stuff
that
you
provide
in
the
certificate
was
thin,
then
it
wouldn't
be
a
problem.
Okay.
E
Q
Q
S
suggestion
yeah
so
so,
because
I
would
expect
from
well
it's
the
discussion
from
the
core
mailing
list
about
RT,
but
that
there
is,
for
instance,
also
adjust
the
certificate
based
way.
So
if
the
client
has
a
certificate,
the
tears
that
feel
queer,
basically
the
endpoint
name
comes
from,
and
it's
proven
that
you
process
that
meaning-
and
this
is
one
way
another
way-
could
be
that
you
have
some
something
like
just
open,
so
that
some
some
external
authority
says
yeah.
You
are
allowed
to
use
it
so
meaning
in
general.
Q
E
On
this
again,
but
you
do
embrace
another
interesting
question,
namely,
is
the
registration?
Does
it
require
some
authorization?
So
you
have
the
scope
for
army
today
which
provides
that
information.
So
if
you
have
a
son
sort
of
a
separate
authorization
server,
food
then
allows
you
to
get
the
token,
which
indicates
that
you
are
able
to
do
the
authorization.
Maybe
that
could
be
useful
but
specifically
for
those
cases
for
you
have
is,
which
is
another
feature
which
you
didn't
have
in
your
slide.
E
But
it's
in
the
document
is
this
third
party
registration,
I
think
the
earth
this
mechanism
comes
in
handy.
It
doesn't
quite
work
in
a
way.
You
describe
it
in
my
opinion,
because
you
have
a
third
party
who
registers
a
bunch
of
different
end
points
in
in
sort
of
one
shot
in
this.
Of
course,
there's
the
question
of
like
how
do
you
actually
secure
this,
and
currently
the
spec
says
oh
and
I
was.
J
D
D
So
that's
a
bit
the
people,
the
point
of
view
of
that
and
coming
from
me
and
I,
don't
have
solutions.
They
only
have
questions
but
I
think
it's
worth
to
take
this
stand
for
what
exactly's.
So
all
the
discussion
on
the
mailing
list
was
about
the
endpoint
name,
which
is
kind
of
useful.
If
you
are
sitting
in
front
of
a
management
station
and
want
to
know
whether
that
thing
over
there,
actually
it
still
works
or
not.
G
D
So
the
assumption
here
seems
to
be
that
the
registration
requires
authorization
for
registration
under
and
in
point
name,
but
the
resource
directory
does
not
care
at
all
about
what
is
registered
under
this
thing
and
okay,
that
the
effect
that
the
particular
end
point
registered.
Something
probably
also
protects
changes
through
that,
so
that
only
that
end
point
can
change.
So
that's
useful
thing
to
have,
but
it
sent
out
quite
clear
whether
the
the
second
bullet
here,
the
resource
break,
who
doesn't
care
about
what
is
registered.
Another
name
actually
solves
our
objectives.
Next
slide,
please.
D
So
what
are?
Potential
threats
and
I
certainly
didn't
try
to
be
exhaustive
here,
but
just
just
as
a
simple
example.
So
if
you
don't
control
the
attributes
that
you
actually
registered
together
with
the
other
information
for
an
endpoint,
then
of
course
I
can
register
something
under
another
nodes:
appearance,
for
instance,
so
I
can
put
in
a
registration
that
has
the
wrong
attributes
in
it
or
I
could
also
for
myself
claim
the
wrong
attributes
I'm
the
temperature
sensor
for
room
405.
D
So,
in
those
cases
we
are
where
it's
important
that
the
discovery
process
which
uses
the
resource
directory
actually
finds
the
things
that
need
to
be
thought.
I
think
this
is.
This
is
not
good,
so
yeah.
On
the
other
hand,
endpoint
names
are
kind
of
not
so
important,
I,
don't
care
how
the
temperature
sensor
in
room
405
is
is
named,
I
might
have
an
application
where
I
have
a
Symantec,
endpoint
name
and
so
on,
and
then
it
starts
to
make
more
sense.
D
But
if
I
have
a
random
one,
it's
just
not
that
important,
and
actually
we
have
designed
the
resource
query
in
such
a
way
that
the
endpoint
name
isn't
even
visible
to
someone
looking
at
the
resource,
so
protecting
it
is,
is
kind
of
beside
the
point
next
time
so
really
in
I'm.
Sorry,
we
spent
the
weekend
talking
about
semantics,
so
maybe
I'm
a
little
bit
on
a
particular
rail
here,
but
they
have
a.
D
We
have
to
talk
about
protecting
semantics,
so
dust,
the
authorization
that
we
get
from
an
authorization
server,
maybe
have
to
include
the
the
effect
that
the
authorization
in
this
case
is
for
a
temperature
sensor,
and
no,
you
cannot
say
you
are
a
refrigerator
when
you
are
a
temperature
sensor.
Does
it
include
that
that
would
be
intrinsic
semantics?
Are?
Can
can
you
Limit
registrations
to
some
extrinsic
cement-like?
D
You
are
the
temperature
sensor
in
room
405
406,
and
what
we
need
to
do
not
today
not
here,
but
what
we
ultimately
need
to
understand
is
we
need
to
represent
those
authorization
semantics
in
our
authorization,
data
structures
and
the
only
place
we
have
right
now
is
this
scope,
and
that
might
be
a
little
bit
too
unwieldy,
because
just
a
string
cannot
put
structural
information
in
there.
So
maybe
we
have
to
think
about
other
scope
like
claims
that
clarify
what
the
authorization
is
for.
There
are
also
other
proposals
for
authorization,
information
formats
and
so
on.
E
Interesting
I
think
you
are
sort
of
like
shuffling
the
problem
around.
In
some
sense,
you
know,
like
the
discussion
we
started
office.
Do
we
need
is
in
pointing
and
the
answering
cannot
be.
Oh,
there
are
all
these
other
things
that
we
could
security
issues.
Could
we
talk
about
them
that
I
want
to
solve
this
endpoint
name
thing?
D
Yeah
I
think
the
the
the
problem
we
are
going
to
run
into
if
we
just
solve
the
the
protection
of
the
endpoint
name,
is
that
people
are
going
to
start
encoding,
the
semantics
that
they
actually
need
and
they
actually
want
to
project
into
those
endpoint.
Yet
and
I
mean
we
are
seeing
this
in
real
world
deployments
or
that
this
is
not
hypothetical.
F
Ctbt
actually
expanded
the
spoke
to
be
a
binary
garden,
so
you're
not
restricted
to
just
drink.
We
can
actually
have
spoken,
so
that
is
probably
not
as
good,
whereas
a
suggesting
there
is
a
potential
problem
that
we
don't
have
any
sort
of
standardized
idea
of
how
to
structure
data,
but
that's
a
different
issue.
We
have
many.
F
I'm
trying
to
figure
out
two
things
here,
one
is
are,
you
is:
are
we
asking
the
group
to
solve
a
particular
problem?
You're
dealing
with
resource
directory
is
school,
or
are
we
trying
to
say
it
use
this
as
an
example
of
a
more
general
problem,
in
which
case
I'm
having
a
problem,
our
from
Peters
presentation,
I'm
having
a
problem
of
punishment
with
general
papoulas
I've
got
a
bit
more
of
an
issue
of
an
idea
from
your
presentation.
You
think
the
general
problem.
R
Violent
PMS
but
DNS
SEC
doesn't
say
anything
about
the
actual
rasa
T
of
the
information.
That's
in
that
zone
file.
We
assume
that
there's
a
human
administrator
in
India
or
that
there's
a
trusted
element
that
puts
things
so
we're
talking
about
a
case
where
they
come
out
of
the
box
and
they
need
to
be
able
to
represent
to
other
clients
what
they
actually
services
they
actually
provide,
and
we
want
that
to
be
accurate.
Information
I
wouldn't
want
to
be
trusted
information.
A
A
R
S
D
So
the
original
assumption
was
that
there
is
some
way
that
the
optimization
servers
and
resource
directory
are
covered
in
such
a
way
that
that
all
this
can
be
done
behind
the
scenes,
and
what
we
are
doing
now
is
trying
to
understand.
How
can
we
reduce
that
coupling
and
actually
have
a
resource
directory,
maybe
inject,
with
authorization
service
of
very
different
kinds
and
still
collect
information
in
one
place?
That
has
some
veracity
to
it?.
S
D
R
Carolyn
Oracle
plus
9
I
have
a
question
about
actually
have
to
first.
My
understanding
and
I
could
be
wrong.
Is
that
the
information
that
one
finds
in
a
resource
directory
could
also
be
gotten
directly
from
the
node?
Yes,
if
one
does
it
get
the
Roman
four,
so
I
guess
question
number
one
is:
should
protecting
this
information
also
extend
to
the
client
itself
and
you
basically
ask
the
client,
you
know
what
is
what
does
it
support
and
number
two?
D
Yeah,
so
the
interesting
thing
about
right
on
call
is
that
it's
very
clear
that
the
information
that
is
in
there
is
a
claim
by
the
device
that
carries
that
final
call.
Now
in
a
recess
break,
we
we
mix
all
this
stuff
up,
and
this
mixing
has
has
a
lot
of
problems
to
it,
because
somebody
who
goes
to
the
users
directory
doesn't
have
the
provenance
of
the
information
that
is
mixed
up
in
that
Lisa
stretcher.
D
So
maybe
we
just
have
to
be
a
bit
more
careful
and
preserving
that
and
preserving
ways
for
somebody
who
looks
into
a
resource
directory
to
assess
the
information
in
there
so
that
that
would
be
one
behalf
of
the
answer.
The
other
half,
of
course,
is
a
resource
review,
also
associate
resource,
and
we
have
to
protect
that
shared
resource.
So
we
need
to
understand
what
the
text
sign
there.
So
somebody
could
masquerade
as
1
million
endpoint
names
and
make
it
really
hard
to
find
anything
in
their
thing.
D
D
D
D
D
E
D
N
N
So
if
we
are
able
to
achieve
the
context,
what
we
are
talking
about
in
that
particular
system
between
Rd
under
particular
endpoint
name,
that
could
be
same
name,
which
is
being
listed
by
three
people.
But
if
you
are
able
to
find
the
comp
context
between
that
endpoint
and
that
RV
and
it's
not
exchanged
between
anybody
else,
then
that
constant
remains
that
context,
which
remains
constant.
So
you
can
have
three
a
ones
but
the
with
multiple
identities
between
the
Rd
and
a
1
1,
a
1
2
A,
1
B.
Q
This
is
Matias,
I
want
to
go
back
to
the
argument
or
discussion
before
so
initially.
I
was
a
bit
confused
after
usage
of
scope
in
the
proposal
by
Peter,
and
now
I
got
even
more
confused
saying
that
it's
the
authorization
server
that
kind
of
grant.
Yet
this
is
the
right,
endpoint
name
and
so
on
so
step
a
bit
back.
So
my
understanding
of
all
this
was
that
we
have
a
coupe
of
possession
token
and
there
I
can
prove
that
a
certain
claim
that
is
precise,.
Q
It
because
so
the
the
client
can
prove
a
certain
claim
possession
token,
and
so
the
over
setup
would
be
that
an
authorization
server
can
grant
authorization
to
register
at
an
RD.
But
then
it's
up
to
the
client
that
the
client,
who's,
yeah
and
I
really
am
allowed
to
use
this
endpoint
name.
And
that's
so.
It
would
be
a
claim
in
the
full
possession
token
that
somehow
has
to
be
proven
by
the
means
of
the
token.
But
it's
not
something
that
is
granted
by
the
authorization
server.
But.
D
Q
There
must
be
some
something
like
a
certificate
that
says
yeah.
This
entity
is
allowed
to
use
that
name
and
that
can
be
imprinted
on
the
device
that
as
a
client
want
to
register,
or
it
could
be
that
this
key
is
also
available,
for
instance,
to
the
commissioning
tool
that
then
can
use.
Yeah
I
am
not
at
the
endpoint
that
he
wants
register,
but
I'm
allowed
to
use
the
endpoint
name
because
I'm
the
commissioning
tool
on
its
behalf.
Yes,.
D
Q
G
Q
That's
not
the
authorization
server
that
has
any
knowledge
of
ever
deafblind
has
the
right
to
use
that
end,
point
name
or
not.
That
has
to
come
well
initially
from
from
Klein
itself.
It
can
be
then
moving
with
the
pop
token
and
so
on,
or
maybe
we
have
been
a
more
elaborate
out-of-band
mechanism,
but
it's
kind
of
a
separate
track
from
the
obvious
authorization
server
that
is
only
about
being
authorized
in
register
at
NRG.
So.
D
Q
Also
and
that
the
bigger
problem
is
also,
this
is
more
complex
and
they
are
some
simple
solutions
there,
for
instance,
there
at
the
time
that
registers
had
a
certificate
that
can
prove
that
it's
allowed
to
use.
That
name,
and
if
that
is
not
enough,
then
we
can
look
into
some
more
elaborate
ways.
But
if
we
intended
multiple
problems
in
this
because
well
the
obvious
thing
is:
we
need
some
authorization
from
register
at
the
Rd.
There's.
D
Q
D
Q
Q
Q
F
Jim
Chuck
there's
one
concept
that
it
suddenly
dawned
on
me
and
resource
directories
that
we
haven't
discussed
here.
That
does
have
some
impact,
potentially
on
names
and
that's
groups,
because,
if
you're
doing
groups,
it
may
actually
be
very
important
that
the
name
to
be
predetermined
rather
than
made
up
on
the
block,
because
the
entity
doing
the
registration
may
not
be.
F
D
T
It's
a
security
mechanism
of
choice
right
the
unborn
tool
says
you
are
authorized
to
be
a
temperature
sensor,
that's
separate
and
they
a
separate
from
saying
that
whether
you're
allowed
to
register
that
information-
and
you
pointed
out
like
Tony,
pointed
out
that
you
know
DNS,
you
put
the
information
in
there
and
you
don't
know
whether
it's
the
correct
information
or
not
whether
you're
off
the
right
to
put
it
in
there
is
a
different
question.
So
there's
actually
two
things
going
on.
One
is
when
resolving
information
you
may
or
may
not
be
using
the
resource
directory.
T
You
might
be
using,
you
know,
multicast
or
whatever,
and
you
still
want
the
same
problem
to
be
solved
right
and
so
the
response,
whether
you're
getting
it
in
a
resource
directory
or
whether
you're
getting
it
from
the
device
itself.
Okay,
contains
some
data,
that's
the
data
that
you
need
to
be
able
to
solve
at
did
at
the
requester
level
to
say
the
information
that
I
got
back
is
good
or
not.
T
Okay,
and
so,
even
if
the
resource
directory
does
not
take
care
of
that,
if
you
had
a
common
mechanism
between
the
two,
which
is
how
all
join,
did
it
then,
whether
if
the
resource
directory
holds
bad
data
or
not
as
just
an
efficiency?
Yes,
because
I
would
throw
it
away
in
the
same
way
as
I
would
throw
away
and
multicast
response
it's
not
on.
You
can
then
choose
to
say
my
registration
server
might
choose
to
check
it
the
same
way
as
any
other
request
to
check
it
before
I
actually
put
it
into
my
database.
E
D
Yeah
there
is
a
slight
terminology
problem.
The
charm
attestation
we've
just
used
is
about
signing
signing
acclaim,
that's
what
you
call
it
a
station.
There
is
also
something
called
a
testing
system,
health
and
these
are
two
different
things.
So
those
people
who
don't
care
about
a
testing
system
as
they
still
want
to
go
to
the
book
this
unit
and.
D
G
L
U
A
Agree,
so
we
were
not
naive
enough
coming
into
this
conversation
that
we
would
get
any
class
of
resolution,
but
just
randomly
aggregating
some
of
the
things
I
heard
you
know
as
to
what
is
even
the
problem.
So
we
can
narrow
down
not
using
the
word
scope
but
narrow
down
what
the
it
is.
So
we
can
make
decision
whether
we
want
to
work
on
it
whether
the
Charter
I
mean.
Are
we
just
talking
about
something
narrow
related
to
end
points?
Is
that
just
an
exemple
arm
a
general
problem?
A
What
is
the
link
between
that
endpoint
discussion
and
the
general
problem,
then
dot
dot
dot?
What
is
the
general
problem
you
want
to
solve,
so
that's
on
the
table.
Then
we
just
briefly
had
a
conversation.
Are
we
trying
to
solve
an
integrity
issue
retrying
to
solve
a
privacy
issue,
probably
kind
of
both,
but
at
what
level
is
it
a
nice
or
we're
using
other
constructs?
We
also
had
a
discussion
about
what
does
this
solution?
Look
like
relative
to
that?
Are
we
talking
about
a
way
versus
bellei?
A
M
M
So
there
was
one
concern
about
not
to
that's
the
date,
the
application
layer,
data
carried
in
message.
Two.
We
are
addressed
that
in
in
the
latest
version
of
the
protocol,
so
we
I
think
this
is
one
good
good
resolution.
The
one
on
discussion
points
in
the
face-to-face
meeting
on
the
formal
properties
of
the
protocol
and
then
another
major.
M
So
some
some
more
details
of
the
changes
that
we
made.
So
we
renamed
the
app
to
parameter
two
unprotected
additional
data
just
to
illustrate
that
this
data.
This
was
the
comment
from
the
formal
verification
that
this
data
is
actually
not
protected.
It's
not
authentic,
but
it's
not
authenticated
party
user
authenticates.
At
the
point
when
this
data
is
being
sent.
That's
one
way
we
address
that.
That
comment
and
the
other
comments
here
are
also
input
from
from
various
reviews.
M
We
made
the
session
identifier
optional,
when
the
underlying
lay
here
can
be
used
to
to
enable
the
binding.
So,
for
example,
in
coop
is
used.
That
was
a
comment
by
Jim
in
the
previous
review.
We
changed
raw
public
key
format
from
x.509
to
cozy
key,
which
reduces
the
message
size
and
also
allows
the
use
of
key
identifier.
M
This
is
from
six
dish
and
also
from
four
applications
using
narrowband
IOT,
which
is
this
cellular
low,
decorate
taxes
and
I
like
to
add
to
that.
For
for
people
working
with
Artie
security,
we
can
still
today
here
2018,
but
some
companies
want
to
deploy
IOT
without
security
because
they
find
the
overhead
problematic
for
latency
and
for
other
reasons.
So
that's
actually
the
reason
why
we
are
doing
this
work
and
we
think
that
this
is
going
at
least
aiding
in
the
overhead
inspector.
M
So
here
are
the
other
changes
in
terms
of
reduced
overhead,
and
the
first
point
I'd
like
to
stress
here-
we're
like
to
have
a
discussion
around
is
what
we
are
actually
removing
the
monsters
from
from
the
protocol.
So
this
is
the
previous
version
of
the
protocol.
We
had
nonces,
but
we
allow
the
reuse
of
ephemeral
keys
in
this
version
of
the
protocol.
We
remove,
denounces
and
do
not
allow
the
reuse
of
Meral
keys.
So
this
may
be
a
contention
contention
point,
but
we
are
happy
to
discuss.
M
M
Intramural
key,
we
only
send
x-coordinate
the
curve,
algorithm
the
ciphertext
and
encrypted
signature
instead
of
the
full
cozy
structures.
So
this
is
actually
in
line
with
what
I
was
course
doing,
and
it's
in
line
with
what
was
requested
to
the
mailing
list
to
do
in
the
sport
profile.
So
60s
has
a
problem
fitting
it
into
the
frames
and
instead
of
carrying
the
entire
Coast,
the
object.
M
You
you
pick
out
the
important
parts
and
you
recreate
the
cozy
object
at
the
receiver
side.
That
gives
a
good
last
compression
of
the
message.
Use
algorri
indices,
specify
chosen
algorithms,
which
is
also
another
technique
for
reducing
overhead
and
and
last
but
not
least,
we
use
sequence
of
C
border
elements
instead
of
arrays.
Perhaps
it
was
actually
least
anyway.
So
that's
that's
the
type
of
changes
that
led
to
this
low
overhead.
The
next
steps
is
to
ensure
that
the
formal
verification
of
version
zero,
eight
actually
holds
also
for
these
changes
in
Sarah.
M
A
Okay
thanks.
Thank
you.
Okay,
administrative
really,
most
important.
Where
are
the
blue
sheets?
Has
everyone
signed
the
blue
sheets,
so
I
see
folks
need
to
sign
in
the
back,
so
if
you
could
who
things
to
but
to
the
signup
to
the
back,
we
have
a
couple
of
minutes
for
open
mic.
Is
there
anything
anyone
wants
to
talk
about.
A
And
they
just
read
them
off:
okay.
So
when
we
were
talking
about
the
CWT
proof
of
possession
kind
of
draft
about
what
the
next
step
will
is
related
to
that,
the
authors
are
gonna,
look
at
what
was
posted
on
the
mailing
list
for
the
last
week.
That
summarize,
what
are
some
of
the
outstanding
issues,
and
that
will
be
the
steps
necessary
for
further
progression.
Then,
in
talking
about
the
law
or
position
kind
of
framework,
another
draft
is
going
to
be
published
kind
of
the
August
timeframe.
A
When
we're
going
to
go
working
with
last
call
in
September,
there
were
no
more
drafts
individual
drafts.
We
talked
about
relative
to
group
communication.
We
decided
we're
going
to
continue
kind
of
working
on
those,
but
we're
gonna
defer
working
group
adoption
until
some
of
the
framework
documents
are
complete.
We
had
a
very
robust
discussion
around
resource
directory
kind
of
authorization.
You
know,
as
I
have
kind
of
wrapped
up.
There
is
some
issues
of
what's
the
real
problem
which
part
of
the
problem.
What
are
kind
of
solutions
and
we're
gonna
have
to
continue
discussing
that.