►
From YouTube: IETF99-ACE-20170717-0930
Description
ACE meeting session at IETF99
2017/07/17 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
A
Okay,
so
reality
check
milestones.
Two
things
are
obvious.
First
of
all,
the
years
wrong,
we
are
little
little
slow,
unfortunately,
so
there
we
have
currently
to
my
son's
on
the
on
the
chanter
page,
which
refer
to
the
act
on
the
framework
document
and
also
to
what
was
previously
called
actors
document
and
there's
two
authorization
for
a
stockman,
and
we
are
somewhat
behind
on
those.
A
We
have
one
item
later
on
the
agenda
that
talks
about
an
open
issue
that
surfaced
between
Chicago
and
this
idea
of
meeting
on
the
on
the
definition
of
where
the
definition
of
the
proof,
possession
CWD
should
go
and
Mike
is
going
to
speak
about
this
issue
first,
but
besides
that
we
are
slow
under
currently
chart
that
items.
Unfortunately,
that
didn't,
however,
prevent
anyone
else
from
making
lots
of
other
contributions.
A
We
have,
as
you
can
see,
mq
d
d,
ipsec
coop
specific
stuff.
Later
we
talk
about
some
different
credentials
and
also
about
different
ways
to
obtain
keys.
Besides,
what
we
haven't
in
the
hours
for
the
proof,
possession
like
here
is
the
so
lots
of
stuff,
let's
jump
straight
into
it,
Mike
any
other
agenda,
bashing
questions.
B
B
B
That
adds
a
confirmation
claim
and
members
of
it,
the
most
important
being
one
to
represent
a
key
and
that's
an
elliptic
curve
key.
That
is
in
this
confirmation
claim
again,
that's
Jason,
but
just
like
for
JSON
web
tokens.
Now
that
we're
very
close
to
having
a
Seaboard
web
token
done.
We
also
have
need
both
in
ace
and
in
other
places,
do
you
have
a
representation
of
proof
of
possession
keys
next.
B
Now,
there's
really
a
administrative
point
that
I'm
here
to
talk
about
and
seek
input
from
the
working
group.
It
turns
out
that
I
had
done
an
independent,
just
port
of
RFC
7800.
That
does
nothing
else
at
the
same
time
living
and
others
I
guess
before
me,
but
I
wasn't
as
aware
of
it
did
almost
exactly
the
same
thing
and
put
it
in
ace,
o
auth
authorization
draft.
Why?
Because
it
needed
it
next.
B
So
the
question
I
was
asking
once
we
had
this
conversation
about
well
now
we
have
two
versions
of
this
is
why
would
we
want
this
to
be
in
its
own
draft,
rather
than
just
be
part
of
the
a
co-author
framework
and
there's
a
number
of
fairly
simple
reasons?
One
of
them
is
just
like
the
Seaboard
web
token
itself.
B
It
invents
essentially
nothing
it's
just
a
syntax
transformation,
and
so
should
the
working
group
decide
to
adopt
the
draft
I
believe
that
we
could
get
this
to
be
a
completed
RFC
within
this
year,
based
on
what
I've
seen
before,
in
particular
we're
not
asking
the
idea
for
the
ie
SG
to
review
inventions,
we're
just
asking
them
at
that
point
to
review
syntax,
whereas
I
think
that
the
a
co-op
draft
is
probably
not
on
that
aggressive
of
schedule
and
so
well,
a
so
I
would
need
this
I
think
we
can
get
this
done
and
over
with
very
quickly,
I,
always
believe
in
giving
credit
where
credit
is
due,
and
so
one
of
the
things
I
did
once
we
realized
that
this
was
in
two
places
in
consultation,
honest
and
the
authors
of
the
ACE
Oh
auth
draft
I
said:
look,
let's
just
make
everybody
that
was
an
author
of
a
CEO
of
an
author
of
this
individual
draft
as
well
to
recognize
the
inputs
that
they
may
have
had
towards
creating
the
confirmation
claim
and
proof
of
possession
representation
inside
that
a
still
alive
drafting
next,
you
just
went
backwards,
hums,
maybe
that's
good,
so
laughs
slide
I'm
here
now
to
ask
questions
of
the
working
group
and
the
chairs,
which
is
a
should
we
adopt
this
short
draft
which,
just
as
the
proof
of
possession
claims,
so
that
ace
and
other
use
cases
will
have
this
soon
and
assuming
that
the
answer
to
that
question
is
yes,
there's
a
question
which
I
guess
procedurally
is
to
the
chairs,
which
is
given
the
well
an
early
draft.
B
C
No
excellent,
there
was
a
question
before
this
question,
so
I'm
go
ahead
because
you
were
asking
about
proof
of
possession.
Does
anyone
has
use
cases,
and
so
my
I
haven't
read
the
draft
and
actually
so
what
session?
What
does
that
mean?
Is
it
just
about
this
sign
private
key,
so
I
can
prove
that
you
have
a
secret
key
or.
B
Is
it
it
sometimes
also
called
the
holder
of
key
property
or
proof
of
possession,
and
one
of
the
things
that
conics
told
me
is
that
ASA
decided
to
use
proof
of
possession
in
all
of
its
work,
and
so
there
is
a
natural
reason
that
this
gets
developed
here,
whether
it's
in
an
individual
draft
or
or
you
know
not
just
an
individual
job,
but
a
draft
tailored
to
that
purpose
or
whether
we
leave
it
in
a
so
auth.
In
which
case
everybody
that
would
want
to
use.
B
C
I
can
I
forgot
to
tell
mine
and
I'm
Hank
so
and
yes,
so
use
case
wise
out
of
the
scope
of
all
off
I
would
have
a
ton
obvious
cases
if
the
term
possession
is
extended
to
basically
any
system
entity
property.
So
if
you
want
to
prove
that
you
have
a
specific
property
to
an
external
party,
there
could
be
I.
Have
a
wonderful
trusted
clock
I
can
give
you
a
specific
time
stamps
and
a
lot
of
metadata
about
it.
C
There
could
be
a
vulture
of
Health,
a
system,
integrity
properties
that
I
can
prove
with
evidence,
may
be
based
on
a
hardwood
on
trust
or
a
trusted
in
execution,
environment,
or
even
something
that
is
close
to
identifying
a
group
of
entities.
So
I
would
have
a
lot
of
use
cases
for
proof
of
something
and
if
a
session
would
be
defined
as
a
system
and
system
entity
characteristic
like
from
49
49,
that
would
be
good.
D
A
C
A
A
Okay,
I
think
so
my
I
don't
know
you
can
link,
but
that
was
pretty
clear,
yeah
so
and
of
course,
I
will
talk
to
the
idea
about
creating
around
a
milestone
in
the
Charter,
which
is
it
is
the
same
content,
but
still
it's
a
separate
document,
so
we
have
to
I.
B
C
Question
yeah
just
just
one
thing
so
as
your
draft
would
have
really
faciliate
sub
drafts.
That
would
be
saw
defined,
specific
semantic
context,
because
the
biggest
how
about
the
tokens
is
that
how
do?
How
would
you
expect
what
claims
to
find
in
it
and
and
and
this
is
with
and
then
using
maps?
And
some
people
are
like
this.
B
All
right,
this
should
also
be
mercifully
short
I'm,
just
giving
status
update
on
Seabourn
web
check
next.
So
we
completed
working
group
last
call.
There
was
great
feedback
from
among
others,
some
in
the
front
rows
here,
Jim
Kirsten
with
a
good,
and
you
could
see
the
history
for
the
exact
changes
made.
B
They
were
all
pretty
much
clarification
type
of
changes
such
as
whether
there
should
be
seaport
tags
on
specific
fields
or
whether
to
there's
only
one
of
an
issue
with
the
draft
which
isn't
I
think
blocking
it
going
for
publication
and
ITF
last
call,
but
I
want
more
implementers
to
vet.
The
examples
Jim
had
taken
a
stab
pointed
out.
Some
problems,
samuel,
updated
them
and
we
haven't
received
independent
confirmation,
but
the
examples
are
all
correct.
End
Perceval
at
this
time.
One
thing
Jim
he
did
do,
I,
don't
know.
B
B
B
A
Hopefully
we
get
this
done
this
week,
but
the
document
has
been
out
there
for
a
little
while
already
so
it's
a
in
terms
of
scope.
The
CWD
is
a
it's
a
fairly
sort
of
trivial
effort
in
some
sense,
because
we
are
just
mapping
their
already
existing
CWT
over
here
to
this
to
the
seaboard
based
encoding
right,
the
other
way
round
yeah.
So
if
you
get
that
done
and
we
can
push
it
forward
to
Kathleen
get
this
at
least
this
document
wrapped
up.
A
So
I
know
that
that
we
are
you're
going
to
work
with
Chi,
Minh
and
Samuel
on
the
examples
submit
a
new
version,
maybe
during
this
week,
and
then
we
can,
we
can
push
it
forward
because
otherwise
the
document
has
gotten
good
reviews.
So
I
don't
think
that
there's
more
from
the
body
of
the
document,
but
having
the
examples
is
obviously
obviously
very
useful.
I
have
to
check.
Maybe
it's
either
me
or
cutting.
E
F
Okay,
I
can
start
just
I
can
start
talking,
yeah
I'm
a
bit
bound
pictures
I'd
like
to
see
but
anyway,
so
because
we
talk
about
the
a
spring
work,
this
would
probably
also
be
a
short
presentation,
I'm
going
to
tell
you
about
the
status
and
but
first
I'd
like
to
give
you
background,
just
to
remind
you
what
what
we
are
doing.
Please.
F
So
Hannes
showed
us
the
milestones
and
the
Charter
for
Ace
this.
This
group
is
asked
to
provide
a
solution
for
authorization
in
in
IOT
and
this
so
the
solution
that
is
working.
This
working
group
is
working
on
it's
based
on
a
framework
and
profiles,
and
this
framework
is
essentially
looking
at
the
problem
that
you
have
a
a
server
hosting
resources.
F
This
is
the
essentially
the
content
of
a
sip
or
web
talk.
The
authorization
server
also
provides
credentials,
for
example,
keys
to
the
client
and
to
the
research
server
so
that
they
could
authenticate
each
other
and
therefore
basic
building
blocks.
In
this
framework,
the
protocol
is
is
based
on
OS
2.0.
The
encoding
is
based
on
Seaborg.
F
The
secure
envelope
of
messages
is
based
on
cozy,
for
example,
the
credentials
are
wrapped
the
cozy,
the
authorization
information
is
wrapped
in
cozier,
cheaper
web
token
and
the
be
the
main
candidate
for
for
doing
the
request
and
response
is
cooperative.
These
are
the
four
basic
building
blocks.
However,
the
framework
does
not
specify
exactly
what
goes
on
between
the
client
and
the
resource
server,
and
that
is
what
is
specified
in
the
profile.
F
So
for
the
next
scientist
and
the
reason
why
the
framework
doesn't
specify
the
client
and
server
interaction
is
to
allow
for
a
variety
of
different
IOT
deployments.
So
we
know
that
there
are
many
different
protocols
use
between
constrained
devices
and
this
framework
should
be
able
to
fit
with
with
many
different
deployments.
F
So
for
this
purpose,
you
can
define
the
profile
of
the
framework
and
in
the
Appendix
C
of
the
framework
you
see.
What
the
profile
needs
to
contain
here
are
the
six
drafts
I
think
I
got
them
all
which
are
submitted
so
far,
which
are
profiles
of
the
framework
and
they
some
of
them
describe
access
to
any
type
of
resource.
F
That's
one
two
and
five
today
these
profile
need
to
describe
what
is
the
protocol
between
the
client
and
the
resource
server,
and
also
what
is
the
security
proper
coordination,
because
there
are
different
mechanisms
to
pass
the
access
token,
the
authorization
information
depending
on
which
protocol
you
use.
Some
of
these
profiles
are
very
specific
address.
Very
specific
resources
like
in
four
in
in
this
case
the
resource
is
a
topic
or
a
publish/subscribe
scenario,
so
the
axe,
the
access
control
is,
is
whether
you
have
the
right
to
publish
or
subscribe
to
a
particular
topic.
F
So
this
set
of
profiles
is
assigned
to
check
that
this
framework
actually
is
deployable
in
many
different
settings,
and
the
progress
of
this
profile
is
very
important
for
the
framework
because
it
defines
what
is
being
implemented
between
the
client
and
the
server
and
I.
Come
back
to
that
later.
I
just
like
to
point
out
in
that
item,
six
five
and
six
are
new
profiles
submitted
this
meeting
and
I
to
number
six
is
related
to
another
disk
drive,
which
has
been
discussed
very
much
on
the
mailing
list.
F
It's
this
low
latency
group
communication,
which
has
been
so
if
you're
interested
in
one
of
the
drives
you
may
be
interested
in
the
other.
They
something
and
the
status
so
far
is
that
we
have
included
all
the
major
review
comments
we
had
so
far.
There
are
no
major
changes
in
this
latest
update,
but
we
have
some
plans
for
next
steps.
F
So
what
the
next
steps
are
we
plan
to
import
some
things
from
profiles?
This
is
also
another
good
reason
why
we
have
profiles.
Some
of
the
features
described
in
the
pro
profiles
are
so
well
thought
through
that
we
think
they
need
to
be
used
in
any
profiles
secretly
promote
those
features
to
the
the
framework
and
bullet.
To
is
one
example
here
with
discovery
process
which
is
described
in
the
coop
TTLs
profile
and
originally
comes
from
the
decaf
solution
to
the
ACE
problem.
Is
it's
actually
something
that
we
want
to
use
in?
F
The
framework
bullet
number
four
here
is
about
time
synchronization,
where
which
is
an
open
issue.
The
problem
is:
if
you're
gonna
do
access
control
on
a
resource
server
and
the
access
control,
condition.
The
permission
is
dependent
on
a
time,
and
then
you
need
to
know
that
you
have
synchronized
time
in
in
the
resource.
D
F
F
Jim
has
made
some
recent
review,
which
we
haven't
killed
it
yet
thank
you
Jim,
but
also
next
steps
and
the
implementation
needs
to
progress.
We
have
I,
know
two
implementations
and
there's
the
rumor
of
a
third,
and
there
is
an
interrupt
test
plan
and
these
will
be
on
specific
profiles,
as
I
mentioned.
That's
how
we
actually
test
the
framework
and
the
first
profile
to
be
tested
is
the
DTLS
profile
and
the
second
would
be
the
OS
co-op.
F
G
The
customer
and
the
comment
I
would
check
to
make
is
just
general
comment
on
how
we
work
with
this
framework
document,
because
in
the
end
we
want
to
have
protocols
that
actually
have
certain
security
properties
and
looking
at
things
closely,
usually
is
really
hard
to
confirm
many
security
properties
of
the
framework,
because
it's
just
very
entangled
with
the
way
the
framework
is
being
used
in
a
profile.
So,
in
the
end,
it's
the
profile
where
we
can
actually
show
security
properties,
and
this
means
we
actually
have
to
be
very
careful
about
the
the
framework.
G
The
each
profile
has
certain
expectations
or
requirements
on
the
framework
that
are,
that
need
to
continue
to
be
fulfilled
for
getting
the
security
properties
of
the
profile
and
I'm
not
entirely
sure
we.
We
are
documenting
these
relationships
as
well
as
as
we
could
be,
and
maybe
we
can
put
special
attention
on
the
fact
that
the
profile
doesn't
work
if
the
framework
doesn't
expose
a
specific
requirement.
So
this
is
not
really
a
comment
on
your
document.
G
F
It's
good
good
comment,
so
certain
security
features
are
provided
by
the
framework
like
likely
like
the
security
of
the
authorization
information,
how
security
authorization
information
is
secured
end
to
end
from
the
authorization
server
to
the
resource
server,
how
the
credentials
are
protected.
Those
are
things
that
could
be
included
in
training
work
but,
as
you
say,
the
security
considerations
of
the
profile
should
define
exactly
what
the
security
is
provided
of.
Security's
considerations
need
to
be
made
for
using
this
profile.
G
Yeah
the
point
that
I
was
trying
to
make
is
that
the
framework
actually
cannot
provide
security
because
everything
it
actually
talks
about
these
things
that
are
only
reified
in
the
profile.
So
you
are
saying
it
provides
security
for
the
credentials,
but
the
credentials
may
not
mean
anything
without
the
profiles.
So
it's
really
hard
to
actually
provide
firm
properties
of
the
framework.
It
may
succeed
in
some
cases,
but
really
normally
the
the
actual
security
properties
you're
interested
in
come
from
the
let's.
F
Say
the
Seaboard
web
token,
which
is
passed
from
the
authorization
server
to
the
resource
server,
but
that's
not
something
that
the
profile
needs
to
I
mean
that's
something
the
profile
can
rely
on,
but
there
is
a
mechanism
for
securely
transporting
authorization
information
why
the
slice?
Why
can't
that
be
accounted
for
by
the
program.
H
Okay,
I
think
continue
from
Carson's
question.
I
think
I
have
the
same
confusion
about
the
framework
document
and
the
other,
so
many
profile
document
I'm,
sorry
I'm
French
from
Hawaii
I'm,
the
new
in
the
working
group.
H
So
my
confusion
is:
could
you
go
back
to
you
paid
you
for
I
have
seen
that
this
cager
has
a
good
summary,
also
current
profile
for
the
SE,
if
in
Canada
I
use,
which
protocol
security
protocol
to
transport,
the
authorization
information-
and
you
have
done
some
category
of
which
kind
of
profile
have
some
category
stick
and
what
they
are
useful.
But
I
don't
see
any
more
more
concrete
or
more
detailed
summary
of
why
we
should
define
so
many
profile
for
the
AC
architecture
and
what
is
their
most
suitable
scenario
from
the
user
perspective.
A
That's
an
excellent
question,
so
we
had
in
the
in
the
beginning.
We
said
that
okay,
you
can
use
different
protocols
already
back
in
the
during
the
agenda
discussion
we
said,
or
the
Charter
discussion
of
the
working
could
be
said,
that
we
would
not
only
just
focus
on
coop,
but
would
also
provide
the
possibility
to
use
other
protocols
and
mechanisms
and
it
turned
out.
A
We
had
fairly
long
debate
on
different
types
of
credentials
and
different
sort
of
communication
patterns,
and
that's
I
I
think
the
discussion
back
then,
is
it's
now
reflected
in
a
variety
of
different
profiles.
What
we
still
have
to
decide
is
which
ones
have
a
higher
priority
now,
after
a
few
years
into
the
work
on
what
actually
want
to
use,
as
we
don't
I,
don't
think
necessarily
expectation
is
that
we
standardize
everything
that
comes
to
our
mind,
but
rather
to
to
make
some.
H
But
but
from
my
from
my
thought,
I
think
as
a
working
group.
If
we
propose
so
many
in
profile
and
the
way
if
we
can
give
some
helpful
guidance
and
the
solution
and
just
summaries
of
what
they
are
most
suitable
scenario
and
something
I
think
it's
helpful
for
the
industry,
so
I
hope
so
yeah
but
I
think
it's
not
easy.
F
So
I
think
that
each
I
mean
these.
These
are
proposals
is
six
one
of
these
craft
is
adopted.
That's
the
first
one
and
the
others
are
proposals,
and
it's
up
to
the
working
group
to
decide
which
which
of
these
we
should
adopt
and
work
with
so
and
each
profile
should
motivate
its
existence,
basically
to
describe
what
other
relevant
use
cases
where,
where
you
need
to
apply
this
profile,
but
I
was
arguing.
F
Is
that
it's
good
that
we
have
multiple
profiles
for
the
framework,
because
it's
a
sanity
check
and
eventually
the
implementations
of
the
profiles
will
determine
interoperability
so
that
that's
why
we
need
to
have
more
than
one
profile,
but
exactly
which
profiles
we
use
is
up
to
the
working
group
to
decide.
I
think.
G
Another
way
to
say
what
Frank
said
is
this
working
group
is
no
big
enough
to
actually
have
a
load
map
document
that
we
are
maintaining.
So
maybe
we
should
just
start
having
one
so
I
mean
the
decision
graph
which
of
these
profiles
use
this
pretty
easy.
If
you
know
what
for
fascist,
but
it,
it's
really
good
thing
to
have
a
document.
You
can
show
it's
on
page.
Seven
of
that
object.
I
Kathleen
Marie
already
ad,
so
I
do
like
Frank's
suggestion,
but
I
got
up
originally
before
the
document
suggestions.
You
could
just
use
the
working
group
wiki
to
start
hashing
this
out
and
it
may
result
in
a
document
later,
but
I
think
knowing
which
profile
is
best
suited
for
which
applications
would
be
helpful
to
industry
and
then
figuring
out
later
how
we
present
that
is
it
a
draft.
Is
it
in
some
other
form
would
be
fine,
but
I
do
think
that
would
be
helpful
information
and
and
then
tying
back
to
security
properties
of
each
right.
J
F
There
is,
there
are
two
proposals:
one
is
the
draft
was
reference
reference
8
and
the
other
is
in
the
property,
TLS
profile
and
basically
time
sync
is
handled
with
the
authorization
server
as
the
trusted
time.
I.
Never
do
the
implementations
already
have
this
I.
Suppose
I,
don't
know
if
the
court
yeah
it's
it's
mentioned
in
the
coop
DTLS
profile.
I,
don't
know
those
who
implemented
the
coop
DTLS
profile
have
implemented
the
nonce
functionality
in
there.
F
J
Worry
is
that
if
these
are
separate
proposals
in
separate
documents,
then,
like
the
the
framework
document,
is
insecure.
Now
you
have
to
rely
on
these
other
pieces,
not
just
the
profiles,
but
also
on
these
other
documents.
So
if
I'm
going
to
implement
I,
just
not
read
one
profile,
I
have
to
read
like
five
other
documents
right
so
that.
F
That's
a
good
concern.
That's
that's
one
reason
why
we
move
things
from
from
profiles
through
the
framework,
so
you
you
don't
have
to
read
all
these
other
profiles.
If
you
actually,
you
should
have
the
framework
should
be
self-contained
in
what
you
need
and
on
a
general
level.
But
then
you
need
to
specify
exactly
what
you
want
for
this
paper,
but
anyway
there
is.
There
is
ideas
around
time.
Synchronization
I
think
we
just
need
to
decide
which
idea
to
go
for.
B
Mike
Jones
Microsoft-
and
this
is
really
coming
back
to
the
discussion
on
which
profiles
we
would
want
to
standardize.
I
know
that
the
working
group
created
a
use
cases
document
which
is
now
informational,
RFC,
77,
44
and
I'm
wondering
does
that
inform
sort
of
the
choices
of
which
profiles
we
need
to
produce
because
there's
demonstrated
need
for
them.
I.
G
Really
about
use
cases
the
custom
over
again,
so
it's
not
really
going
into
details
about
specific
protocols
and
you
usually
meet
the
profiles
because
the
you
need
to
bind
the
framework
to
properties
of
those
protocols.
So
it
would
be
a
really
strange
of
the
use
case
document
would
have
you
annachi,
it
doesn't
so
again,
I
think
we
should
do
this
roadmap
work
and
we
also
should
make
sure
that
each
of
the
four
five
documents
I
think
some
of
them
already
do
clearly
explain
what
what
the
scope
and.
I
Kathleen
rarity
ad,
so
just
one
more
suggestion,
as
opposed
to
a
roadmap,
maybe
an
overview
document.
They
seem
to
be
viewed
a
lot
more
positively
as
they
get
through
the
iesg,
so
rtcp
web
just
put
one
through,
and
that
was
viewed
really
positively.
So
it
might
be
nice
to
start
from
an
example
that
people
really
liked.
K
So
the
new
thing
is
that
it
is
now
working
group
document.
It's
already
an
easier
one
state,
because
I've
received
a
review
from
agent
Roger
that
very
detailed
review.
I
just
copied
the
editorial
changes
right
into
the
document.
And
but
there
are
still
many
clarifications
needed
to
be
made
in
the
text
and,
as
you
already
heard,
some
parts
should
be
moved
into
the
framework
document
because
they
are
more.
K
K
So
there's
a
bunch
of
open
issues
and
I
have
created
those
in
the
issue
tracker.
The
document
still
lives
that
it
happened
on
my
personal
account.
The
if
you
want
to
follow
up
on
that,
you
could
also
click
on
the
issue
numbers
they
are
in
the
titles
here,
so
I've
linked
them
to
the
parity
to
the
issue
tracker,
so
I'm
kind
of
briefly
go
through
these
through
the
important
issues
that
I
think
that
the
working
group
has
to
decide
on
at
some
point
of
time.
K
So
its
first
one
is
that
you
have
the
mechanism
from
a
framework
where
you,
basically
as
the
client,
get
a
nexus
token
from
the
authorization
server
and
then
send
it
post
to
some
resource
on
the
resource
server
to
drop
that
access
token
there.
So
the
resource
over
server
knows
about
that
when
you're,
actually
creating
the
GLSL
yeah
mechanism
that
you
could
use
to
transfer
the
access
token
that
has
originally
been
proposed
in
the
decaf
document
and
now
is
in
the
details.
Profile
as
well
is
some
sort
of
shortcut
for
you.
K
Just
save
this
round
trip
for
the
additional
post
requests
and
getting
the
response
back
and
instead
transfer
the
access
token
in
the
PSK
identity
field
during
the
DTLS
engine.
So
the
problem
that
Jim
pointed
out
is
that
the
client
doesn't
know
in
advance
which
methods
are
supported
by
the
researcher.
So
the
es
framework
has
the
first
mechanism,
which
is
posting
through
the
off
info
and
on,
and
this
kind
of
implies
that
that
this
is
mandatory
to
implement.
K
You
know
and
we'll
see
later
that
that
it
will
be
useful
thing
because
we
want
to
dynamically
be
able
to
update
the
the
authorization
well,
the
access
token,
that
that
author
is
authorizes
certain
actions,
so
you
want
to
have
there
and
then
we
need
to
decide
how
can
handle
the
case
B,
which
is
yeah
just
that
that's
specify
some
signalling
or
configuration
option.
That
says
that
this
method
is
supported
or
not
a
particular
client
server.
K
F
A
is
the
default
way
of
doing
it
in
the
framework
I'm,
not
sure
it
should
be
mandatory
to
implement.
That's.
That's
that's
for
discussion
right,
I,
don't
think
it
has
to
be
mandatory
and
be
one
option
for
signaling
is
to
use
of
the
claim
than
the
profile,
and
there
is.
If
you
look
at
the
ipsec
profile,
they
are
adding
claims,
which
is
instructions
for
the
client,
how
to
start
communicating
with
the
resource
or
how
to
initiate
the
authentication,
so
they
are
used
in
that
case,
as
well
as
in
the
escort
profile.
F
There
are
different
modes
where
you
either
start
directly
with
a
communication,
security
protocol,
IP,
SEC
or
always
co-op,
or
you
start
with
the
key
management
protocol,
which
is
ad
hoc
or
IP
version
2,
and
then
this
claim
KMP
key
management
protocol
indicates
the
client
how
to
start
your
temptation.
Maybe
we
can
do
something
similar,
which
is
or
more
generic,
which
applies
both
to
to
copy
TLS
profile
about,
as
well
as
those
on
the.
E
G
Yeah
caster
Owen
I
just
want
to
quickly
state
that
I
believe
the
PSK
identity
approach
has.
Is
this
a
little
bit
more
favorable
to
approaches
in
managing
the
u.s.
attacks?
So
I
think
it
would
be
a
good
thing
to
be
able
to
rely
on
it
in
the
end
there,
with
all
the
info,
there
always
will
be
a
little
bit
of
a
trial
and
error
situation
in
there,
because
you
don't
know
whether
the
server
actually
still
remembers
what
you
told
in
five
seconds
or
five
years
ago.
G
L
Jim
shot
if
the
PAS
identity
version
is
capped,
there
is
going
to
be
one
consideration.
That's
going
to
need
to
be
well
documented
to
be
Flemish
in
it,
which
is
if
the
server
ends
up
doing
introspection
on
the
thing
passed
to
it.
There's
going
to
be
some
interesting
potential,
timeout
issues
on
the
detail
on
the
DTLS
protocol.
Why
is
waiting
for
the
server
to
actually
do
that
introspection
bed
to
give
a
s.
K
So
solve
this,
this
is
an
easy
one.
I
don't
expect
there
to
be
many
discussions
about
that.
So
there's
some
the
question:
when
does
the
message
that
you
receive
is
actually
unauthorized
and
the
text
currently
is
pretty
restrictive
at
so,
for
example,
the
well-known
car
resource
currently
would
be
yeah.
K
You
would
be
prohibited
to
again.
We
press
on
it
following
the
current
texts
on
that,
and
my
proposal
is
just
to
change
that
that
so
actually
the
text
says
that
if
you
have
a
channel
that
currently
isn't
protected
and
there's
no
valid
access
token
in
the
resource
server
to
handle
that
request-
and
it
would
just
send
sent
act
for
one
response
and
so
be.
My
proposal
is
just
to
make
clear
that
this
is
for
resources
that
you
will
actually
want
to
protect
this
way
and
not
those
they
are
open
to
the
public.
F
K
So
and
and
then
there's
the
question:
if
you
follow
up
on
it
at
some
point,
you
might
have
had
the
valid
access
token
for
some
communication
going
on
and
that
has
expired
or
even
didn't
even
yet
exist
or
somebody
fakes
tokens
and
the
question
is
what
to
do.
With
the
deaconess
session.
There
Jim
asked
whether
it's
useful
to
say
that
it
must
be
terminated
here,
which
has
the
advantage
that
that
you
just
can
can't
forget
about
the
state
of
that
Nicholas
session
very
soon
be.
K
On
the
other
side,
on
the
con
side,
the
resistor
or
the
entity
there
that
has
now
lost
its
last
access
token.
For
for
that
session,
might
in
future
wanna
true
want
to
choose
to
send
requests
over
that
channel
again,
for
example,
when
it
reverses
the
roles
and
has
been
contacted
as
a
resource
server
and
at
some
point
becomes
a
correct
client
to
do
something
else
ending
on
the
excess
amount
which
we
had
had
a
very
long
discussion
when
doing
the
news
cases
document.
K
K
K
G
Jackass
moment
again,
I
think
we
need
to
synchronize
here
it
rich,
so
RFC
725
to
makes
one
curve
mandatory
and
it
would
be
nice
to
have
consulted
agreement
between
working
groups
on
when
we
kind
of
switch
away
from
that
and
switch
to
something
else,
and
so
I
think
it
would
it's
about
time
to
do
that.
I
mean
the
coop
document
is
four
years
old
now
and.
G
Yeah,
if
we
can
get
wide
unitary
wide
agreement
on
what
those
curves
should
be,
we
should
make
the
switch
and
I
don't
think
the
core.
The
core
working
group
is
going
to
be
the
one
who's
leading
that
discussion,
but
we
would
definitely
want
to
make
sure
that
we
apply
our
changes
to
the
coop
specification.
So
I
have
no
idea
which
bird
look
should
should
do
this,
but
this
works
out
and
sounds
as
good
to
me
as
any
other.
So
please
go
ahead,
make
that
decision
and
coordinated
with
us.
So
we
can
make
Carroll
synchronous
changes.
G
G
So
it
kind
of
seems
to
be
a
no-brainer
for
me,
but
there
may
be
new
information
that
any
file
type.
So
that's
why
it's
good
to
ask
that
question
and
have
a
wide
body
of
you
to
look
at
it
because
I,
just
that's!
What
now
co-op
has
today
has
mandatory
and
I
forget
what
the
higher
security
one
is,
but
it's
from
the
same
family
and
we
probably
want
to
have
a
pair
and
I
think
this
would
be
255
19,
plus
the
for
4h,
saying
I,
think
and
somebody
who
was
really
into
this
whole
trouble
thing.
K
K
The
other
options
were
true
and
that
the
actual
access
token
in
the
PSA
identity
field,
which
leaves
you
with
the
option
to
not
use
the
post
request
at
all
and
just
save
that
round-trip
and
provide
the
access
token
with
the
GTRs
handshake,
so
it
that
the
server
doesn't
have
to
keep
this
state.
So
when
you
upload
the
access
token
using
the
code
method,
then
you
have
to
store
it
until
some
point
of
time.
K
So
if
the
access
token
isn't
valid,
then
yet
you
just
terminate
that
that
session
and
if
I
mention-
and
you
can
do
two
things-
you
could
just
wrap
the
key
encrypted
by,
like
your
reservation,
server
that
that
generates
the
session
key
and
sends
it
in
the
access
token
s
encrypted
key
object
and
the
research
server
knows
how
to
unwrap
that
and
could
use
that
Thank
You
pizza,
oven.
He
crypt
it
and
use
it
as
a
session
key
and.
K
D
K
K
So
this
brings
me
to
the
erosion
update,
so
it's
apparently
the
text
doesn't
distinguish
between
the
rekeying
and
updating
of
permissions.
So
you
should
just
clear
that
that
if
you
want
to
update
the
permissions
for
accessing
your
resource,
then
this
could
be
done
within
the
existing
Duty
last
session.
I.
Not
just
do
this
using
this
option.
A
K
K
So
the
last
one
refers
to
the
time
synchronization
issue
that
we've
been
discussing
so
there's
the
section
five
one
root,
which
is
within
the
security
considerations.
That
says
it's
not
about
many
words
about
the
discovery
that
there,
the
resource
server
may
point
the
requesting
client
that
tries
to
initiate
the
session
to
its
authorization
server
and
the
problem
with
this
profile
is
that
you
already
need
to
have
an
existing
security
relationship
with
this
authorization
server.
K
Otherwise,
because
the
the
initial
communication
between
the
resource
server
and
the
client
isn't
protected
at
all,
you
could
just
yeah
get
that
fake
asfo
messages
from
some
men
in
the
in
the
middle,
which
event
should
should
ignore.
So
one
idea
that
came
from
from
the
dkf
work
is
just
to
copy
the
a
s
address
or
information
which
authorization
server
key
used
into
the
client
to
a
s
request.
K
That's
in
this
rat
in
the
framework,
and
if
you
do
that,
then
the
authorization
server
can
actually
check
that
it
is
an
authorization
server
for
the
use
of
survive.
F
is
the
one
that
that
is
allowed
to
to
do
these
decisions
on
the
authorization.
This
might
go
into.
The
framework
document,
if
you
decide
to
do
that.
K
So,
let's
this
makes
me
to
the
framework
document
they
are.
There
were
parts
that
already
have
been
moved
into
the
final
document
or
are
in
the
progress
process
of
moving.
First
thing
is
discovery,
so
there
have
been
some
comments
on
that
by
Jim
in
the
review
of
the
indigenous
profiles
of
that's
the
reason.
Why
put
it
here
as
well?
K
So,
and-
and
here
we
have-
the
discretion-
is
this
issue.
The
proposal
that
it
have
made
was
that
we
just
generate
Ananse
at
there
is
a
server
that
is
copied
into
the
client
s
request
and
then
mirrored
back
from
the
authorization
server
back
to
the
user
server
by
including
it
in
the
access
token.
So
this
would
be
the
most
simple
thing
that
you
could
do
when
you
don't
have
really
synchronized
clocks
between
the
resource
server
and
the
authorization
server,
but
at
least
ensure
that
this
authorization
is
fresh
and
not
five
years
old.
D
K
A
A
D
K
K
M
D
K
So
and
then
the
last
minor
remarks,
where
that
we
should
sort
out
the
AAS
information
that
we
include
in
error
responses.
So,
for
example,
if
you
try
to
access
the
resource
out
of
any
predicted
channel
and
without
a
valid
access
token,
then
we
might
want
to
give
only
the
information
which
organization's
server
to
ask
why,
if
you're
already
within
a
secure
session,
then
we
might
expand
to
more
information.
K
Why
why
this
never
happened
and
we
had
the
understanding
that
much
of
the
error
and
they
should
go
into
the
framework
document,
or
least
some
guidance
of
error
and
in
should
go
into
there.
We
should
include
this,
at
least
in
these
security
considerations
here
and
yeah
related
to
that
there
might
be
more
information
going
into
the
AA's
info
as
currently
just
that,
so
there
is
some
proposes
from
CD
at
video.
That
says
what
an
AAS
information
record
should
look
like
and
might
expand
that
and
to
give
you
more
information,
why
certain
actions,
favor.
N
Hello,
I
am
Martin
new
Gunnarsson
I
am
one
of
the
co-authors
of
a
co-op
profile
for
Ace,
like
this
yeah
I,
so
shown
in
this
image.
This
shows
how
the
OS
co-op
profile
fits
into
the
bigger
picture.
It's
depending
on
the
ACE
framework
document
on
the
a
dock
document
on
there
and
on
the
OS.
Co-Op
document
slide.
Please-
and
here
it's
shown,
you
know
how
it
fits
in
in
a
more
functional
context
as
to
connect
to
what
your
on
said.
N
This
is
a
picture
of
the
signaling
in
the
ACE
framework,
and
this
document
defines
how
the
signaling
between
the
client
and
the
recessed
server
is
going
to
be
done,
and
the
document
defines
three
ways
in
which
the
signaling
can
be
done
and
it's
using
OS
co-op
only
and
then
you
can.
You
use
OS
co-op
with
ad
hoc
and
you
can
use
either
symmetric
keys
and
a
symmetric
keys
and
then
a
list
of
choices.
N
N
The
client
will
post
its
token
to
the
resource
server
and
it
will
get
there
for
apply
and
then
everything
is
ready
to
begin
sending
OS
co-op
requests
and,
of
course
you
don't
need
to
post
your
token
every
time
you
want
to
send
one
request
but
offer
the
Pope
token
is
suppose
that
you
can
send
as
many
was
Corp
requests
as
you
want.
As
long
as
the
tokens
value
and
the
status
of
this
draft
is,
it
was
first
presented
at
IETF
97.
N
We
recently
updated
it
to
version
o3
to
align
it
with
the
lace.
This
changes
to
the
ad
hoc,
a
document
and
OS
co-op
document
Jim
recently
posted
published
a
review.
Thank
you
Jim,
and
we
are
currently
done
commenting
that
those
erasing
those
issues
from
the
review
and
the
document
will
be
updated,
yeah
in
the
close
future
and
our
planned
next
steps
is
to
get
more
feedback.
There
are
currently
two
implementations
being
worked
on
and
we
think
that
this
document
is
reaching
maturity
and
that
perhaps
it
should
be
taken
to
the
next
step.
O
Protection
against,
for
instance,
as
poofing
of
IP
addresses,
and
as
also
here
I
mentioned
before,
we
are
taking
profit
of
the
fact
that
IPSec
provides
a
file
of
flexibility
as
to
the
actual
establishment
of
the
IPSec
channel.
So
we
can
see
here
different
nodes,
including
the
provisioning
authorization,
server
or
pre-built,
so
to
say,
security
associations
for
IPSec
or
the
establishment
of
them
through
an
actual
key
management
protocol
like
I,
give
it
you
as
default
option
or
alternative
like
header
base
protocol
that
are
not
discussed
and
appendix
section.
E
O
Timing
and
of
course,
this
is
agnostically,
actual
application
here,
just
to
give
an
overview.
This
is
the
whole
very
current
landscape
of
our
season.
Drafts
relate
to
this
area,
and
this
word
actually
takes
place
in
this
corner.
So
taking
advantage
of
IPSec
agree
to
the
ACE
framework,
of
course,
and
I
give
it.
You
yeah
I'm,
not
going
to
spend
much
time
on
this,
because
we
have
a
nice
review
before
already.
We
just
stick
the
ACE
framework,
so
several
sporting
protected
resources
to
coins
that
are
going
to
get
access
token
to
access
them.
E
O
Give
you
a
little
bit
more
detail
as
I
say
we
consider
different
modes
to
establish
such
an
IPSec
channel
between
client
and
server
server
as
the
first
one.
We
call
the
direct
provisioning,
so
the
pair
of
security
associations
are
actually
built
by
the
translational
server
and
provided
to
the
client
directly
in
the
accident
response
and
then
to
the
RS
indirectly
as
encoded
in
the
access
token.
In
that
case,
all
information
necessary
to
set
up
the
security
associations
are
actually
direct
with
the
value.
O
In
fact,
the
second
and
third
alternatives
assume
instead
that
client
was
a
server,
actually
run
a
key
management
protocol
to
fully
establish
the
IPSec
channel,
and
you
can
go
consistently
with
the
other
profiles
for
a
symmetric
or
asymmetric
to
a
physician
key
and
then
it's
again
up
to
the
authorization
server
ultimately
to
determine
the
precise
key
management
protocol
to
run
and
the
default
choice,
for
that
is,
of
course,
activity.
As
you
can
see
in
the
green
box,
the
opposition
server
signals
the
use
of
this
profile,
and
so
all
of
the
establishment
of.
H
O
The
pool
yeah
this
should
be
even
clearer
now
so
circle
speaking
a
first
step.
Client
is
to
each
the
access
request,
get
a
token
and
instruction
to
proceed
with
the
IPSec
session
establishment
client,
whereas
to
post
the
token
and
establish
the
type
is
a
channel
through
the
indicated,
alternative
and
finally
client
arrest,
secure
communication
over
IPSec
channel,
and
this
is
aligned,
of
course,
without
the
profiles
on
different
aspects.
So
we
also
consider
that
possible
unauthorized
resource
requests
to
find
exact
is
the
contact,
if
unknown
to
the
client.
O
We
consider
also
possibility
of
a
talking
update
for
the
sake
of
renegotiation
of
the
IP
succession.
You
can
find
an
eraser
server
and
like
in
other
profiles,
communications
between
a
s
and
RS,
as
well
as
between
a
s
NC
must
be
secured,
but
it's
out
of
scope
of
this
profile
exactly
how
this
s
that
you
can
go
for
detail
as
possible.
Alrighty.
Second,.
O
In
the
very
same
message
exchange
in
the
end
to
fulfill
an
additional
number
of
security
requirements,
especially
in
the
presence
of
intermediary,
a
proxy
notes,
so
in
that
case
would
make
sense
to
have
actually
implemented
only
a
dog
to
be
used
both
for
the
establishment
of
the
official
channel
as
an
alternative
to
activity
and
of
the
Oscar
context,
as
it's
supposed
to
be
in
in
the
first
place.
So
with
further
additional
advantages
on
the
practical
implementation
side.
Q
How
about
this
I
bet
that,
after
question
about
so,
if
you're,
not
using
IV
to
to
establish
key
material,
there's
a
lot
of
things
actually
to
actually
does
to
keep
up
certain
security
premises
so,
for
instance,
not
reusing
the
same
counter
on
ast
CMR.
Things
like
that.
So
does
your
alternative
to
IQ
to
take
all
of
those
considerations
into
account
because
there's
a
reason
we
have
IQ
to
with
all
those
features
in
there.
O
Q
But
so
so
let
me
give
an
example
of
where
I
am
worried,
where
things
might
go
wrong.
So
let's
say
this:
the
central
management
system
has
the
keys
and
the
counters
for
an
encryption
session.
It
hands
it
out
to
the
to
I,
can
put
one
of
these
I
can
Prince
reboots
and
it's
V.
Given
the
same
session
and
now
the
session
starts
over
and
are
the
same
counters.
Q
A
You
worried
that
the
large
number
of
different
options
could
potentially
lower
the
interoperability
and
in
an
IOT
deployment,
because
now
you
have,
as
you
said
you
like-
between
the
client
and
the
AES
you
can
use,
you
can
use
DTLS
above
typical
entry.
You
can
use,
I
could
be
do
the
IPSec,
you
can
use
AWS
co-op
and
then
between
the
client
and
the
resource
server
you
could
have
Ike.
We
do
maybe
well
that
here
you
say:
communication
between
AES
and
RS
and
RS,
and
a
s
and
C
must
be
secured
using
all
these
different
options.
A
A
M
So
we're
using
MQTT,
karo,
T
prototyping
and
we're
looking
into
privacy
security,
and
we
think
the
ACE
framework
can
be
can
add
value
to
and
PTT.
So
this
draft
answers
the
question:
how
can
we
use
an
MQTT
server
and
then
keep
you
focused?
Sorry
as
an
ace
framework
resource
server
and
the
authors
are
today
I'm
single-
you
can't
be
here
today
and
backgrounds,
more
a
wall
for
uber
and
I'm
Anthony
Kirby,
my
backgrounds
kind
of
more
of
today
at
least,
is
more
impute
et
now.
M
This
is
the
first
time
we
presented
this
in
this
in
this
context,
and
so
this
is
kind
of
a
brief
summary
of
those
who
can
less
familiar
with
NPT
kind
of
like
start
from
a
solid
foundation.
That's
not
too
tedious.
So
an
PTT
is
a
simple
publish/subscribe
messaging
protocol
using
IOT
is
a
TCP
connection.
Over
TLS
messages
are
published
to
a
topic.
Topics
are
defined
in
a
string
and
the
string
represents
our
hierarchy.
D
M
M
R
A
M
See
how
a
so
standard
MQTT
security
involves
using
TLS,
username
and
password
for
our
work.
We
wanted
to
use
tokens
rather
than
a
username,
a
password
we
looked
at.
Whom
are
we
look
to
I
wore
those
kind
of
flows,
kind
of
as
humor
interactive
user
and
no
bit
HTTP
centric
as
well,
but
J's
framework
fitted
our
requirement.
M
M
E
M
So
I'll
just
skim
through
the
summer
you
wanted
reading
it
allows
the
important
parts
are
that
we're
focusing
on
the
client
resource,
server,
mutual
authentication
and
authorization.
So
the
MQTT
broker
is
a
resource
server
and
we're
not
covering
IAS
discovery.
Token
requests
and
Inter
specters
they're
outside
the
scope
of
game
competing
ultimate,
and
we
really
want
to
use
a
basic
TLS
flow
to
make
it
feasible
to
integrate.
With
the
existing
client,
libraries
and
server
implementations.
M
We
don't
have
to
do
an
entirely
custom,
compute
ET
server,
because
that
kind
of
slightly
defeats
the
purpose
of
the
exercise
really
so
the
basic
implementation
that
we're
talking
about
doesn't
youth
doesn't
use
offset
info
because
this
doesn't
really
fit
in
very
well
in
our
appendix
we
do
discuss
a
way
that
we
could
use
or
said
info,
and
this
is
something
we
discussed
with
Ludwig
as
a
write.
Only
MPEG
topic,
m4m
PTT
file
that
will
be
more
flexible
and
we
heard
more
likelihood
felt
to
use.
E
A
M
Excellent,
so
this
is
the
standard,
a
stoking
load
that
you're
familiar
with
in
a
similarity.
The
MQTT
broker
is
the
resource
server
and
the
mqt
topics
are
the
protective
resources,
the
authorization
server
controls
who
can
publish
and
subscribe
on
a
topic
by
topic
basis,
because
MQTT
t
treats
publishers
and
subscribers.
Similarly,
there's
a
single
authorization
server.
This
is
different
to
corrupt
pops
up
and
from
QT
t.
M
There's,
no
really
good
reason
to
split
into
two
different
authorization:
servers:
n
PDT
is
collection
orientated,
so
the
tokens
provided
with
the
connection
the
tokens
provided
by
bundling
it
int
into
the
MGP
T
password
as
a
JSON
web
token,
and
the
broker
then
caches
the
token
for
as
long
as
the
client
stays
connected
well,
I
see.
We've
said
that
and
I've
put
in
the
draft,
but
based
on
our
experiments
with
the
integrating
listen
to
existing
broker
code,
it'll
be
better
to
put
it
in
the
username
and
we'll
come
back
to
that.
A
bit
later.
M
So
after
having
connected
they
resource
over
text,
the
stored
token,
when
the
client
subscribes
it'll
fix,
there's
a
couple
of
points
worth
raising
thirstiest
wild
cups
topics
can
can
have
one
cards
so
if
they
use,
then
of
course
the
token
must
contain
an
equal
or
wider
scope
well
card.
The
broker
resource
server
will
return
some
back
only
code
if
the
climb
close
to
subscribe
to
a
topic
that
it
doesn't
know
whether
token
for
and
we'll
talk
a
bit
about
expiry.
M
When
a
client
publishes
the
broker
first
checks
the
scope
and
the
expiry
of
the
token,
if
it's
not
valid
it
disconnects
the
client.
This
is
something
will
be
different
with
possibly
be
they'll,
be
scoped
anymore,
with
MP
2
t5,
their
friend
PTT
3.
Then
we
just
have
to
close
the
connection.
If
the
policies
is
accepted,
the
broker
then
checks
the
token
actually
only
need
to
check
the
expiry,
then
for
each
subscriber
to
the
topic
and
all
the
valid
subscribers
get
get
the
message
delivered
and
any
with
expired
tokens.
Any
subscribers
with
expired.
M
Tokens
will
be
disconnected
at
that
point,
I
guess
probably
from
the
spec
20
or
that
leave
the
latest.
So
after
tokens
expired,
a
client
will
be
disconnected.
There
wasn't
any
opportunity
to
have
feedback
or
in.we
authentication
with
impunity
through
your
month.
I
think
that's
I,
think
that's.
Okay,
it's
kind
of
an
established
thing.
It's
a
standard
thing
that
mpg
declines
expect
to
be
disconnected
and
reconnected
in
automatically
that's
kind
of
part,
normal.
D
M
And
for
completeness,
we
considered
the
possibility
that
a
published
message
could
also
include
a
new
token
to
kind
of
update
the
current
token
in
session
and
we've
had
some
feedback
from
the
look
like
about
that.
I
think
it's
probably
that
probably
more
context
here
than
we
really
want
at
least
for
their
this
stage
of
the
draft
next,
please.
M
So
what
are
our
next
steps
and
we've
got
a
prototype?
This
is
implemented
as
a
plug-in
there's
just
a
plug-in.
We
don't
have
to
write
our
own
broker
to
the
mosquito
broker,
it's
kind
of
one
of
the
industry
standard
ones
and
we're
working
towards
publishing
that
they're
kind
of
we're
getting
close
to
that
when
we
wrote
the
draft
we
based
it.
The
draft
on
and
pewt
t31
one
MP
2
t5
is
now
kind
of
starting
to
come
out.
M
It
hasn't
been
published
yet
and
we
want
to
integrate
feedback
from
look
excites
and,
hopefully
monthly,
so
I
think
it's
kind
of
time
to
reevaluate
exactly
where
we
are
so
planning
to
revise
the
draft,
we're
keen
to
maintain
support
for
NPT
to
three
on
one,
but
probably
do
a
small
and
simple
bare
minimum
that
just
works
for
NPT
d3
on
one
and
kind
of
a
more
and
a
canary
appendix
that.
What
second
half
the
draft?
M
P
So
there's
been
several
reviews
of
the
document.
It
was
presented
at
c4g
at
the
Eurogroup
meeting
by
him
shot
thanks
for
that
team
and,
after
I've
ever
said,
quite
detailed
security
reviews
by
Don,
Dan,
Hawkins
and
Hillary
Isabella,
and
all
of
these
comments
have
been
taking
into
account
in
the
0-7
version
and
yeah.
And
overall
things
like
the
reviewers
are
happy
with
the
quality
of
the
drops.
P
So,
what's
new
in
the
0-6
version,
as
we
promised
last
time,
we
have
implemented
error
messages.
They
are
also
seaboard
array,
but
with
message
type
0
and
then
a
short
text
ring
all
the
other
data
messages
have
message
type
1
to
6,
and
these
are,
for
example,
to
some
general
error
messages
or
to
indicate
which
type
of
curve
that
the
second
party
support
well
introduce
the
verification
of
common
preferred
insidious
curve.
This
is
so
that
party
you
sends
a
curvy
party.
P
P
P
P
The
application
unique
strings
to
derive
key
so
know
now
in
the
field
algorithm
ID,
instead
of
the
other
making
it
ya,
know
cryptographic.
Oh,
but
it's
more.
It's
a
better
structure.
The
default
go
up.
Your
iPad,
then
using
either
uber
co-op
has
been
changed
from
a
duck.
It
hook
to
well-known
ad-hoc
and
there's
a
chapter
on
how
to
derive
Keith's
new
PSK.
P
P
P
Better
explanation
of
this
session-
I
don't
first,
this
was
a
comment
from
Dom,
so
this
has
been
detailed
in
several
sections:
how
to
choose
this
and
why
and
what
to
think
about
them
how
to
handle
them
compact
representation
of
easy
to
points.
This
was
a
comment
from
dawn
that
the
point
compression
was
not
recommended
and
he
suggested
that
Edie
hook,
he
used
a
compact
representation
according
to
RFC
6890.
P
P
Then
also
bell-shaped
slightly
change
the
structure
of
identities,
the
forest
was
a
idv
field
and
a
certificate
feel
that
went
into
the
ID.
Now
this
has
been
more
structured
so
that
identity
always
is
a
sad
fate,
kept
or
a
hash
of
a
certificate
and
then
any
hint
of
which
credentials
to
used
or
sent
in
the
hint
ID
be
filled.
P
P
S
Morning,
dentists,
better
yeah
I
will
try
to
give
a
short
presentation
of
the
est
over
coalesced
draft.
Fantastic
I
have
presented
this
over
a
few
times
or
two
times
before
so
they'll
keep
it
short,
a
short
introduction,
please
the
next
time.
Thank
you
very
much.
So
the
East
t
/
coop
s,
is
linked
to
the
work
which
is
done
in
the
animal
working
group
where
they
start
bootstrapping
small
devices
into
a
network
use.
S
Is
there
an
ESP
which
is
an
enrollment
of
a
secure
transport
exists,
an
RFC
which
makes
it
possible
that
open,
secure
transport
you
can
enroll
and
certify
certifies
that
the
network
into
which
you
go
is
the
network
you
wanted
and
actually
that
the
node
that
wants
to
go
into
the
network
is
actually
set
if
authorized
to
do
so.
So
that
is
where
EST
is
useful
and
is
very
nice
and
it
exchanges
certificates
where
this
EST
is
currently
based
on
HTTP
and
TLS
for
small
devices
we
wanted
to
use
coop.
S
So
that
is
what
is
the
AFT
is
about
having
ESD
over
TLS
changes
to
EST
over
come
on.
Please
next
slide.
There
is
a
small
picture
here.
So
what
is
happening
in
Brisky
is
that
you
have
the
pledge,
which
is
the
joining
device
ads
into
the
secure
domain
and
freedom
proxy.
It
gets
in
connection
to
the
EST
server
and
there
we
exchanged
the
certificates.
What
is
new
in
duplicity
protocol
is
that
are
also
vouchers
are
changed
which
are
described
in
the
voucher
draft
and
which
is
exchanged
between
the
vendor
and
the
and
the
pledge
devices.
S
A
Bit
a
question
on
this,
so
the
draft,
the
idea
of
using
es
de
over
koa,
it's
somehow
independent
of
animal
but
but
you're
showing
the
animals
like.
How
do
you
see
that
that
relationship,
okay.
S
I
see
this
relationship
that
we
have
these
additions
to
the
est
for
having
the
voucher
transport.
But
on
the
other
side
we
see
that
you
can
use
the
est
independently
of
the
animal
contact.
So
the
angle,
it
provides
a
facility
to
describe
est
a
huge
coop,
so
we
can
use
the
independently
from
that.
So
if
you
have
a
nice
tea
server
which
dogs
go
up
in
low-resource
Network
and
another
client
that
wants
to
use
that,
then
this
draft
also
serves
a
purpose.
S
Next,
please,
so
we
have
done
some
work
since
the
last
time.
For
example,
we
have
edit
and
protein
section
I
should
very
much
like
people
to
have
a
look
at
this
because
it
may
be
actually
too
much
not
having
the
protein
section
or
it
may
be
due
to
the
smoke
so
I
think.
Actually
the
desserts
and
the
separate
sections
are
would
be
very
much
appreciate
some
comments
from
this
working
group
about
this
section.
What
kind
of
if
they
see
this
is
sufficient
or
that
say
no.
S
You
really
have
to
work
this
out
much
more
as
it
is
done
now,
and
it
tells
you
about
the
proximity
ft
est,
independent
est
and
and
the
client
just
for
the
coop
arm,
and
you
have
an
est
server,
which
is
HTTP
and
the
client
which
uses
coop.
Then
you
put
epoxy
and
HTTP
code
proxy
in
between
the
other
case
that
we
talked
about.
Is
that
if
you
have
the
ESD,
sir,
from
its
docks,
Khoa
of
know,
HTTP,
and
it
talks
to
the
toxicity
yet.
S
S
So
that
also
has
some
impact
on
the
security
corner,
assault
consideration.
So
we
have
added
this
security
considerations.
Sections
talk
about
the
proxies,
might
me,
and
also
the
ESD
server
considerations,
which
are
very
much
the
same,
which
has
been
described
from
the
SD
servers
using
dealers.
The
discovery
has
been
extended.
That
has
been
some
comments
on
them,
so
we
have
changed
that
and
finally,
that's
changed
because
brisk
is
still
of
all
things
of
the
whisky
functionality
which
has
been
added
has
to
follow
the
terminology
which
evolves
into
the
whisky
environment.
Any
questions
about
this.
S
So
what
still
needs
to
be
done?
We
have
some
section
operational
parameter
values
which
are
actually
the
coop
parameter,
values
everything
after
some
testing
that
maybe
the
time
out
should
be
changed,
or
something
like
that.
So
that
is
what
this
section
is
about.
We
should
very
much
like
to
react
to
reviews
like
some
feedback
from
you,
and
we
have
some
other
additions
and
text
layouts,
which
has
to
be
improved.
S
S
S
I
should
like
to
know
if
this
is
really
interact
with
sweet
boots
with
users
in
version
footpath
in
the
ACE
version,
and
it
will
be
very
happy
if
that
is
possible
and
I
think
it
should
be
in
here,
because
it's
very
much
security,
oriented
and
security
for
small
devices
is
the
subject
of
this
group.
Thank
you.
G
Yeah
customer
and
if
I
were
to
answer
that
question
the
answers.
Yes,
we
should
do
this
year.
This
is
the
place
where
we
do
authentication
authorization
for
constrained
environments,
and
this
is
authentication
for
than
20
environments
and
makes
a
lot
of
sense
just
have
to
make
sure
that
we
actually
are
chartered
to
do
that.
But
I
think
the
Charter
supports
this.
S
A
Currently,
I
don't
think
it
currently
does,
but
but
it's
a
a
discussion
with
the
ad
whatever
we
want
to
pick
up
new
work
and
sort
of
like
this
key
certificate
management.
Defining
a
certificate
management
protocol
on
top
of
co-op
wasn't
something
that
we
had
initially
ambitions
to
be
done
here.
But.
H
Oh,
a
Frankish,
aha,
I,
think
from
the
user
perspective,
I
think
this
solution
is
very
useful
because
it
can
help
the
IOT
devices
automatically
to
enrollment
to
the
network
it
wants
to
and
to
authenticate
each
other
I
think
that's
a
very
useful
solution
and
the
draft
is
good
and
so
I
I
hope
that
that
our
SE
group
can
extend
our
scope.
Our
charter
to
include
this
work,
Oh.
I
Kathleen
we
already
ad
I
would
love
to
get
a
sense
of
what
the
working
your
participants
think
and
then
also
just
to
make
sure
that
the
work
through
prioritize
is
what
work
gets
done,
because
there's
a
lot
on
the
table
and
I'd
like
to
see
us
have
some
good
wins
and
get
some
of
the.
You
know,
protocol
work
and
profiles
through.
S
S
S
A
Would
be
interesting,
though,
on
how
to
find
out
how
this
relates
to
actually
the
other
aids
work,
because
it
come
it
sort
of
competes
a
little
bit
with
the
azores,
because
that
also
provides
a
mechanism
for
key
distribution
getting
the
key.
So
it
raises
an
interesting
question
on
whether
this
actually
replaces
some
of
the
work
that
we
have
just
been
talking
about
earlier.
Leave
that
up
to
your
interpretation,
but
it
may
look.
Everything
looks
very
simple.
At
the
beginning.
I
I
I
really
ask
for
prioritization,
because
some
of
the
drafts
will
I'm
working
taking
a
long
time
to
get
through
and
it
would
nice
it
would
be
very
nice
to
see
documents
get
all
the
way
through
publication
and
see
the
stuff
get
used.
So
the
working
group
really
needs
to
prioritize
where
this
fits.
If
they
think
it's
so
when
I
I'll,
let
the
queue
go
and
then
Hannes.
If
you
want
to
ask
some
key
questions,
just.
F
Your
honor
under
Eriksson,
so
I'm
in
favor,
of
working
with
certificate,
enrollment
related
questions.
In
this
working
group.
We
had
another
proposal
last
meeting,
it's
the
EI
LS
draft,
which
is
addressing
the
same
same
problem
and
which
is
very
lightweight
so
I
think
that
this
is
a
good
topic,
and
this
is
a
good
working
group.
But
we
have
a
lot
of
things
on
the
plate
and
there
is
no
discussion
of
adoption
of
any
profile
yet
or.
F
A
F
Right
but
we
haven't
even
had
a
discussion
about
the
adoption
of
profiles,
and
now
we
have
discussion
about
work
it
or
about
the
draft,
which
is
not
at
all
in
scope
of
the
Charter
I.
Think
that
focus
is
very
interesting
here
and
I
think
we
should
definitely
consider
bringing
in
the
certificate
work,
but
we
have
a
lot
of
things
that
needs
to
be
progressed
in
the
existing
Charter
before
I
hear.
A
U
Trying
I'm
just
sure
I
can
jump,
Nancy
can
widget
from
Cisco.
So
it's
not
clear
to
me:
I
mean
I,
I,
guess
what
I'm
trying
to
voice
is
I
think
this
draft
needs
to
be
move
forward,
whether
it's
in
this
group
or
not
I,
guess
it's
is
the
question
for
us
to
decide,
but
I
think
it
is
important.
So
we
brought
it
up
an
anima
and
it
was
very
clear
because
it
isn't
really
Enterprise
it's
more
for
IOT.
It
was
decided.
It
didn't
belong
in
that
group
right.
U
So
the
purpose
of
this
is
because
co-op
is
supporting
from
a
security
standpoint,
the
use
of
TLS
and
TLS
certificates.
We
need
to
have
some
way
of
managing
those
certificates
right
and
so
and
again,
I'll
just
say:
I
think
this
draft
needs
to
move
forward,
whether
it's
in
this
group
or
not
I,
think
that's
up
to
us
to
discuss
and.
E
G
There
are
these
these
x.509
certificates
and
they
are
out
there
and
people
use
them
and
so
on.
Clearly,
they
are
not
necessarily
the
focus
of
achiever,
but
they
are
out
there
and
people
are
building
security
systems
around
them,
so
we
still
have
to
support
them,
and
until
we
have
a
working
group
that
that
is
focused
on
making
certificates,
x.509
certificates
useful
in
the
IOT
I
think
this
workgroup
is
as
good
as
any.
G
If
I
were
going
to
prioritize
the
work
we
already
have
been
doing
and
any
any
work
on
certificates,
my
priority
would
be
on
the
other
work,
but
I
still
think
this
work
should
be
done.
It's
relatively
easy
to
do
because
it's
really
just
parting
over
a
protocol
that
is
already
well
understood
so
and,
as
Mike
said,
we
are
not
inventing
anything
here.
We
are
things
that
are
already
well
understood
in.
V
Shun
Turner
plus
one
Kathleen,
said
about
prioritization.
The
other
thing
is
that
one
of
the
epic
failures
in
the
PGI
space
was
the
fact
that
they
didn't
pick
one
enroll
map,
rotation,
things
and
just
kind
of
weather
flies
it
a
little
bit
and
it's
good
that
you
can
just
make
it
co-op.
Let's
not
have
another
enrollment
protocol,
let's
pick
one
and
move
on,
so
that
it's
easy
for
people
to
decide
what
to
implement
as
opposed
to
like
well,
what
do
I
have
to
do
because
we
get
back
to
the
enterprise
solution
space
there.
W
Michael
Richardson
I
guess
I'm
gonna,
disagree
with
Nancy
said:
I,
don't
think
that
Panama
rejected
this
document,
I
think
that
Anna
I
don't
think
that
anima
rejected
this
document.
I
think
like
this
working
group,
animus
said
it's
not
yet
in
our
charter.
Okay,.
W
W
I'm
really
happy
with
your
document:
I,
don't
think
it'll
get
the
right
review
in
this
working
group
that
it
needs
to
get
that's
just
my
my
my
take
on
right.
I
think
you
need
to
have
it
elsewhere,
but
and
and
finally,
as
to
what
Kirsten
said,
I
don't
think
if
somebody
comes
up
with
some
kind
of
caught
base,
you
know
statement
of
identity,
pretty
sure,
that's
easy
and
caught
I'm,
pretty
sure
that
that
est
could
enroll
it
okay.
W
So
just
because
it's
peak
Hicks
origin
doesn't
mean
it,
the
things
turn
have
to
be:
have
asn.1
goo
in
them.
We
could,
when
you
request
a
certificate
and
you
enroll
things
the
thing
that
you
get
back
might
in
the
future,
not
be
it
could
be
some
kind
of
a
CWT
object
rather
than
a
certificate.
So
don't
don't
assume
that
just
because
this
protocol.
A
W
A
W
Before
key
right,
so
so
so
so
that's
a
reason
to
to
discuss
the
cut
and
contrast
this
protocol
to
another
one.
But
the
OAuth
protocol
doesn't
have
the
voucher
mechanism
and
the
voucher
mechanism
I
think
would
I
would
like
it
to
be
essentially
look
you
know
fit
into
this
this
basis
profile.
So,
okay,.
A
W
A
W
A
Challenge
there
is
that
we,
so
we
somehow
had
this
isolated
presentation
about
the
now
today
and
if
people
want
to
make
an
a
decision
about,
they
can
decide
whether
they
want
to
have
one
or
my
Giroux
are
standardized
yeah.
That's
that's,
probably
fair,
but
they
cannot
pick
among
all
them
because
they
haven't
seen
all
of
them
right.
I
A
I
should
get
on
in
I,
wrote
down
these
couple
of
questions,
and,
and
maybe
I
can
sort
of
ask
for
your
feedback.
I
believe
what
I
want
to
hear
is
that
for
certificate
management,
whether
you
believe
that
this
is
the
right
group
ace
is
the
right
group
to
do
that
type
of
work
or
not
like
over
co-op
or
what
idealist
Baba,
co-op
and
son.
A
F
Think
so
maybe
we
should
take
that
discussion
exactly
so
I,
it's
hard
in
a
few
words
to
say,
but
essentially
it's
est
on
application.
So
it's
the
analog
of
is
the
own
application,
but
are
you
modifying
ESD?
Well
now
it's
not
in
any
other
way.
Then
we
move
it
to
application
it.
So
we're
doing
that
there
is
a
handshake.
Est
is
already
at
the
application
layer.
Well
est
is
on
transport.
Oh,
it's
TLS
I
mean
you're,
protecting
est
with
transport.
F
The
rationale
for
TLS
is
that
you
have
an
existing
TLS
implementation
and
you'd
like
to
reuse
for
enrollment
and
the
ration
now.
Therefore,
what
what
what
is
called
eels
or
Els
is
that
you
have
an
existing
application
layer,
security
and
you
want
to
do
enrollment
so
it'sit's,
the
analog
on
application
layer
which,
which
is
suitable
for
certain
applications,
maybe
not
throw
up
Sean.
A
Is
that
a
new
certificate
management
protocol,
or
is
it
chest
or
not,
wrapping
new
wrapper
so
is
so
maybe
maybe
I
should
phrase
it
differently.
So
easter,
is
this
the
right
group
to
define
a
new
wrapper
for
ESD
or
nothing
ESD,
but
for
certificate
management
protocols?
Maybe
there's
some
other
people
who
want
other
protocols
than
ESD?
Is
this.
X
Okay,
this
is
this:
is
Dave
Robin
I'll
go
ahead
and
ask
my
question,
even
though
I
was
in
private
negotiations
with
Karsten
back
here
as
to
whether
I
should
I
was
what
I'm
going
to
state
is
that
it
seems
to
me
as
an
observer
of
these
groups,
that
cor
created
a
Co
FS
it
went,
it
did
not
stop
at
compressed
HTTP.
You
could
have
said
the
coop.
You
know
the
mission
of
coop
was
just
we're
going
to
find
compressed.
X
Http
know
it
kind
of
out
stepped
its
bounds,
I
think
and
invented
Co
FS
and
talked
about
algorithms.
You
know
curves
that
talked
about
certificates.
Rpk
created
the
certain.
You
know
the
the
keying
material
of
coop
s.
So
why
is
this
discussion
of
certificates
and
establishment
not
over
there?
Because
to
me
this
working
group
is
authentication.
This
would
be
like
going
to
the
OAuth
working
group
and
saying
hey.
Let's
talk
about
certificate
management,
you're
going
whoa,
whoa
whoa,
no
cert!
That's
you
know,
that's
somebody
else.
We
are
about
authenticate
off
authorization.
X
A
X
It
looks
like
a
certificate.
I
know,
I'm
saying
this,
so
the
risk
here
is
that
this
becomes
the
everything
security
working
group
and
we
already
defined
the
the
certificate
aspect
of
it
over
in
coop
s
over
in
core.
So
it's
just
a
suggestion.
It
could
be
done
there
if
we're
worried
about
workloads-
and
maybe
core
has
nothing
to
do.
G
G
A
F
A
Yep,
okay,
so
as
two
questions
I
would
like
to
know
on
hum
how
many
of
you
are
interested
in
doing
this
proposal.
That
is
the
over
coop
in
this
group,
and
the
other
question
is,
if
you,
if
you're,
not
interested
okay
so
hum.
If
you
are
interested
in
doing
the
proposal
that
Peter
presented
in
this
group
hum
na
and
hum,
if
you
are
not
interested
in
doing
this
proposal
in
this
group,.
E
A
A
Okay,
so
the
next
presentation
is
since
about
the
multicast
groups.
O
So
why
have
been
doing
this
and
why
here?
Well
we
have
another
draft
running
in
core
describing
how
to
use
on
scoping
multicast
group
communication
context
and
of
course
you
have
the
problem
of
authorizing
and
actually
enforcing
the
join
of
new
members
to
the
group.
We
are
proposing
a
way
to
do
that
using
the
ACE
framework
and
its
profiles,
keeping
the
approaches
such
oblivious,
the
specific
profile
of
a
besides
use.
O
This
document
focuses
on
three
specific
things
so
authorizing
a
node
to
join
the
group
through
a
responsible
group
manager,
after
the
authorization
of
the
authorization
server
establishing
a
secure
channel
between
the
joining
node
and
the
group
manager
responsible
for
the
group
and
then
performing
the
actual
join
process
so
practically
providing
joining,
not
with
a
key
material
needed
to
communicate
within
the
group
period.
On
the
other
hand,
this
document
does
not
cover
an
authorization
process
aimed
at
authorizing
access
to
protected
resources
at
group
members
or
the
actual
secure
communication
takes
place
within.
D
D
O
D
O
Have
north
acting
as
multi
casters,
so
sending
out
a
multicast
messages
addressed
to
other
listeners
in
the
group
that
can
in
turn,
reply
back
with
a
unicast,
fine
responses
and
we
guarantee
also
source
authentication
of
messages
within
the
grouping
to
the
multicast
requests
by
using
a
symmetric
cryptography
essentially
in
appendix
sections.
We
also
define
alternative
modes
like
switching
this
solution
to
a
pure
symmetric
one.
So
don't
worry,
I
need
to
represent
occasionally
and
also
further
mode
where
source
authentication
through
signatures
is
kept,
but
messages
are
unencrypted
instead,.
O
So
yeah
a
group
is
managed
by
a
special
entity
called
group
manager.
That
is
not
necessarily
an
actual
group
member
as
such,
and
can
be
responsible
for
managing
multiple
multiple
groups
at
the
same
time
practically
takes
care
of
the
joining
of
new
members
in
the
group
and
of
the
renewal
of
the
key
material
in
the
group.
It
especially
drives
the
join
process
for
new
members
intending
to
join
the
group.
O
So
it's
the
main
contact
point
for
joining
nodes
to
join
the
group
and
to
enforce
the
actual
admission
in
the
group
I'm,
providing
a
key
material,
meaning
annisquam
security
context.
The
group
manager
can
optionally
also
be
configured
as
a
repository
of
public
keys
of
group
members.
In
that
case,
that
implies
some
additional
actions
during
the
actual
joint
process.
O
While
the
group
manager
is
the
resource
server
exporting
one
join
resource
per
group,
it
is
managing
and
then
the
improvisation
server
responsible
to
enforce,
join
policies
on
behalf
of
the
group
manager,
essentially
so
issuing
practically
the
joining
node
an
access
token
to
access
the
correct
during
resource
or
jumper
sources
at
the
group
manager,
corresponding
to
the
groups
that
that
joining
on
wants
to
join,
and
in
order
to
do
that.
Well,
the
authorization
server
and
the
joining
node
they
can
rely
on
on
whatever
specific
profile
arrays.
They
want.
E
O
The
joining
process
as
such,
well,
the
joining
of,
is
supposed
to
issue
a
co-op
request
to
the
group
manager
separately
per
group
that
it
wants
to
join
and
since
the
access
has
been
authorized
in
the
first
place.
Thanks
to
the
access
token,
then
the
group
manager
is
supposed
to
provide
the
journey
not
with
some
material
to
properly
and
role
the
node
as
a
group
member
meaning
no
scope
and
font
ID
and
key
material,
so
practically
no
scope,
security,
common
context.
As
I
said,
the
group
manager
can
also
act
as
a
repository
of
public
keys.
O
X
Question
Dave
Robin
you
that
one
little
last
thing
you
threw
in
there
had
me
thrown
says
the
AAS
can
or
the
group
manager
can
also
provide
the
public
keys
of
the
members
to
a
subscribing
member.
There
could
be
thousands
I
really
hope,
that's
not
necessary
for
group.
It's.
X
F
So
one
application
I
was
thinking
of
is,
if
you
have
a
a
multicast
setting
with
a
number
of
listeners
and
only
few
listeners
respond
and
then
the
new
listener
is
joining
the
group,
but
the
broadcaster
doesn't
have
the
public
key
of
of
that
particular
listener.
So
you
will
be
able
to
look
up
that
particular
company.
Oh
did
I
misunderstand
the
question:
what's
the
question
about
how
to
when
you
want
to
acquire
a
particular
public
key
or
a
particular
node.
X
The
question
is,
if
I'm
part
of
a
group
and
I'm
sending
to
the
group
I
don't
want
I
and
the
the
group
manager
has
given
me
keying
material
that
I
use
to
validate
that
I'm.
A
member
of
the
group
I
send
with
that
keying
material
to
prove
that
I'm,
a
member
of
the
group
and
everybody
in
the
group,
hears
it
and
listens
to
me.
Why
would
I
want
to
know
the
identity
of
any
other
member.
F
If
you
want
to
verify
response,
as
coming
specifically
from
that
that
particular
note
I
mean
either
you're
happy
with
the
symmetric
key
shared,
so
you
don't
really
know
exactly
from
which
note
you've
got
the
response,
which
is
one
use
case
or
you're,
not
happy
with
that
that
you
want
to
know
exactly
from
which
node
you
got
the
response,
and
then
you
would
need
the
public
key
of
that
note.
I.
O
G
Think
the
important
point
years
to
start
talking
about
members
of
a
group,
there
are
receivers
in
a
group
the
ones
authorized
to
read,
and
there
are
senders
in
a
group
that
one's
authorized
to
write
in
and
for
the
letters
for
the
letter
you
usually
want
to
have
source
authentication,
but
sometimes
group
authentication
is
also
appropriate,
but
not
all
receivers
in
the
group.
We
need
the
sender
group
of
education.
If
you
go,
have
robust
making.
A
Y
Y
Y
Y
So
client
credentials
are
often
suit
suitable
for
constraining
environment.
Yes,
because
what
I
said,
it's
a
provision
as
an
administrative
task
and
not
on
a
user
base
to
set
up
a
set
of
devices
and
connect
them,
and
they
will
act
on
their
own,
like
sensors
or
door
openers
and
so
on,
and
you
authorize
and
the
specific
device
and
not
all
all
ways
that
you
authorize
based
on
a
user
next
slide.
Y
And
final
I
think
we
do
need
these
new
client
credentials,
because
the
client
credentials
defined
by
off
to
the
dahle
framework
is
more
or
less
the
username
and
password
the
declined,
ID
and
giant
secret.
So
it
requires
the
transport
layer
to
be
secure
with
constrain
devices.
We
can't
rely
on
always
having
a
server
authenticated,
TLS
connection
and
therefore
it
makes
sense,
running
DTLS
and
so
on
and
using
keys
that
identifies
the
client
and
the
server
directly
and
also
having
the
client
authentication
on
transport
layer.
So
next
slide.
Y
So
this
draft
defines
two
new
client
credential
types,
raw
public
key
using
the
handshake,
as
defined
in
RFC
7250,
the
using
raw
public
key
transport
layer,
security
and
data
layer,
transport
layer
security.
Here
we
also
suggest
a
way,
according
on
how
to
encode
the
raw
public
key
into
a
client
ID.
Since
it's
not
obvious
how
to
transfer
the
client
ID
over
in
the
handshake
before
the
authentication
is
actually
done.
So
then
it
might,
you
might
have
to
derive
the
client
ID
to
look
up
the
the
public
key
on
the
server
side
for
pre
shared
key.
Y
We
define
it
with
the
PSK
identified
to
be
used
to
send
the
client
ID
so
that
the
authorization
server
can
find
the
appropriate
pre
shared
key
to
use
for
this
setup.
So
as
a
difference
from
the
the
profiles
that
has
been
discussed
so
far,
this
draft
is
only
addressing
the
communication
between
the
client
and
authorization
service
when
it
requests
tokens
next
slide.
Y
So
we
don't
define
how
to
use
the
this
key
for
when
doing
resource
requests.
The
reason
for
that
is,
for
example,
the
the
DTLS
profile
of
the
ACE
framework.
Does
that,
and
also
with
transport
layers
being
very
diverse.
For
example,
we
have,
in
the
connection
between
resource
server,
routing
quiet,
client
and
resource
server.
We
need
to
exclude
that
to
make
in
this
draft
very
simple
next
slide.
Y
Y
Y
And
then
the
MPLS
draft
that
defines
new
client
credentials
for
x.509
certificates.
Doing
it
a
bit
annoying
in
hindsight,
seeing
the
x.509
certificates
used
quite
a
lot
in
the
wild
I
think
it
makes
sense
to
define
for
role
public
key
and
pre
shared
key
now
directly
and
it's
slightly
wider
sculpt
and
the
dis
dropped.
I
think
that
was
the
last
slide
it
could
be
interesting
is
to
ask
the
question:
does
this
fit
into
the
ace
workgroup
I
think
so,
since
it
very
much
complements
the
profiles
and
also
D
framework?
Y
However,
it
is
pure
client
credentials
and
it
doesn't
refer
to
any
other
ace
document,
so
it
could
just
as
well
be
moved
it
to
the
off
word.
I
was
working
with
and
then
I
would
like
to
just
ask
for
feedback
I've
gotten
some
questions
and
comments
on
it,
but
it
would
be
awesome
to
get
some
more
comments
on
it,
create
a
new
version
and
then
maybe
later
on.
Ask
if
this
makes
sense
for
adoption.
F
F
Y
F
So
I
don't
have
an
opinion
about
what
is
the?
What
working
group
is
best
I.
Think
case
is
fine
for
this
work.
I
just
had
one
question
about
what
protocol
to
use
between
the
client
and
a
s
is
that
or
between
the
RS
and
a
s?
Is
that
defined
in
this
or
could?
Could
it
be
any
type
of
protocol
using
Republic
keys
to
communicate.
B
Hello
Samuel
Mike,
Jones,
Microsoft,
well
I
asked
my
question
about
this
draft
I'm
gonna
take
advantage
of
the
fact
that
you're
with
me
right
now
to
say
Jim
shod,
said
that
there's
still
a
problem
with
the
C
Bar
web
token
encryption
example
and
I'm.
D
B
There's
three
other
drafts
about
client
assertions
or
about
client
authentication
using
assertions.
One
is
RFC
75
21,
which
defines
how
to
use
a
signed
assertion
in
general
for
client
authentication,
75
22
is
how
to
do
it.
If
the
assertion
is
a
sam'l
token
and
75
23
is
how
to
do
it.
If
it's
a
job-
and
you
could
use
this
and
have
the
key
be
in
the
signed
assertion
and
then
there's
already
a
defined
number
for
how
to
do
that.
I'm
not
asking
you
to
discuss
it
now,
but
you
should
at
least
read
the
read
75215.
A
I
So
just
to
wrap
up,
this
is
Kathleen
rarity
ad,
so
Hannes
and
I
just
chatted
wiki
will
get
set
up
and
I
think
if
folks
are
able
to
discuss
on
the
wiki
and
enumerate
the
reasons
for
the
different
types
of
profiles.
That
would
be
very
useful.
I
think
that
so
I
personally
think
that
would
be
a
much
easier
jumpstart
to
getting
to
a
prioritization
list
than
trying
to
get
a
hold
document
together
and
a
wick.
I
You
will
allow
more
people
to
jump
in,
hopefully
other
than
just
the
you
know
the
usual
character,
so
I'd
love
to
you
know,
see
contributions
from
others.
You
know
what
why
you
might
like
different
profiles,
and
so
we
can
figure
out
how
we
prioritize
them.
One
has
been
adopted.
How
do
we
figure
out
how
to
adopt
more?
So
this
could
result
in
an
overview
document
later.