►
From YouTube: ACE WG Interim Meeting, 2020-09-07
Description
ACE WG Interim Meeting, 2020-09-07
A
Go
ahead,
okay,
so
for
agenda
bashing
I
was
saying
I
wanted
to
request
a
little
bit
more
time
for
today,
because
so
I
only
had
planned
to
discuss
one
one
question
for
or
ayanna
question,
but
then
we
got
a
good
review
from
john
yesterday
and
I'd
like
to
discuss
some
of
these
points
today,
so
it
might
take
a
little
bit
longer
than
the
10
minutes.
I
asked
for
so
next
slide.
Please.
B
Okay,
so
just
for
the
sake
of
information
because
recording
is
just
being
started,
we
have
shown
the
not
well
slide
just
before
the
recording
started,
and
here
we
are
so
next
slide.
A
Yes,
so
the
status
of
the
document.
First
of
all,
all
the
reviews
from
the
last
call
were
addressed
before
john
posted.
This
his
review
and
the
the
one
from
the
upstairs
was
okayed
and
then
from
the
gen
art
review.
There
was
just
one
comment
left
about
being
clear
about
encryption,
authentication
status
of
the
various
messages
that
wasn't
addressed
slide.
Please.
A
We
use
these
new
parameters
that
we
need
to
register
these
non-s1
and
nods2
that
are
sent
in
the
client
to
resource
server
and
resource
server,
to
client
messages
and
from
what
I
understand.
These
need
to
be
understood.
A
These
need
to
be
registered
in
the
oauth
parameters
registry,
which
I
linked
here
and
this
the
template
for
doing
this
registration
is
not
clear
on
what
would
be
the
right
location
to
use
and
the
process
to
get
this
registered
is
to
to
send
a
registration
request
to
the
designated
expert,
and
in
this
case
it's
hannes
who
is
not
on
the
call
today,
and
so
since
the
template
does
not
specify
a
location
for
this
client
resource
server
resource
server
to
client
messages.
A
I
think
my
proposal
will
be
to
come
up
with
a
good
name
for
these
two
messages,
and
then
I
would
send
this
to
johannes
and
and
let's
see
if
he
accepts
it
or
if
he
complains.
I
just
want
to
mention
for
anybody
who
has
not
been
participating
in
the
discussion.
The
mailing
list
that
there
are
almost
all
parameters,
use
the
template
locations,
but
there
is
a
couple
of
of
parameters
that
use
different
names,
so
he
might
just
go
ahead
and
accept
an
accepted
different
name
than
those
in
the
template.
A
I
don't
really
know
so.
If
anybody
has
proposals
on
good
names
for
these
two
messages,
then
we
can
take
those.
A
Okay,
I'll
just
give
it
a
try
and
and
send
it
to
the
main
list
so
to
the
ace
mailing
list,
and
then,
if
no
one
objects
after
a
couple
days,
I
will
send
it
to
the
designated
expert
and
then
a
second
comment
was
where
to
put
this
new
oscar
security
context,
parameters,
registry
and
ludwig
was
suggesting
we
put
it
into
under
the
ace
page.
A
I
thought
core
was
better
choice,
just
because
that's
where
all
the
oscar
stuff
is.
A
C
A
Not
right
now,
but
it
might
be
this,
this
structure
might
be
used
somewhere
else,
but
it
doesn't
really
matter
it's
just
where
to
put
it,
it
can
be
found
anywhere.
So,
okay,
it's
fine
for
me
to
go
for
ace.
The
next
slide.
A
We
had
one
negotiation
for
one
of
these
two
parameters
before
so
the
rs
could
choose
the
client
sender
id
and
that
was
removed
because
it
was
too
complicated
and
following
ben's
review
and
several
meetings
that
was
removed
and
so
right
now
we
have
the
following
mechanism
to
set
up
these
identifiers,
and
the
mechanism
is,
is
the
following:
the
asc
identifier,
both
for
client
and
server
and
those
are
sent
in
the
access
token
and
in
the
rs
information
and
yeah.
That's
it.
A
Next
slide,
please
john,
and
this
is
text
from
his
mail,
which
you
can
read
here
and
I'm
I'm
sure
that
some
people
will
not
have
seen
this
email
because
it
might
have
come
yesterday,
late
or
early.
A
The
co-op,
client
and
co-op
server
roles
are
fixed
and
cannot
be
switched.
So
the
the
client
and
server
will
not
reverse
roles
and
only
draft
itfa
score
profile
is
used,
so
if
only
the
oscar
profile
is
used,
and
in
another
case,
if
you
take
any
order
of
these,
then
this
can
cause
recipient
id
collisions
and
also
in
future
system.
Where
the
as
supports
something
like
an
addock
oscar
profile,
then
you
cannot
have
both
the
current
oscar
profile
and
the
adulkoscope
profile
at
the
same
on
the
same
node.
A
A
Slide
yes,
so
the
proposal
that
john
brought
up
is
the
following:
that
each
node
picks
the
sender
id
of
the
other
node.
So
the
client
picks
the
sender
id
of
the
resource
server
and
the
resource
server
picks
the
sender
id
of
the
client
and
they
exchange
this
at
the
same
time
as
the
post
to
authorization
info
together
with
the
token
and
then
on
the
response
to
that.
A
We
can
go
to
the
next
slide.
I
think
consequence
of
that
would
be
that
also
the
oscar
security
context.
Object
would
need
a
new
identifier,
because
right
now
also
security
context.
Object
is
identified
with
the
sender
id
of
the
client
and
the
id
context,
and
we
can
separate
that,
like
we
won't
have
the
sender
id
sent
in
the
oscore
security
context
object
anymore,
and
we
need
to
have
an
identifier
of
this
object.
A
This
identifier
is
used
when
the
client
wants
to
talk
to
the,
as
he
can
send
this
identifier
to
identify
this
input
key
material.
It
could
be
a
nominator.
It
could
be
a
hash
of
this
object,
but
yes,
so
the
question
is
so.
This
is
a
big
change.
So
if
we
wanted
to
go
forward
with
this
change,
it
will
probably
bring
it
back
to
the
working
group.
I
assume.
D
Two
follow
up
comments
on
your
presentation.
Francesca
the
problems
would
be
collisions
or
large
messages.
It's
obvious.
If
you
have
long
random
ideas,
everything
works
without
collisions,
but
then
it's
not
efficient.
D
A
Yeah,
but
I
just
had
sender
id
because
enos
core
terminology,
that's
what
it's
is:
sent
the
sender
id
of
the
node,
sending
the
message
when
it's
the
request
but
yeah.
It's
the
same
thing.
A
The
point,
though,
is
that
with
oscor
you
set
up
the
oscar
security
context
and
then
you
could
switch
roles.
You
need
to
set
that
to
post
a
talk
on
what
was
previously
the
co-op
client,
but
you
use
the
same
oscar
security
context
to
protect
communication
in
both
directions.
E
Yeah,
I
think
it's
a
good
point,
jim,
that
there
is
sort
of
there
needs
to
be
reverse
setup
as
well
with
where
we
had
the
two
endpoints
both
need
to
be
contacting
the
as
and
requesting
tokens
and
posting
them
to
the
other
endpoint.
E
So,
but
but
the
result
yeah
so
yeah,
it's
a
good
question.
Can
we
use
the
same
as
core
security
context
for
both
these?
Perhaps
not
that's
true.
D
A
Score
ask
for
protect
the
communication,
but
without
a
need
for
access
rights
to
be
posted
at
the
previous
co-op.
A
A
Nothing
prevents
it,
but
there
might
be
on
the
client
or
the
previous
client.
The
ace
client.
C
A
E
A
Same
a
couple
of
slides
just
to
go
to
the
picture,
maybe
slide
fix.
C
But
you're
talking
about
situations
which
are
not
new,
we've
we've
discussed
that
as
a
problem
for
some
time,
and
we
have
decided
at
the
moment
that
we
don't
care
about
that
problem.
So
now
you're
suddenly
deciding
you
care
about
the
problem.
A
A
A
I
am
thinking
we
might
want
to
fix
this,
and
I
understand
the
document
is
yeah.
It's
a
bit
of
it's
bit
of
a
shame
that
it
comes
only
now.
A
C
F
A
Okay,
that
could
be
one
way
forward.
I
I
think
this
is
to
implement
in
the
document
it's
an
easy.
It's
easy
to
do
as
you
can
imagine
it's
just
adding
two
more
parameters
and
removing
them
from
the
the
object
that
the
aes
sends.
D
C
E
D
You
get
less
and
less
collisions,
but
you
will
still
get
collisions.
I
don't
know
how
serious
it
would
be
and
how
much
of
a
corner
case
the
collisions
would
occur
in.
C
D
I
don't
think
my
migration
path
to
ad
hoc
has
been
discussed.
I
don't
think
rule
switching
has
been
discussed.
C
Well,
I
I
don't
believe
that
role,
switching
is
a
problem,
so
you're
not
going
to
convince
me
with
that,
and
when
I
brought
the
issue
up
quite
a
while
ago,
I
discussed
both
the
issue
of
multiple
as's
and
the
issue
of
getting
identifiers
assigned
outside
of
the
ax
as
being
issues
and
at
that
point
in
time
the
decision
was.
It
was
not
a
big
enough
problem
to
deal
with.
So
I'm
having
a
hard
time
saying
it's
a
big
enough
problem
to
deal
with
now.
C
C
If,
if
you
put
the
same
context
onto
multiple
rss,
that's
going
to
be
a
problem,
but
that's
already
known
to
be
a
problem
and
it's
something
that
right
now
we're
saying
you're
not
supposed
to
be
doing.
C
Otherwise,
yes,
you
have
a
collision,
you
also,
if
you
put
it
on
multiple
rs's,
you
have
a
huge,
even
larger
problem
than
that
which
is
you
are
going
to
reuse,
ivs.
D
D
A
I
think
if
more
people
were
to
pitch
into
the
male
thread
that
john
has
started,
that
would
be
helpful.
I
know
we
discussed
previously
about
identifiers
and
creation
and
several
aes
and
several
auras
etc,
but
we
did
not
discuss
this
role
switching
particularly,
and
I
did
not
yeah
I.
I
did
not
think
about
running.
A
Something
like
an
adult
profile:
yeah
they're
on.
A
Yeah,
as
I
said,
the
change
would
be
a
practice
more
like
the
the
the
written
text,
but
it's
a
big
change
in
in
in
concept.
So
I
would
assume
that
if
we
were
to
do
this
change,
the
document
would
be
delayed
quite
a
bit.
I
don't
know
exactly
how
how
much
I
think
for
this
either
gym
or
well.
That
is
not
here,
but
there's.
C
C
A
Okay,
so,
hopefully
now
you've
got
the
overview
of
of
what
would
be
changing,
which
is
the
aes
would
not
be
picking
out
the
identifiers
for
sending
id
for
the
cloud
and
the
resource
server,
but
this
will
be
negotiated
at
the
same
time
as
the
nonsense
are
sent-
and
I
think
john
mentioned
in
his
email
that
this
will
be
in
the
same
way.
A
D
I
think
the
negotiator
mechanism
in
the
adult
was
initially
suggested
by
jim
himself,
referring
to
in
a
similar
she
asking
to
do
it
in
a
similar
way
that
I
do
it.
If
I
remember
correct.
A
The
negotiation
that
we
discussed
and
shook
down
for
was
only
about
the
client's
identifier,
where
the
as
would
assign
a
client
identifier,
and
then
the
researcher
would
say
no.
I
don't
like
this
take
this
instead,
which
is
different
from
this
change.
The
what
we
would
do
here,
because
in
this
case
the
as
would
not
assign
identifiers
at
all-
and
it's
completely
up
to
the
client
and
research
server
to
to
send
identifiers
to
each
other.
A
So
yeah
it
it's
different
from
what
was
discussed
and
down
and
was
shut
down
because
it
was
too
complicated,
and
that's
also
what
makes
me
think
that
if
we
do
an
update
to
this
document,
where
we
with
this
document,
as
is,
we
left
the
ais
at
client
id
and
server
id.
So
these
two
identifiers,
then
we
do
an
update
where
the
client
can
still
negotiate.
B
So
I'm
just
wondering
if
it
would
help
to
given
the
so
I
haven't
read
the
john
say
email.
So
I
guess
in
john's
email
we
explain
some
the
problem,
I'm
wondering
if
it
would
make
sense
to
and
it
would
ease
to
understand
what
are
the
changes
by
just
proposing
it,
showing
a
diff
with
the
existing
document
and.
A
Make
sure
you
do
that
yeah,
I
could
do
that
and
keep
it
on
a
separate
branch
and
keep
it
in
the
github
just
to
have
an
idea
of
what
what
the
changes
would
be,
and
that
would
also
allow
for
people
to
reason
over
and
to
analyze
and
see
like.
Are
we
missing
big
security
considerations
or
analysis
or
anything
else?.
B
Yeah,
so
one
thing
is,
is
to
to
add
some
text
or,
but
just
to
make
sure
that
I
mean
the
I
mean
the
purpose
is
not
to
it's
just
to
make
it
right
not
to
to
minimize
the
changes.
Make
sure
that
some
of
the
former
assumptions
are
appropriately
appropriately
changed
and
and
that's
yeah
I
mean
the
the
the
full
document
is
current.
B
That's
the
the
thing
we
that's
the
the
major
issue
I
would
say
is
to
have
now
at
that
stage
a
document
that
is
not
current,
so
it
is.
B
A
F
B
B
And
then
we
will
see
how
we
make
that
if
we
make
it
or
how
we
make
it.
A
Yeah,
so
I
and
I
had
a
couple
more
slides
and
it
was
about
minor
minor
comments
that
john
had
and
it's
about
names
of
parameters
and
of
objects
to
clarifications,
and
then
there
was
a
comment
on
head
about
server
authentication.
A
So
this
is
also
more
about
clarifying
that
server
authentication
requires
two
additional
things
that
are
is
not
very
clear,
and
then
it
was
a
point
about
appendix
b2.
And
how
can
these
appendix
b2
used
after
asos
core
profile
is
used?
But
we
don't
need
to
take
this
now
because
we
spent
a
lot
of
time
on
on
the
other
comment
and
yeah.
That's
it.
So
I
guess
we'll
be
continuing
the
discussion
in
the
main
list
or.
A
B
A
Will
also
very
much
appreciate
ben
to
pitch
in
and
give
his
opinion
as
a.d.
B
Yeah,
I
think
my
my
feeling
is
that
first,
the
discussion
should
be
within
the
working
group
and
and
once
we
we
have
a
plan
we
may
ping.
B
B
B
Yeah
yeah,
it's
a
working
group,
that's
cool!
So
yes,
it
would
be
appreciated
to
go
through
through
the.