►
From YouTube: IETF104-ACE-20190329-1050
Description
ACE meeting session at IETF104
2019/03/29 1050
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
B
B
F
G
Good
they
easy
of
cop
as
this
in
small
reminder
of
what
it
is
doing.
It
looks
at
the
est,
but
instead
of
HTTP
and
TLS,
it
uses
co-op
and
DTLS
for
constraint
devices.
We
have
two
application
areas
identified.
One
was
to
add
for
the
to
be
used
in
the
Brisky
context
and
other
one
is
a
distribution
of
identities,
independent
of
whisky.
F
G
We
have
had
two
inverted
group
last
call
which
is
end
of
this
virus.
Remember
we
have
many
thanks
to
Jim,
ESCO
clouds
and
Kirsten
for
all
the
remarks
we
sink.
We
have
taken
them
all
into
account.
We
have
discovery
in
content,
format,
negotiations.
The
next
slide
will
be
about
that
have
been
terrified
and
corrected.
G
We
have
added
the
another
application
area
which
was
asked
by
s
Co
because
he
had
this
fantastic
person
which
was
so
fast.
He
wanted
that
so
that
sounded
correctly,
we
had
some
difficulties
in
interpreting
correctly
RFC
7250.
These
have
been
corrected
as
far
as
I
know,
and
we
have
updated
the
example
we
made
and
the
very
call
it
not
very
correct
assumptions
about
how
accept
was
used.
This
has
also
been
removed.
There
were
some
typing
errors,
also
removed.
G
So
the
whole
thing
looks
much
more
clear:
the
detail,
s
sections
we
had
to
detail
our
sections
with
bomblets
explained
why
it
was
necessary
and
by
its
fitted
in
the
context,
another
detail
last
section
said
by
it
also
handy
for
the
application
and
what
was
being
used
by
yet
so
we
merged
all
that
which
was
nice
and
general
I
think
the
document
has
become
much
clearer.
Thanks
to
the
working
group.
Last
call
document
comment.
So
thank
you
very
much
for
all
that.
G
Any
comments,
please
do
not
hesitate.
So
this
is
about
a
multi-part
payload
in
the
surfer
key
generation.
What
he,
what
is
returned,
a
two
type
of
media
types
and
thanks
to
the
core
working
group
understanding
we
have
had
the
multi-part
content
format
has
been
defined
in
which
it
is
possible
to
specify
different
content
formats
which
are
sequentially,
follow
each
other
in
a
Seabury.
G
This
was
great
till
the
moment
we
had
actually
the
possibility
to
either
continue
due
to
send
back
PKS
c7
or
to
send
back
pkix
in
one
of
the
parts,
and
we
saw
this
was
all
very
simple.
We
just
mention
it
somewhere
and,
and
we
do
the
accept
option,
then
it
was
pointed
out
that
the
only
thing
we
can
accept
was
the
complete
format
for
the
62,
and
that
was
not
much
negotiation
going
on
here,
so
that
wasn't
pain
in
the
neck.
G
But
after
several
discussions
on
the
mailing
list,
thank
you
all
very
much
for
the
helpful
remarks,
so
we
finally
decided
to
have
an
additional
pass
bond,
which
is
called
s
ki
J,
which
returns
the
one,
the
PK
7
and
the
P
key
CS
8
and
the
other
one
which
returns
the
PK
of
C
8
and
the
pkix.
We
have
had
no
contraindications
about
the
solution.
So
if
you
everybody,
if
anyone
thinks
it
should
not
be
done,
this
is
the
moment
no
great
now
so
so
this
slide
is
valid.
D
A
E
See
hello
a
little
bit
sights
I'm
going
to
present
updates
in
the
draft
8/8
ace
of
alpha,
which
I
called
framework
and
in
a
companion
document,
the
draft
ITF
ace
of
parameters
which
I
call
the
permanent,
so
I've
split
these
updates
into
several
slides,
because
it's
a
lot
of
update
since
last
ITF,
we
saw
version
16
at
last
ITF
and
we
added
a
lot
of
things
already
version
16
to
17.
So
it
was
pointed
out
to
us
that
we
were
saying
the
RS
receiving
an
access.
E
Token
needs
to
verify
it,
but
we
didn't
say
what
very
fine
meant
so
I
added
a
section
that
explains
what
steps
the
resource
server
needs
to
go
through.
To
verify
a
token,
we
got
the
comment
that
we
were
creating
a
very
dangerous
endpoint
here
of
info
and
that
we're
not
giving
any
guidance
on
how
to
protect
that
against
attacks.
So
now
there's
a
section
that
is
saying
that
you
shouldn't
permit
any
actions
of
the
children
resources
of
off
info.
E
We
have
a
mechanism
of
token
expiration
based
on
sequence,
numbers
and,
as
in
our
discussion,
it
turns
out
that
it's
very
likely
that
every
device
will
have
at
least
the
real-time
clock
chip.
We
remove
that
because
it
was
designed
for
devices
that
don't
have
any
clock
and
the
discussions
indicate
that
this
is
unrealistic.
E
We
added
also
it
was
pointed
out.
We
require
the
secure
communication
between
all
the
entities
and
we
weren't
saying
what
secure
communication
actually
meant.
So
we
added
a
section
that
specifies
all
the
known
things
that
you,
you
probably
already
know
and
expected.
But
now
it's
explicitly
said
so
we
want
the
Krypton
integrity,
protection,
protection,
freshness
and
binding
of
the
response
to
the
request.
E
I
E
Is
when
you
are
interacting
with
token
interface,
with
the
introspection
endpoint
and
with
the
resource
server?
So
in
some
way
you
need
to
know
if
you
get
a
response
back
to
which
requests
was
that
related,
so
that
you're,
an
attacker
cannot
serve
your
old
responses
right,
and
that
applies
to
any
interaction
like
if
I
do
a
request
for
a
token
I
want
to
know
that
an
attacker
is
not
suppressing
the
real
request
and
sending
me
some
fake
token
back.
E
I
J
E
E
Okay,
next
authorization
information,
so
I
was
pointed
out
to
me
that
we
were
speaking
about
claims
of
a
token
as
the
information
that
the
resource
server
uses
to
decide
whether
an
access
was
allowed
or
not,
and
it
was
pointed
out
to
me
that
there's
other
information
like
keys
and
and
lists
of
trusted,
keys,
etc,
etc
that
are
not
covered
by
these
claims,
but
that
are
relevant
for
the
authorization
decision.
So
I
looked.
E
How
was
wording
this
and
OAuth
used
the
term
authorization
information,
but
it
didn't
seem
to
me
that
it
was
explicitly
defined
so
I
just
went
ahead
and
added
the
definition
in
the
terminology
list,
so
it's
now
defined
to
be
whatever
information.
The
resource
server
uses
to
determine
access
rights
and
sadly,
it's
very
easily
confused
with
the
term
access
information,
which
is
the
additional
information
the
authorization
server
returns
to
the
client.
E
In
addition
to
the
token,
so
all
the
things
that
the
client
needs
to
know
like
the
proof
of
possession
key
the
profile,
the
token
type
etc.
So
don't
confuse
those
two.
Please
then
Jim
is
very
comprehensive.
Reviews
pointed
out
that
this
information
object,
I
called
a
s
information,
which
is
when
you
do
an
unauthorized
request
to
a
resource
server.
It
returns
to
you
an
information
object
that
basically
tells
you.
This
is
the
authorization
server
you
need
to
go
to
to
get
AB
token.
To
access
me.
Jim
pointed
out
a
s.
E
E
We
also
added
some
functionality
optional
functionality
there.
So
you
don't
you
can
you?
You
are
required
to
return
the
address
of
your
a
s,
and
you
can
optionally
also
say,
and
for
the
resource
you
wanted
to
access.
You
would
need
to
request
this
scope
and
by
the
way
you
can
address
me
with
this
audience
so
that
you
can
as
a
client
that
doesn't
know
anything
about
the
resource
server.
E
You
can
query
it
in
that
way
and
then
build
a
valid
requests
for
a
token
that
will
work
with
that
with
add
resource
server
to
the
a
s.
So
it's
it's
a
functionality
that
supports
clients
that
have
no
previous
configuration
telling
them
how
to
talk
to
the
RS
and
it's
optional.
So
if
you
have
like
everything
pre-configured,
then
you
just
skip
those
message
fields.
E
We
added
also
a
key
identifier
to
the
a
s
request.
Operation
hints
this
supports
a
mechanism
where
you
already
have
an
established
security
Association
with
the
resource
server
and
at
some
point
you
hit
the
401
unauthorized
and
you
say:
damn
it.
I
want
a
new
access
token
to
give
me
that
access,
but
I
want
to
avoid
redoing
the
detail
s
handshake.
So
please
find
this
new
access,
token
to
the
same
security
Association
or
the
same
proof
of
possession
key
that
I'm
already
using
so
that
I
can
skip
redoing
the
detail,
s
handshake.
E
Then
we
had
a
long
discussion
about
security
considerations
for
multi
RS
audiences.
So
if
you
have
an
access
token
with
an
audience
claim
and
the
audience
claim
identifies
a
group
of
resource
servers,
basically
that
a
lot
of
questions
around
this
one
was
that
one
conclusion
was
that
you
cannot
use
a
symmetric
proof
of
possession
key
here,
and
you
cannot
use
a
symmetric
key
to
protect
this
access
token
here,
because
otherwise,
any
member
of
this
resource
group
can
change
the
access
token
or
can
impersonate
the
client
towards
other
members
of
this
resource
group.
E
So
there
is
a
new
section
in
the
security
consideration
that
elaborates
on
that
problem
and
I
was
told.
I
need
to
provide
expert
review
instructions
for
the
registries
that
map
parameters
to
abbreviations,
so
I
did
that
copying
generously
from
both
the
GWT
draft
and
the
Cosi
draft.
Thank
you
for
your
input
and
finally,
now
we
are
stepping
up
the
numbers
to
the
current
or
almost
current
version.
E
We
had
a
discussion
about
the
keys
that
the
client
uses
to
authenticate
the
resource
server.
So
Stephanie
pointed
out
that
as
a
client,
there
might
be
situations
where
you're
sitting
under
an
access
token.
You
don't
know
that
it
is
it.
It
is
expired,
or
rather
you're,
sitting
on
a
key
for
the
resource
server,
and
you
don't
know
that
this
key
is
no
longer
valid
and
then
you're
sending
requests
through
this
resource
server.
That
might
contain
sensitive
information
like
if
you're
doing
a
post
request
that
contains
say
a
firmware
update.
E
E
So
basically
now
the
problem
boils
down
to
the
client
needing
to
know
whether
the
token
has
expired
or
not,
and
the
token
is
opaque
to
the
client.
So
there
are
several
ways
for
the
client
to
learn
whether
it's
tokens
are
expired,
one
would
be
to
do
introspection
and
there
is
going
to
be
another
presentation
about
client
introspection
later
if
we
manage
to
keep
the
time.
E
We
are
now
saying
that
if
you
as
a
client
get
a
token
and
cannot
determine
whether
this
token
is
when
this
token
expires,
then
you
should
not
use
it,
which
implicitly
says
use
expired
in
aspires
in
or
any
other
means
at
your
disposal.
But
if
you
don't
have
any
of
them,
don't
use
the
token.
So
it's
kind
of
making
this
expires
in
bit
more
than
just
recommended.
E
Anyway,
next
one
was,
we
had
a
section
with
Ayana
mappings
and
it
was
saying
that
a
certain
number
range
of
of
abbreviations
required
specification
Jim
pointed
out
to
me
that
this
would
be
very,
very
ridiculous
specifications.
You
would
have
a
specification
that
says
the
open,
ID
claim
assertion
has
the
abbreviation
47
.
end
of
spec
and
that
sounded
really
not
like
a
good
use
of
specifications.
So
we
changed
the
mapping
sections.
Only.
E
Olaf
pointed
out
to
me
that
if
you
use
the
mechanism
in
the
detail
s
profile,
where
you're
sending
the
token
in
the
detail-
s
handshake,
you
don't
have
the
ability
to
return
these
error
responses.
This
restful
error
responses.
You
can
raise
some
detail.
S
errors,
but
they
don't
map
to
the
the
restful
errors.
So
now
it
is
optional
for
the
RS
to
give
an
error
response,
which
is
probably
in
general,
a
good
idea,
because
there
are
situations
where
you
don't
want
to
tell
a
potential
attacker.
E
F
K
E
E
Okay,
so
this
were
the
changes
up
until
dim
press
the
publication
required
button,
because
at
that
point
we
thought
we
had
addressed
all
the
comments.
Sadly,
a
few
days
after
Jim
pushed
the
button,
we
got
another
comment
that
turned
out
to
be
a
review.
Actually,
so
oh
I
got
the
order
of
my
slides
wrong.
I
was
going
to
talk
about
the
terms
first
and
then
about
that.
So
let's
do
the
perms.
E
First
param
was
a
document
we
split
out
of
the
framework,
and
the
idea
here
was
that
we're
using
this
document
to
define
things
that
Oh
F
is
working
on
in
parallel
and
that
at
some
later
point
in
time
they
one
might
want
to
supersede
like
invalidate
and
to
avoid
them
to
have
to
invalidate
the
whole
ace
framework.
We
split
it
out
into
separate
draft,
so
if
at
some
point
they
make
something
that
breaks
or
changes
this
they
can
just
update
this
one
and
and
and
obsolete
it
without
obsoleting
the
framework.
I
Was
wondering
whether
you
also
included
the
resource
parameter
in
addition
to
the
audience?
The
audience
is
the
logical
name,
the
resources,
absolute
your
eye,
and
and
in
some
cases
one
or
the
other
may
be
more
appropriate
depending
on
what
you
want
to
do
in
the
hours
document,
so
yeah.
If
it's
not
the
end,
it
would
be
just
one
additional
registration
for
the
probably
I'm
just
saying
so.
At.
E
The
moment,
let
me
just
go
through
this
bullet
and
then
it
will
become
clearer.
What
we
did
is
two
things.
We
added
a
lot
of
examples
for
every
of
these
parameters,
and
then
we
had
a
long
discussion
about
our
required
audience,
parameter
that
we
defined
and
found
out.
There
is
an
equivalent
parameter
in
the
OAuth
token
exchange
specification,
which
is
called
audience
not
to
confuse
without
a
UD,
which
is
the
audience
claim,
which
can
also
be
used
as
a
parameter,
meaning
something
slightly
different.
E
So
since
this
and
this
had
exactly
the
same
semantics,
we
struck
that
out
of
the
params
document
it's
removed
and
instead
we
defined
a
mapping
to
audience.
In
the
framework
we
haven't
defined
a
mapping
for
resource
which
now
strikes
me
as
a
bit
odd.
We
could
actually
do
that
without
any
any
issues,
just
like
specify
a
number,
a
British
number
for
the
parameter
and
say
usage
like
it's
defined
in
the
resource
indicators,
trust.
E
So
this
is
what
we
did
on
that
and
then
Jim
pushed
the
publication
required
button
and
then
I
got
a
comment
that
was
actually
pointing
out
some
problems,
not
big
problems
with
an
cleric
Clara
unclear
parts.
So
we
will
have
to
do
some
changes.
Most
of
them
are
already
in
the
version.
I
posted
on
Tuesday
or
so
so
is.
There
is
a
version
23
now
of
the
framework
and
a
version
of
five
of
the
params,
and
there
were
some
issues
with
the
parameter
mapping.
E
Sadly,
apparently,
when
I
changed
it
in
one
place,
I
forgot
to
change
it
in
another,
so
I
aligned.
All
of
this
made
a
big
table
to
make
sure
that
all
the
mappings
were
correct
now
and
I'm,
really
hoping
they
are
we're
going
to
mess
that
up
by
adding
resource
now,
but
hopefully
that
I
will
be
able
to
do
that
without
more
problems.
E
Then
it
turned
out
in
this
question
that
a
parameter
we
had
taken
from
the
detail-
s
profile
because
we
thought
it
was
generic
enough
to
being
the
framework
was
now
under
specified,
or
rather
the
processing
of
that
parameter
was
under
specified.
So
this
parameter,
which
was
originally
called
nonce,
and
then
we
discovered
that
Open
ID
has
already
registered
parametric
called
nonce.
We
had
to
change.
E
I
E
There's
several
mechanisms
now
to
deal
with
clocks
between
RS
and
AAS
that
are
not
synchronized.
This
is
one
of
them,
the
other
one
is.
This
expires
in
clay
that
tells
the
resource
server.
When
you
receive
this
token,
look
at
this
claim.
It
contains
the
number
of
seconds,
and
you
start
counting
now
and
when
these
seconds
elapsed,
then
you
throw
the
token
away.
This
is
another
way
of
dealing
with
with
expiring
but
you're
talking
about
the
other
mechanism.
Okay,
there
are
two
mechanisms
for
dealing
with
this,
either
of
which
might
be
appropriate
for
your
specific
application.
E
We
didn't
want
to
mandate
just
one
and
the
people
writing
details
profile
or
some
of
the
people.
Writing
the
Detailers
profile
thought
that
this
was
a
very
good
mechanism
to
include,
and
then
I
felt
it's
generic
enough.
It's
not
specific
to
detail
s,
so,
let's
put
it
into
the
framework,
so
it
turns
out
that
all
this
processing
that
you
had
to
do
like
client
has
to
send
this
onto
the
token
endpoint
a
SS
to
include
it.
E
In
the
token,
we're
kind
of
not
explicitly
stated
so
I
added
text
to
state
that
explicitly
and
finally,
there
were
a
number
of
small
clarifications
where
the
text
was
less
than
desirably
clear.
So
I
updated
that
and
I'm
very
sorry
for
that,
especially
that
it
came
so
late,
but
I'm
hoping
it
will
not
interfere
with
the
is
the
review
process.
So.
E
Yes,
so
details
profile,
I'm,
not
wearing
my
year
until
under
hat
somewhere.
No
Aaron
asked
me
to
do
that
presentation
for
him.
So
the
details
profile
for
Ace
is
the
one
of
the
framework
related
documents
for
which
publication
has
not
been
requested.
Yet
because
we
were
still
resolving
issues
and
there
is
a
new
update
coming
very
soon.
Actually
I
was
told.
Olaf
is
in
a
very
different
time
zone
now,
so
it
might
take
a
few
cycles
until
we
catch
up
in
our
not
very
synchronized
discussion,
but
we're
waiting
for
him
to
push
an
update.
E
What
have
we
been
doing
since
the
last
IDF?
So
at
the
last
IDF,
you
saw
version
0-5
of
that
draft
and
we're
now
at
I
think
0-8.
So
at
some
point
we
found
out
that
if
you
have
a
401
unauthorized,
while
you're
talking
to
a
resource
server
that
was
being
handled
as
a
fatal
detail,
s
error
or
the
people
could
handle
that
as
a
fatal
detail,
s
error,
which
is
bad
because
then
the
detail
s
connection
is
shut
down
and
401
unauthorized.
E
You
might
just
want
to
get
a
new
access
token
post,
that
to
off
info
endpoint
and
then
continue
using
the
same
detail
a
session.
So
we
are
now
explicitly
saying
that
this
should
be
a
non
fatal
detail
s
arrow.
You
should
continue
having
the
detail
s
session
so
that
the
client
can
fetch
a
better
access,
token
submit
it
and
then
continue
without
having
to
redo
the
handshake.
E
E
We
added
a
large
example
to
illustrate
the
case
where
you
would
have
a
confirmation
plane,
so
I
claimed
identifying
the
proof
of
possession
key.
That
was
just
containing
a
key
identifier,
so
before
I
think
in
earlier
versions
were
actually
specifying.
Some
specific
mechanism
turns
out
just
giving
an
example
of
how
you
could
do
this
and
then
saying
how
you
actually
do.
It
is
it's
down
to
the
application,
because
application
handle
resolving
key
identifier
to
actual
keys
in
many
different
ways
would
be
a
much
better
solution.
E
Speaking
of
normative,
there
were
a
few
sections
where
we
were
using
non
normative
language
and
I
felt
this
is
actually
normative.
Like
you
must
authenticate
the
client,
you
must
verify
the
signature,
etc.
That
felt
exact,
extremely
normative
to
me.
So
we
adjusted
that
and
we
compared
to
the
ausco
profile
and
the
ausco
profile
had
a
lot
of
very
nice
examples
for
every
protocol
step
and
we
didn't
so.
We
felt
we
didn't
want
to
be
worse
than
doors
profile
and
added
examples
for
each
step.
E
And
finally,
there
is
a
section
now,
a
specific
section.
It
was
hidden
somewhere
in
the
text
before
about
how
you
securely
communicate
with
the
AAS.
So,
if
you're
the
client
and
you
communicate
by
the
token
endpoint
or
if
you're
the
resource
server
and
communicate
via
the
introspection
endpoint,
this
section
tells
you
that
you
and
use
DTLS
for
this,
and
you
use
it
in
this
and
that
way.
E
B
E
E
L
E
B
E
M
This
is
the
message
flow
of
the
communication,
so
that
the
point
is
to
get
authorization
and
keys
distributed
to
clients
to
talk
to
the
dispatcher
and
group
members.
So
the
first
part
of
the
communication
is
or
of
the
message
flow
is
covered
by
ACE
or
defined
in
the
ACE
and
the
second
part.
So
after
the
token
post,
the
kiss
key
distribution
request
and
response
from
the
key
distribution
center.
That's
not
part
of
the
ACE
framework.
M
M
So
this
general
key
field
has
now
a
type
that
is
the
defining
a
new
register
which
we
call
a
scope,
compete
ready
stream.
We
also
define
a
new
profile,
so
this
is
not
the
same
profile
field
as
in
the
ACE,
because
this
is
not
a
anymore
so
and
also
we
have
any
registry
for
that-
a
scope,
cone
profile
and
we
also
define
a
new
xpl
field
which
is
related
to
the
keying
material,
so
yeah
just
to
get
some
feedback.
Do
you
think
this
makes
sense
or
any
objections
to
that.
M
The
reviewer
was
happy
with
that.
So
if
no
objection
we'll
keep
this
in
next,
we
have
a
new
section
about
how
to
request
to
leave
a
group.
So
we
define
this
the
format
for
this
request.
It's
a
co-op
post
to
the
resource
that
is
associated
with
the
group
at
the
KDC.
The
the
payload
of
this
request
look
like
that.
So
there
is
a
leave
field,
which
is
just
an
empty
array.
M
This
is
to
basically
to
distinguish
it
from
join
request,
which
is
just
the
same.
Without
the
leave
field,
then
we
have
in
the
current
draft.
We
have
a
scope
that
should
identify
the
group
and
then
optionally,
the
client
credential.
If
the
client
wants
to
send
that
now,
we
are
considering
that
the
scope
is
not
necessary
because,
anyway,
when
you
send
to
the
resource
associated
with
the
group
you're
already
telling
the
KDC
I
want
to
get
I
want
to
leave
this
group.
So
we
are
considering
removing
that.
M
N
M
Yeah,
okay,
so
another
point
is
that,
with
this
request,
the
node
can
ask
to
leave
the
group
altogether.
So,
if
you
remember,
we
have
scope
in
this
request
and
for
4k
distribution
and
for
for
leading
that
include
both
the
group
and
role
the
node
wants
to
have,
and
we
consider
that
it
only
makes
sense
to
request
to
leave
the
group
altogether.
So
you
cannot
ask
oh
I
was
I,
was
a
requester
and
a
listener,
and
now
I
just
want
to
be
a
listener.
We
don't
have
that.
M
Client
can
rear
equestria
group
without
contacting
the
AES
as
long
as
the
token
is
valid.
So
this
means
that
in
this
message
flow
the
client
can
just
do.
The
greediest
region
request
a
response.
It
doesn't
need
to
redo
the
authorization
request,
response
and
token
post
if
the
KDC
still
has
two
valid
token.
M
Okay,
so
next
point,
so
this
is
something
that
is
not
in
the
current
document,
but
we
are
considering
adding
it
and
we
would
like
to
hear
the
working
groups
feedback
so
right
now
the
scope
is
defined
as
I
was
saying,
with
an
array
with
the
first
element
is
the
group
or
the
topic,
and
the
second
element
is
the
role.
So
the
role
is
not
defined.
M
Specific
profiles
of
this
needs
to
define
exactly
what
the
format
is,
so
it
could
be
a
requester,
it
could
be
post
yet
it
could
be
something
else
that
defines
of
of
this
type.
So
now
we're
considering
that
we
might
want
to
add
finer
granularity
on
operations
and
resources,
so,
rather
than
say,
I
want
to
be
a
requester
or
broadcaster
in
this
group
you
might
want
to
say,
I
want
to
be
able
to
access
that
resource.
You
impose
using
post,
and
these
are
the
resource
using
post
and
get
or
something
like
that.
G
M
E
M
M
Finally,
we
had
a
request
from
Jim
to
add
some
some
text
about
the
key
redistribution
initiated
by
the
KDC.
So
right
now
we
have
this
section
and
it
covers,
or
it
gives
some
example
of
how
the
KDC
can
distribute
the
key
material.
So
the
first
one
is
using
unicast
requests
to
each
client
over
secure
Channel,
and
this
is
the
one
that
is
very
well
specified
and
described
in
detail.
And
then
we
have
these
other
points
which
are
for
now
only
examples
using
observe
using
pub/sub
using
multicast.
M
M
D
M
M
M
E
E
P
P
The
group
was
called
security
context
and
then
and
continue
with
communication
with
the
group
members.
Oh,
this
auto
scope
of
this
document
is
reusing,
possibly
the
very
same,
a
yes
or
another
one
to
get
access
tokens
to
access
resources
at
the
group
members
or
to
even
actually
communicate
with
those
group
members.
That's
just
about
the
group
of
score
document
in
core.
P
This
document
was
adopted
in
the
last
year
and
there
was
a
recognition
of
version.
0
of
just
the
latest
version
we
had
as
individual
submission,
so
this
update
is
about
the
working
it's
like
his
months
was
pending,
updates
that
we
had
end
of
last
year
already,
but
today,
I'll
focus
mostly
on
two
big
updates,
only
out
of
which,
of
course,
will
Italian
registrations
all.
P
Hopefully,
as
for
some
figures
from
you,
the
first
the
update
is
about
restructuring
the
way
the
journal
response
message
is
shaped
compared
to
the
previous
known,
adopted
version,
so
still
a
civil
map
and
of
course
it
follows.
The
main
model
describe
eNOS
Kiku
come
in
the
first
place.
We
have
p-type.
P
The
finance
speaker
come
here
with
value
grupos,
core
security
context
object
that
we
register
in
the
registry
and
that's
why,
in
fact,
the
K
parameter
following
is,
in
fact
the
silver
encoded
version
of
this
core
security
context
object,
defining
the
escort
profile
from
which
we
take
essentially,
as
they
are
the
parameters
within
the
the
red
frame
with
values.
Consistent
with
with
this
case
plus,
we
are
defining
two
additional
parameters
registered
as
new
parameters
for
the
Ascona
security
context
object.
P
They
essentially
indicate
the
counters
insure
algorithm
used
in
the
group
and
optionally,
if
applicable,
the
specific
parameters
to
be
considered
for
that
algorithm,
and
this
is
also
consistent
with
related
recent
updates
in
grupos
core
as
to
the
new
profile
parameter
define
in
SQL
comm
also
here
it
has
value
a
core
group
of
score
registered
in
the
related
registry
and
we
just
use
consistently
other
following
parameters
from
SQL
common.
This
was
the
first
update
and
when
working
on
this
way,
we
noted
another
issue.
P
We
hadn't
thought
about
before
right
before
joining
the
group,
meaning
right
before
sending
the
join
request.
The
group
manager,
the
client,
is
supposed
to
provide
its
own
public
key
to
the
group
manager,
but
in
general
it
doesn't
know
the
exact
countersignature
algorithm
parameters
using
the
group.
So
it
may
not
know
the
exact
format
for
the
public
key
that
the
group
manager
is
expected
to
be
used
in
that
group.
P
Please
include
your
public
key
according
to
a
format
that
makes
sense
for
the
country,
signature,
algorithm
parameters
we
use
in
the
group,
and
so
right
after
that,
the
client
has
the
dragon
sending
a
new
join
request
this
time,
including
the
public
key
according
to
that
format.
So
it's
a
blank
attempt.
P
The
second
approach
instead
is
about
coming
to
an
agreement
already
during
the
top
and
post
request,
a
response
that
happens
right
before
issuing
the
je
request.
So
the
client
in
case
of
that,
of
course,
can
explicitly
ask
their
server
for
an
indication
of
the
condition
sure
are
going
to
be
used
this
time,
including
the
client
itself.
Keen
for
parameter
side
by
side
with
the
access
token,
and
in
this
case
the
key
in
for
parameter
well,
which
was
it
to
be
just
a
super
simple
value,
no
just
be
alighted
as
as
a
flag.
P
P
P
E
P
P
Okay,
a
third
possible
approaches
just
that.
Well,
the
client
learned
the
right
expected
format
of
the
public
key
to
be
used
in
the
group
in
advance.
Somehow,
when
discovering
the
Oscar
group,
for
instance,
using
an
approach
we're
proposing
for
that
in
the
core
working
group
implementation,
wise
I'm,
working
on
implementing
this
drafting
californium
building
on
ludwig's
implementation
of
ACE
I
worked
especially
on
that
branch.
But
during
the
week
we
actually
merged
it
into
the
master
branch.
So
you
made
a
pool
you
you
find
everything
I've
done
so
far,
and
the
purely
is
segment
is
done.
P
P
So
to
summarize,
it's
mostly
document
wise
about
the
two
big
updates
on
the
new
structure
of
the
joy
response,
aligned
with
the
one-income
just
specialize
this
to
values
and
exact
content
and
three
possible
approaches
complimentary
and
with
each
other
about
having
the
client
and
the
group
manager
agreeing
on
the
public
key
format
expecting
in
this
group.
So
that
the
client
can
provide
it
correctly
upon
driving,
so
we
mostly
need
outside
feedback
on
these
two
points,
mostly
document
as
a
whole,.
D
That
was
it
so
in
the
hackathon
we
would
did
some
interrupt
testing
on
getting
the
group
message,
key
format
running,
which
is
a
core
document,
and
we
got
most
of
the
way
there.
The
intention
is
to
basically
start
testing
these
last
two
documents
at
the
hackathon
in
Montreal.
So
if
people
have
implementations
or
want
to
look
at
implementations
to
bring
along,
please
do.
C
P
D
N
I'm
Cheatham
Shankar
presenting
the
MQTT
TLS
profile
first
I
want
to
give
you
a
bit
of
a
motivation.
Why
we
submitted
this
profile
in
QT
is
an
oasis
standard.
However,
it's
wire
leads
make
security
recommendations.
It
leaves
the
authorization
solution
to
the
responsibility
of
the
implementation
and
when
we
were
searching
with
my
colleague
Anthony
for
authorization
solutions
for
MQTT,
we
basically
ended
up
in
blog
posts.
N
So
when
we
submitted
the
draft
first
draft
describing
mqtt
TLS
and
how
it
works
with
ace,
we
also
approached
one
of
the
main
authors
that
work
on
authorization,
solutions,
oath
style,
authorization,
solutions
for
mqtt
and
who
used
to
participate
in
Isis,
impute
et
Technical,
Committee
view
and
author
vehicle
through
on
the
draft,
and
that's
full
free
mental,
just
a
quick
overview
of
what
MQTT
is
it's
no
asa
standard.
It
is
a
publish/subscribe
protocol
and
it
has
a
centralized
broker
that
manages
message
exchange
from
publishers
to
subscribers.
N
N
There
are
a
few
sample
messages
here
that
is
in
the
scope
of
the
draft,
of
course,
that
every
message
of
amputees
in
the
scope
of
the
AIDS
framework,
the
first
thing
that
a
publisher
and
subscriber
client
needs
to
do
is
to
connect
to
the
broker.
After
a
connection
is
established,
the
publish
and
subscribe
messages
can
be
sent.
The
ping
requests
are
also
can
be
important.
They
are
keepalive
messages
from
clients
to
the
broker.
The
topic
subscriptions
can
be
quite
sophisticated,
including
topic
filters
with
wildcards.
This
is
important
for
ace,
especially.
N
This
means
that
a
single
topic
subscription
may
cover
multiple
resources
so
for
a
token
validation.
It's
going
to
be
important
topic
subscription
may
also
include
a
quality
of
service
which
basically
tells
the
broker
whether
you
need
a
acknowledgement
message
and
if
it's
needed
then,
is
it
a
two-way
or
a
four-way
handshake.
N
The
work
has
gone
through
several
revisions
so
far.
The
first
zero
is,
your
version
was
describing
how
ace
and
MQTT
could
work
based
on
the
MQTT
version
3.1
after
the
MPT
version
5
was
published.
We
basically
decided
to
cover
those
changes
in
the
syrup.
1
version
update
just
to
note
this
is
an
obsolete.
What
we
described
in
the
0-0
version,
it's
just
that
the
version
5
added
new
message
flows
and
better
error
handling
that
actually
helped
with
a
style
authorization.
So
it's
actually
a
positive
and
we
describe
these
extensions
in
the
version
1.
N
The
other
two
version
updates
were
based
on
the
reviews
that
we
received
after
the
version
1.
We
approached
the
voices
in
courtesy,
Technical
Committee,
and
we
were
a
an
agenda
item,
and
then
we
received
a
review
from
one
of
the
participants
who
also
published
the
review
in
the
ACE
work
group.
He
was
supportive
of
the
of
the
draft.
He
also
mentioned.
We
might
use
finger
requests
as
an
early
detection
for
token
expiration.
N
Previously
we
were
validating
the
tokens
during
connect,
of
course,
and
every
published
subscribed
message
triggered
a
token
revalidation,
but
then
ping
requests
can
also
be
used
for
early
detection
of
token
expiration.
So
we
added
that
as
a
response
to
his
review,
and
then
we
thankfully
received
a
review
from
Ludwig
and
we
tried
our
best
to
clarify,
based
on
his
review
the
token
structure
and
encoding
and
added
more
to
the
privacy
and
security
considerations.
N
I
think
the
best
way
to
describe
what
we
did
is
looking
at
the
profile
checklist,
it's
at
the
core
document
and
described
how
empty
TTLs
ace
profile
works.
The
underlying
transport
layer
security
is,
of
course,
TLS.
The
RS
is
authenticated
through
server-side
certificates.
At
the
version
3.1
we
didn't
we
weren't
able
to
support
s
discovery.
This
was
not
possible
with
the
current
messages
that
we
had
with
mqtt,
but
now
can
be
supported
with
version
5,
the
current
authentication
and
token
transport.
We
have
several
methods
described
again.
N
Why
we
described
for
version
3.1
can
also
be
used
by
version
5
implementers,
but
then
other
methods
could
made
were
made
possible
with
the
version
5
specification
for
token
introspection
and
token
request.
We
assumed
those
endpoints
could
be
HTTP,
but
there
is
nothing
stopping
them
being
co-op
or
mqtt
endpoints,
actually
again,
with
mqtt
version,
5
request
response
style
message:
flows
are
supported
better,
so
this
can
be
better
implemented,
natively
using
MQTT
all
that
info
interface.
N
N
Way
to
pass
the
token
it's
inside
the
connect
message,
the
version
3.1.
We
basically
did
what
a
lot
of
practical
implementations
in
the
wild.
There
is
no
consistency
in
the
implementations,
do
overloading
username
and
password.
Basically,
we
decided
to
put
username
as
token
and
then
the
password
could
have
the
proof
of
possession
data
to
do.
The
validation
of
the
keys
for
proof
of
possession,
however
MQTT
version
5
is
I
hinted
before
gave
us
a
better
way
of
doing
it.
N
Now
there
is
a
new
property
in
the
connect
message
that
allows
us
to
define
an
oath
method,
which
we
can
expertly
say
ace,
mqtt
TLS,
for
instance,
and
then
we
can
put
all
the
data
there,
which
could
potentially
be
empty
and
that
could
be
treated
as
an
unauthorized
request,
which
would
lead
to
a
s
discovery
or
it
can
have
token
or
token
data.
In
that
case,
the
if
it
has
the
token
class
or
the
pop
data
then
could
be
just
clarified,
as
you
would
do
in
a
username
password
basis.
E
N
E
N
N
The
final
thing
I
want
to
talk
about
is
the
error
handling
again
in
fut
version
3.1
when
I
talked
and
expired,
we
had
to
be
really
brutal.
He
just
had
to
disconnect
the
client
under
the
MQTT
layer.
This
was
because
there
was
no
proper
server
disconnect
message
from
the
broker
to
the
client
with
proper
message:
coats
error
codes-
this
was
the
other
alternative
was
silently
fighting
and
we
didn't
think
that
was
a
good
thing
to
do
so.
In
mqtt
version,
five
things
have
been
cleaned
up
much
better.
N
Now
it's
server
disconnect
as
possible,
and
you
can
send
a
error
code
not
authorized.
Also,
if
you're
supporting
calls
your
service
levels
higher
than
one
like
higher
nickel
to
the
one,
then
the
acknowledgment
messages
can
include
a
not
authorized
error
code.
However,
this
was
also
partly
supported
in
version
3.1,
but
it
was
not
consistent.
For
instance,
published
messages
did
not
have
this
subscribed
messages
had
this
and
said
right
now,
it's
more
consistent
and
we
do
have
proper
error
codes.
N
So
in
summary,
we
thought
the
eighth's
worker.
It
was
a
good
place
to
do
a
proper
description
of
how
all
to
style
authorization
can
work
with
mqtt.
The
work
at
the
moment
covers
both
drafts.
This
was
a
response
to
what
we
expected
to
happen.
We
expected
that
the
current
implementations
of
MQTT
would
support
both
versions,
which
is
the
case.
N
We
also
see,
with
the
current
version
5
a
more
natural
way
of
supporting
MQTT
a
style
authorizations
in
mqtt
compared
to
other
pub/sub
submissions
to
the
grant.
We
do
trust
the
broker
and
a
single
AAS
at
the
moment
controls
the
permissions
to
publish
subscribe
messages.
The
broker
is
a
trusted
party.
It
ends
the
TLS
connections.
However,
if
we
were
to
do
some
more
payload
protection
or
create
a
confidential
group
of
publishers
or
subscribers
I
think
there
would
be
synergies
with
the
group
come
draft.
That's
all
I
wanted
to
say
about
the
employee
details
profile.
E
Comment
and
my
personal
opinion
on
that
question
comment:
I've
been
seeing
a
lot
of
IOT
deployments
you
seeing
MQTT
so
I
think
in
the
IOT
space.
This
is
definitely
a
very
relevant
protocol
and
personally
I
very
much
support
this,
because
I
think
if
we
don't
have
a
solution
for
MK,
tts
is
much
less
relevant
in
practice
and
I
don't
want
that.
Q
This
is
Dave
Robin
speaking
for
bacnet
building
automation
protocol.
Yes,
we
definitely
support
this.
We
just
one
went
one
Wednesday.
We
refactored
our
back
net
secure
connect
to
make
it
much
easier
to
have
an
adapter
for
MQTT
as
opposed
to
our
own
hubs,
so
either
hub
or
broker
same
things.
So
the
protocol
works
on
either
one.
We
then
discuss.
What
do
we
do
about
authorization?
That's
next
right!
Now,
it's
really
mutual
TLS.
You
know
our
own
hugs
mutual
TLS
you're,
either
one
of
the
group
or
you're.
Not
that's
it.
I
N
G
B
B
E
From
the
people
that
seem
you
who
have
worked
with
ace,
especially
with
the
interrupts
of
ace-
and
they
have
been
studying
a
specific
use
case-
which
they
wanted
to
present
in
this
draft
clients
in
disadvantage
networks.
So
what
our
disadvantage
networks?
Actually
it's
like
constraint,
networks,
but
worse,
so
they
are
like
frequently
disconnected
connectivity
is
intermittent,
which
is
basically
the
same,
and
they
are
very
limited
and
the
practical
uses
they
are
looking
at.
E
So
two
of
the
things
they
have
been
considering
in
the
light
of
these
specific
extra
constraint
requirements
is
that
the
AAS
might
want
to
revoke
tokens
for
known
compromised
resource
servers
and
the
climb
want
to
check
that
their
tokens
are
still
valid
before
they
interact
with
resource
server.
So
that
reflects
a
bit
the
discussion
we
had
on
on
validity
of
the
resource,
server
authentication
keys
for
the
framework.
E
Only
here
it's
worse
because
you
expect
your
resource
servers
to
be
captured
or
impersonated,
so
they
were
looking
at
different
ways
of
helping
the
client
to
not
use
tokens
that
belong
to
a
compromised,
RS.
One
way,
the
usual
way
you
you
would
like
spontaneously
solve
this
is
to
give
the
show
the
tokens
are
very
short
lifetime.
And
then,
if
you
know
that
there
is
a
compromised
RS,
you
just
stop
issuing
new
tokens
for
it.
E
Problems
with
that
is
that
you're
going
to
be
creating
a
lot
of
tokens
and
wasting
the
very
limited
and
intermittent
bandwidth
that
you
have
and
that
you're
good
tokens,
or
rather
the
tokens
for
good
RSS,
might
not
be
valid
long
enough
to
do
what
you
actually
intend
to
do,
because
you
have
like
an
intermittent
window
of
connectivity
to
your
ASU,
fetch
it
open
and
by
the
time
you
need
to
contact
the
ers.
The
token
might
already
be
expired,
so
it's
a
bit
tricky
to
handle
the
lifetime
because
you
have
conflicting
requirements,
so
they
looked
at.
E
E
There
are
several
problems
with
that,
for
example,
if
you
allow
fully
introspection,
then
attackers
could
just
introspect
tokens
that
they
captured
on
the
radio
to
learn
what
they
contain
as
claims
this
means
you
need
to
differentiate
between
clients,
doing
introspections
on
tokens
and
resource
servers,
because
the
resource
servers
need
to
learn
the
claims.
That's
the
whole
point
for
them
of
doing
introspection.
The
clients
actually
don't
need
to
know
that
they
just
need
to
know
the
active
parameter
for
their
token
and
if
you
then
can
differentiate.
This
is
a
client
doing
introspection.
E
The
other
problem
is
if
you're,
using
CW,
T's
or
gwt's
that
are
encrypted,
which
you
typically
would
want
to
do
in
such
an
environment,
because
you
need
a
self-contained
token
and
you
need
an
token
that
an
attacker
cannot
see
the
content
off.
Then
the
AES
needs
to
decrypt
the
token
when
it
gets
an
introspection
request.
E
On
that
token,
so
usually
the
way
you
can
do
that
if
it's
a
resource
server,
is
you
know
which
is
the
resource
server,
so
you
know
you
can
like
map
that
token,
but
if
it's
a
client,
typically
the
a
s
would
not
know.
What
kind
of
token
is
this:
how
can
I
see
which
token
disease
and
decrypt
it
to
find
out
how
it
matches
to
the
tokens
I
issued?
E
Oh
this
and
I'm
being
asked
to
introspect
I
mean
you
could
iterate
through
all
the
tokens
that
the
a
s
has
issued
and
just
search
until
you
find
the
wrong
one
that
matches,
but
we
were
expecting
that
this
might
be
a
lot
of
tokens
and
you'd
rather
not
want
to
do
this,
especially
if
the
cost
is
only
adding
a
key
identifier
in
the
header
of
the
token.
So
this
is
the
problems
they
have
looked
at.
D
Gym
shot
individual
I
found
the
document
interesting,
but
I'm
worried
that
it
really
wasn't
exploring
the
entire
problem,
because
it
didn't,
for
example,
talked
about
revoking
clients.
I
mean
it
was
not
clear
how
a
resource
server
could
do
this
opportunistic
checking,
given
that
it
is
only
intermittently
seeing
the
AF
sin,
they
probably
didn't
see
the
client
token
until
after
it
saw
the
AF.
D
E
O
Custom
over
there
is
our
group
that
works
with
this
kind
of
networks,
the
DTN
working
group-
oh,
so
maybe
it
would
be
worth
getting
some
DTM
people
involved.
Did
he
end
started
out
as
a
research
group
attaching
colors
to
zebras,
and
then
things
like
that,
so
they
know
her
about
network
problems
and
I
can
imagine
that
they
would
be
interested
in
getting
its
bits
and
pieces
they
that
they
can
use
for
authorization
in
these
networks.
Good.
B
D
B
L
A
L
So
that's
the
EST
coop
s
draft
which
is
now
done,
and
then
there
was
another
proposal
which
was
looking
at
protecting
EST
payloads
on
application
layer.
That's
the
istic
Oscar
draft.
So
that's
that's
the
one
I'm
talking
about
here
and
the
questions
was
asked
for
the
working
group
for
the
two
solutions
which
one
should
be
work
on
and
the
answer
was
do
both
but
start
with
est
corpus.
D
L
Start
with
est
corpus,
the
DTLS
version-
and
so
that's
done
now-
and
we
intend
to
restart
the
work
on
est
our
score
so
reminder
of
what
what
how
it
works.
It's
basically
addressing
the
problem
or
for
the
same
reason,
as
is
the
coop,
as
is
a
good
idea
that
you
already
have
implemented
a
security
protocol.
In
this
case
a
transport
layer,
security
call,
and
you
want
to
reuse
that
for
protecting
enrollment.
That's
the
same
rationale
here,
assume
that
you
have
devices
who
are
implemented
or
score
and
a
key
exchange
protocol
which
we
have.
L
We
use
the
name
ad
hoc
as
a
placeholder,
and
then
how
would
you
reuse
that
you
don't
want
to
have
multiple
communication
security
protocols,
you'd
like
to
reuse
that
communication
security
protocols
is
communication
security
protocol
for
protecting
the
enrollment?
So
that's
basically
the
problem
statement
and
it
turns
out
it's
very
much
of
the
est
corpus
translates
directly.
So
that's
simple.
It's
not
like
a
completely
new
enrollment
protocol
is
basically
reducing
what
what
already
exists
but
protecting
it
on
application
layer
rather
than
on
transport
layer.
But
there
are
some
slight
differences.
So,
for
example,.
L
The
EST
over
with
all
score,
you
could
use
end-to-end
rest,
so
you
could
dissuade
change
between
co-op
and
HTTP.
So
a
client
could
start
with
co-op
and
the
enrollment
request
could
pass
the
nation
for
up
to
HTTP
proxy
and
end
up
in
the
registration
authority,
and
you
can
have
end-to-end
security
networks
over
UDP
or.
R
L
D
TLS
or
TLS,
or
or
other
transport,
but
minor
differences,
but
basically
we
would
like
to
have
an
enrollment
protocol
for
these
devices,
which
only
implement
or
score,
and
the
next
steps
well
is
to
flesh
out
these
details.
Now,
ESD
capacitor
has
developed
a
lot
and
matured
so
we'd
like
to
take
over
those
details.
G
Pitifulness
talk
one
of
the
FT
Corp
as
co-op
s,
authors,
yeah
I,
don't
read
that
now
having
virtual
sauce
core,
there
is
not
too
much
work
to
support
them
to
the
other
children
agreed.
You
will
need
ad
hoc
or
something
similar
to
get
the
whole
thing
working
or
you're
also
worried
about
that
I.
Don't
well!
For
my
experience
with
my
background.
G
O
O
Well
know
when
you
look
at
STS,
they
have
defined
names
to
get
things
in
certain
formats,
so
they
I
mean
it's
not
like
the
project
hold
changes,
but
there
are
some
details
that
actually
cater
with
the
fact
that
we
have
different
formats
for
different
things.
So
maybe
it's
just
worth
looking
at
this.
L
L
Yes,
we
need
to
look
at
Ed
hook
also,
it
could
actually
make
sense
without
ad
hoc
here
in
in
a
setting
where
you
do
implement
multiple
communication
security
protocols,
but
before
that
thing
would
be
that
you
have
a
key
exchange
protocol
in
place
and
that
that
would
be
ad
hoc
or
what
it
will
be
called
now
and
when
we
hopefully
get
this
new
working
group,
Ronnie
and
I
will
already
have
one
other
suggestion
here
from
from
Carsten.
Is
there
any
other
other
suggestion
you'd
like
to
add
to
this
work?
D
The
big
one
is
Edie,
Hawk
has
been
in
this
group
presented
here
several
times
and
he
went
through
a
set
dispatch
process
and
a
summary
message
from
the
current
ADEs
was
posted
on
sec
dispatch
yesterday
for
those
people
who
would
like
to
see
ad
hoc
done
or
for
those
people
who
really
don't
want
to
see
it
Hart
done,
if
you
can
get
on
to
the
sector
specialist
and
express
support
or
whatever
that
would
be
appreciated.
The
current
plan
forward
can
I
say
about
that
or
cannot
say
about
that.
O
S
D
R
O
Would
need
this
would
be
happy
with
the
working
repeating
farm
to
work
on
this
I
asked
the
same
question
in
the
call,
a
working
group
and-
and
we
had
consensus
that
this
was
a
good
thing
to
do
so.
I
just
would
like
to
hear
from
a
slightly
different
constituency
whether
that's
also
the
case
I
would
ask
the
chairs
to
maybe
consider
asking
that
question
because
I
want
us.
This
fresh.
I
Customer
key,
but
you
asked
us
whether
their
core
group
was
happy
with
not
doing
that
in
core,
which
was
a
different
question
and
I
heard
that
question
and
I'm
fine
with
not
doing
that
in
core,
but
talking
about
the
more
substantive
and
so
I
when
we
had
the
presentation,
a
virtual
intermitting,
the
conference
called
there
were
requirements
being
presented
and
I
tried
to
sort
of
in
a
follow-up.
Melinda's
discussion
get
a
better
sense
of
what
the
size
requirements.
I
We're
and
I
got
some
good
feedback
on
six
dish,
but
I
didn't
I,
didn't
hear
any
any
other
things
on
on
some
of
the
other
radio
technologies
in
terms
of
empty
you
size,
so
I
think
that
would
be
useful
together
and
also
there
was.
There
was
the
question
about
the
power
consumption
model
that
was
presented
for
the
MBI
OD
and
it
seemed
to
refer
to
it
wasn't
clear
whether
that
was
assimilation.
It
wasn't
clear
what
a
data
came
from.
So
that's
also
someone
at
the
conference.
I
R
Hive
room
engineer:
one
of
the
complexities
we
had
in
producing
that
summary
for
kind
of
ad
hoc
is
that
we
had
the
discussion
in
so
many
different
places.
So
if
we
want
to
bring
comments
to
what
was
there,
we
would
beg
you
to
take
it
to
this
sec
dispatch,
mailing
list
and
kind
of
talk
about
there.
I
mean
it's
great,
that
there's
customers
from
different
working
groups
getting
endorsements
and
getting
that
feedback
is
very
helpful.
But
ultimately,
please
gonna
bring
that
back
to
the
discussion
that
we
are
having
on
safe
dispatch.
L
So
your
acid
on
them,
so
I
I,
think
I've
addressed
all
those
questions
in
the
secretary
list.
Could
you
please
go
back
and
check
and
see
because
both
the
Laura
one
and
two
sizes
were
discussed
and
they
are
also
presented
in
the
in
the
slides?
As
for
narrow
band
IOT
power,
consumption
is
also
extensively
described
that
it's
not
a
critical
there.
Since
there
is
a
fragmentation
scheme
built
into
narrowband
IOT,
there
are
no
critical
and
view
sizes.
It's
basically
handled
that
was
stated
multiple
times.
R
I'll
summarize
what
Roman,
Denis
I'll
summarize
what
I
said
before
we
believe
that
the
consensus
opinion
in
half
of
all
the
bits
are
in
air
right
up
if
we
are
incomplete
and
we
think
we
need
to
kind
of
flesh
that
out
whether
it's
with
kind
of
additional
details
or
or
otherwise.
It
would
be
again
very
helpful
to
us
if
we
poke
at
the
specific
things
we
said
on
sick
dispatch,.
T
G
D
D
It
seems
to
me
that
it
may
be
something
that
this
group
wants
to
explore
deeper
at
some
point,
because
it
provides
an
analogous
behavior
to
the
PS
K,
where
you
can
send
the
token
as
the
identifier.
So
you
can
just
send
the
token
as
the
certificate
directly
without
having
to
post
it
to
the
authorization
point.
D
The
core
and
seaboard
working
groups
have
been
holding
alternating
weekly
interim
meetings.
The
intention
is
for
us
to
get
together
and
set
up
a
schedule,
hopefully
to
go
at
least
through
Singapore,
and
one
of
the
things
that
we
are
looking
at
doing
with,
that
is
to
offering
offering
occasionally
some
of
those
slots
to
other
working
groups
so
that
they
are.
D
We
have
a
very
predictable
time
that
a
lot
of
people
can
get
on
to
it,
so
we
will
be
sitting
a
beautiful
and
we
will
be
including
this
mailing
list
on
that
beautiful
all,
and
we
would
like
you
to
give
us
feedback,
so
we
can
help
in
terms
of
deciding
a
consistent
time
and
being
get
the
most
people
on
the
right
set
of
people.
If
we
do
have
an
ace
interim,
it
will
not
necessarily
be
at
that
time,
but
it
will
be
one
of
the
options.