►
From YouTube: IETF-ACE-20221219-1400
Description
ACE meeting session at IETF
2022/12/19 1400
https://datatracker.ietf.org/meeting//proceedings/
A
B
B
C
A
B
B
D
It
has
progressed
more
slowly
than
I
imagined,
but
I
finally
aligned
the
document
better
with
the
current
group
com
and
also
had
a
look
at
groupcom
Oscar
to
have
a
few
ideas
of
how
to
meet
the
requirements
of
groupcom,
which
are
30
mandatory
requirements
than
15
optional
requirements,
which
were
not
previously
thought
in
the
previous
versions
of
the
document
and
in
the
previous
versions
of
the
document.
It
only
considered
authorization
to
two
asses.
D
We
changed
that
if
you
remember
to
a
single
as
with
two
audiences
and
it
only
handled,
join
requests
and
responses
and
protecting
the
pub
sub
communication
now
the
document
has
expanded
to
be
to
meet
the
groupcom
requirements.
So
we
talk
about
more
about
the
KDC
interface.
The
resources
hosted
operations
permitted
on
those
resources
for
the
different
roles
which
are,
namely
the
publisher
and
subscriber,
and
the
group
operation
discussions.
The
subsections
have
expanded
to
include
clearing
for
group
information,
updating,
authentication
credentials,
removing
being
removal
from
the
group
and
re-keying
the
group.
D
So
we
we
have
discussions
around
this
currently
I've
selected
the
very
basic
default
mechanisms
that
were
suggested
already
in
the
group
com
for
these,
but
in
the
next
slide,
I
also
ask
for
maybe
more
considerations
need
to
be
added
to
expand
on
these
group
operations.
Let
me
not
switch
yet.
Let
me
talk
a
little.
D
Too
so,
in
addition,
I've
also
defined
a
scope,
the
aif
for
AI
format,
similar
to
the
the
oscore
one.
It's
called
aif
Pub
sub
group
comb.
It
describes
how
the
scope
should
be
formatted
with
two
two
roles:
publisher
and
subscriber,
so
it's
very
similar
to
the
oscore
document.
In
that
case
the
scope
change.
So
those
were
the
changes
introduced.
D
D
Just
that
the
co-op
pops
up
is
a
way
of
doing
Pub,
sub
communication
for
different.
You
know,
type
of
protocol
and
mqtt
is
exactly
doing
the
same,
perhaps
up
communication
or
using
a
different
protocol.
It's
just
that.
If
things
are
implemented
in
mqtt,
you
would
imagine
that
you
know
it
stays
in
the
mqtt
ecosystem
and
then
the
HTTP
was
able
to
be
justified,
because
you
would
say
you
know
we
didn't
expect
clients
to
do
the
HTTP.
D
We
expected
them
to
be
onboarded
somehow
in
at
the
beginning,
with
mqtt
TLS
profile,
and
it
was
the
resource
server
that
was
supposed
to
do
a
little
bit
HTTP
and
that
was
kind
of
acceptable
because
of
the
current
applications
of
amqtt
allow
that
kind
of
plugins
to
the
resource
server
or
the
broker
mqtt
broker.
So
there
were
already
examples
of
that
in
the
in
in
practice.
D
Now
we
don't
have
examples
of
mixed
Co-op,
mqtt
clients
or
any
applications
to
that
end,
and
I
personally
didn't
know
how
to
justify
that
kind
of
combination
of
protocols
to
be
able
to
do
the
co-op
communication
with
the
KDC.
That's
why
I'm
questioning
how
applicable
the
strap
will
be
to
mqtt
and
that's
why
I
pushed
the
emphasis
to
the
end
just
a
sketch.
A
B
D
The
there's
a
line
in
the
sentence
in
the
yes,
that's
the
question
just
to
say
to
people.
There
is
a
sentence
in
the
draft
which
said:
oh,
you
know
you
can
use
other
Pub
sub
protocols
and
Etc.
But
even
when
you
try
to
sketch
the
solution
for
mqtt,
I
would
say
it
would
require
another
profile
rather
than.
A
D
A
E
I
I
I
just
agree
with,
what's
been
said:
I
think
that
makes
sense.
I
I
actually
had
a
question
just
about.
Perhaps
this
is
I
haven't,
read
the
draft
in
a
long
time.
So
perhaps
this
is
answered
already,
but
the
dependence
on
the
co-op
Pub
sub
draft
that
that's
still
the
draft
and
I
don't
know
I,
don't
remember
really
the
state
of
that
draft
is
there.
Is
there
some
sensitivity
there
in
in
design
choices
in
the
pub
subdraft
that
will
have
impact
on
this
draft.
D
I
think
we
have
to
keep
an
eye
on
this.
Definitely
definitely
so
when
I
first
agreed
to
participate
in
the
draft.
I
was
thinking.
My
role
was
on
the
mqtt
part,
but
now
and
the
Pop-Up
Parts,
more
or
less
were
established,
but
and
the
role
has
changed,
I've
been
adding
more
and
trying
to
understand
how
it
pops
up
works,
and
that
was
another
question.
D
I
think
either
Francesca
needs
to
actually
come
back
to
the
to
the
draft
to
be
able
to
answer
these
questions
and
justify
some
of
the
choices
that
have
made
been
earlier,
which
is
the
topic
of
my
slide
three.
There
are
some
earlier,
even
choices
from
even
the
security,
and
that
needs
to
be
reconsidered
and
if
there
are
changes
to
the
co-op
pop
sub,
I
think
they
need
to
be
also
addressed
back
in
this
document.
If
what
we're
saying
no
more
holes
so
short
answer,
I,
don't
know
thanks.
C
The
authors
are
trying
to
revive
it
and
there
was
a
rebump
literally
a
few
weeks
ago.
I
think,
and
it's
mostly
on
high
Miss,
ends
to
progress
that
and
as
far
as
I
know,
he
had
a
to-do
quite
detailed
to
follow,
but
yeah
when
I
remind
about
that.
I
also
put
it
in
context
of
this
Ace
document
so
that
one
doesn't
block
the
other
eventually.
A
D
I,
do
definitely
need
a
little
bit
of
help,
because
I
feel
like
I'm
making
decisions
on
my
own,
which
needs
to
be
I,
think
and
needs
a
bigger,
wider
working
group
consensus,
as
well
as
a
person
who's,
much
more
familiar
with
Co-op
pops
up
and
maybe
slide.
3
will
explain
some
of
the
some
of
the
questions
that
I'm
trying
to
answer.
So
there
are
a
number
of
to-do's.
D
So
one
of
these
there
are
various
different
things
that
the
documents
tries
to
be
flexible
at
the
moment
and
therefore
has
to
due
to
that
flexibility
has
to
put
even
more
considerations
into
how
things
need
to
be
handled.
The
first
one
is
the
token
transfer
method.
The
draft
says
you
can
either
use
or
score
or
dtls
profile
to
do
the
transport
and
like
Ace
transport
so
and
then
the
token
transfer
method.
D
The
draft
describes
at
the
moment
is
using
the
the
the
endpoint
for
token
transport,
but
it
also
accepts
that
in
the
details
profile,
you
could
use
other
methods
during
the
TLs
handshake
the
TLs
handshake.
Now,
if
that's
the
case,
there
should
be
a
method
to
do.
The
KDC
Challenge
from
the
KDC
communicated
somehow
and
Oscar
describes
a
method,
and
we
need
to
also
decide
on
a
method
for
that.
D
There
were
outstanding
questions
regarding
those
already
and
then
the
documents
referred
to
got
older.
Now
we
need
to
refer
to
the
newer
documents
for
the
signature.
Algorithms,
as
well
as
the
structure
of
the
code,
say,
object
and
talk
about
the
acceptable
authentication
credentials
much
more
clearly.
Previously,
these
were
all
Koza
keys
and
I
updated
it
to
be
a
list
of
things,
including
Seaboard
web
tokens
and
Etc
following
the
Oscar
lead,
the
group
home
Oscar
lead,
but
then
I
would
like
to
know
in
a
pub
sub
Co-op
setting.
D
D
The
way
that
it's
described
in
the
document
at
the
moment
doesn't
seem
to
be
entirely
correct
because
of
how
the
base
IV
is
sent
to
the
group
members
by
the
KDC
and
how
the
partial
IV
is
generated
by
the
group
members,
it
seems
under
defined.
There
seems
to
be
some
details
missing
there
and
then
at
the
moment,
for
instance,
group
re-keying
I
defaulted
to
point
to
point,
which
is
the
grip
com's
recommendation,
but
then
one
could
easily
imagine.
D
It
would
be
much
nicer
to
have
the
KDC
being
involved
in
group
wreaking
through
the
pub
sub
communication,
for
instance,
and
having
a
wreaking
topic
that
the
group
members
register
to
and
KDC
publishes
new
king
material
there
and
it's
group
breaking,
and
that
needs
to
be
again
defined
at
the
moment.
The
the
document
response
to
the
a
number
of
groupcom
requirements
or
leaves
them
as
to
do
and
that's
clearly
marked,
but
we
do
definitely
need
to
go
through
I'm
clearly
say
for
each
of
those
13
mandatory
requirements.
D
How
do
we
answer
them
and
that's
still
missing?
So
in
summary,
I
I've
done
a
number
of
additions
to
the
draft
to
make
it
closer
to
groupcom
requirements,
but
there
requires
at
least
one
or
two
iterations
to
make
sure
that
it
answers
all
the
mandatory
requirements,
at
least,
and
then
it
might
leave
optional
requirements
as
they
are.
But
there
needs
to
be
definitely
and
more
work
to
be
done
on
this
draft.
So
I.
D
D
D
B
F
F
So
the
the
interface
between
the
group
comp
keying
here
and
the
pub
sub
keying
and
the
various
transfer
methods
and
so
on
employed
is
well
defined.
So
it
becomes
easy
to
say:
oh
for
dtls,
we
put
this
here
and
then
there
and-
and
we
are
done
and
I'm
wondering
if
that
could
simplify
the
the
work
here,
because
the
the
pub
sub
authorization
mechanism
itself
would
simply
say:
oh
I
need
a
way
to
to
redistrute,
redistribute
changed
key
and
then
a
profile
would
say
yeah.
D
I'm
not
I'm,
beginning
of
the
meeting
we
were
thinking
mqtt
from
the
draft
anyway.
Thinking
that
it
with
the
combination
of
the
product
protocols
is
too
much
to
expect
on
a
mqtt
client
to
be
Co-op
at
the
same
time
to
manage
the
KDC
so
and
whether
it
was
practicable
and
that's
why
I
suggested
to
remove
mqtt
anyway.
F
Yeah
I'm
not
sure
I,
like
the
suggestion
too
much
I
mean
it
sure,
simplifies
the
document
so
that
that's
a
a
good
thing
but
having
another
base
protocol
on
transfer
project
called
India
would
make
sure
that
the
the
this
architecture,
Plus
profile
approach
actually
is
exercised,
and
we
do
it
more
in
more
than
one
way
so.
I
think
the
the
mqtt
mechanism
would
actually
be
good,
and
what
we
would
need
to
do
here
is
make
sure
we
do
this
in
a
way
that
actually
makes
sense.
F
D
Okay,
sorry
I
should
have
been
clear,
so
the
mqtt,
because
the
document
assumes
that
the
end,
the
underlying
communication
between
the
As
and
the
RS
is
somehow
secured
by
Ace
transport
profile
and
the
only
one
that
is
existing
for
mqtt
at
the
moment
is
mqtt
TLS
profile
which
uses
HTTP.
That's
why
it
became
three
protocols.
D
Because
we
have
to
assume
somehow
the
client
is
able
to
talk
to
the
as
and
then
the
client
is
able
to
talk
to
the
RS.
The
broker,
with
some
kind
of
an
ace
transport
profile
and
the
only
one
that
exists
at
the
moment,
is
the
mqttls
profile,
which
kind
of
ties
them
to
that
HTTP,
TLS,
plus
Ace,
related
stuff
and
then
mqtt
for
the
pub
sub
communication.
And
then,
on
top
of
this,
to
secure
the
pub
sub
communication
to
encrypt
the
content,
the
payload.
D
We
have
to
get
the
KDC
architecture,
the
pub
sub
architecture
that
is
described
here
and
then
the
KDC
is
only
supporting
co-ops
so
that
now
the
mqtt
client
needs
to
be
able
to
get
tokens
using
the
mqtt
TLs
profile.
And
then
it
needs
to
approach
the
KDC
using
Co-op.
And
then
it
needs
to
approach
the
broker
using
mqtt.
F
F
D
D
Yeah
I
mean
so
I
completely
agree
that
a
solution
can
be
can
be
found.
That's
why
I
kept
the
sketch
there,
but
then
I
noticed
that
that
sketch
to
be
anything
useful
for
mqtt
would
have
to
answer
a
number
of
questions
for
re-keying,
especially,
and
it
felt
like
a
bit
hand
wavy
to
describe
it
over
three
protocols
just
to
make
it
fit
so
I
wouldn't
close
the
door
to
mqtt,
but
I
feel
like
it
would
almost
waste
down
the
document.
D
Basically
previously
previously
I
was
thinking
that
there
would
be
enough
common
methods
to
describe,
and
then
you
would
have
a
collab
section
describing
how
you
know
using
these
common
approaches,
you
construct
a
solution
for
Co-Op
and
then,
if
you
take
this,
and
this
and
change
a
bit
of
this,
you
would
do
that
for
mqtt.
It
ended
up
not
being
so
that
way.
A
D
Why
I
said,
let's
take
a
step
back
from
mqtt
now,
because
I
don't
even
know
how
to
answer
some
of
the
questions
for
Co-Op
and
the
co-op
help
that
I
I
was
asking
for
is
mostly
about
probably
a
second
eye,
and
it
could
be
resolved
with
a
review
on
another
review.
It
doesn't.
You
know,
I'm,
definitely
happy
to
have
other
co-authors
on
this,
but
more
on
reviewing
the
selection
of
the
key
algorithms
as
well
as
authentication
credentials
to
be
future
proof
as
they
are.
They
are
selected.
D
The
previous
version
of
the
draft
was
not
future
proof
and
there
were
a
number
of
questions
raised
about
Key,
Construction
and
then
kind
of
wrote
it
up
similar
to
the
group
com
oscar,
but
then
the
Key
Construction
Group
Key
Construction
there
uses
a
very
oscar-specific
solution
and
just
I
do
not
think
that
directly
applies
to
the
pub
sub
Co-op.
So
something
needs
to
be
fixed
in
specifically
how
the
group
keys
are
constructed
in
the
in
the
draft.
D
So
that's
I
think
the
major
the
major
mandatory
requirement
that
needs
to
be
addressed,
others
other
questions,
I'm
raising
are
more
or
less
optional
like
we
do
have
a
default
working
solution
described
in
the
draft,
but
since
we
are
trying
to
be
flexible
in
terms
of
token
transfer
methods,
Etc
or
it
would
be
a
good
addition.
If
we
had
a
group
wreaking,
for
instance,
even
though
we
do
have
a
default
solution
described
in
the
draft,
so
all
of
these
are
nice
to
have.
D
Yeah
I
think
the
mqtts,
the
mqtt
sketch
at
the
moment
is
more
or
less
following
the
co-op
for
so
for
getting
the
authorization,
it
is
more
or
less.
There
is
a
solution
for
this
and
then
for
the
KDC
to
get
to
send
the
join
requests
and
response
to
the
groups.
You
know
there
there
could
be
a
sketch
on
this
as
well.
D
The
group
communication
or
the
pub
sub
communication
is
going
to
be
over
mqtt
how
that
is
protected.
That
could
be
also
described.
The
group
re-keying
approach,
the
one-to-one
communication
that
is
necessary
from
that
should
be
initiated
from
KDC
to
the
mqttc
client.
That's
not
very
clear.
So
that
is
the
part
where
there
is
a
struggle
and
that's
that's
the
part
that
needs
to
be
resolved.
Basically,
yeah.
D
D
C
Well,
just
jump
into
the
mic.
I
think
I
can
assist,
especially
on
the
key
usage
and
hopefully
update
and
in
the
alignment
with
key
group
com
overall.
Well
I
reviewed
the
document
before
I
plan.
To
do
it
again,
I
I
think
you
you
prefer
to
wait
for
yet
another
revision
for
for
an
actual
review.
That's
my
guess.
At
least
in
general.
I
can
help
out
see
them.
D
Yes,
thank
you
Marco
I
would
yes,
I
would
like
to
push
another
update,
but
maybe
I'll
send
you
an
email
to
ask
for
your
feedback
on
the
choices
that
I
am
going
to
be
putting
in
that
revision,
a
mother
that
makes
sense
based
on
your
involvement
with
core
pops
up
as
well.
As
you
know,
your
because
you've
re
you've
done
the
Oscar
one
for
groupcom,
so
compared
to
that
whether
that's
kind
of
an
acceptable
choice.
C
D
Thought
about
this,
yes,
I've,
read:
I've,
read
it
through
I've,
read
it
through
I
thought
about
this.
I
left
it
because
I
wanted
to
check
so
I
think
what
I
have
struggled
with
is
that
there
were
certain
choices
or
default
paths
that
were
chosen
by
Francesca
when
she
started
out
the
document
and
I
wasn't
too
sure
how
serious
we
were
to
oh
offer.
D
Those
options
of
you
know
other
flexible
paths
and
Etc,
and
whether
there
was
a
there
was
a
kind
of
a
strong
opinion
to
include
those
other
options
or
not
so
yes,
I
completely
agree
with
you.
If
we
were
to
provide
the
other
dtls
profile,
token
transfer
methods,
then
the
the
one
that
you
describe
in
group
Commerce
course
definitely
can
just
be
taken
and
put
into
this
draft
as
well
or.
D
C
C
But
building
on
that,
you
may
want
to
consider
an
additional
optional
feature
that
is
defining
key
group
com
in
the
first
place,
and
then
it
is
specialized
in
Kiger
com
Oscar,
and
it's
about
the
optional
tagging
of
the
scope
claim,
in
the
access
token,
to
Signal
its
semantics
and
and
thanks
to
the
existence
of
the
file,
major
currency,
I,
don't
remember
the
exact
number
out
of
my
head.
You
don't
actually
need
to
manually
register
a
new
sieber
tag.
You
have
one
automatically
registered
from
the
content
format.
C
D
B
B
D
It
would
be
good
to
have
a
little
bit
Insight
on
to
you,
know,
quiet
pops
up
and
the
security,
the
security
expectations
on
applications
using
Co-op,
Pub
sub,
and
what
kind
of
policies
need
to
be
hosted,
though
that's
the
part
where
I
would
definitely
need
more
input,
as
I
do
not
have
as
much
experience
or
examples
as
I
do
for
mqtt,
for
instance,
for
the
co-op
pops
up.
What
policies
could
look
like
that
needs
to
be
hosted
at
KDC?
B
A
D
Yes,
apparently
I
mean
definitely
if
I,
don't
think
I
neither
Francesca
nor
I
mind
if
there,
if
there
is
other
people
who
would
like
to
join
the
co-author
list,
I
mean
with
Marcos
reviews.
We
can
definitely
add
him
as
a
co-author,
because
he's
made
such
useful
suggestions-
or
you
know,
with
his
reviews
already-
which
some
of
which
were
addressed
and
recorded
in
GitHub.
B
F
Fold
in
more
people
would
be
to
announce
the
design
team
meeting
so
so
Marco
and
you
and
hopefully
Francesca-
would
be
part
of
that
meeting,
but
other
people
could
too
could
also
be
part
of
that
meeting
and
also
make
their
suggestions.
I,
don't
know
if
this
is
helping
or
a
team,
but
I
would
at
least
propose
considering
it.
B
C
C
It
has
always
been
a
must
because
we
couldn't
imagine
reason
to
really
omit
it,
but
then
brought
up
a
good
reason
for
for
the
pub
sub
profile
we're
having
that
parameter
wooden
heart
functionality,
but
it
would
be
a
sub-optimal
in
terms
of
performance.
So
if
you
check
the
issue,
there
is
a
new
alternative
text,
a
change
in
the
mass
to
assured
and
adding
a
sentence
clarifying
good
cases
where
it
should
still
be
included
and
under
which
prerequisites.
C
So
the
issue
is
there
now.
My
proposal
would
be
to
not
rush
implementing
the
issue
in
the
document
as
submitting
yet
another
revision
just
to
not
confuse
Paul
and
instead
waiting
wait
for
the
ad
review
and
when
it
comes,
I
can
very
easily
address
this
point
and
that
new
text
as
part
of
the
ad
review
addressing
unless
this
is
very
urgent
but
yeah
I,
don't
think
so
and
for
consistency.
C
B
C
C
Okay,
the
issue
with
propose
text
is
there.
Thank
you,
yeah
on
kegelcom
Oscar,
it's
in
waiting
for
shipper,
right
up
and
record
accepted
to
to
Shepherd
this
document
he's
on
it
already,
but
with
the
review
and
the
write-up
I've
had
another
look
at
the
document,
myself,
I,
don't
know
if
he
needs
to
to
fix
and
and
this
this
big
part
here
with,
that
figure
is
actually
something
that
Carson
noted
one
day
where
we
were
working
on
on
totally
different
things.
C
C
C
Earlier
this
year,
Francesca
suggested
that
this
is
document
was
sent
to
the
isg
for
the
ASG
convenience
and
together
with
two
other
core
documents,
so
the
exact
way
to
implement
this
may
be
open
to
interpretation
about
the
chairs,
pushing
the
request,
publication
button
or
a
responsible
ad
holding
on
their
list.
Cam
documents,
I
I,
don't
know,
but
I
just
wanted
to
raise
this
up,
and,
and
probably
it's
good
anyway.
B
B
B
F
Well,
my
working
group
chair
view
is
somewhere
buried
in
in
my
head,
so
I
would
have
to
look
these
two
documents
and
then
the
current
status
up
again.
But
yes,
indeed
this
these
could
be
shipped
to
the
ad,
with
Shepherd
comment
that
these
are
meant
to
be
clustered
with
the
two
other
documents
which
are
coming
out
well
not
next
week,
but
in
in
reasonable
time.
F
We
have
different
different
ads,
so
yeah
one
one
thing
that
is
occasionally
done
in
cases
like
this
is
that
an
idea
of
a
different
area
of
one
of
the
two
areas
takes
over
the
whole
cluster.
So
we
we
have
an
a
common
view
on
this,
so
this
is
at
least
something
that
that
should
be
mentioned
as
a
possibility.
F
B
Okay,
yes,
so
yeah.
What
I
see
is
that
where,
where
when
so
at
the
time
we
will
have
addressed
the
shepherd
review,
I
I
will
try
to
Ping
the
the
two
ads
and
the
multiple
the
working
group
chairs
and,
in
my
case
I,
have
no
opinion
on
who
Hades
should
take
that
over
and
I
think
if
we
are
the
first
to
be
to
be
ready,
it's
gonna
be
on
the
shoulders
of
the
core
chairs
to
say
when
the
full
cluster
is
ready
right.
B
C
Definitely
and
I'll
try
to
be
quick.
Yes,
an
update
on
remote
token
notification.
Next
slide,
please
to
rack
up.
This
is
addressing
the
case
that
was
not
addressed
before
where
tokens
can
be
revoked
before
they
reach
the
natural
exploration
for
a
number
of
reason,
and
there
was
no
way
or
easy
way
for
the
interested
parties
to
to
learn
about
that.
The
best
thing
around
was
introspection
that
is
limited
to
the
resource
server
with
the
number
of
limitations.
C
So
here
we
are
defining
essentially
interface
at
the
authorization
server
that
both
client
and
resource
server
can
use
to
learn
about
revoke,
but
not
yet
expired
access.
Tokens
pertaining
them
issuing
a
get
to
a
dedicated
resource
at
the
authorization
server
or
more
conveniently
observing
it
to
obtain
automatic
notifications-
and
this
is
not
intended
to
be
a
replacement
for
introspection,
but
it
complements
it
nicely
and
there's
no
need
for
new
resources
or
endpoints
at
the
client
and
resource
ever
next
slide.
C
Please
yeah
I
showed
this
before,
but
this
is
now
aligned
with
latest
updates.
We've
also
made
this
can
be
used
with
two
modes
of
operation.
The
first
one
has
to
be
supported
by
the
AES
and
it
allows
a
client
or
resource
server
to
really
obtain
the
full
list
of
revoked
access
tokens
pertaining
to
to
that
client
or
resource
server.
C
C
Okay,
next
slide,
please
and
I
think
a
lot
happened
since
March
in
Vienna
when
we
presented
the
draft
for
the
last
time.
We
had
two
more
revisions
since
then.
Also,
thanks
to
yet
another
review
we
received
from
from
Marcos
sorry
next
slide,
please,
and
just
to
summarize
what
happened
during
the
the
revision
yeah
the
use
of
the
course
on
from
a
third
mode
of
it.
C
Actually,
we
concluded
that,
even
if
a
little
less
efficient,
it's
way
easier
to
understand
and
to
implement
to
have
all
the
messages
from
the
authorization
server,
at
least
from
that
resource,
to
have
a
c
board
map
as
payload,
so
that,
of
course,
produce
a
number
of
additional
case
and
coordinate
cases
to
to
handle
that
that
we
did
and
I
also
wanted
to
mention
that
some
editorial
fixes
and
included
also
suggestions
on
the
pr
from
from
David
Navarro.
That
also
contributed
next
slide.
C
Please
thanks
yeah
for
the
London
meeting
we
actually
produced
yet
another
revision,
considering
also
the
review
from
Marco,
and
we
further
improved
the
possible
use
of
the
cursor
extension
in
order
to
admit
a
rep
around
of
the
index
used
as
practical
cursor
that
was
not
supported
yet
and
now.
It
is
so
in
principle
that
this
pattern
can
go
on
forever,
just
nicely
handled
in
case
of
referral.
C
That,
of
course
required
to
introduce
some
more
common
stance
and
internal
parameters
to
the
AES
to
to
keep
track
of
that
and
manage
that
correctly.
On
top
of
that,
just
just
clarifications
next
slide,
please
so
what's
left,
we
definitely
still
need
to
add
an
example
of
messages,
message:
exchanges
where
the
query
mode
is
used.
C
B
A
A
E
F
C
B
Yeah
yeah,
that's
one
thing
so,
okay
right!
So
so
we
can
do
that
and
also
you
can
use
the
meeting
list.
If
you
want
to
raise
some
issues
so
I
think
what
would
we
well?
The
point
I
see
is
that
we
we're
trying
to
make
progress
on
the
pub
sub
and
I'm
pretty
confident
that
we
can
make
quite
I,
don't
see
anything
that
should
prevent
us
to
have
a
working
group
last
call
for
the
token
draft.