►
From YouTube: ACE WG Interim Meeting, 2020-04-15
Description
ACE WG Interim Meeting, 2020-04-15
A
B
A
A
C
C
A
E
You're
you're
you're
you're
right
because
of
the
ring
because
of
the
because
also
because
of
the
YouTube
Content
ID
every
day
astronaut
has
a
really
nice
theme
that
he
uses
that
he
got
composed
in
the
public
domain.
It's
very
cool.
Have
you
ever
never
watched
it?
It's
really
easy
awesome
right.
So
we
have
an
Elena
and
Francesca
Paolo
Eenie
coincidence.
A
F
A
D
E
Basically,
probably
means
that
your
audio
and
on
Linux
it
means
that
your
audio
subsystem
has
restarted
for
some
reason
and
other
pieces
haven't
reconnected
or
something
like
that
and
they're
all
supposed
to
reconnect
automatically.
But
that's
what
can
happen,
or
sometimes
you
just
have
to
restart
everything
which,
for
some
people
just
means
they
reboot,
but
yeah.
It
only
happened.
You
like
after
I've,
been
like
after.
If
my
desktop
has
been
you
know
up
for
200
some
days,
then
sometimes
it
gets
weird
like
that.
Yeah.
A
E
A
E
A
F
A
E
Every
other
row
yeah,
but
it's
it's
it's
and
that's
the
right
way.
If
people
don't
have
suitcases
that
they
want
to
put
in
the
overhead
and
it's
the
overhead,
it's
the
stopping
to
put
crap
in
the
overhead
that
causes
people
to
bang
up
the
plane.
And
so
so
it
turns
out.
You
want
the
the
overhead
somewhat
at
a
simulation
and
they
said
the
best
way
is.
G
Here
is
the
note:
well
I'm
sure
it's
not
the
first
time,
you're
reading,
those
and
well
aware
of
those
so
Jim
is
doing
the
at
the
pad
editor
for
the
queue
management.
We
have
this
minus
Q
plus
Q,
so
we
usually
use
the
WebEx
chat
too
and
you
you
write
a
plus
Q
if
you
want
to
be
in
online
and
you
write
a
minus
Q
if
you
want
to
retrieve
yourself
from
the
line,
but
given
the
number
of
participants
for
that
meeting,
we
may
consider
I
mean
a
discussion
as
a
regular
conversation.
G
B
We
we
talked
about
this
during
an
interim
we
solved
almost
since
Bonnie's
here
that
I,
let's
make
the
point,
so
we
answered
almost
all
of
his
review
comments.
There
was
one
point
point
left
the
gym
volunteer
to
to
propose
some
text
and
there
has
been
no
progress
there.
So
we
are
a
version,
10
and
normally
version.
11
would
be
all
Ben's
comments
addressed
so
I'm,
just
waiting
where
that
proposal
text
or
if
I,
should
try
to
write
something
myself.
Just
let
me
know
generally.
C
I
Have
been
talking
to
Jim
and
we
decided
that
we
don't
really
have
things
to
discuss
here,
so
I
refrained
from
presenting
slides
the
status.
Basically,
is
that
that
I
and
or
tried
to
answer
we
have
offered
try
to
answer
all
the
questions
that
been
head
and
put
then
them
into
the
editors
copy
before
sending
a
new
internet
draft.
G
C
J
G
G
G
F
F
So
version
for
addressed
many
of
the
issues
that
have
been
raised
in
the
previous
review
round.
There
is
a
github
issue
list.
There
I
highlighted
two
which
basically
added
more
text
than
the
others.
The
others
were
quickly
addressable
and
based
on
the
interim
decisions,
so
I
create
Laura
fide
the
format
of
the
AES
creation
hints
in
the
connect.
F
This
is
supporting
the
AES
discovery
for
the
mqtt
version,
five
clients
and
also
clarified
the
format
of
the
old
data,
so
that
it's
possible-
and
there
were
several
other
improvements
and
clarifications
based
on
James,
Daniel's
and
Hannah's
comments
in
the
past,
both
interim.
It
was
also
clarified
that
this
document
does
not
rely
on
the
earth
pop
key
distribution,
which
was
actually
stopped
working
on
and
Hannes.
Looking
at
their
parameters
draft
and
the
core
ace
draft
he
concluded,
we
can
do
pretty
much
everything
defined
in
his
previous
draft
for
the
HTTP
and
JSON
case
dot
case.
F
One
of
the
things
that
we
do
is
we
have
a
substantial
section
on
how
the
client,
authenticates
and
authorizes
to
the
resource
server
and
due
to
two
layers,
TLS
and
MQTT,
we've
kind
of
have
a
table
that
clarifies
what
is
acceptable
and
for
this
document
we've
recommended
the
option
of
TLS
anonymous
and,
with
the
token
authentication,
authorization
and
Jim
was
such
a
was
asking
whether
this
recommended
option
is
acceptable
to
everyone.
So
this
is.
This
is
one
thing
that
I
would
like
to
bring
to
the
discussion.
F
The
other
thing
is
that
we
do
not
like
the
core
document.
We
don't
accept
multiple
tokens
and
when,
in
the
fourth
case,
when
a
token
is
proved,
might
be
provided
for
the
TLS
handshake
as
well
as
a
token
in
the
connect
message
in
the
mqtt
case,
we
overwrite
the
previous
token
and
accept
the
latest
token
and
Daniel
was
asking
whether
we
should
really
prescribe
that
method
or
there
would
there
be
any
way
other
way
to
do
this.
So
these
are
the
two
questions
remaining
for
the
for
that
table
next
slide.
F
We
basically
went
with
the
eight
byte
eight
byte
nonce
is
provided
by
either
side
and
I
understand.
There
has
been
a
discussion
about
it
for
the
the
oscar
profile,
and
probably
all
that
will
apply
to
this
one
as
well.
One
of
the
questions
that
Jim
raised.
This
does
not
use
channel
binding,
should
it-
and
we
were.
F
We
I
remember
discussing
that,
given
that
the
value
that
you
get
from
the
TLS
exporters
to
be
the
same,
do
you
still
want
to
use
this
in
this
case
when
the
real
authentication
is
possible
and
I
think
this
is
one
thing
that
we
would
like
to
clarify
whether
we
use
channel
binding
in
the
challenge-response
case
as
well.
That's
the
third
question
that
I
would
like
to
bring
to
the
discussion
and
then
the
final
slide.
F
F
There
is
a
github
issue
about
how
well
we
support
any
version:
31
clients,
especially
with
version
5
servers,
and
we
basically
decided
in
the
github
issue-
and
this
is
one
of
the
things
that
I
would
like
to
add
to
the
new
version
of
the
draft-
is
that
the
newer
version,
5
servers,
support,
/
version,
5,
clients,
version,
3-1,
servers,
support
version,
3-1
clients
and
v5
server
support
for
me.
3-1
clients
is
only
for
the
first
part
where
it
accepts
username
password
based
overloading
to
transport.
The
token,
however,
for
additional
support
for
the
enhanced
error
messages.
E
I
F
That
was
that
was
the
case,
but
I
discussed
with
Jim
that
actually
any
of
the
options
I'm
ready
to
follow.
It's
just
that
it
was
good
to
present
a
recommended
option
that
there
is
a
recommended
option.
Clarified
though
I
don't
feel
too
strongly
for
either
case
I
thought
for
the
clients
that
do
not
want
to
do
the
old
set
info
that
they
need
to
pass.
The
token
before
the
unknown
ace
option
would
be
kind
of
a
good
recommendation.
F
G
G
G
F
Had
here
was
about,
if
we
are
in
the
over
authenticated
case,
where
a
token
has
been
provided
and
checked
and
validated
and
then
another
token
has
been
provided
by
the
connect
message
of
the
MQTT.
If
these
two
tokens
are
different,
of
course,
the
validation
has
been
done
for
both
of
them.
We
keep
the
last
one.
We
don't
do
merging
of
permissions
of
what
the
different
token
say
and
etc.
Is
this
an
acceptable
way
of
going.
G
G
F
That
could
be
that
we
wouldn't
be
able
to
stop
that
from
happening.
That's
why
I'm
saying
that
this
is
an
over
authenticated
case,
where
the
tokens
might
be
the
same
or
different.
In
any
case,
they
would
be
validated.
However,
we
over
wrote
the
one
that
is
provide.
You
know
we
take
the
one
that
is
provided
in
the
connect
as
the
final
and
do
not
try
to
see
whether
you
know
you'd
be
Parsa
token
for
this
client.
What
permissions
had
already
had?
Shall
we
merge
them
together?
We
don't
do
that.
I.
H
F
Think
if
the
client
ends
up
having
two
tokens
and
uses
the
older
one,
it
might
lead
to
not
being
able
to
authorize
a
client
that
was
authorized
in
the
TLS
layer.
If
you're
asking
that
yes,
but
then
the
client
will
be
given
that
authorization
error
and
will
figure
out
that
it
has
done
something
wrong.
F
The
class,
if
the
two
token
one
is
earlier-
and
none
of
them
have
expired,
but
has
the
older
token
has
a
reduced
set
of
permission,
sets
and
the
client
might
end
up
being
operating
in
a
reduced
set
of
permissions,
and
then
again
it
will
discover
that
by
trying
to
publish
to
or
subscribe
to
some
topics
and
being
rejected
and
discover
it
again
as
an
authorization
error
and
we'll
have
to
figure
something
about
it
again.
Okay,.
H
Yes,
and
maybe
that's
something,
I
mean
this
relates
to
something,
but
it's
just
before
about
order
of
whether
you
need
be
able
to
understand
what
is
the
earth?
What
is
the
earliest?
What
is
the
latest
token
I
just
wondered
it
from
this
particular
procedure
that
how
do
you
acquire
the
tokens?
Could
that
could
it
be
that
you
acquire
the
token
that
you
would
use
to
connect
before
you
acquire
that
used
with
Els,
or
is
that
at
least
that
in
the
right
order.
A
A
F
Student,
sir,
we
just
say
in
the
document
that
it
shouldn't
do
that
it
shouldn't
try
to
do
the
last
version
that
last
option.
It
is
there
for
completeness,
but
we
do
not
actually
recommend
that
option
to
be
to
be
selected.
It's
it's
kind
of
over
authenticating.
It's
in
the
case
of
the
same
token,
it's
like
you're
pushing
the
token
in
two
different
layers
in
terms
of
different
tokens.
That's
the
part
where
I
want
it
to
be
more
careful
and
that's
why
I
said
whatever
you
do.
F
I'll
accept
the
token
the
last
I
have
here,
which
is
the
resource
server.
We'll
get
the
token
at
the
connect
MQTT
later
then,
of
course,
the
TLS
handshake.
So
it
will
just
stick
to
what
it
knows
latest
from
the
client.
That's
what
I
thought
and
if
client
misused
its
tokens
or
did
a
behavior
that
kind
of
reduced
its
set
of
actions,
then
it
will
be
reminded
of
that
by
authorization,
errors.
C
G
G
F
The
content
or
the
secrets
to
do
the
pop
over
it
and
that's
we
decided
on
the
size
of
the
exporter
and
we
decided
on
the
label
of
the
exporter,
so
I
just
wanted
to
make
sure
that
everybody
knows
that
that's
been
updated
in
the
last
interim.
However,
what
I
wanted
to
say
is
that
when
you
want
to
real
tentacle
in
this
version,
I
assume
I
understand
this
correctly,
that
the
value
you
get
from
the
TLS
exporter
with
the
same
label
will
be
the
same.
F
B
C
F
That's
what
I
would
I
was
so
that
doing
the
pop
would
make
no
sense,
because
it
will
be
the
same.
Well,
you
derived
from
the
tls
exporter.
That's
how
I
understand
so
I
thought
I
should
be
clear
that
my
authentication
should
not
be
supported
if
Lyon
connects
with
token
in
the
connect
message.
This
way
by
already
having
computed
a
pop,
whereas
in
the
second
version
we
have
a
challenge
response
scheme
where
the
broker
provides
a
challenge,
Klein
adds
its
own
nonce
and
then
what
Jim
was
suggesting.
F
We
can
still
do
channel
binding
and
add
the
TLS
exporter
to
here,
as
well
than
in
the
real
authentication.
At
least
there
are
estimates
and
the
current
notes
would
be
different,
even
though
we
get
the
same
TLS
export
value.
And
then
the
question
is:
is
there
any
value
of
adding
US
exporter
here
doing
channel
binding
here
I.
C
F
G
F
F
C
E
G
F
F
K
F
C
G
D
J
F
Ok,
this
was
referring
to
how
interoperable
we
are
in
terms
of
supporting
older
clients.
That
is
me
3,
1
1,
and
at
the
moment,
what
we
described
is
that
we
5
servers
can
also
implement
the
authentication
method
supported
or
that
can
be
used
by
v3
1
1,
which
is
basically
overloading
the
username
password
fields
to
pass
the
token
to
the
resource,
server
or
the
broker,
and
they
could
support
this.
F
But
then
v5
does
more
in
terms
of
returning
error
messages
that
do
not
exist
in
v3,
1,
1
and
Jim
was
rightfully
pointing
out
that
some
of
the
clients
may
might
be
just
dropping
those
messages
or
just
parsing
as
much
as
they
understand,
and
then
not
what
weathering
about
the
rest
or
silently.
These
things
might
be
right
and
not
communicated
to
the
client,
and
these
are
important
issues,
because
the
behavior
would
be
that,
for
instance,
for
a
publication
acknowledgement.
F
The
server
would
send
a
pub
back,
but
it
would
have
an
authorization
error.
The
v31
Klein
can
understand.
This
is
a
pub
AK
publication
acknowledgement,
not
realizing.
That
message
is
not
relayed
to
the
clients
that
are
subscribing
to
that
topic,
so
it
will
be
like
a
silent
drop
of
message
at
the
broker
side
and
we
kind
of
think
that
the
language
around
how
much
interoperability
supported
should
be
strengthened.
So
that's
if
I'm,
if
I
interpreted
our
discussion
correctly,
Jim.
A
F
Again,
the
security
is
not
if
in
this,
in
a
sense
that,
if
you're
not
authorized,
your
messages
are
not
relayed.
It's
just
that
the
clients
will
have
a
confusing
period,
thinking
that
their
messages
are
going
through
and
they're,
not
for
instance,
if
they
are
not
supporting
the
enhanced
error
messages,
if
the
so
that's
why
we
were
clarifying
very
clearly
tell
us
your
aversion
through
one
client.
In
that
case
we
can
the
the
Version
three
one
servers
would
disconnect
these
clients
directly
abruptly.
F
A
F
F
C
C
F
A
C
C
F
F
I'm,
just
thinking
how
mqtt
is
approaching
this
and
in
the
specification
the
mqtt
specification,
they
basically
suggest
policy
suggestions.
Basically,
they
make
policy
suggestions
as
I
suggested
in
the
bullet
fee
and
he
doesn't
seem
like
they
were
going
towards
a
negotiation
phase
in
the
in
courtesy,
connect
message
regarding
I'm,
basically
saying
if
the
client
is
asking
to
long
expire,
ease
and
you're,
not
able
to
support
this
due
to
whatever
you
have
an
admin
policy
I'm
not
too
sure
there
will
be
a
protocol
answer
to
this.
Okay.
A
F
F
F
F
B
F
A
B
B
These
are
the
subjects,
so
you
can
go
and
see.
Some
of
these
are
quite
old,
but
we
haven't
forgotten
about
them.
We
just
haven't
had
the
time
to
to
discuss
yet-
and
there
is
some
couple
of
open
points
to
check
from
a
previous
review
which
might
be
outdated,
but
we
never
never
really
checked
so
so
this
will
be
included
in
the
version
7
next
slide.
B
So
since
ITF
106
there
was
two
versions
that
were
submitted,
one
on
January
15th
that
closed
most
points
from
ITF
106.
Then
we
got
a
review
from
Jim.
Thank
you
very
much
for
that,
and
we
presented
and
discussed
that
during
the
two
interims
in
January
and
February,
and
then
before
the
submission
cutoff,
we
submit
the
version
5
and
that
was
based
on
the
previous
review
and
we
already
got
another
review
from
Jim
which
we
and
translated
into
github
issues.
B
This
does
not
address
your
comment
and
if,
if
we
don't
see
any
anything
happening
after
some
days,
we
will
close
it
ongoing
means
I'm
working
on
it
at
that
very
time,
so
I'm
planning
on
getting
the
editor
damn
label
soon.
Then
question
if
I
need
more
information.
I,
don't
understand
this
issue.
Pr
was
just
to
label
the
issues
that
I
was
going
to
include
or
are
included
in
this
PR.
B
So
right
now
the
status
is
they're,
not
sorry.
33
open
issues
51
were
closed
from
before
there
is
actually
off
these
33
27
or
editor
done
so
I
think
that
they
should
be
closed.
But
let's,
let's
see
if
there
is
anything
that
you
don't
think.
So
there
are
three
open
and
three
questions
next
slide.
Please.
B
So
we
also
got
some
some
okay,
so
this
is
the
update
that
is
already
included,
but
that
we
wanted
to
discuss
because
we
think
deserves
discussion.
So
this
is
the
from
the
scope
question
from
Jim
or
how
we
are
dealing
with
multi
scope
tokens.
So
the
goal
was
to
have
one
access.
Token
cover
multiple
groups
at
once,
so
there
is
only
one
token
post
for
several
groups.
B
The
access
token
response
will
include
this
sign
info,
our
meter,
which
is
an
array
of
sign
info.
So
this
sign
in
fluently
includes
information
about
what
signing
algorithm
and
parameters
are
to
be
used
in
that
group.
So
before
we
had
just
this,
when
we
had
just
one
token
per
group,
then
we
had
only
one
of
the
signing
for
parameter.
Now
we
have
an
array
of
them
and
also
for
the
scope.
We
have
an
array
of
scopes
what
we
had
before
for
scope.
B
So
there
was
a
group
identifier
and
roles,
so
an
old
can
join
several
groups
if
they
use
the
same
public,
key
encoding
and
signing
algorithm,
and
that
would
be
done
with
one
token
post,
followed
by
several
joining
exchanges.
So
if
you
just
go
quickly
to
the
next
slide,
we'll
have
to
go
back,
but
so
this
is
what
what
will
happen.
B
A
client
would
send
this
token
post
to
the
KDC
for
two
groups,
and
you
would
get
one
response
with
the
token
and
it
would
use
this
token
twice
at
the
same
KDC
to
join
two
different
groups.
You
can
go
back
one
slide,
so
there
is
something
that
is
more
worrying.
Is
that
the
same
so
we
we
have
this
KDC
nonce
that
is
used
as
an
input
one
of
the
input.
B
There
is
also
a
client
nonce,
two
dissonant
signature
for
the
client
to
prove
procession
of
its
private
key,
and
if
we
do
it,
this
way
that
the
same
KDC
nonce
is
used
to
join.
Each
different
group
also
wanted
to
note
that
the
S
key
bukhoma
score
does
it
differently.
So
the
KDC
notes
in
that
case
is
used
only
once
and
then
it
base
the
next
nonsense
on
the
existing
security
association
between
the
client
and
the
KDC.
B
A
C
C
B
Is
not
right
now,
that's
correct,
it
could
be,
but
I
mean
the
signatures,
so
we
say
that
the
client,
so
this
signature
is
computed
over
these
KT
Sinan's
and
also
a
client
nonce.
So
the
client
must
generate
different
knowns
where
it's
choice,
so
the
signature
will
be
different
as
a
consequence,
but
the
problem
is
that
we
are
still
generating
these
kisi
nonce
and
then
we
are
using
it
several
times
as
one
of
the
inputs
of
the
signature.
C
L
B
G
G
L
B
B
So
this
was
Jim's
proposal
on
legal
requests,
or
so
that
was
the
subject
of
the
mail.
So
the
goal
was
that
the
role
is
to
be
propagated,
along
with
the
signature
public
key
for
each
node
from
the
KDC
to
the
server
during
the
joining
process-
and
this
was
just
so
that
a
client,
a
client,
a
client
joining
the
group
can
get
the
information
of
what
each
node
of
the
key
is
supposed
to
have
us
role.
B
So
in
this
case,
what
we
did
to
solve
this
was
to
add
this
peer
roles
parameter
so
before
we
have
up
keys
parameters.
So
this
this
is
all
sent
from
the
KDC
to
the
joining
node
and
before
the
joining
node
was
getting
only
the
keys,
and
now
we
have
added
this
parameter
where
it
also
gets
list
of
roles.
B
B
B
B
So
when
a
new,
when
an
old
post,
a
new
public
key
to
the
KDC-
and
if
this
applies
to
everything,
I
am
Not
sure
that
this
adds
a
lot,
because
the
joining
and
the
public
key
processes
are
quite
orthogonal
and
I.
I
mean
I
think
that
these
considerations
are
correct,
but
I
am
Not
sure
that
these
adds
a
lot
in
terms
of
it
helps
with
clarifying
or
it
covers
things
that
are
not
already
covered
in
document.
B
A
Okay,
so
what
I
was
thinking
was
that
you
could
associate
the
public
key
with
the
token,
as
opposed
to
associating
the
public
key
with
the
join,
and
that
means
that
the
first
join
on
that
not
a
single
token.
You
had
to
present
the
public
key
and
do
the
proof
of
possession
on
the
second
join.
With
the
same
token,
one
could
presume
that
the
same
he
was
being
used
and
he
would
therefore
not
have
to
do
the
pop
on
it.
B
B
Do
you
say
requirements
on
when
you
have
to
you
when
you
must
send,
but
we
say
that
it
must
be
sent
and
for
the
next
joining
I
think
that
we
might
need
to
add
that
you're
right,
we
might
need
to
add
more
consideration
about
the
key,
might
be
omitted
or
possession
might
be
omitted,
etc
with
that,
is
that
what
you
were
aiming
for?
Yes,.
B
A
A
B
Issue
83
section,
so
this
section
was
the
post
to
public
key
group
routine.
If
a
public
key
is
replaced
and
your
comment,
Jim
was
if
a
public
is
replaced,
does
this
constitute
the
reason
that
the
key
rollover
is
going
to
be
required
and
the
answer
I
wrote?
The
answer
is
not
necessarily,
but
nothing
stops
the
KDC
to
do
a
key
role
over.
If
you
want
I
think
they
should
already
be
clear,
and
if
not,
can
you
help
me
out
what
is
missing.
A
B
B
G
G
G
B
This
is
not
something
that
we
really
thought
about.
I
mean
we
thought
about
the
when
the
client
would
sign
with
public
key
too,
and
then
the
other
nodes
would
get
the
message
and
realize.
Okay,
I
need
to
fetch
the
new
or
yeah
we
sign
with
you
with
key
to
and
then
the
other
notes
would
have
to
fetch
the
public
key
too
I.
B
A
A
C
B
B
B
L
B
B
B
So
Jim
again,
these
need
to
be
explained
a
bit
more
I
copy
pasted
the
first
paragraph.
It's
just
that
one
sentence
there
when
a
client
receives
a
message
from
a
sender
for
the
first
time
he
needs
to
have
a
mechanism
in
place
to
avoid
replay,
for
example,
Appendix,
B
2
of
a
score
and
you're
saying
this
needs
to
be
explained
a
bit
more.
B
So
the
question
we
have
is:
is
this:
what
you'd
like
to
see
in
this
more
mechanism
like
Appendix,
B
2,
is
useful
in
case
of
lost
context
and
reboot,
so
that
the
recipient
can
be
on
the
safe
side
and
and
if
the
group
is
rekeying
the
time
window
between
the
end
of
the
wreaking
and
the
next
loss
of
context
is
safe
to
go.
It's
this.
That's
discover
what
you
wanted.
A
B
B
B
B
B
D
B
B
Also,
like
this
combination
of
roles,
so
this
is
because
the
oscar
profiles,
for
example,
specifies
combination
of
so,
if
you
know
this
requester
and
responder,
you
can
indicate
this
by
saying
this
is
an
array
with
requester
in
a
string
call
my
responder
in
the
next
thing,
and
this
this
is
one
role,
but
if
a
different
profile
say
MQTT
or
something
else
wants
to
define
the
combined
role
as
without
using
seaboard
as
one
element
with
like
a
one
string
with
a
plus
in
the
middle,
or
something
like
that.
That's
also
fine.
B
A
B
B
A
D
B
Issue,
ninety
and
MIT
encoding
in
Jason-
and
this
was
your
comment
again
Jim
in
terms
of
the
name,
what
about
doing
the
encoding
in
Jason?
So
are
you
talking
about
registering
faith
group
comm
last
Jason
or
Matt's
work
on
I
media
type?
Yes,
and
also
all
at
that
point,
all
the
ACE
Group
parameters
will
have
to
also
be
defined
for
a
Jason,
because
now
they
only
are
defined
for
C
poor.
Yes,.
D
K
D
D
A
B
That
that
was
for
ace,
though,
and
this
part
where
we
define
new
parameters,
is
for
the
two
message
exchange
that
happen
after
after
the
ACE
exchange.
I
do
agree
that
I
mean
to
make
it
consistent
with
the
first
part
we
base.
It
will
make
sense
to
say
if
you're,
using
Reebok,
if
using
C
borer
and
if
you're,
using
Jason,
keep
using
Jason.
D
This
contamination
effect
well
just
because
some
part
of
the
system
is
handling
material
in
in
one
encoding.
You
suddenly
after
implement
it
everywhere
else,
because
that
stuff
might
be
leaking
over
over
to
your
side.
So
it's
really
expensive
to
do
this
kind
of
thing
and
I
would
prefer
not
to
create
choices
where
there's
no
need
for
what.
B
A
C
A
B
We
have
other
consideration
about
that
in
the
text
and
what
I
said
was
that
you
do
not
need
to
be
a
member
of
the
group,
so
you
don't
have
to
have
done
the
joint
process
to
actually
get
the
public
keys
from
the
table
key
resource.
As
long
as
you
are
authorized
by
das
to
get
access
to
the
public
key
resource,
you
can
get
the
public
keys
and
do
the
signature.
B
B
A
B
Yes,
I
slide
my
plan
that
was
yeah.
The
plan
forward
was
to
get
okay
for
all
of
the
editor
done.
Issues
include
issues
above,
as
we
said,
merge
the
PR,
submit
versions,
your
six
and
then,
after
that
we
work
on
the
rest
of
the
points
that
were
in
the
previous
slide
and
if
we
could
have
an
interim
about
this
just
to
speed
up
the
process,
that
would
be
great
and
then
submit
version,
zero,
seven
and
unless
Jim
comes
up
with
another,
very
extensive
review.
K
L
L
Just
a
quick
recap:
this
is
about
a
client
asking
for
an
access
token
to
an
authorization
server
to
be
posted
to
an
Oscar
group
manager
acting
as
resource
server
to
get
into
an
Oscar
group
and
get
back
the
king
material
to
communicate
with
group
ascore
in
that
group
building
on
whatever
compatible
transport
security
profile
race.
What
is
out
of
scope
of
this
document
is
the
I
usage
of
group
was
calling
the
group
to
communicate
and
the
access
control
inside
the
group
among
group
members.
That's
another
document
next
slide.
Please.
L
So,
since
Singapore
we
had
two
versions
submitted
and
each
language
discussed
the
entering
we
had
in
January
or
in
February.
We
got
reviews
and
comments,
especially
from
Jim,
thanks
us
for
them,
and
thinking
of
the
latest
review,
especially
we
addressed
most
of
it.
In
the
current
text
we
have
in
the
editors
copy
on
get
up.
There
are
a
few
open
points
left
for
which
I
have
some
slides
later
next
slide,
please,
and
to
quickly
summarize
the
the
biggest
updates
between
the
latest
interim
actually
and
today,
following
input
from
from
Bennett
Singapore.
L
Mostly,
we
had
the
security
considerations
related
to
the
analysis
exchange
between
find
the
server
for
the
sake
of
the
signature
process
and
to
build
the
signature
challenge.
So
we
discuss
especially
their
size
as
well
as
implication
of
possible
reuse
edge
in
case
of
device
reboot
and
the
fact
that
instant,
we
don't
really
incur
any
risk
of
replay,
because
after
all,
the
they
are
combined
for
a
challenge
that
is
sent
over
a
secure
channel.
A
channel
between
the
client
and
the
group
manager
also
is
much
less
critical
than
in
other
situations
like
the
Oscar
prophetess.
L
When
a
TLS
exporter
is
used
to
build
that
challenge
instead
at
later,
joins
among
a
client
and
group
manager
using
the
DTLS
profile,
also
lying
with
Peru
come,
and
we
are
also
considering
move
the
group
scope
all
covered
by
the
same
token,
possibly
with
different
roles,
and
in
this
particular
draft
we
are
adding
integer
abbreviations
for
the
different
roles
simply
to
save
some
bite
on
the
wire
next
slide.
Please.
L
Current
group
members
are
supposed
to
refrain
from
communicating
in
the
group.
Well,
actually,
no
new
members
can
can
join
until
the
group
becomes
active
again.
So
this
additional
sub
resources
in
three
and
it's
handlers
are
defined
next
slide.
Please
right!
This
is
instead
already
present
in
the
editors
copy
on
github.
Of
course,
we'll
need
your
confirmation
or
feedback
that
everything
is
okay.
We
tried.
L
Now
it's
just
possible
as
an
ace
and
following
a
comment
from
Jim,
especially
in
the
case
where
a
group
member
asks
to
be
individually,
Rick
he'd
in
particular
to
get
new
sender
ID.
We
are
admitting
the
possibility
for
the
group
manager
to
do
kind
of,
as
as
part
of
the
same
process,
both
an
individual
Rick
into
that
node,
as
requested
plus
and
an
overall
hero
luring
the
group
aligned
also
with
latest
things
of
SQL
comm.
L
L
Next
slide,
please
and
now,
I
have
a
few
upper
points
for
you.
The
ones
in
this
slide
relates
some
changes.
We
plan
in
the
group
of
score
document.
Actually,
as
we
discussed
last
week,
group
of
score
is
introducing
a
new
mother
operation,
the
pairwise
mode,
where
messages
sent
one-to-one
are
protected
with
pairwise
key
material
derived
by
the
two
particular
members
of
the
group,
and
this
is
a
number
of
side
effects
for
group
members
that
are
supposed
to
be
only
monitors
as
their
only
roles.
L
So
normally
they
are
not
supposed
to
ever
send
any
message,
so
they
don't
even
need
a
public
key
because
they
may
never
need
to
sign
anything.
But
in
order
to
support
that
mode,
when
even
those
group
members
will
need
to
have
a
public
key
so
that
they
need
to
post
one
to
the
group
manager
upon
joining,
and
they
also
have
practically
to
receive
a
sender
ID
used
as
identifiers
of
the
public
key
for
that
keys
received
trivial
for
other
group
members.
L
So
we
plan
to
slightly
extend
with
a
bit
more
details
the
joining
process
here
to
say
that,
even
if
presenting
itself
to
join
only
as
monitor
and
not
can
anyway
provide
a
public
key
to
the
group
manager
and
receive
a
sender
ID
in
return,
so
they
will
fully
enable
even
that
not
to
support
and
use
the
pairwise
model
group
post
call
and
of
course
this
is
in
turn
some
side
effects
on
the
text.
We
have
on
uploading,
retrieving
and
cashing
public
keys
of
the
group
manager.
A
side
point
this
please
Jim
can.
L
A
L
Okay,
we'll
think
of
that
thanks
for
feedback,
a
related
point
on
this
same
topic,
all
in
all,
is
we
think
of
having
an,
if
not
group
policy
registered
in
this
document.
Just
for
the
group
manager
to
signal
that
the
group
supports
the
pairwise
model
group
of
score
and
it
is
used
in
the
group.
Is
it.
A
L
L
That's
easy:
it's
just
this
document
registering
in
the
registry
created
in
in
SQL.
Come
all
right.
Thanks
next
slide,
please,
and
it
should
be
the
last
one
with
the
last
of
endpoints
yeah.
That's
something
that
Francesca
started
to
raise
in
the
previous
presentation.
It's
about
the
KDC
nouns
was
ours,
nouns
returned
by
the
group
manager
right
after
the
token
is
posted,
as
I
mentioned
before.
L
I
took
it
literally
in
this
context
and
think
of
these
values
to
be
used
once
only
by
the
client
and
group
manager,
meaning
exactly
in
the
drawer
request
immediately
following
the
token
post
to
build
the
signature
challenge
as
resource
server
share
than
any
following
joining
requests.
Just
rely
on
an
established,
secure
channel,
for
instance,
ridiculous
channel
and
during
the
document
we
are
describing
how
different
signature
challenges
are
supposed
to
be
derived,
for
instance,
with
a
TLS
exporter.