►
From YouTube: ACE WG Interim Meeting, 2020-06-22
Description
ACE WG Interim Meeting, 2020-06-22
A
I'm
gonna
check
if
the
h-town
works
and
works
pretty
well.
So
please
read
the
note
wells.
If
you
haven't
read
so
and
be
a
word
that
the
meeting
is
under
those
not
well
I
I
guess
everyone
is
familiar
with
those,
so
we
might
move
quickly
to
the
agenda.
So
we
need
a
jab
ascribe
a
minute
taker
and
if
you
haven't
shined
a
blue
sheet,
please
do
sign
it
I
in
the
chat,
the
link
to
the
Kadeem.
A
D
C
C
D
B
B
C
They're
still
an
idiot
valuation.
Sorry
I
guess
my
my
notes
were
bad.
So,
yes,
we
will
not
need
to
do
a
second
last
call.
We
don't
need
to
do
a
first
last,
call
you
and
then
DTLS
profile.
There
I
knew
that
I
have
not
looked
at
yet,
but
it
is
believed
to
address
all
of
my
review
comments
and
so
then
I
guess
we
could
do
the
ITF
last
call
for
the
two
profiles
together.
D
E
Either
and
have
not
the
time
to
read
up
so
that
I
can
understand
what
that
really
implies.
The
only
thing
I
noticed
and
and
Jim
confirmed,
that
is,
that
has
not
registered
any
well
known
identifiers
for
for
their
token
endpoints
and
for
the
authorization
endpoints
and
so
on,
and
that
gives
me
the
feeling
we
shouldn't
either
I
mean
we
are
trying
to
actually
mirror
OAuth
as
close
as
possible
and
reasonable,
and
in
this
case
I
don't
see
why
we
should
do
something.
That's
all
dozens
right.
C
I
guess
the
recollection
is
that
Roth
has
like
a
discovery
document
that
gives
you
the
URLs
for
all
of
the
different
endpoints
that
you
can
use,
and
so
you
only
need
to
find
the
discovery
document.
And
then
you
have
everything
you
need
the
rest.
I,
don't
remember
us
in
haste
having
a
discovery
document.
E
B
C
And
RS
and
whatnot
can
provide
in
point.
You
are
all
they
want,
but
we
say
we
have
a
default
value
of
it
and
the
issue
sort
of
comes
in
if
people
take
the
default
value
as
being
like
what
basically
everybody
uses
and
almost
here
part
of
the
protocol,
we
forgive
a
default
value,
but
we
don't
have
a
discovery
mechanism.
Then
the
only
way
to
use
something
other
than
the
default
value
is,
if
you
have
really
configured
it
besides
and
may
not
happen
very
often.
C
C
E
F
E
Including
the
offing
for
resource,
then
I.
Remember
we
had
that
discussion
or
we
had
a
very
brief
discussion
about
it.
Carson,
and
that
was
really
helpful
for
me,
because
I
haven't
gotten
the
competence
haven't,
got
the
competence
and
the
time
to
look
into
how
it's
done
in
in
core
right
now,
I
haven't
got
the
competence
and
I
don't
have
the
time
to
get
it.
D
We
registered
the
interface
description
link
target
attribute
is
group
to
indicate
that
no
one
node
the
resource
server,
whatever
it
implements.
This
bunch
of
resources
and
I
saw
a
custom
that
you
suggested
that
the
ACE
free
work
that
the
ice
framework
register
resource
type
link
target
attribute
values
instead
of
interface
description.
So
is
that
like
comparable
and.
F
That's
a
great
question,
so
in
2012,
when
we
did
this,
we
didn't
have
a
very
clear
idea
of
what
this
was
going
to
be
and
the
interface
link
target
attribute
really
just
says:
this
is
the
the
kind
of
behavior
you
can
expect
for
this
resource
and
the
resource
target
says
this
is
the
overall
behavior
and
purpose
of
this
resource
so
that
there
is
not
a
very
strong
distinction
between
those
two.
But
it's
a
little
bit
like
multiple
inheritance
in
a
programming
language.
F
F
A
D
E
B
C
A
F
E
C
C
Well,
I,
guess
that's
a
question:
would
it
be
for
your
resource?
That
is
a
discovery
document
for
all
of
the
ace
things
or
would
it
just
be
for
this
is
the
yes
and
point
and
we
have
the
resource
servers
to
find
I
have
a
resource
type
for
there
off
see
info
I
guess
maybe
it's
not
quite
as
simple
as
I
first
thought.
We
should
have
I.
C
F
Let's
think
about
that
some
more,
but
the
different
kinds
of
end
points
should
be
findable
and
I'm
really
not
talking
about
end
points,
because
that
means
something
different
I'm
talking
about
entry
points,
so
the
places
that
you
need
to
go
to
if
you
start
talking
with
a
device
or
a
server
for
the
first
time,
resource
types
for
those
and
I
agree
with
you
that
really
we
want
to
do
those
in
the
profiles,
even
though
the
results
will
look
very
similar
for
the
detail.
S
and.
F
E
D
B
C
Jim's
proposal
is
to
say
that
the
framework
just
talks
about
the
off,
see
info
endpoint
and
does
not
say
anything
about
default
path
or
anything
like
that
does
not
refer
to
/lc
info
every
every
place.
You
might
talk
about
it,
it
will
just
say
the
off
see
info
endpoint
and
then
it's
up
to
the
profiles
do
give
an
interpretation
to
that.
So.
D
D
F
A
D
G
This
is
one
thank
you,
so
an
update
on
this
draft
that
was
just
quickly
announced
in
two
minutes
in
November
at
the
Singapore
meeting
and
describing
an
admin
interface
at
the
Oscar
group
manager
right.
So
we
have
another
document
in
a
in
fact,
describing
an
interface
of
the
group
manager
for
candidate
group
members
that,
through
that
interface,
can
join
the
group,
get
the
key
material
to
operate
in
the
group
and
later
on,
continue
interacting
with
with
the
group
manager.
G
So
what
is
missing
yet
is
a
different
interface
at
the
group
manager
again,
but
intended
for
an
administrator
to
create
setup
and
delete
those.
Those
core
groups
next
slide.
Please
right-
and
this
is
what
we
define
this
document.
In
fact,
it's
a
different
restful
interface
for
the
administrator.
That
is
the
first
thing
to
be
done
before
the
group
is
properly
set
up
and
can
be
joined
by
candidate
members
and
interestingly,
the
the
interface
and
the
way
groups
are
represented
here
is
very
similar
to
the
pattern
used,
for
instance,
by
the
intended
co-op
ops
a
broker.
G
Practically
we
have
a
single
instance
of
a
group
collection
resource
at
the
group
manager,
say
the
example
path,
slash
manage,
and
then
we
have
under
that
resource.
One
group
figuration
resource
pair
Oscar
group
and
created
at
that
group
manager
that
you
essentially
identify
over
the
same
path,
append
inferences
the
group
name
and
well.
G
Of
course,
we
use
ace
for
the
sake
of
access
control,
for
the
administrator
here
becomes
the
client,
while
the
group
manager
is
again,
there
is
your
server
and
we
just
use
transparently
transfer
profile
availeth
for
the
secure
communication
between
administrator
and
group
manager.
Next
slide,
please.
G
Right
well,
what
we
showed
in
November
last
year
was
a
version
zero
and
after
that
we
got
the
review
from
Jim
thanks
a
lot
for
that.
They
were
mostly
addressed.
In
fact,
in
this
revision
zr1,
we
especially
organized
better
the
parameters
describing
the
current
configuration
and
we
encouraged
the
interface
with
more
functionalities,
describe
what
can
happen
as
side
effects
to
the
group
members
in
case
the
administrator
changes
something
delicate
like
the
algorithms
used
in
the
group
for
their
parameters
other
than
revising
the
examples
we
had
already.
G
We
also
added
examples
in
coral
and
Klaus
also
joined
the
author
list.
Next
slide,
please
right
to
give
a
more
operative
overview.
Some
operations
are
available
at
that
single
group
collection
resource.
So
the
idea
is
to
send
a
post
request
to
that
resource
in
order
to
create
an
obscure
group
and
possibly
providing
at
that
time
already.
Some
values
for
the
configuration
parameters
instance
sending
a
get
or
a
fetch
request
if
it's
interesting
to
specify
some
filter
criteria
is
possible
to
retrieve
some
of
the
configurations.
All
or
some
of
the
configurations
of
the
currently
registered
groups.
G
Next
slide,
please
well.
Instead,
sending
a
request
to
a
particular
group
configuration
well
with
the
get
you
just
retrieve
the
content
of
that
configuration
and
the
full
list
of
parameter
with
values,
a
pootis
for
time
being
intended
for
fully
update
the
current
configuration
just
overwriting,
the
current
one
and
we
delete
you
can
destroy
that
resource
and
and
this
mental,
the
the
oscar
group.
G
Next
with
yes,
as
I
said,
we
played
also
the
parameters
describing
how
the
group
is
configure
now.
A
first
set
is
the
configuration.
Property
is
essentially
describing
how
the
group
works
from
crater
graphic
point
of
view,
and
then
we
have
the
status
properties
with
anything
else.
If
the
group
is
currently
active
and
communication
can
actually
happen
in
that
the
name
for
the
sake
of
announcement
and
discovery,
title
is
intended
to
be
more
descriptive
of
what
the
group
is
about
then
later
on.
G
We
also
have
the
joining
path,
which
is
actually
a
URL
by
pointing
at
the
site
resource
at
the
group
manager,
where
Johnny
nodes
should
send
their
general
request
instead,
as
described
in
the
other,
is
document,
and
we
also
have
the
URL
to
the
authorization
server
where
those
journey
notes
should
check
to
get
an
access
token.
First,
before
joining
the
group
next
slide,
please
right
just
sound
selected
examples
from
the
draft.
There
are
more
there
get
to
the
collection
resource
returns
to
you.
G
Essentially,
the
the
list
of
all
the
configurational
resource
is
currently
present
as
corresponding
to
the
registered
oscar
groups.
So
practically
the
links
or
the
entries
to
to
later
on
sender
requested
those
groups.
Next,
please
yeah
I,
post
the
collection
resource
for
creating
the
group.
You
can
see
here.
Some
values
are
specified
for
some
of
the
parameters
for
other
parameters,
default
values
apply
at
the
group
manager
and
when
a
new
group
is
created,
the
group
manager
actually
creates
two
resources.
G
The
one
is
the
group
configuration
resource,
I've
talked
about
and
that's
again
intended
for
the
administrator
and
in
parallel,
the
corresponding
group
membership
resource
is
created
and
that's
the
one
intended
for
the
joining
node
sending
the
join
request.
An
explicit
final
example
I
think
I
get
sent
to
a
configuration
of
resource
just
returns,
the
full
current
configuration
of
that
ascore
group
with
all
its
parameters.
G
Next,
please
yeah.
We
have
also
section
describing
what
happens
in
the
group,
especially
to
recur,
include
members.
If
the
ministry
tour
changes
something
delicate
like
a
bit
switches
of
the
group
as
inactive
or
if
it
changes
current
algorithms
and
parameters,
and
especially
if
the
signature,
algorithm
or
its
parameters
are
changed.
G
Current
group
members
may
not
support
that
anymore.
In
that
case,
they
just
have
to
leave
the
group
essentially,
or
they
might
just
end
up
with
a
public
key
that
is
not
compatible
with
the
new
algorithm
or
parameters
anymore.
So
in
that
case
they
can
either
leave
and
join
a
game
providing
the
new
compatible
public
key
or
just
stay
in
the
group
and
upload
a
new
compatible
public
key
with
the
interface
we
have
for
them.
G
At
the
group
manager
described
in
the
other
document
and
considering
comments
from
Jim,
we
are
working
to
simplify
the
section
because
it
wasn't
convention
to
too
difficult
to
read
next
slide.
Please,
and
we
are
done
yes,
we're
defining
restful
interface
for
an
administrator
of
all
score
groups.
Add
the
group
manager
to
create,
configure
and
delete
all
score
groups,
so
it
goes
hand
the
end
with
the
other
interface
intended
for
joining
nodes,
and
we
have
examples
both
in
format
or
C,
bar
and
coral.
G
G
A
A
F
D
F
F
If
there
is
an
application
running
somewhere,
that
is
creating
groups
and
removing
groups
and
from
the
application
state,
it's
clear
what
those
groups
need
to
be.
You
don't
need
this
admin
interface,
because
it's
the
application
state
that
controls
sending
up
again,
the
connections
and
I
think
similar
to
the
resource
directory,
which,
which
can
be
described
as
a
relatively
independent
Network
element
or
can
be
defined
as
something
that
provides
an
application
that
provides
a
resource
directory
interface.
In
addition
to
its
other
application
interfaces,
we
have
a
similar
situation,
yeah.
F
A
G
G
G
We
inform
interested
parties
about
tokens
that
are
expired,
sorry
revoked,
but
on
expired.
Yet
so
thanks,
please,
and
here
we
are
in
fact
defining
an
interface
and
resource
at
the
authorization
server
having
a
single
instance
resource
after
the
last
revision
of
a
token
revocation
list
or
TRL,
essentially
containing
the
names
or
hashes
of
tokens
that
have
been
revoked,
don't
not
expired
yet,
and
that's
a
client
or
a
resource.
G
Everyone
can
just
send
a
get
or
even
observe
that
you're
a
resource
to
get
back
the
list
of
pertaining
access,
tokens
or
automatic
notification
about
that
for
pertaining
access
tokens
that
have
been
revoked
and
there
are
a
number
of
benefits.
Well,
we
can
serve
both
clients
and
resource
service.
We
are
complementing
introspection
mechanism
and
there's
no
need
on
clients
or
resource
servers
for
more
resources
or
end
point,
and
this
virtual
one
already
was
the
result
of
reviewing
the
list
from
Travis
Spencer
and
a
lot
of
site
discussion
with
Jane.
Thank
you
both
next
slide.
G
Thank
you.
So
what's
the
rationale?
We
give
names
or
identifies
two
tokens,
but
not
in
the
sense
of
city
ice.
We
actually
named
tokens
with
hashes
as
describing
6920,
and
we
are
actually
able
to
support
the
case
where
the
token
is
transported
either
C
bar
or
on
Jason.
So
this
token,
revocation
list
on
das
is
essentially
a
Sybil
array
of
the
token
ashes
of
tokens
that
that
is
issued
are
not
yet
expired,
but
I've
been
revoked.
So
if
a
token
is
Rock,
stokin
ashes,
add
it
to
the
list
later
on
when
it
eventually
expires.
G
Token
ash
is
removed
and
interactions
are
pretty
simple,
so
the
client
and
the
resource
server,
somehow
registers
EDS
through
a
mechanism
that
it
as
far
as
I,
know
out
of
scope
even
for
a
sit
self,
but
in
the
response
from
the
s
following
the
registration
they
kept
packets
at
URI
of
the
TRL
resource
at
the
authorization
server
and
later
on,
they
can
send
a
request
or
observation
request
to
remain
up
to
date.
They'll
get
back
only
what
exactly
pertain
to
them.
G
So
not
the
full
list,
only
the
revoked
tokens
that
have
been
issued
to
that
client
only
or
intended
to
be
consumed
to
that
resource
server
only,
but
we
are
also
meeting
the
case
of
a
particular
requester
like
system
administrator
that
in
instead
every
trip
just
the
full
list.
Cuz
the
whole
of
it
is
pertinent
to
it
next
slide,
please
yeah
just
to
give
an
intuitive
overview
in
ASCII
art.
Here
we
have
the
administrator
to
client
series
of
servers.
G
We
have
one
client
with
two
access:
token
t1
and
t2
to
be
consumed
by
only
Rs
1
or
only
our
steal
respectively
and
then
client,
who
has
only
token
t3
to
be
consumed
by
our
s2.
So
let's
say
all
of
them
are
registered
at
the
S.
All
of
them
observe
that
theory
so
and
at
some
point,
all
of
those
three
thousands
get
revoked
their
token
ash
is
included
in
the
TRL
resource
and
utilization
server
sends
the
five
different
notifications
indicating
only
the
pertaining
token
ashes
to
each
of
the
five
requesters.
G
That
slightly
is
right
and
we
started
thinking
of
this
with
a
single
mode
of
operation
that
we
called
food
query
we're
essentially
the
requesters
sends
a
get
request
or
get
observe
and
the
result
coming
back
is
the
the
whole
pertaining
portion
of
the
TRL
resource.
Jim
suggested
also
to
consider
deep
query
mode
where
the
requester
is
interested
not
in
getting
the
full
current
content
of
the
pertaining
part
of
the
Tyrael
resource,
but
only
what
happened
in
the
latest
specified
and
updates.
G
So,
in
this
case,
the
response
would
be
a
collection
of
diff
entries,
one
for
each
of
the
latest
and
updates,
and
each
the
entry
in
turn
would
specify.
The
token
is
that
for
that
request
that
were
added
or
deleted
at
that
update,
we
got
a
recent
review
from
Kirsten
and
we
are
working
to
simplify
both
the
interface
and
representation
of
the
response
payload
in
DF
mode.
Thanks
for
that,
I
conclude
with
the
example
we
have
in
the
draft
just
to
fix
ideas.
It's
pretty
basic.
G
We
have
only
one
resource
server
here,
considering
the
full
mode
and
observing
material
resource,
so
it
registers
first
gets
back
the
URI
to
the
TR.
The
resource
starts.
Observing
it
of
course,
gets
immediately
back
and
empty
zebra
array,
then
later
on
the
AES
issues
to
access
tokens
to
some
of
the
clients
around
but
to
be
consumed
by
the
same
RS.
So
next
slide.
Please.
G
Can
you
move
to
the
next
light?
Thanks
yeah
at
some
point
access
token
t1
is
revoked,
so
the
access
to
the
authorization
server
sends
back
a
notification
indicating
that
the
resource
server
then
later
on
t2
is
also
revoked,
and
the
second
notification
is
sent
indicating
both
access
tokens-
you
know
later
on
t1
eventually
expires.
So
third
notification
is
sent
now
indicating
only
tteyuu
as
part
of
the
pertaining
portion
of
TRL
for
the
resource
server.
G
G
Revoke,
though,
not
expired
yet,
and
there's
no
need
for
new
resources
or
endpoints
at
clients
or
servers,
and
this
revision
is
the
result
of
process
comments
from
the
review
from
Travis
and
sigh
discussion
with
Jim,
and
we
plan
to
have
a
revision
before
the
next
cutoff
also
dressing
review.
We
have
recently
got
from
Karsten
thanks.
That's
it.
C
Ok,
I
will
jump
in
two
points.
First,
one
was
with
a
sort
of
diff
update
that
from
Jim's
review
first
discuss
seemed
pretty
useful
I'm,
not
entirely
sure.
If
these
sort
of
give
me
the
last
n
changes
is
the
most
effective
way
to
do.
That,
I
had
actually
reminded
me
a
lot
about
the
J
map
protocol,
which
was
originally
JSON
mail
access
protocol,
but
they
changed
it
to
be
a
more
generic
name
and
I
forget
what
it
now
stands
for,
but
there's
a
working
group
they
put
out
documents.
C
What
the
general
concept
is
to
give
a
deep
to
the
state
on
the
server
for
a
given
resource
and
like
this
name,
is
probably
going
to
be
some
output
or
similar,
and
so
then
you
server
you
the
state
of
the
full
TRL,
or
it
also
sends
that
hash
value
that
sort
of
identifies
that
state
in
time
of
the
resource.
And
then
when
you
go
and
ask
for,
as
you
can
say,
this
is
the
name
of
the
last
thing
that
you
gave
me.
C
G
G
C
A
F
This
this
kind
of
situation,
where
you
have
a
series
of
things
that
gets
added
to
that's
exactly
what's
discussed
in
this
serious
transfer
pattern
draft
that
I
sent
the
name
of
through
the
chat
and
I
think
it
might
be
worth
looking
at
that
draft
and
and
seeing
do
we
have
a
conventional
way
of
handling
this
kind
of
situation
already,
and
if,
yes,
we
might
want
to
use
it.
If
no,
we
might
want
to
add
this
particular
case.
The
serious
transfer
pattern
draw
so
so
we
know
how
to
handle
similar
situations
in
the
future.
G
G
C
I
I,
haven't
I,
haven't
prepared,
slides
because
there's
not
much
to
say,
except
that
a
version
5
being
submitted
that
Unser,
the
that
were
raised
in
the
previous
interims
and
Jim,
sent
a
review
which
authority
of
the
comments
they're,
not
major
technical
issues
outstanding.
There
are
editorial
ones
and
new
definitions.
I
have
there
are
a
few
outstanding
things
to
discuss
regarding
converging
what
session
States
the
authorization,
the
resource
server
the
Brooke
keeps
as
well
as
formats.
I
I
D
I
B
D
I
That
I,
wasn't
too
clear
on
is
I
can
understand
that
the
new
keywords
can,
of
course,
we
added
the
publish/subscribe,
but
the
idea
was
to
be
able
to
use
those
those
permissions
over
a
subset
of
topics
which
are
really
nicely
described
with
the
topic
filters
using
wildcards
in
entity
and
I.
Wasn't
too
sure
how
that
is
represented
in
AI
F,
when
you
want
that
permission
to
apply
to
multiple
resources.
B
A
A
D
A
A
I
I
The
state
information
that
it's
kept
for
continuing
sessions
at
the
Rs
and
Jim
was
suggesting
that
the
token
used
should
be
part
of
the
state
and
I
was
questioning
whether
that
means
the
client
can
only
continuous
session
with
a
previous
token,
because
if
it
got
a
new
token
between
the
two,
then
it
would
want
to
use
the
new
token
to
reconnect.
So
there
is
a
discussion
ongoing
in
github
about
this.
So
that's
the
only
slightly
technical
remainder,
basically
for
the
amputee
profile.
A
A
I
I've
opened
a
issue
in
it,
hop
with
Jim's
comment
and
commented
back,
so
if
I've
understood
him
correctly,
and
he,
if
we
can
converge
there,
it's
fine.
It's
just
that.
It
is
the
question
of
what
this,
what
we
allow
the
client
to
do.
Do
we
we
now
the
clients
can
continue
sessions
in
mp,
OTC
and
when
the
client
reconnects,
it
has
to
still
provide
a
token
if
the
token
is
part
of
the
state
that
I'm
expect
that
to
be
cool
to
the
old
token.
I
However,
if
the
client
got
a
new
token
between
the
county
between
these
two
events,
then
we
have
an
issue.
I
suggested
the
clients.
Token
may
be
part
of
the
stage,
rather
than
must
be
part
of
the
state,
and
in
that
case
we
are
not
really
authorizing
the
venue
Asian
of
the
session,
we're
authorizing
the
just
client
coming
back
and
I
thought
that
was
acceptable,
because
mu
TT
anyway
recognizes
clients
only
by
client,
ID
and,
at
you
know,
finds
client
state
by
just
using
client
ID
as
a
key,
and
that's
why
I
thought
it
was
acceptable.
I
I
I
A
solution
would
be
other
solution.
That
I
propose,
which
I
will
add
to
github.
Is
that
if
we
want
to
really
do
better
client
identification
than
original
MQTT,
then
we
would
have.
We
can
say
continuing
clients
can
only
connect,
with
their
old
token,
were
even
that
day
expired,
and
then
we
do
a
key
checking
there
and
then
immediately.
They
have
to
submit
a
new
token
by
using
real
talk.
I
No,
so
they
connect
me
all.
They
know
that
that's
expired,
that's
another
whale,
but
that
means
the
continuing
clients
can
only
use
the
challenge
based
mechanism
to
authenticate
to
the
artists
anyway,
so
that
will
be
in
the
issue
in
the
github.
So
that's
one
issue
remaining
and
the
other
issues,
the
scope
issue.
D
I
Would
be
used
to
just
show
to
the
RS
that
I
am
the
client
that's
coming
back
mm-hmm,
but
what
I
was
saying
that
original?
If
you
look
at
mqtt
specification,
when
they
do
continuing
sessions,
they
basically
only
mechanism
to
identify
this
client.
That's
coming
back
is
the
client
ID.
They
use
the
client
ideas,
then
parameter
tacky
to
look
up
the
client
state
and
they
don't
and
that's
why
what
I
was
falling
back
on
just
to
check
which
client
is
continuing.
I
However,
there
might
be
an
issue
in
this
case
where
client
a
with
a
ID
joins
with
session
continuation
drops.
Then
a
client
becomes
with
the
same
client
ID,
and
then
the
state
is
kept
for
the
client
and
the
RS
thinks
it's
the
same
client,
but
it's
not
it's
just
the
same
client
ID
to
different
clients
in
that
case,
since
the
token
present
and
validated
and
verified
client
will
never
get
any
messages
that
they
were
not
supposed
to
get,
and
they
were
not
be
able
to
publish
to
anything
that
they
were
not
supposed
to
get
anyway.
I
D
This
is
a
long
slide
and
I'm
not
gonna
go
through,
but
it's
just
to
summarize
what
happens
in
this
last
interim.
Basically,
we
submitted
a
new
version
that
was
based
on
Daniels
review
and
some
the
points
that
were
discussed
during
the
last
interim
and
then
in
each
bullet
point
here
you
can
find
you
can
find
the
commits
that
answer
each
point.
So
this
is
all
of
them
and
also
we
answer
Peters
review,
which
was
from
version
zero
three.
D
So
this
is
quite
all
the
review
and
it's
it
took
us
some
time
to
get
to
it,
but
we
finally
implemented
it,
and
there
is
a
couple
of
points
that
we
want
to
follow
up
discuss
today.
The
first
point
is
the
normalized
scope.
So
during
last
interim,
we
we
decided
to
add
this
informative
reference
to
a
f4
scope,
and
while
we
were
doing
that,
we
realized
okay.
This
might
not
be
the
best
like
this
might
not
be
adapted
to
this
document
and
then
Peter
review.
D
So
this
is
nothing
major,
but
you
need
to
be
done
so
next
yeah
normalized
scope.
So
this
is
the
the
point
where
we
should
have
more
interesting
discussion.
So
right
now
the
scope
for
the
document.
Just
as
a
reminder,
we
have
what
we
call
a
group
identifier
and
the
roll.
These
are
defined
by
the
application
profile,
for
example
the
kiosk
or
defines
a
thesis,
for
example,
byte
string
and
text
string,
and
then
we
have
a
scope
entry,
which
is
an
array
that
contain
a
first
element.
Is
the
group
ID
or
topic
identifier?
D
Whatever
you
want
to
identify
your
you
need
to
identify
your
security
group
and
then
optionally.
The
second
element
is
one
or
more
roles:
this
could
be
requester
responder,
it
could
be
publisher
subscriber
or
it
could
be,
a
combination
of
those
and
then
finally,
the
scope
is
just
a
sequence
or
it's
a
an
array
of
several
scope
entries.
So
in
this
example
for
a
group
of
core
communication,
we
have
a
group
identifier.
D
D
So
requester
means
that
the
node
is
allowed
to
send
group
requests
and
accept
group
responses
and
responder
is
someone
who
accept
group
request
and
send
grouper
sponsor.
Then
then
we
have
requester
and
responder,
which
is
thus
both
and
monitor,
which
is
accept,
group
request,
but
does
not
reply
and
we
rethinking
the
AAF.
D
So
an
example
of
AI
F
is,
if
you
take,
for
example,
the
first
on
the
right
h0
one
requester.
This
is
a
scope
as
we
define
it
right
now
with
the
scope
entry,
and
if
we
want
to
use
AF
for
the
role,
then
we
replace
this
requester
with
this
si
boar
ray
where
the
first
element
is
the
group
resource
your
eye
path
in
this
case
topic,
that's
the
one
and
then
the
second
element
is
bitmap
with
that
indicates
what
what
methods
this
node
is
allowed
to
do.
D
So,
since
this
is
a
requester
we're
assuming
that
it
can
do
anything
else
on
this
resource.
In
this
specific
example,
so
we
say
63
and
and
we're
thinking.
Okay,
is
this
the
equivalent
to
the
scope
that
we
have
defined
in
our
document?
And
we
try
to
do
this
for
the
several
for
the
several
roles
that
we
have
so,
let's
see
for
the
responder,
we
thought.
Okay,
the
responder
is
not
allowed
to
request
anything.
D
Okay,
so
for
requester
and
responder,
we
kind
of
made
the
mix
and
we
say:
okay,
we
can
maybe
merge
these
two
roles
and
then
say
that
this
is
just
a
array
that
contains
both
of
those
and
we
don't
have
any
way
to
say,
monitor
to
say:
okay
you're
allowed
to
to
accept
requests,
but
you're
not
allowed
to
reply.
We
don't
have
any
like
I,
didn't
find
any
way
to
express
that,
because
AAF
only
specifies
policy
for
request
methods
and,
in
our
case,
roles
also
refer
to
responses
or
for
the
off
score.
D
A
ski
group
come
or
score
document.
Also,
another
problem
that
the
AF
does
not
cover
is
that
the
yes
does
not
necessarily
know
the
group
resource.
So
the
AES
is
the
first
note
that
it's
gonna
send
a
scope.
So
it's
gonna
send
the
scope
in
in
the
token
and
to
the
to
the
client,
and
then
the
client
is
gonna
forward
that
so
the
s
does
not
necessarily
know
the
group
resource.
So
it
cannot
include
that
in
the
scope-
and
those
were
two
reasons
why.
D
B
D
D
F
I'm
asking
this
question,
because
I
just
want
to
make
sure
that
those
translations
actually
are
done
in
a
secure
way,
so
the
authorization
actually
means
something
well
defined.
As
long
as
you
can
make
sure
what
there
is,
we
can
essentially
the
the
what
AF
does.
Is
it
Associates
names
of
things
with
permissions
on
things,
and
what
we
find
out
is
that
names
of
things
are
not
always
URI
paths
and
we
find
out
that
permissions
on
things
are
not
always
method,
names
or
method
numbers.
B
B
D
G
D
So
then,
if
that's
like
that,
then,
instead
of
hearing
instead
of
having
this
equivalence
between
the
way,
we
define
it
right
now
and
and
the
one
with
AF
being
an
array
inside
the
array,
then
it
will
become
the
same
as
we
have
right
now
with
h0
one
with
the
group
name
or
group
ID
or
whatever.
We
want
to
call
it
and
the
second
element
being
the
requester,
the
text
string.
D
D
D
The
point
is,
let
me
summarize
a
yes
as
its
defined
right
now.
That's
not
cover
the
a
ski
calm
or
score
case,
which
is
why
I
had
the
problem
putting
in
in
the
document
and
say
we
recommend
the
use
of
AF,
because
for
the
one
document
that
we
have,
it
does
not
work
and
Jim
said
that
he
has
suggested
changes
that
would
make
it
work
and.
F
Yeah
I
think
this
is
really
interesting.
There
are
two
aspects
to
a
f-1
is
defining
an
overall
structure
for
authorization,
information
that
that
is
relatively
simple
and
the
other
one
is
actually
defining
the
elements
of
that
structure
and
I.
Think
what
you
said
is
that
the
the
elements
you
have
don't
fit?
F
D
F
So
so
maybe
it's
actually
worse,
taking
the
document
and
essentially
divided
into
two
parts,
one
the
set
which
has
this
overall
structure.
Essentially,
we
are
using
these
arrays
with
names
for
four
things,
and
permissions
and
and
Jim
has
a
proposal
on
what
to
do
with
the
permissions
as
well,
and
the
other
one
is
defining
what
those
names
mean
and
what
those
permissions
mean.
Yeah.
A
But
just
a
comment
regarding
mqtt
if
we
use
a
AF,
a
AI
F
I'm
wondering
if,
because
I
have
the
impression
that
we're
replacing
the
topics
names
with,
maybe
some
stars
and
special
characters
by
something
that
provides
more
information.
That
is
already
known
by
the
context
of
the
session.
So
I'm
wondering
if
we're
not
trying
to
make
something
hotter.
At
least
in
am
quiddity.
A
A
F
Yeah
so
the
other
question
from
Daniel,
without
having
strings
with
wildcards
in
them
and
so
on,
really
is
something
we
should
be
doing
in
a
constrained
environment.
That's
actually
an
interesting
question,
so
maybe
we
should
look
at
the
MQTT
use
case
and
see
how
exactly
there
should
be
done.
Yeah,
but
I
think
that
that's
a
bit
orthogonal
to
the
question.
Can
we
define
a
comments,
try
sure
and
can
we
define
some
some
default
or
basic
meanings
for
the
element
of
that
structure?.
A
I
One
aspect
of
the
AI
F
draft,
the
we
all
discussed
that
it
at
the
moment
there's
the
method
sketch
and
etc,
but
in
the
future,
will
it
be
possible
or
will
it
be
defined
in
a
way
where
the
profile
can
insert
its
own
method?
I
mean
I
can
now
be
defined
to
include
publish
and
subscribe,
but
to
be
future-proof.
Other
permission
works
that
needs
to
be
used
in
the
scopes.
Could
it
be
that's
the
profiles
are
able
to
register
those
keywords.
I.
D
D
D
A
G
Thank
you
yeah.
This
was
last
presented
a
virtual
meeting.
We
had
in
April
as
a
replacement
for
2006.
Next,
please
yeah,
quick
recap:
this
is
a
profile
of
a
ski
girl,
calm.
The
client
requested
token
to
pose
that
the
group
manager
here
acting
as
resource
server
and
then
sends
the
join
request
getting
back
in
the
general
response
to
key
material
to
use
group
of
score.
Next,
please
right.
Since
the
virtual
meeting
we
submitted
to
revisions
version
six
after
that
was
mostly
based
on,
we
got
from
GM
version
5.
G
Last
week
we
also
submitted
a
version
7
most
before
alignment
with
calm
and
processing
comments
left
from
Peter,
just
as
an
overview.
We
have
added
an
register
at
your
policy.
So
now
the
group
manager
can
signal
in
the
joining
response
that,
in
the
group
notes
also
use.
The
pairwise
model
group
of
score
recently
introduced
an
out
of
discussion
with
gene.
G
We
also
added
the
role
of
verifier,
so
this
is,
strictly
speaking,
not
a
group
member
doesn't
join
the
group,
but
still
it
gets
an
access
token
into
the
group
manager
and
the
only
thing
it
is
authorized
to
do
after
that
is
sending
a
request
to
a
particular
sub
reduce
at
the
group
manager
related
to
that
group
to
retrieve
is
of
the
group
member
and
acting
a
signature
verifier
for
messages
that
are
protected
in
the
group
mode.
Oh
next
slide,
please
yeah.
This
follows
some
discussions.
G
We
had
a
few
meetings
ago
about
the
parameter
that
used
to
be
called
RS,
nouns
so
other
than
changing
its
name
to
K.
This
challenge.
We
change
the
text
so
that
it's
not
announced
any
more.
So
as
long
as
the
access
token
that
was
posted
right
before
returning
the
response
with
this
parameter
is
valid.
This
parameter
can
in
fact
be
reused
several
times
by
the
client
to
produce
a
signature
challenge
to
join
in
multiple
groups.
G
Under
the
same
token,
at
some
point
based
on
application
policies,
the
group
manager
can
still
invalidate
the
current
KDC
challenge
value
and
well,
if
that
client
comes
again,
it
will
get
first,
an
error
response,
including
a
new
KDC
challenge
value,
to
consider
from
then
on.
For
that
token,
and
of
course
we
have-
that
is
security
considerations
about
this
analysis,
so
to
say,
I
use
for
building
scenario
challenge
according
to
this
change,
but
about
this
parameter
again.
G
Jim
knows
the
case
where
a
client
may
not
really
need
it,
one
at
all
and
the
cases
where
the
posted
access
token
specifies
for
each
mention
group.
In
the
token,
only
the
role
of
monitor
or
only
the
role
of
verifier,
so
for
different
sub
reasons.
In
this
case,
the
client
doesn't
need
to
produce
anything
in
sure
to
prove
anything.
So
it
doesn't
really
need
to
get
that
value
and,
of
course,
the
group
manager
can
understand
it.
That's
the
case
when
processing
the
access
token
still
we
are
living
to
the
implementer.
G
The
final
choice
to
take
advantage
of
this
optimization
so
to
say
and
not
return
the
case,
each
challenge
in
that
case,
but
in
those
case
it
wouldn't
be
of
any
need
any
way
for
the
client
next
slide,
please
right
and
the
latest
update.
Instead,
we
have
updated
the
format
to
the
countersignature
algorithm
used
in
the
group
and
the
related
parameters,
and
this
happens
in
two
places:
the
structure
returning
response
to
the
totem
post
and
that
just
Falls
a
skier
come
and
also
the
corresponding
parameters
we
have
later
on
in
the
join
rest
mirrors.
G
The
group
breaking
process-
remember
mrs.,
ladies
routine,
so
it
just
remains
with
all
key
materials,
so
this
knot
will
start
receiving
messages
that
it
is
not
to
decorate
them
validate
anymore
at
some
point
it
realizes
and
it
has
to
go
to
the
group
manager
to
get
updated
key
material.
The
problem
is
that
that
note
can
be
multiple
groups
and
the
invalid
messages
that
is
receiving
may
be
may
not
include
sufficient
hints
further,
not
to
understand
to
which
exit
group.
G
G
The
groups
of
the
different
group
managers,
possibly
asking
for
the
king
material
there's
a
number
only
and
in
case
of
mismatch,
go
back
to
that
group
manager
for
that
group
to
request
the
latest
key
material,
but
we
noticed-
and
we
added
in
the
document
that
if
the
group
ID
used
this
context,
ID
is
formatted
in
a
particular
way
that
we
just
give
us
an
example
in
the
group
of
score
document.
The
prefix
part
can
give
a
hint
for
discriminating
between
different
group
managers.
G
G
The
problem
is
when
this
should
be
exactly
checked
and
enforced
and
by
whom
the
way
the
draft
is
written.
Now,
that's
the
authorization
server
so
very
early
in
the
workflow.
The
client
requests
an
access
token
and
it
has
to
specify
a
combination
of
rows
that
has
to
be
legal
already
at
that
point
in
time.
So
requester
monitor
who
then
be
valid.
G
But
then
we
run
into
some
inconvenience
so
think
of
a
node
that
wants
to
join
the
group,
let's
request
their
only
first
and
then
leave
it
and
join
it
again
as
monitor
only
and
the
thing
should
be
possible.
The
way
the
draft
is
written
now
that
no
has
to
ask
two
different
tokens.
First,
as
requests
they're
only
join
us
requester
leave,
as
the
second
token
is
monitor
only
for
the
joint
as
monitor,
which
is
pretty
inconvenient.
A
G
A
G
J
G
G
Slide,
yes,
and
last
one,
we
expect
one
more
revision
before
the
cutoff,
mostly
to
address
this
open
point
and
is
also
one
small
other
thing
that
Jim
raised
in
the
review
of
the
group
manager,
admin
interface.
Actually
in
that
document
now
we
are
defining
the
default
values
for
the
group
parameters
describing
the
algorithm
the
country,
signature,
algorithm,
their
parameters
and
Jim
was
suggesting
to
move
the
default
values
for
those
parameters
in
this
document.