►
From YouTube: IETF112-DISPATCH-20211108-1200
Description
DISPATCH meeting session at IETF112
2021/11/08 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
Or
a
beverage
of
your
choice,
they're
exchangeable.
If
you've
already
got
spanish
beer,
I
can
see
in
the
chat
so
super.
Thank
you
for
volunteering.
If
anyone
wants
to
head
over
to
the
new
hedge
dock
site
that
we've
got
to
help
take
notes,
that
would
also
be
appreciated
as
well.
Thank
you.
Bronn.
A
So
hopefully
everyone's
got
their
audio
set
up.
Okay
and
you
can
see
the
slides
as
well
that
we're
projecting.
So
if
either
of
those
things
aren't
showing
for
you-
and
you
can't
hear
me-
then
maybe
refresh
or
follow
some
of
the
echo
troubleshooting
stuff
that
we've
got
going
on.
A
Okay,
well
we're
at
12
o'clock.
So
let's
get
the
party
started:
welcome
to
itf
112.
the
dispatch
working
group,
art
area
virtual
meeting
the
first
session
of
the
week
as
always
delighted
to
have
you
here.
I'm
kirsty
payne,
one
of
the
co-chairs
of
dispatch
and
we've
got
patrick
mcmanus,
as
my
other
co-chair
here
as
well,
so
we're
gonna
run
through
the
note.
A
So
do
read
that
through
and
just
be
aware
that
by
participating
in
the
itf,
you
agree
to
all
of
these
procedures,
so
have
a
read
through
the
anti-harassment
procedures,
the
code
of
conduct,
copyright
working
group
procedures,
internet
standards,
procedures,
patents,
participation
and,
of
course,
the
privacy
policy.
A
You
will
have
agreed
to
this
when
you
registered
for
the
meeting,
but
just
to
make
a
little
note
of
it.
Now
especially,
note
really
well,
and
so
we're
just
going
to
highlight
these
few
things
as
a
new
push
for
this
itf.
So
you
might
see
this
in
a
few
other
working
groups
as
well.
Please
really
take
a
moment
to
look
at
the
guidelines
for
contact
the
anti-harassment
policy
and
the
anti-harassment
procedures.
A
Those
are
all
the
rfcs
and
links
on
the
slides
which
you
can
find
on
the
meeting
materials
in
the
echo
or
on
the
dispatch
page
as
well,
and
if
you
have
any
concerns
about
observed
behaviors,
please
talk
to
the
old
woodsman
team.
They
are
there
they're
available.
If
you
need
to
confidentiality,
confidentially
raised
concerns
about
harassment
or
other
conduct
in
the
itf.
A
It's
really
important
that
we
have
a
creative,
maintain,
an
environment
that
where
people
can
be
treated
with
dignity,
decency
and
respect,
and
that
allows
us
to
do
our
best
creative
work.
So
those
who
participate
in
the
itf
should
have
behavior
according
to
professional
standards
and
appropriate
workplace
behavior
do
not
engage
in
harassment
and,
if
you
believe,
you've
been
harassed
like
we
said,
please
raise
it
with
the
ombuds
team.
A
Okay,
so
move
on
to
a
little
bit
about
virtual
meeting
participation.
This
might
be
your
sixth
virtual
meeting
at
the
itf.
It
might
be
your
first
one,
but
just
as
a
for
your
awareness,
this
session
is
being
recorded.
So
please
use
a
headset.
You
can
add
yourself
to
the
echo
queue
to
speak
and
say
your
name
before
speaking
so
you'll
see
that
on
the
top
left
of
your
screen,
there's
a
little
hand
with
a
line
through
it.
A
If
you
click
that
that
puts
you
in
the
queue
and
then
the
chairs
can
call
you
forward
or
the
presenter
can
call
you
forward
in
the
queue
and
then
you'll
see
a
few
kind
of
buttons
along
the
top.
You
can
start
your
video
and
you
can
share
your
audio
as
well.
We
ask
you
not
to
share
your
video
unless
you
are
speaking
just
to
help
others
with
bandwidth
issues,
side,
discussions
in
jabba
that
you
can
see
on
the
left
of
your
screen
in
that
chat.
A
They're
fine,
but
please
do
consider
bringing
important
points
to
the
queue
for
the
recording
and
for
those
of
you
that
remember
in
person
meetings
you
don't
have
to
worry
about
blue
sheets.
That's
all
taken
from
the
meat
echo
roster,
so
we've
got
some
useful
links
on
this
slide.
Anything
about
meeting
materials
and
stuff
like
that
are
on
the
dispatch
session
pages.
A
A
So
with
that
kind
of
bit
done
and
we'll
look
at
the
dispatch
virtual
meeting
that
we've
got
going
on
today,
so
here's
our
agenda
just
nearly
one
minute
to
go
to
finish
this
sort
of
status
and
the
gender
bash
from
chairs.
Ladies
we've
got
a
couple
of
items
this
morning
in
dispatch
and
just
to
mention
and
the
media
over
quick
item
in
the
art
area,
which
is
new
kind
of
a
shout
out,
but
the
timing
there
is,
unfortunately,
not
right.
A
It
will
just
be
after
at
the
end
of
the
art
area
meeting
and
we'll
just
sort
of
do
a
quick
mention
on
media
over
quick.
But
that
item
is
new
and
those
slides
were
just
uploaded
this
morning.
So
do
take
a
look
at
that
if
you
would
like
to
participate
in
that
discussion,
it's
just
for
info
really.
A
A
A
B
Great,
thank
you
so
much
kirsty.
This
is
my
first
participation
in
iutf.
So
it's
a
pleasure
to
be
here
and
hello
from
the
west
coast
bright
early
in
in
the
morning.
B
Some
use
cases
do
necessitate
sharing
of
these
credentials
from
one
person
to
another.
So,
for
example,
you
may
have
a
vehicle
and
a
digital
key
on
your
mobile
device
that
allows
you
to
unlock
and
operate
that
vehicle,
and
you
may
endeavor
to
share
this
credential
with
a
family
member
or
a
friend
or
a
valet.
B
B
B
This
also
must
work
for
symmetric
and
asymmetric
credentials,
so
I'm
just
going
to
spend
a
few
seconds
talking
about
this.
A
symmetric
credential
would
be
something
akin
to
a
my
fair
desk
fire
applet.
My
fair
desk
fire
is
a
very
popular
technology
in
the
access
space
for
corporate
offices,
hotels,
sometimes
even
transit
around
the
world,
and
then
there
are
asymmetric
keys
that
are
used.
One
example
of
an
asymmetric
key
would
be
the
iso
one.
Eight
zero
one,
six
specification,
that's
an
asymmetric,
credential
and
then
also
digital
car.
B
Key
credentials
are
asymmetric
as
well.
There's
the
ccc,
the
car,
the
connected
car
consortium,
public
standards
body
that
specifies
how
these
keys
work
for
vehicles
that
the
vast
majority
of
the
oems
participate
in
and
that's
how
those
keys
work
across
different
types
of
vehicles.
B
So
that's
a
very
important
feature
here
if
you've
shared
your
key
to
your
home
or
your
vehicle,
and
you
wish
to
revoke
that
share,
you
should
be
able
to
do
that
and
then
we
also
want
the
ecosystem
to
support
any
mobile
device
operating
system.
Oem
that
adheres
to
the
standard
being
proposed
here,
so
this
should
work
between
devices,
running
apple's,
ios
platform
or
google's
android
platform,
or
any
other
mobile
operating
system
that
chooses
to
participate
in
in
this
standard
I'll
also
just
touch
really
quickly.
B
A
couple
of
folks
in
the
email
group
had
some
really
great
questions,
and
I
just
want
to
touch
on
one
of
them
really
fast
on
this
slide,
which
is
the
ability
to
actually
share
these
credentials
themselves
on
mobile
devices.
These
credentials
are
stored
in,
what's
called
a
secure
element.
The
secure
element
is
a
tamper,
resistant
piece
of
hardware
they're,
almost
always
single
threaded
and
part
of
those
secure
elements
is
that
it's
impossible
to
extract
a
credential
or
or
it's
you
know
extremely
difficult
to
extract
a
credential
from
them.
B
B
Once
the
receiver
receives
this
data,
it
will
likely
need
to
contact
a
server
which
is
typically
the
credential
authority
in
order
to
actually
provision
a
credential.
In
other
words,
it's
not
the
credential
itself
that
is
sent
between
sender
and
receiver.
It
is
some
metadata
or
some
seed
data,
some
authorization
data
in
order
for
the
receiver
to
be
able
to
procure
such
a
credential.
B
The
relay
server,
also
from
a
privacy
perspective,
should
only
receive
data
that
is
field
level
encrypted
and
then
some
high-level
metadata
for
the
receiver
to
be
able
to
understand
what
it's.
What
it
has
just
received.
B
Some
of
the
design
requirements
here
include
that
the
relay
server
should
not
know
the
identity
of
the
sender
nor
of
the
receiver.
So
in
the
internet
draft
there
are
some
additional
complexity
listed
for
having
anonymous
attestations
to
authenticate
the
sender
that
don't
disclose
the
identity
of
the
sender.
B
This
relay
server
also
shall
not
interface
with
any
other
server.
It's
purely
used
for
transport
between
sender
and
recipient
and
in
some
cases,
vice
versa.
Back
from
recipient
to
sender,
as
I
mentioned,
all
of
the
sensitive
data
over
the
relay
server
is
field
level
encrypted,
ensuring
that
the
relay
server
cannot
see
what
is
being
shared
and
the
sharing
should
be
able
to
be
initiated
or
occur
for
in
any
communication
channel.
This
could
be
email.
This
could
be
sms
or
imessage,
or
a
whatsapp
application.
B
So
in
the
lower
left
of
your
screen,
that's
the
sending
device,
that's
the
device
that
ostensibly
already
has
a
credential
provisioned
on
it
that
wants
to
share
to
the
the
box
in
the
lower
right.
That
is
the
receiving
device
in
the
bottom
middle.
There
is
the
communication
channel
itself.
This
could
be
whatsapp,
sms,
email
or
anything
else
in
the
middle
of
your
screen
is
the
relay
server.
That
is
this
new
actor
in
the
ecosystem
that
that
we've
been
proposing
transport,
the
data
between
sender
and
receiver.
B
There
are
a
number
of
reasons
for
the
relay
server,
I'm
hoping
we
can
get
into
some
q
a
after
the
slides
and
talk
about
it.
The
metadata
required
to
provision
these
credentials
is
oftentimes
fairly
large,
maybe
500,
bytes
or
a
kilobyte,
and
that
data
obviously
can't
travel
in
a
single
sms
message.
It
would
also
be
very
confusing
to
the
user
if
they
saw
you
know,
binary
data
that
was
encoded
in
hex
or
base64
traveling
in
their
actual
message
channel.
B
So
by
sending
a
url
in
number
three
that
points
to
the
data,
you
can
have
a
much
better
experience
for
the
receiver,
with
the
data
actually
being
procured
from
the
relay
server
in
the
upper
left
of
your
screen,
device
operating
system,
manufacturer
server
and
then
same
thing
on
the
upper
right.
This
would
be
a
server
that's
owned
and
operated
by
apple.
B
If
the
sender
was
an
iphone
or
an
apple
watch
or
by
google,
if
the
sender
was
an
android
device
and
then
vice
versa
for
the
receiver,
so
it's
basically
the
operating
system
on
the
mobile
device,
whichever
company
builds
that
operating
system
and
operates,
it
would
be
that
server
that
you
see
there
in
the
middle
top
of
your
screen,
credential
authority.
B
So
when
you
look
at
these
types
of
credentials,
there's
almost
always
a
remote
credential
authority
that
is
issuing
these
credentials,
and
this
credential
authority
typically
is
the
only
entity
that
can
issue
them.
So,
for
example,
if
you
were
sharing
a
hotel
key
that
credential
authority
would
be
you
know,
for
example,
the
hyatt
company
as
one
example
I
mentioned
earlier,
why
you
can't
just
send
a
credential
from
the
sender
to
the
receiver.
You
also
can't
duplicate
it.
You
can't
clone
them.
These
are
all
security
primitives
of
the
secure
element
on
the
sending
device.
B
The
credential
authority
would
be
the
only
entity
that
can
issue
a
credential,
so
the
basic
flow
starting
in
the
lower
left
and
going
up
with
number
one.
The
sending
device
is
effectively
reaching
out
to
the
credential
authority
through
the
oem
server
and
obtaining
effectively
a
bearer
token
authenticating
to
the
credential
authority.
B
As
the
sender
that
already
has
a
current
provision
credential
that
credential
authority
will
mint
a
new
bearer
token
and
store
it
and
send
it
back
down
to
the
sender.
And
then
the
sender
is
going
to
be
wrapping
this
data
up,
sending
the
data
to
the
relay
server.
B
The
relay
server
will
generate
a
url
for
the
relay
server
itself.
The
uri
will
be
highly
defined
in
the
specification
the
url
could
be
whatever
the
relay
server
wants
to.
That
might
give
spatial
locality
for
bandwidth,
depending
on
where
you
know
folks
are
in
the
world
or
load
balancing.
You
know
if
you
want
to
have
different
shards,
and
then
the
sender
will
send
this
url
over
the
communication
channel
down
at
the
bottom
here
to
the
receiver.
B
The
receiver
will
download
the
data
from
the
relay
server
and
provision
or
register
this
credential
against
their
own
device,
os
oem.
That
then
goes
to
the
credential
authority,
exchanging
the
bearer
token
for
a
newly
minted
credential.
B
It's
also
worth
noting
we
were
thinking
of
using
open
graph
as
a
data
structure
for
the
contents
of
the
link
when
an
http
get
is
called
on.
The
relay
server
open
graph
is
a
very
popular
standard,
as
I'm
sure
a
lot
of
folks
on
this
call
would
be
aware
that
allows
for
rich
preview.
B
I
think
I
think
with
that.
That's
the
the
basic
presentation
that
I
wanted
to
describe
for
how
it
works.
I
know
kirsty
mentioned
that
we
do
have
a
little
bit
of
extra
time
today,
which
is
great.
I
know
there
were
some
questions
over
the
email
group
from
eric
and
from
others
I'd
be
happy
to
answer
those
or
if
we
wanted
to
take
some
questions
from
folks
in
the
chat
again.
C
Is
patrick,
I'm
christie's
co-chair
here
going
to
help
run
the
queue
during
this
part
of
the
discussion
so
great.
I
wanted
to
start
by
thanking
you
for
bringing
this
to
the
ietf.
I
really
appreciate
it.
There
are
a
few
very
interesting
elements
here
and
we'll
see
whether
or
not
folks
think
this
is
an
appropriate
ietf
work
item
or
not,
but
either
way.
I
do
appreciate
you
bringing
it
in
a
reminder
to
our
group
because
it
is
the
first
meeting
of
the
week.
D
C
To
figure
out
what
the
right
group
of
people
the
right
form
it
is
to
work
on
so
matt.
I
do
have
one
question
for
you
before
and
feel
free.
I
see
pete's
in
the
queue
feel
free
to
join
the
queue
we
do,
as
matt
said,
have
a
little
more
time
than
usual
with
a
light
agenda,
so
we
won't
be
too
strict
on
staying
into
our
time
window.
C
So
we
can
do
some
discussion
of
what's
in
the
draft
as
well
as
its
outcome,
if
it's
helpful
in
figuring
out
the
outcome
so
matt,
I
do
have
one
question
before
we
get
started
just
what
is
the
sort
of
state
of
the
technology
described
by
this
draft?
Is
this
conceptual
and
all
change
control
will
live
with
the
iatf
if
the
iatf
chooses
to
adopt
this
work?
Is
this
something
that's
already
been
deployed
and
there's
some
constraints
around
that
that
kind
of
thing,
if
you
could
kind
of
give
us
some
flavor
I'd
appreciate
it.
B
Yeah,
absolutely
patrick,
I
would
say
it's
somewhere
in
between.
We
have
there
have
been
meetings
between
some
companies
around
this
topic
so
far,
so
one
of
the
topics
here
has
been.
B
This
is
a
cross-platform
sharing
mechanism
that
would
need
to
be
adopted
by,
for
example,
the
vehicle
oems,
and
so
we
have
been
having
some
preliminary
discussions
with
both
the
device
os
oems,
as
I
mentioned
before,
so
that
would
be
google
and
apple
and
and
others,
and
then
also
the
vehicle
oems,
because
there
is
currently
a
sharing
protocol
defined
in
the
ccc
standard
that
we
are
actually
proposing
to
remove
and
reference
the
ietf
standard
for
a
more
global
and
cross-platform
and
open
channel
solution.
B
So
we
have
had
some
discussions
with
the
ccc
body
as
well,
and
so
there's
no
there's.
No.
The
feature
is
not
launched
yet,
but
we
do
have
plans
to
build
something
like
this,
and
we
will,
you
know,
obviously,
would
love
to
take
feedback
and
and
make
the
solution
better
from
the
ietf
group.
But
there
are
concrete
plans
to
implement
a
solution
that
satisfies
the
goals
described
in
this.
In
this
presentation,.
C
Okay,
thank
you
for
that.
Would
you
like
me
to
open
up
the
queue
or
would
you
like
to
address
any
of
the
comments
from
the
mailing
list?
First
I'll,
leave
that
up
to
you.
B
I
think
eric
roscorla-
hopefully
I
did
not
butcher.
Your
last
name
had
a
number
of
great
questions.
Maybe
I
can
touch
on
those
really
quickly
and
yeah.
C
He
is
in
the
queue
as
well.
I
thought
you
might
want
to
address
ted's
comments.
I
know
ted
cannot
make
the
meeting.
B
C
C
Sake
of
time,
pete
you're
first.
F
Okay,
yeah,
why
not
use
saml,
I
mean
like
it
exists
as
a
standard.
It
was
designed
to
do
exactly
this.
B
I
I
may
not
be
familiar
with
that.
Can
you
describe
it
a
little
bit.
F
F
It's
the
way
that
pretty
much
every
piece
of
enterprise
software
will
talk
to
and
pretty
much
every
other
piece
of
enterprise
software
under
the
covers,
where
a
needs
to
authenticate
to
be
there
is
a
binding
to
html
and
the
web,
of
course,
but
you
don't
have
to
do
that.
You
can
do
it.
You
can't
do
it
without
I've
not
been
involved
in
that
world
for
well
over
a
decade,
but
it
it
does
exist.
It
is
widely
supported.
B
B
I
think,
the
the
main
architectural
piece
that
I'm
trying
to
highlight
that
I
think
there's
a
gap
for
is
that
the
messages
can't
be
sent
directly
from
the
sender
to
the
receiver.
B
The
credential
itself
cannot
be
extracted
from
the
sender
and
sent
to
the
receiver,
and
we
need
some
kind
of
a
of
a
server
that
relays
messages
to
and
from
the
sender
and
receiver
to
get
around
certain
communication
channel
restrictions,
and
so
I'm
I
I
would
be
open
to
researching
different
formats
of
messages
in
two
and
four
absolutely.
But,
but
I
I
think
the
main
architectural
piece
here
is
the
presence
of
the
relay
server
and
how
the
how
the
sender
and
the
receiver
use
it
if
that,
if
that
makes
any
sense.
F
Are
you
doing
it
in
jason,
but
I
I
would
look
at
the
assertion
format.
It
was
designed
to
be
a
completely
flexible
system.
Originally
it
may
have
been.
It
may
have
ossified
into
a
particular
niche,
but
that
was
the
goal,
but
anyway.
G
Sam
you're
up
matt
thanks
for
bringing
to
us.
This
looks
like
a
set
of
problems
that
I've
been
thinking
about
in
the
context
of
web,
then
which
I've
characterized
as
selective
permissionless
delegation,
and
I
posted
that
the
solution
to
it
will
also
potentially
address
the
device,
recovery,
loss
and
migration
problems.
G
I'm
not
hearing
you
describe
that
this
is
permissionless.
I'm
hearing
you
say
in
the
case
of
the
auto
folks
that
you
need
the
auto
oem
to
get
involved,
and
I
wish
I
were
hearing
that
as
a
requirement
and
I'm
also
not
sure
I'm
hearing
an
answer
here
for
revocation
I
I've
used
the
word
or
the
require
this
word
selective
delegation.
G
I
think
we've
been
talking
a
little
bit
here
about
revocation,
but
I
don't
see
that
answer
so
well.
I
think
there's
some.
There
are
interesting
problems
here.
I
would
love
to
see
progress.
G
I'm
not
convinced
that
we
actually
have
that
you
here
have
the
problem
statement
worked
out,
never
mind
a
good
solution
for
it,
so
maybe
the
best
suggestion
is
a
buff
to
work
on
the
requirements
and
I'll
turn
it
back
over
for
responses
or
to
stephen.
C
E
Yeah,
so
so
I
guess
kind
of
like
sam,
I
think,
there's
an
interesting
area.
I
don't
think
the
internet
draft,
particularly
or
the
presentation
indicates
that
it's
yeah,
the
problem
statement
is
fully
worked
out
yet,
and
it
sounds
like
this
would
get
very
complicated,
particularly
with
managing
credentials
after
you've,
shared
them
or
or
or
transferred
them.
So
I'm
not
first
if
it
would
turn
into
a
buff,
but
I
do
think
that
there
would
be
need.
You
know
if
this
goes
forward
and
I
would
like
to
see
it
go
forward.
E
E
B
Got
it?
Thank
you
so
much
sam
and
steven,
I,
I
might
just
take
a
quick
minute
to
respond
to
a
couple
of
those
things
on
the
revocation
story
when
you
think
about
revocation
with
something
like
this
once
the
receiver
has
provisioned
a
credential,
you
have
to
imagine
that
that
relay
server
and
the
communication
channel
no
longer
exist
right,
because
the
sender
only
has
the
ability
to
send
messages
to
the
receiver
over
text
or
email
or
whatever
the
communication
channel
was,
and
they
could
be
totally
different
operating
systems.
B
B
The
credential
authority
is
the
authority
of
those
credentials
and
it
understands
the
link
between
them,
given
that
the
sender
shared
with
the
receiver
and
so
basically,
the
idea
for
revocation
is
that,
if
the
sender
desires
to
revoke
the
credential,
it
would
send
a
message
to
the
credential
authority
asking
to
revoke
a
specific
share
or
send
and
from
that
share
identifier
or
send
identifier.
B
In
that
case,
the
credential
authority
essentially
has
to
keep
a
graph
of
of
shares
on
its
side
and
all
the
revocation,
the
authentication
for
it
needs
to
be
performed
by
the
credential
authority,
which
is
the
only
authority
that
really
bridges
the
gap
between
the
sender
and
the
receiver
and,
and
so
that
was
kind
of
my
answer,
I
think
mostly
to
sam's
question.
But
these
are
all
great
comments.
I'm
also
taking
notes
here
on
my
side.
H
Thanks
for
thanks
for
the
talk,
so
I
think
you
know,
let
me
start
with
the
dispatch
questions,
which
is,
I
think
that,
like
as
other
people
were
saying,
I
think
it's
pretty
hard
to
reverse
engineer
the
requirements
out
of
this
document.
H
So
that's
the
place
to
start
is
the
requirements,
and
then
we
can
talk
about
what
you
know
what
the
design
there
seem
to
be
a
bunch
of
important
requirements,
they're
driving
this
design
that
I'm
having
trouble
like
sort
of
understanding
how
you
got
here
so
in
particular,
like
I
guess,
given
that
you
have
to
you
know,
I
heard
this
point
repeatedly
about
how
big
sms
messages
are,
but
given
that
what
you're
actually
doing
is
giving
a
token,
which
is
then
used
to
redeem
at
the
device
oem
server
via
the
credential
authority,
I'm
not
sure
why
this
can't
be
small.
H
I
think
you
know
generally
like
what
I
notice
about
this
is
you
seem
to
be
solving
the
easy
problem,
which
is
once
you've
established
a
secure
channel?
How
do
I
get
data
across
it,
but
the
problem
with
this?
The
difficult
problem
is
how
to
establish
a
secure
channel,
and
so
I
think
you
know,
first
to
sort
of
assume
like
sms,
is,
like
totally
secure,
seems
like
kind
of
like
not
a
great,
a
great
place
to
start,
but
any
case.
H
B
Got
it
that
makes
sense
eric,
thank
you
and
thank
you
so
much
for
your
comments
and
email.
Those
were
great
as
well.
I
think
I
think
the
on
the
requirements.
I
sounds
good.
I
hear
you.
I
will
try
to
document
them
further.
On
the
small
token,
the
the
bearer
token
that's
obtained
from
the
credential
authority
needs
to
be
somewhat
polymorphic,
or
at
least
be
allowed
to
be.
B
Things
like
that,
and
so
I
think
the
size
of
that
token
will
be
relatively
small,
but
maybe
you
know
maybe
up
to
a
kilobyte
or
two
depending
on
what
key
was
used
to
sign
it
or
if,
if
they
want
to
store
it,
then
of
course
it
could
probably
just
be
a
uuid
and
they
don't
need
to
sign
it.
B
B
Also,
notably,
it
needs
to
have
information
required
for
any
device
os
oem
to
provision
this,
and
so
you
might
have
apple
specific
data
or
google
specific
data
you'd.
All
of
them
would
need
to
be
present
to
invoke
the
right
api
in
number
five
to
actually
provision
that
credential
number
five
is
not
standardized
and
then,
lastly,
on
your
comments
on
secure
channel
totally
agree,
sms
is
obviously
not
a
secure
channel.
I
think
in
general,
in
this
cross-platform
cross-channel
solution,
we've
effectively
deemed
recipient
binding
a
non-goal
and
effectively
an
impossible
problem.
B
You
would
need
you
know,
global
directory
system
with
all
different
kinds
of
channels
in
it,
mapping
to
public
keys,
so
you
could
do
field
level
encryption
to
them
and
that
just
doesn't
exist
in
a
cross-platform
cross-channel
capacity.
Today,
I
think
we
we
do
have
a
number
of
security
mitigations
that
that
we've
thought,
through
in
terms
of
a
low
ttl
on
the
relay
server,
for
this
particular
share
device
binding
in
number
four.
B
The
idea
being
a
receiver
sends
a
uuid
up
in
number
four,
when
it
first
obtains
the
data
and
that
kind
of
binds
that
receiver
to
that
relay
server.
The
main
security
mechanism
is
the
entropy
of
the
url
itself.
The
url
will
contain
128
uuid
and
it's
sent
over
this
channel.
The
channel
itself
may
be
insecure,
but
the
receiver
will
be
bound
to
the
relay
once
it
first
invokes
that
relay
upon
receipt
of
the
message
and
the
url
itself
will
be
very
challenging
to
guess
because
of
the
entropy
inside
of
it.
B
H
I
mean
yeah,
it
means
I
mean
I
guess
I
don't
really
want
to
try
to
break
down
the
design.
So
I
guess
you
know
you
know,
like
all
those
things
depend
on
the
channel
right,
the
channel
isn't
secure,
then
this
game
over
so
like.
In
any
case,
I
think
I
I
get
so
I
guess
I
would
make
two
points.
As
I
said.
First
of
all,
I
think
it'd
be
really
helpful
to
like
a
lot
of
requirements.
H
I
don't
mean
by
the
way
a
document
with
like
a
list
of
like
you
know,
r1
r2
r3.
What
I
mean
is
a
description
of
the
setting
and
description
of
the
things
that
you
think
are
kind
of
the
constraints
to
operate
with,
and
then
we
can
debate
with
those
constraints
are
important
or
not.
So
I
guess
with
that
said
like.
H
I
am
pretty
sad
about
this
session,
that
what
has
to
happen
here
is
that
the
sender
has
to
generate
a
thing
which
is
acceptable
for
like
every
possible
kind
of
receiver.
That
seems
like
the
point
of
standards
does
not
have
to
do
that,
and
that
seems
to
have
an
incredible
set
of
lock
in
to
the
incumbent
on
device
manufacturers,
which
is
the
point
steve.
H
I
think
stephen
farrell
was
racing
so,
like
I
think,
if
we're
going
to
do
this,
what
ought
to
happen
is
there's
one
message:
format
which
you
send
and
that
message
is
important
actually
process
by
everybody
and
they
have
to
change,
not
that
we
have
like
some
sort
of
thing
where
it's
like
I
have
to.
I
have
the
standard
thing
for
android
and
ios
and
whatever,
because
that
means,
if
I
roll
a
new
operating
system.
Basically
I'm
host.
C
C
Yeah,
that
was
a
good
discussion.
Thank
you,
I'm
going
to
move
on
to
richard
next.
I
just
wanted
to
give
folks
the
heads
up
that
I'm
gonna
hit
this
powerful,
lock
q
button.
I
got
in
front
of
me
in
a
few
seconds
so,
if
you'd
like
to
get
into
the
queue
now's
the
time
to
virtually
stretch
your
legs
and
get
over
there,
but
so
richard
barnes,
I'm
sorry
rich
richard
brunson's.
Next,
in
the
queue
you're
on
the
list,
though,.
I
Thanks,
patrick
so
just
to
hit
the
dispatch
question
first,
I
think
this
is
probably
about
the
right
size
of
work
for
a
small
working
group.
It's
I
think
it
does
mirror
the
working
group
as
opposed
to
going
somewhere
else,
just
because
it's
a
fairly
discreet
subject
area
and
a
non-trivial
amount
of
work.
I
I
don't
think
as
well
as
several
other
folks
who
said,
I
don't
think
that
the
clarity
is
is
quite
here
yet
with
regard
to
what
this
group
will
be
doing
and
what
problem
it
would
be
solving.
I
So
I
think
we
need
another
iteration
on
that,
but
this
seems,
I
think,
there's
probably
a
worthwhile
thing
to
work
on
here.
That's
kind
of
where
my
my
substantive
comments
are
it's
like.
I,
I
I'm
a
little
confused
on
a
couple
points.
The
trust
like
this,
this
question
of
trust
establishment
has
been
raised.
A
couple
of
times,
I
think,
is.
I
I
was
a
little
troubled
by
these
assertions
just
now
that
the
the
communication
channel
is,
we
basically
assumed
to
be
insecure
because
you
know
if,
if
there's
no
security
at
the
bottom,
zekker
noted
like
there's,
there's
no
security
in
the
rest
of
the
system
either,
and
so
basically
all
we're
just
doing
is
inventing
a
fancy
compression
scheme.
So
I
think
we
need
to
be
super
crisp
on
on
what
the
you
know,
what
we
assume
about
that
communication
channel.
I
What
we
assume
about
the
relationship
between
the
sender
and
the
receiver
is,
I
think
there
are
probably
some
options
here
in
terms
of
things
that
have
a
reasonable
user
experience
and
do
achieve
security
on
that
communications
channel,
but
it
will
require
a
little
bit
of
thinking
about
how
to
align
the
use
case
with
the
the
security
technologies.
We
have
available
a
quick
question.
I'm
a
little
bit
curious.
Why
this
is
this
mechanism
is
focused
on
credentials.
I
It
seems
like
this
could
be
framed
as
a
general
mechanism
for
syncing
private
data
across
different
instances
within
a
security
within
a
particular
security
boundary.
So
I'm
a
little
curious
why
this
isn't
a
general
sync
protocol,
why
it's
quite
specifically
focused
on
on
credentials
and
finally,
the
last
point
I
had,
which
I
think
well,
I
think
rich
was
going
to
cover
pizza
along
I'll.
Put
that
off
so
yeah.
That's
what
I
got
things.
B
Got
it?
Thank
you
very
much
richard
I.
I
fully
concur
with
your
last
statement
there
this
this
really
could
be
generic.
I
don't
think
it
would
be
a
great
mechanism
per
se
for
sync
in
terms
of
ongoing
persistent
synchronizing
of
data
between
sender
and
receiver.
B
Typically,
in
those
scenarios,
you
want
a
much,
at
least
in
my
opinion.
You
want
a
much
more
well-defined
authentication
authorization
story
between
sender
and
receiver
and
who
can
sync
and
who
can
push
in
this
case,
it's
kind
of
like
a
one-shot
send
where
you
kind
of
lob
this
thing
over
the
fence
to
the
receiver,
that
they
can
then
kind
of
go
provision,
and
it's
I
mean,
obviously
you
know
a
bearer
token.
B
The
idea
is
that
whoever
has
possession
of
the
bearer
token
has
the
permission
and
authority
to
go
off
and
use
it,
and
so
I
think
I
think,
you're
right
that
it's
it's
much
more
generic
than
just
credentials,
but
I
don't
think
it
should
be
used
for
like
a
persistent
sync
mechanism.
That's
like
an
ongoing.
You
know.
You
know
sync
of
data,
totally
hear
you
on
the
lack
of
clarity.
I
think
that's
been
mentioned.
A
few
times
I
will
work
on
putting
together
a
better
kind
of
user
story
and
requirements,
documentation
for
that.
I
If
I
may,
like,
as
you're
thinking
through
those
requirements,
I
would
think
I
would
focus
a
lot
on
kind
of
the
security
assumptions
here.
Who
knows
what
about
whom,
with
confidence
and
things
like
that
who.
I
I
think
you've
captured
some
of
that
with
talking
about
what
the
relay
server
is
trusted
to
do
and
not
to,
but
I
think
highlighting
those
kind
of
security
assumptions
would
be
really
useful.
B
Yeah
the
problem
statement
we
started
with
was
really
you
know.
If
you
imagine,
sharing
a
photo.
Let's
say
you,
you
snap
a
photo
on
your
phone,
you,
you
know
typically
device
oem,
you
can
click
a
share
button
somewhere
and
it
you
know
it
kind
of
says:
hey.
You
know.
How
do
you
want
to
share
this?
You
want
to
share
it
over
email
or
sms,
or
you
know,
apple
has
airdrop.
B
You
know
those
kind
of
things.
The
idea
was
something
very,
very
similar
to
that,
making
it
as
easy
as
possible
and
as
seamless
as
possible
to
share
a
credential
like
a
hotel
key
with
a
loved
one
or
a
family
member,
just
as
if
you
were
sharing
a
photo-
and
you
know
wanting
it
to
work
cross-platform
that
that's
kind
of
the
problem
statement
that
we
really
started
with
and
with
the
sender
being
able
to
revoke
and
view
who
they
shared
to
and
all
those
kind
of
things
and
the
short
ttl
single.
B
You
know
single
redemption.
We
didn't
think
that
the
security
channel-
it's
excuse
me,
the
communication
channel
itself
needed
to
be
all
that
secure,
because
if
it's
compromised,
you
can
just
revoke
the
credential
and
share
it
in
some
other
way.
But
but
I
will
save
some
of
these
comments
and
responses
for
whenever
we
establish
the
appropriate
working
group.
J
So
two
different
points:
I
want
to
talk
about
one
one
with
spam
and
one
was
just
what
we
need
to
standardize
here
and
but
let
me
just
start
by
saying
thank
you
for
bringing
this.
I
really
like
just
the
way
you've
been
dealing
with
all
this.
I
know
how
frustrating
it
can
be
to
deal
with
getting
a
new
group
of
people
up
to
speed
with,
what's
no
doubt
years
of
thinking
going
into
this,
so
bear
with
us
and
help
us
get
to
the
thing.
J
So
with
that
said,
let
me
jump
into
the
the
big
picture
here.
I'm
in
I
mean
like
we
have
this
problem
with
how
to
standardize
and
move
things.
We
actually
need
to
move
credentials
between
devices
and
video
conferencing,
things
and
stuff.
I
wear
my
employer,
I
mean
we
use
ultrasound
for
the
communications
channel
that
you
have
there,
which
is
even
lower
bitrate
than
sms.
I
mean
I
I'm
really
strongly
in
favor
of
solving
this
problem,
but
the
problem
is
not
standardizing
the
relay
server.
The
problem
is
standardizing.
J
This
whole
slide
that
you
have
the
slide
six,
I
feel
very
strongly.
We
need
to
figure,
and
that
doesn't
mean
that
every
one
of
these
standards
can
be
done
by
itf
or
whatever
it
is
just,
but
we
need
an
overall
solution
to
the
the
big
problem
of
of
your
title
right,
which
is
how
to
transfer
credentials
from
sender
to
receiver,
I'm
strongly
in
favor
of
that,
but
if
all
we
need
was
the
relay
server
here
I
mean
there's
many
things
we
could
use.
J
I
mean
there's
many
iot
messaging,
but
I
mean
there's
a
ton
of
technologies
that
existed
over
time
that
allow
us
to
effectively
expand
out
a
link
to
some
larger
data
and
do
what
the
relay
server
thing
is
here.
That's
not
that's
not
the
problem,
you're
really
solving.
So
I
think
when
you
think
about
the
requirements
and
the
solution,
I'd
I'd
really
ask
for
us
to
talk
about
the
whole
problem
here,
not
a
teeny
part
of
it.
So
I
want
to
you
know,
standardize.
J
You
know
the
syringe
that
moves
the
drugs
around
and
the
drugs
here
such
that
we
have
an
interoperable
solution.
I
mean
what
we
need
to
be
able
to
say
at
the
end
of
this.
Is
you
know
if
two
different
devices
both
implemented
this?
They
would
be
able
to
securely
exchange
credentials
not
well.
They
could
both
talk
to
the
same
relay
server
but
they're.
All
the
hard
parts
are
ignored
right.
Let's
not
ignore
the
hard
parts.
Let's
do.
J
The
whole
thing
I
mean
does,
that
is:
is
that
a
reasonable
scope,
you're
willing
to
deal
with
sort
of
hitting
this
whole
thing.
B
Thank
you
so
much
colin.
I
think
I
think
I
really
appreciate
your
comments
and
questions.
I
think
you're,
I
think
you're
spot
on
the
part
of
the
the
challenge
here
is
that
when
you
look
at
the
major
device
os
oems
like
apple
and
google,
they
they
have
existing
provisioning,
apis
and
rails
to
get
secure
credentials
into
mobile
devices
for
years
now,
and
if
you
look
at
you
know,
credit
and
debit
cards
and
transit
and-
and
you
know,
car
keys,
these
things
exist
in
production
today
and
part
of
the
complexity.
B
Here,
I
think,
is
the
way
that
apple
does
it
in
the
apis
are
completely
proprietary
to
apple
and
the
way
that
google
does
it
and
the
apis
are
completely
proprietary
to
google
and
so
on
and
so
forth,
for
you
know
for
different
device,
os,
oems
and
so
building
a
system
that
allows
you
to
exchange
these
credentials
and
standardize.
B
Those
vertical
legs
there
right
number,
one
and
number
five
to
your
point-
would
be
fully
ideal
and
be
a
much
more
comprehensive,
all-encompassing
solution,
but
the
background
compatibility
story
and
the
level
of
effort
required
to
standardize
these
apis
would
be
absolutely
monumental.
On
the
order
of.
J
J
We
have
to
take
into
account
the
reality
of
what
exists
there,
but
I'm
saying
that
we
we
define
some
of
those
and
that
that
yes,
car
manufacturers
and
hotels
and
others
will
we
will
try
and
design
them
in
such
a
way
that
that
is
that
meets
the
that
is
close
to
what
they
have
today
or
ideally,
they
can
use
exactly
what
they
have
today,
but
that
we
need
to
take
that
into
account
of
the
design
of
the
whole
system
and
we're
gonna.
We're
gonna
pick
some
that
win
and
some
that
lose.
J
B
Oh
go
ahead.
C
No,
I
was
gonna
say
I
mean
you
always
have
good
insight
into
the
dispatch
outcomes.
All
right.
Are
you
suggesting
that
this
is
perhaps
like
requirements
that
would
come
back
and
you
know
be
an
excellent
ietf
wide
buff.
I
think
christian
are
sort
of
talking
about
that,
as
maybe
the
sentiment
we're
hearing
across
the
room.
J
I
mean
look,
you
know
I've
seen
many
of
these
over
there,
the
years
or
whatever.
My
guess
is.
This
conversation
is
going
to
end
in.
We
should
have
a
both.
That
really
does
this,
but
I
mean
I
think
that
we
have
to
decide.
You
know.
Are
we
defining
the
syringe
and
what
goes
in
it?
Are
we
just
defining
like
a
carrier
for
the
drugs
right?
I
mean
those
are
two
very
different
things
to
work
on
and
I'm
I'm
I'm
arguing
for.
J
We
need
to
have
an
architecture
for
what's
on
slide
six
here.
The
overall
problem
that
slide
six
is
trying
to
argue
for
I'm
all
totally
in
favor
of
doing,
and
I
think
that
just
what
I've
heard
on
the
call
today
makes
it
strong
it's
very
clear
that
there
are
major
players
where
we're
willing
to
work
together
to
do
something
really
relevant
here.
So
there's
no
lack
of
energy.
For
this.
B
No,
not
at
all,
I
I
I
was
just
gonna
respond
to
one
thing
that
you
mentioned
colin
and
then
the
the
idea
here
you
you.
J
Realized
that
that
makes
sense,
but
I
think
this
gets
the
hardware
a
little
bit
different.
I
don't
think
that
exists
today
at
all,
okay
and
your
point
that
it
exists
for
merely
two
of
the
thousands
of
different
types
of
device
os's
out
there.
It
is
is
an
argument
that
it's
is.
It
makes
exactly
my
point
of
why
we
need
to
why
we
need
to
do
the
overall
scope.
So
just-
and
I
want
to
be
clear
here-
I'm
not
arguing
against
doing
this
work.
I'm
arguing
in
favor
of
this
is
great
work.
J
We
should
do
it,
but
the
work
we
need
to
do
is
what
is
your
whole
slide?
Six,
not
not
not
just
lines,
two
and
four
on
the
on
the
slide.
That's
that's
the
only
thing
and
that
that's
just
my
point
of
view.
I
mean
I'm
sure
other
people
have
other
points
of
view,
but
that's
that's
sort
of
my
my
direction
of
how
I
think
about
this.
So.
D
Actually,
pete
resnicks:
does
he
posted
a
while
ago
saying
he
was
having
device
problems?
So
the
question
from
pete,
which
is
sort
of
a
elaboration,
I
think,
of
what
patrick
said
initially
is?
Are
you
okay,
if
the
ietf
tears
up
what
you've
done
and,
for
example,
completely
changes
the
architecture.
D
B
C
B
Better
now,
okay,
great
thanks,
like
I
said
I,
there
are
large
actors
in
this
in
this
ecosystem
that
endeavor
to
build
a
solution
that
solves
some
of
the
problems
that
I've
that
I've
outlined.
B
I
think
I
think,
if
it
solves
the
same
goals
and
and
is
compatible
with
the
way
that
these
things
kind
of
have
to
work
in
the
credential
authority
space
and
when
I
say
that
I
mean
there's,
there's
a
number
of
entities
in
the
world
think
about
assa,
abloy
and
hid
and
and
these
large
credential
providers
that
provide
access
control
systems
and
key
material
for
the
majority
of
corporations
in
the
world.
To
be
honest
between
the
two
of
them
dormacaba
it.
B
I
think
I'm
certainly,
and
I
should
say
we
I
mean
there's
five
other
co-authors
on
this,
but
we
we
certainly
would
love
to
get
feedback
and
make
it
better
and
and-
and
I
think
it's
it's
hard
to
say
without
seeing
where
we
end
up,
but
I
do
think
we're
all
committed
to
the
process
and,
like
I
said
this
is
my
first
time
at
ietf.
B
But
I'm
I'm
really
looking
forward
to
discussing
it
in
additional
detail
and
seeing
what
we
can
come
up
with
and
and
and
if
it's
better
than
what
we
have
here
and
solve
the
same
problems.
Then
I
don't
see
any
reason
why
we
can't
why
we
wouldn't
adopt
it.
If
that
makes
sense,
yeah
yeah.
C
So
dispatch
sometimes
sees
work
for
what
are
essentially
complete
and
deployed
protocols
for
which
they're
looking
for
you
know,
recognition
by
a
standards
body
but
are
not
willing
to
bring
that
really
allow
that
standards
body
to
bring
its
full
consensus
to
how
that
is
going
to
operate
right,
more
or
less
a
rubber
stamp
or
nothing
which
is
not
really
the
mode
in
which
the
ietf
operates
as
a
collaborative
consensus
design
that
has
to
go
on
what
I'm
hearing
more
of
you
is
that
you've
got.
C
You
know
some
requirements
of
an
existing
ecosystem
that
you
want
to
design
a
protocol
to
fit
into.
You
know
that
causes
challenges.
Of
course,
as
you
go
along,
but
that's
you
know,
I
think,
a
pretty
reasonable
thing
to
put
on
the
table
and
to
work
around.
That's
the
the
distinction
I
usually
see.
Does
that
sort
of
match
your
where
you
think
this
lies.
B
Yeah,
I
think
that
makes
sense
I
mean
there.
Are
you
know
a
lot
of
these
companies
really
do
want
to
build
a
solution
that
solves
this
problem,
and
so
I
think
another
thing
that
that
that
I
would
would
mention
is
is
is
timing
right
and,
and
you
know,
I
realized
that
academically
having
us
discuss
and
debate
for
as
long
as
it
takes
to
get.
B
The
right
answer
is
obviously
the
right
sort
of
theoretical
and
academic
thing,
but
you
know
a
lot
of
times
these
companies
are,
you
know,
want
to
launch
a
solution
that
solves
this
problem,
and
I
I
think
it
wouldn't
be.
Intellectually
honest
if
I
didn't
mention
that
there
are
a
lot
of
driving
factors
here
to
build
something
that
satisfies
these
goals.
So
I
guess
what
I'm
saying
is
if
we
can
establish
a
working
group
and
discuss
it
and
really
dig
in
on
relatively
short
order.
I
think
that
would
be
fantastic.
B
I
I
I
truly
do
welcome
the
changes,
but
if
it
ends
up
taking,
you
know
a
year
or
two
or
three
to
come
up
with
the
right
solution.
I
think
it
would
be
likely
that
that
the
the
companies
that
have
been
discussing
this
so
far
would
proceed
with
something
that
looks
like
what
I
presented
today.
Just
in
the
interest
of
full
disclosure.
C
No,
I
mean
that
makes
a
lot
of
sense.
It's
it's
often
actually
a
good
dynamic
when
the
folks
that
are
actively
involved
in
doing
the
work,
if
there
were
to
be
an
eventual
working
group,
feel
some
sort
of
you
know
commercial
or
otherwise
time
pressure
that
that
tends
to
result
in
good
outcomes.
C
C
I
am
reminded
here
that
I
actually
just
want.
I
said
I
would
summarize
ted's
email
which
did
appear
to
go
to
the
list.
I'm
not
sure
why
it
didn't
end
up
in
your
mailbox,
but
let
me
get
a
couple
highlights
out
of
there
for
you
in
case
there's
anything
you
want
to
address
ted
hardy
says
based
on
the
rest
of
the
draft.
C
C
If
so,
you
may
want
to
consider
whether
device
is
the
right
unit
of
discussion,
since
even
mobile
devices
can
have
multiple
persona,
accounts,
etc.
Think
of
work
profiles,
if
it's
not
your
document
needs
a
good
bit
of
work
to
rethink
some
of
those
core
elements
such
as
account
claim.
In
the
end,
he
thinks
the
security
and
privacy
aspects
of
this
need
a
fair
amount
of
work,
and
that
leads
him
to
suggest.
The
answer
to
the
dispatch
question
is
that
a
working
group
would
be
appropriate
with
both
app
and
security
folk
involved.
B
Yeah
great
great
comments
and
questions
I
mean,
I
think
the
challenging
the
noun
of
devices
is
great.
I
mean
we've.
I've
debated
that
myself
for
for
for
months.
You
know,
I
think
I
I
don't
see
a
reason
why
a
protocol
like
this
wouldn't
work
on
you
know
another
type
of
device
or
entity
like
a
laptop
or
a
you
know,
pc
or
something
like
that.
It
would
need
the
requisite
hardware
to
provision
these
type
of
credentials.
B
Like
I
said
these
actors
with,
like
you
know,
assa
abloy,
you
know,
hid
they
have
very
strict
compliance
requirements
and
certification
requirements
for
the
hardware
that
stores
the
credential
itself,
and
so
you
know
not
a
lot
of
laptops
and
pcs
have
that
hardware.
There's
a
lot
of
certification
involved
in
a
lot
of
the
mobile
payment
industry.
Just
for
those
those
who
are
not
involved
in
in
that
industry.
You
know,
pci
compliance,
there's
there's
all
kinds
of
those
restrictions,
but
I
do
I
do
agree
in
principle.
B
You
know
challenging
the
term
device
and
what
it
means
is
great.
I've
been
doing
that
myself
for
quite
a
while
on
the
security
point
wholeheartedly
agree.
We
have,
you
know
been
talked
about
that
on
this
farm
already,
the
past
hour
quite
a
bit,
I
think
the
security
of
and
what
security
primitives
we
would
like
to
guarantee
of
this
protocol
are
really
something
that
truly
needs
to
be
discussed
in
additional
detail.
Fully.
Concur
with
that
point.
C
All
right,
thank
you
so
much.
I
hope
you
had
a
good
dispatch
experience.
A
Yeah,
thank
you
very
much
and
thanks
for
the
discussion
this
morning
or
afternoon
or
evening
or
middle
of
the
night,
wherever
you
are
so
we're
now
going
to
move
on
to
the
art
section
of
the
meeting
today.
So
that's
the
end
of
dispatching
and,
as
patrick
said,
we'll
go
away
and
talk
about
and
come
back
at
the
end
of
the
session
with
what
we
think
we
heard
matt
I'd,
just
ask
you
to
stop
sharing
your
slides.
A
If
you
can,
because
I
seem
to
not
be
able
to
thank
you
super,
so
we
can
just
talk
through
what
we
have
coming
up
in
the
art
meeting.
A
Okay,
hopefully
you
can
see
that
so
we
now
just
have
a
couple
of
updates
on
boss
meeting
of
interest
and
the
leds
we'll
talk
a
bit
and
then
we
have
just
a
couple
of
items
that
shouldn't
take
very
long
at
all
and
so
we'll
just
kind
of
proceed.
A
A
So
we've
just
had
our
dispatch
topic
and
now
we're
moving
into
our
area.
Part
of
the
meeting
francesca
did
you
want
to
talk
through
some
of
the
highlights
here?
I'm
happy
to.
A
K
Right,
mute
and
mute
buttons,
as
always,
and
I
can
send
my
video
as
well
so
thank
you
chrissy
for
putting
up
this
this
light
together.
It
is
a
bit
cut
or
okay.
No,
I
can.
I
can
slide
it
sorry,
so
yeah
we
got.
We
have
gotten
one
buff
priv
privacy,
respecting
cooperation
of
values.
On
wednesday
we
have
new
and
nearly
new
art
working
groups.
K
I
wanted
to
mention
ohi,
which
is
in
the
security
area,
but
because
of
its
it's
so
close
to
art
that
it
would
be
good
to
remind
everybody
that
this
is
meeting
for
the
first
time,
oblivious
http
application
intermediation.
K
This
is
the
old,
oh
dpp
and
or
working
group,
or
both
and
changed
name
a
couple
of
times.
We
also
have
a
newly
chartered
working
group.
Media
man,
media
type
maintenance
and
see
date
is
also
meeting
again.
She
realized
in
the
extended
data
about
times
and
events
and
both
of
these
are
on
tuesday.
L
I
just
wanted
to
mention
that
mediaman
is
looking
for
a
co-chair
if
anybody
is
interested
in
helping
us
with
that
effort.
Looking
for
co-chair
experience,
please
get
in
touch
with
me.
K
Good
reminder,
thank
you,
and
also,
if
you're
interested
in
in
sharing,
even
if
it's
not
only
for
media
men
or
for
other
topics,
please
get
in
touch
we're
always
looking
for
co-chairs
and
barry.
Did
you
have
something
to
add.
M
Also,
we've
just
rebooted
the
skim
working
group,
the
I
don't
even
remember
what
it
stands
for
now,
but
you
might
want
to
mention
that.
K
Yes,
yes,
thank
you
for
that.
I
had
it
in
my
notes,
but
forgot
to
send
do
to
make
it
to
the
slide.
So
yes,
scheme
reopened,
and
it
was
working
group
that
was
terminated
and
had
a
buff
last
itf
and
it
is
now
meeting
again.
K
K
I
don't
have
slides
for
those,
but
I
thought
I
would
take
a
second
if
that's
okay.
So,
first
of
all,
I
wanted
to
say
that
art
art
is
now
fully
working,
and
I
wanted
to
thank
everybody
who
has
made
this
possible
every
reviewer
barry
as
the
secretary.
Thank
you
so
much.
This
has
been.
It's
now
been
working
for
three
months
or
maybe
a
bit
more.
It
has
realized
around
30
reviews.
K
K
K
So
I
wanted
to
mention
it
just
so
that
everybody
is
aware
that
now
is
the
time
to
take
a
look
and
and
and
see
if,
if
the
work
is
ready
to
advance
also,
I
wanted
to
mention
that
we
are
having
rtd
office
hours
this
time
as
well,
so
we're
only
having
one
hour
this
week
and
it's
at
the
end
of
today
so
half
an
hour
after
the
end
of
the
last
session.
Today,
I'm
not
checking
the
chat.
K
Okay,
let's
talk
about
skim,
that's
fine,
so
you're
all
welcome
to
come
and
say
hi
or
talk
about
any
art
topic
you
might
want
with
me
or
marry
yeah.
So
your
I.
E
K
That
some
of
you
show
up
also,
I
wanted
to
remind
that
site
meetings
are
always
a
possibility.
There
is
a
wiki
for
it.
I
can
post
it
in
the
chat
to
organize
and
that
should
complement
the
gather
town
that
we
have
so
I'll,
try
to
being
other
town
as
much
as
possible
during
this
week.
So
you
can
come
and
find
me
if
you
would
like
to
say
hi
and
finally,
that
the
nom-com
is
requiring
feedback
still.
So
please
remember
to
do
that
and
take
a
second
to
do
that.
K
That's
that's
good,
and
I
think
I
covered
everything
I
wanted
to
and
of
course
again,
as
marie
said,
if
anybody
is
interested
in
sharing,
please
get
in
touch
with
us.
A
Thank
you
francesca
for
all
the
updates
and
yeah.
It's
really
good
to
see
the
art
art
team
taking
off
so
super
achievement,
since
the
last
meeting
well
done
so
we're
just
gonna
have
a
brief
presentation
or
really
a
chat
through
from
barry
lieber.
If
you're
uncle
just
about
internalized,
I
can't
speak.
M
Well,
hi:
this
is
barry
lieber
now
well,
actually,
the
I
I
was
going
to
mention
art,
art
and,
and
then
riff
from
there
and
so
francesca.
Thanks
for
plugging
that
the
goal
of
the
art
area
review
team
is.
Let
me
turn
on
my
video.
M
The
goal
of
the
art
area
review
team
is
not
to
review
every
document,
but
to
go
look
at
ones
that
that
I
think,
as
I
do,
a
triage
might
help
might
benefit
from
somebody
in
art
looking
at
them,
and
so
we've
been
reviewing
probably
about
half
of
the
documents
that
are
going
to
the
iasg
something
around
there
and
and
we've
had
good
good
results
from
that.
M
As
francesca
said,
the
ads
are
pleased
with
the
result
of
that,
and
we
also
have
an
internationalization
directorate,
which
pete
is
the
secretary
for
and
it
does.
It
deals
with.
Internationalization
issues
collects
the
experts
on
internationalization
and
where
I
wanted
to
mention
in
the
the
junction
of
the
two.
Is
that,
as
we
are
reviewing
documents
for
the
art
area,
we'll
sometimes
come
up
with
ones
that
we
think
might
need
internationalization
expertise
to
look
at
it
also.
M
M
What
we
we
intend
to
come
up
with
a
a
list
of
things
to
watch
for
that
we
can
post
and
then
you
can
look
at
those
and
and
see
what
specific
issues
raise
flags
that
would
need
an
internationalization
review.
So
we're
not
expecting
everybody
in
the
art
area
to
understand
all
the
quirks
of
why
internationalization
is
hard
and
what
needs
to
be
done,
but
just
to
start
to
learn
a
few.
M
A
few
flags
that
indicate
that
somebody
who
knows
more
about
this
ought
to
take
a
look
at
it.
So
we'll
we'll
be
posting
something
to
the
art
mailing
list.
Once
we
get
a
list
up
that
of
of
of
these
sorts
of
flag
issues,
and
I
think
that's
all-
I
really
wanted
to
say
about
that.
John
clenson,
if
you're
on
is
there
anything
you
want
to
add?
N
I
sorry
having
coordination
problems.
N
I
yeah
the
the
the
the
only
trick
here,
which
you
didn't
mention
but
which
I
think
is
worth
mentioning.
Is
that
there's
a
little
bit
of
a
balance
problem,
which
is
that
sometimes
we
look
at
a
document
sometimes
long
before
we
look
at
a
document,
that's
coming
from
somewhere
else.
We
discover
that
there
are
fundamental
issues
that
need
to
be
addressed
in
a
internationalization
specification
and
we
are
lacking
ways
to
develop
and
handle
those
specifications
that,
and
I
think
it's
safe
to
say
that
any
that
anybody
is
satisfied
with.
N
So
that's
another
piece
of
this
puzzle,
but
but
other
than
that,
I
think
barry's
very
summary
is,
is
reasonable.
M
M
So
watch
again
watch
for
for
a
list
of
of
flag
issues
that
that
john
and
I
will
try
to
come
up
with
and
perhaps
others
on
the
internationalization
director.
N
Yeah
one
other
observation:
if
I
can
break
in,
as
as
as
we
are
working
on
a
more
complete
list,
you
can
assume
rewriting
your
documents
that
there
are
going
to
be
two
obvious
questions.
As
soon
as
you
decide,
you
need
characters
other
than
asking.
N
One
of
those
questions
is
why
and
the
other
one
of
those
questions
is
that,
unless
what
you're
doing
is
guaranteed
to
be
free
text,
which
is
never
going
to
be
compared
to
anything
or
looked
at
other
than
visually,
that
writing
down
the
equivalent
of
just
using
utfh
is
not
going
to
do
it.
There
are
complexities
there,
which
I
trust
as
we
put
the
list
together,
we
will
elaborate
on,
but
but
but
the
most
common
problem
we
see
is
somebody
who
says
well.
A
Great,
thank
you
very
much.
Both
really
good
update
there
and
I
I'm
going
to
try
and
say
tonight
the
association
again
right
so
we're
just
gonna
have
a
final
presentation
from
spencer,
spencer
dawkins
on
media
over
quick
and
hopefully
you
can
see
those
slides
worse,
just
one
slide
showing
for
you
there
spencer,
so
take
it
away.
O
Yeah
thank
and
thank
you
for
the
opportunity
to
do
this,
the
so
some
of
you.
Perhaps
many
of
you,
remember
the
video
inches
of
a
quick
side
meeting
from
ietf
111.
O
O
The
there
are
lots
of
people
with
different
needs
for
legitimate
reasons
for
what
they
want
to
do
with
media
over
quick,
and
we
need
to
understand
those
needs
to
do
anything
at
the
itf.
O
O
They
are
working
meetings,
but
they
are
public.
So,
if
you
could
contribute
please
come,
I
expect
to
publish
minutes
on
the
on
the
mock
mailing
list.
Afterwards,
the
you
should
have
live
links
on
this
slide
in
the
proceedings
for
the
mailing
list
and
for
the
where
the,
where
the
the
that's
actually
the
the
side,
meeting
link
that
francesca
was
said
to
say
she
would
put
in
the
chat,
but
it's
there
also
as
well.
We
are.
O
We
are
interested
in
hearing
from
people
with
a
variety
of
things
on
their
mind,
especially,
I
think
interested
in
pain
points
on
what
people
are
not
not
able
to
do
now
with
various
forms
of
media
streaming
interest
and
distribution.
A
O
A
Now,
thank
you
for
bringing
it's
really
interesting
work
super,
so
we
have
got.
We
have
no
desire
to
make
the
meeting
longer
than
it
needs
to
be,
but
we
do
have
time
on
the
agenda
for
any
other
business
or
anything
that
people
would
like
to
mention
in
the
flex
time.
Otherwise,
patrick
and
I
will
just
get
to
our
dispatch
outcome
for
the
one
item
on
our
agenda
today.
I'll
just
take
a
pause
in
case.
Anyone
does
want
to
join
the
queue.
A
As
we're
navigating
meet
echo
functionality
still
either
you
have
nothing
to
say
or
you're
still
trying
to
find
that
join
queue
button,
but
we'll
move
on
and
so
patrick
and
I
have
discussed,
and
we
think
that
the
consensus
for
the
first
item
and
please
do
correct
or
challenge
in
the
queue
or
on
java,
we'll
just
keep
an
eye
on
that.
We
think
that
the
outcome
was
a
consensus
to
have
a
buff
on
the
kind
of
problem
space
constraints
requirements.
A
Whatever
word
you
want
to
give
to
that,
but
to
not
focus
on
a
solution
but
to
kind
of
scope
out
the
use
cases
and
any
constraints
around
that,
and
we
also
heard
that
the
community
would
like
this
work
to
have
a
shout
out
in
sex
dispatch.
So
just
for
awareness
not
to
redispatch,
but
we'll
see
if
there's
time
on
the
sec
dispatch
agenda,
just
to
mention
that,
and
also
a
note
that
this
belongs
really
more
with
the
sec
community
than
art.
A
So
that's
what
we
heard
from
the
group.
I
don't
see
anyone
angrily
objecting
on
jabber
or
calmly
objecting,
but
I
do
see
cullen
in
the
queue
colin.
J
Yeah,
I
was
just
gonna
ask:
could
you
be
a
little
bit
more?
Could
you
be
a
little
crisper
about
what
you
want
the
scope
of
that
conversation
to
be
around
requirements
around
requirements
for
relay
around
requirements
for
the
whole
problem?
I
am
I'm
not
arguing
either
way,
I'm
just
asking
you
to
clarify
a
little
bit.
Crisper.
A
Yeah,
no
that's
reasonable
to
clarify.
I
think
we
heard
that
folks
found
it
quite
hard
to
dig
the
requirements
out
of
the
draft
looking
at
the
solutions,
so
a
bit
more
clarity
on
what
the
problem
space
is,
what
the
problem's
actually
trying
to
solve.
I
know
there
was
some
analogy
going
going
around,
but
just
kind
of
whether
it's
more
protocol
or
whether
it's
more
what's
exactly
the
relay
architecture
or
that
kind
of
thing.
Patrick,
would
you
like
to
add
anything.
C
No,
I
mean
I
would
concur
largely
with
that.
I
think
you
know
cullen
wants
to
make
sure
we
address
the
notion
of
whether
the
yeah,
how
much
of
the
whole
problem
statement
is
in
scope,
and
I
one
of
things
I
heard
is
you
know
that
should
probably
be
a
little
bit
of
the
app
community
might
drive
the
scope
there
and
the
suck
community
might
drive
the
requirements
of
the
individual
protocols
a
little
bit
more
and
that's
actually
why.
I
think
this
is
actually
suitable
for
a
an
ietf
wide
buff.
K
A
Great
thanks
everyone!
So
now
it's
nearly
the
end
of
the
meeting.
We
just
have
meetings
of
interest
to
highlight
to
you.
We
had
this
slide
on
a
little
bit
earlier.
Obviously,
it's
the
first
session
of
the
week
so
really
a
lot
of
stuff
going
on
this
week,
there's
one
buff
and
then
we've
got
a
few
new
and
nearly
new
artworking
groups
that
might
be
of
interest
and
then
other
kind
of
interesting
meetings
there
as
well.
I
can
see
that
justin
jabber
richard
you
said
you
think,
doesn't
belong
in
sec.
I
So
that's
just
my
my
quick
evaluation
on
on
the
credential
transfer
draft,
but
it
seems
to
me
like
the
the
interesting
questions
there
are
around
kind
of
the
the
broader
architecture
of
the
application
who
the
players
are,
what
their
relationships
are,
as
opposed
to
the
details
of
the
cryptography
like
there
are
like
the
cryptography
needs
to
be
arranged
properly,
but
I
think
that's
you
know
an
area
where
we
can
bring
in
some
security
area,
expertise
and
people
who
understand
how
to
do
those
sorts
of
things
and
you
know,
focus
on
the
the
application
architecture
as
the
more
interesting
problems.
A
I
think
this
is
because,
when
we
asked
the
question
in
earlier
in
jabber
about
sexual
art,
every
response
that
came
back
said
sec,
but
it's
good
to
see
that
there
is
actually
a
community
that
thinks
it
probably
belongs
more
in
art
as
well,
so
we'll
yeah,
I
think
francesca,
may
take
that
away
and
discuss
with
the
sec
ads
and
just
sort
of
work
out
where
it
sits
more
more
naturally,
but
it's
good
to
have
the
feedback
from
the
community.
So
thank
you
for
bringing
that
point
to
the
queue.
That's
super.
K
Yes,
exactly
what
you
said:
kersey
we
will
coordinate
with
the
adc.
This
might
be
another
example
of
cross
area,
with
the
work
being
done
in
one
area
and
the
responsibility
being
from
the
other
area.
So
we'll
see,
but
thank
you
for
the
feedback.
A
Great
thanks
everyone,
so
with
that,
I
think
we're
good
to
close
out
the
dispatch
and
art
area
meeting
thanks
so
much
for
your
discussion,
thanks
to
all
of
our
presenters
and
thanks
for
the
good
discussion
and
q
a
that
we
had
going
on,
it
was
really
really
good
start
to
the
week.
So,
thanks
for
me
and
have
a
great
rest
of
the
week,
take
care.
P
P
Yeah
I
switched
to
speaking
through
my
monitor,
mic
and
listening
through
my
headset
we'll
see,
but
we
are
being
recorded
just
so.
You
know.
Well,
that's!
Okay!.
P
P
No,
it's
it's
wonderful,
good.
Okay,
then
this
is
what
I'll
do
is
I'll.
Just
use
the
there's,
a
tiny,
tiny
bit
of
tendiness,
but
it's.
E
P
It
comes
on
the
mic,
but
yeah
nope,
all
right,
we'll
see
what
we
can
do
about
getting
the
mic
on
my
headset
to
work,
but
this
will
work
for
now.