►
From YouTube: IETF114 TIGRESS 20220727 1900
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
But
this
it's
the
background
that
won't
quit
and
they
I'm
lady
once
on
chair,
along
with
Patrick
Jane
from
fastly.
It
was
remote
today
and
let's,
let's
flip
the
flip,
the
slides
and
look
at
our
agenda
all
right,
so
we're
gonna
do
the
usual
intro
and
then
we're
gonna.
Let
spend
quite
a
bit
of
time.
A
This
is
the
first
working
group
meeting
on
a
a
an
introduction,
and
then
we
are
going
to
talk
about
sort
of
the
the
proposed
solutions
for
for
solution
space
for
the
use
case
for
the
use
case
for
the
problem
statements
and
then
we're
gonna
see
where
we
take
it
from
there
from
here
next
slide.
A
So
since
this
is
the
ITF,
and
since
this
is
a
new
working
group,
note
the
note
well
well,
some
of
you
are
have
probably
never
seen
this
before
you
may
be
new
attendees
and
there
there
is
a
there's
a
whole
lot
of
material
behind
this.
This
summary
go
read
that
material
and
make
sure
you
understand
it
before
you
contribute
next
slide
ipf.
Also,
as
a
code
of
conduct
summarized
in
these
four
bullets
and
for
this
meeting,
we
also
require
masks
at
all
times
for
meeting,
especially
in
the
meeting
rooms.
A
A
All
right
with
that
I'm
going
to
invite
or
our
initial
contributors
to
the
working
group
to
come
and
present
sort
of
the
problem
statement
that
led
to
this
work
being
established.
A
This
is
you
know
what
we
typically
do
in
the
IHF,
the
first
working
group
meeting.
We
spend
a
little
time
making
sure
everybody
understands
what
we're
actually
going
to
be
doing.
That's
not
what
we're
going
to
be
doing
for
the
next
and
subsequent
working
group
meeting,
so
we're
going
to
be
actually
doing
work
anyway.
So
I
don't
know
which
of
you
is
going
to
come
up
and
present
this
line
so
Casey.
A
All
right,
so
there
we
go.
B
B
So
this
is
just
a
little
look
over
our
agenda
for
today.
We're
going
to
start
off
by
talking
through
our
problem
statement
for
the
working
group,
the
goals,
vocabulary
and
move
into
some
use
cases
requirements
and
what
is
considered
out
of
scope
for
the
working
group
and
we'll
pause
for
a
q,
a
session
after
that
and
move
on
to
our
proposed
solution
and
then
a
diagram
of
our
stateless
and
stateful
working
flow,
which
all
makes
sense
when
we
present
so
I.
Just
asked
that
you
have.
B
Next
I
just
wanted
to
list
up
our
authors
and
contributors.
You
can
see
there's
quite
a
big
list.
That's
gone
into
contribute
to
this.
To
note
we
have
Matt
Byington,
also
from
Apple
online
and
Nick
Shaw
from
alphabet.
That
will
be
help
dealing
questions
after
like
during
the
Q
a
sessions
all
right
with
that
we'll
get
started
with
the
problem
statement.
B
So,
as
the
prevalence
of
digital
wallets
has
expanded,
there
are
more
and
more
ways
for
the
average
user
to
add
digital
credentials
to
their
wallets.
Users
wanted
to
take
full
advantage
of
the
convenience
and
security
offered
by
these
digital
wallets
are
moving
towards
dishing
their
physical
Keys
entirely.
B
B
Our
first
goal
is
to
minimize
fiction
for
sharing
and
cross-platform
and
cross
vertical
sharing.
So
our
goal
is
to
create
a
layer
onto
a
layer
on
top
of
existing
protocols
like
HTTP,
to
simplify
the
communication
between
devices
of
different
operating
systems.
We
are
not
trying
to
create
a
new
communication
protocol
by
any
means.
B
Our
goal
is
to
Define
a
simple
set
of
apis
that
can
be
implemented
by
any
party,
while
that
party
is
leveraging
their
current
ecosystem
and
their
own
implementation
of
secure
credentials.
Foreign.
This
will
allow
us
to
minimize
friction
both
for
a
new
user.
That's
trying
to
learn
how
to
share
as
well
as
a
new
device
OEM,
that's
looking
to
like
Implement
sharing
as
well
and
being
part
of
the
network.
B
If
two
people
were
to
share
the
exact
same
key,
we
wouldn't
actually
be
able
to
maintain
access
control
because
we'd
never
know
who
was
using
a
key
at
what
time
and
so
say,
I
have
one
hotel,
Key
and
I'm
sharing
it
with
all
my
co-workers,
which
is
not
the
case.
We
have
our
own
rooms,
but
we
wouldn't
be
able
to
just
block
one
of
us.
We'd
have
to
block
all
of
us
or
none
of
us.
B
And
lastly,
or
you
have
a
lot
of
security
and
privacy
goals,
we
will
be
talking
about
them
later
in
the
slide
deck,
but
we
just
want
to
make
sure
that
all
of
these
goals
and
requirements
are
met
so
that
we
have
the
safest
experience
for
our
users,
while
also
maintaining
a
nice
user
experience.
B
So
I'm
just
going
to
Define
some
quick
problem
vocabulary.
All
these
are
defined
in
our
Charter
I
think
as
well
as
our
draft.
Just
that
you
are
aware,
while
we
move
on
so
first,
we
have
the
credential
Authority.
So
this
is
an
entity
which
facilitates
the
trans,
facilitates
credential
information
lifecycle
on
a
device.
So
the
lifecycle
might
include
provisioning
of
that
credential
information,
termination
or
update.
So
you
can
think
about.
B
B
C
C
First,
we'll
look
at
car
key
sharing,
let's
say:
Ben
owns
a
vehicle
that
supports
digital
Keys,
which
comply
with
the
CCC
open
standard
and
Ben
would
like
to
let
Ryan
borrow
his
car
for
his
weekend
or,
let's
say
Sam
is
going
out
for
dinner
and
would
like
to
park
their
car
with
the
valet
at
the
restaurant.
In
both
of
these
scenarios,
Ben
and
Sam
would
need
to
share
their
car
key
with
another
person.
C
Second,
we'll
explore
home
or
residential
key
sharing.
Let's
say:
Brandon
owns
an
apartment
and
is
having
Abby
visit
over
the
weekend.
If
you
would
like
to
give
Abby
access
to
the
apartment,
while
she
is
visiting
or
let's
say,
Sarah
has
a
housekeeper
that
comes
weekly
and
Sarah
wants
to
give
them
access
to
the
front
door
and
only
the
front
door
in
these
cases.
Sharing
a
digital
key
would
provide
an
easier
and
more
secure
experience
than
having
to
give
someone
a
physical
key
and
digital
keys
can
be
revoked
at
any
time.
C
So,
in
the
unlikely
event
of
a
personal
falling
out,
the
key
could
be
removed
without
having
to
coordinate
with
the
receiver
to
get
back
the
physical
key
and
third
hotoki
sharing.
Let's
say:
Fred
is
staying
at
a
hotel
next
week
and
the
hotel
supports
digital
access
credentials
and
Fred
added
the
credential
to
their
phone.
C
C
C
We
expect
our
solution
to
have
some
general
properties
in
order
to
facilitate
a
secure,
credential
transfer.
A
sender
should
be
able
to
initiate
the
share
over
any
communication
channel,
for
example,
email,
SMS,
WhatsApp,
Etc
and
a
recipient
should
be
able
to
view
a
preview
of
the
share
before
accepting
it.
C
The
solution
should
not
require
that
both
the
sender
and
receiver
device
are
online
at
the
same
time-
and
this
is
especially
important
for
mobile
devices
using
cellular
data
and
the
solution
should
support
opaque
message,
content
based
on
the
credential
type
and
because
the
message
content
is
opaque.
The
solution
should
be
able
to
handle
arbitrary
message
formats,
including
those
adhering
to
public
standards
like
the
car
connectivity,
Consortium
and
proprietary
or
close
Community
formats,
and
the
sender
and
receiver
should
be
able
to
manage
the
transfer
process
and
interrupt
it
at
any
time.
C
C
In
addition
to
our
security
goals,
it
is
also
crucial
that
a
user's
privacy
is
protected
while
transferring
a
credential.
So
aside
from
Network
level
metadata,
the
relay
server
should
not
learn
information
about
the
sender
or
receiver.
The
relay
server
should
not
be
able
to
create
associations
between
different
shares
and
they
should
not
be
able
to
create
a
social
graph.
C
The
relay
server
should
not
be
able
to
see
sensitive
details
of
the
share
like
the
provisioning
information
and
the
relay
server
should
not
be
able
to
provision
the
credential
itself
acne.
As
an
intermediary
for
the
receiver
or
a
person
in
the
middle
attack-
and
this
is
especially
important
because
the
relay
server
could
have
thousands
of
mailboxes
full
of
provisioning
information
and
the
provisioning
information
is
necessary
and
sufficient
to
redeem
a
credential.
C
So
a
lot
goes
into
block
goes
into
provisioning,
managing
and
using
a
digital
credential,
and
this
working
group
is
only
focused
on
the
transfer
of
the
provisioning
information.
So
most
of
that
is
going
to
be
out
of
scope
for
us
and
as
part
of
the
credential
transfers.
Some
key
aspects
of
the
flow
are
also
out
of
scope,
for
example,
defining
the
mechanism
the
receiver
will
use
in
order
to
provision
the
credential
with
the
credential
Authority
is
out
of
scope
and
similarly
the
mechanism,
the
sender
device,
will
use
to
get
the
provisioning
information
from
the
credential.
C
Authority
is
out
of
scope
and
the
user
interface
that
is
displayed
on
the
sender
and
receiver
device
during
share
initiation
and
share
Redemption
is
out
of
scope
for
us,
and
this
will
largely
depend
on
the
device,
manufacturer's
interface
guidelines
and
finally,
defining
the
format
for
each
field.
Within
the
encrypted
data
is
out
of
scope,
for
example,
the
provisioning
information
message
structure
stored
on
the
relay
server
and
we
hope
by
now
we
are
able
to
provide
a
clear
picture
of
the
problem.
D
A
D
I'm
Jim
Fenton
when
I
look
at
your
your
problem
statements
and
and
I've
I've
skimmed
your
draft
when
I
look
at
the
problem
statements
I.
Think
of
let's
take
the
hotel
room
case.
If
I
want
to
have
my
partner,
let
into
my
hotel
room
I
would
get
my
partner's
public
key.
D
Tell
the
hotel,
let
the
person
with
this
that
proves
ownership
of
this
public
key
into
my
hotel
room
and
problem
solved,
similar
situation
for
the
others
that
you're
showing
so
I
I
think
if
this
is
an
authorization
problem,
why
is
that
simple,
simpler,
I
think
solution
not
responsive
to
your
requirements.
C
So
our
protocol
is
really
more
of
a
transfer
protocol,
not
authorization,
and
so
we
could
allow
any
sort
of
authorization
to
take
place.
For
example,
something
like
you
are
talking
about,
where
with
pki
could
be
transferred
over
the
relay
server
and
then
back
to
the
recipient
device,
which
is
how
car
key
sharing
Works
or
you
know
other
completely
disconnected
types
of
credentials
like
Hotel
Keys,
which
are
symmetric,
keys.
D
Well,
they
don't
have
to
be,
but
but
yeah
I
mean
I.
It
seems
like
you're
focused
on
a
particular
protocol
rather
than
on.
The
problem
statement.
Is
that
true
that
you
have
particular
protocol
that
you
want
to
fit
into
this
requirement
rather
than
trying
to
solve
a
particular
problem,
because
you
started
with
a
problem.
E
So
yes,
and
no,
the
problem
here
is
that
we're
trying
to
cover
multiple
credential
types
right
and
simply
speaking
about
hotels,
some
of
them
use
symmetric
key,
some
isometric
key
pair
and
the
example
you
gave
with
the
public
key
of
your
partner.
It
covers
like
as
a
matter
keeper
right,
but
it
doesn't
cover
the
case
with
the
symmetric
key
and
at
the
same
time,
we
specifically
mentioned
that
we
want
to
have
granular
control
over
the
credential,
which
means,
if
I'm,
sharing
the
same
key
with
my
partner
and
the
key
is
reboot.
F
Gilmore
thanks
for
for
bringing
this
forward.
Obviously
this
is
something
that
we're
all
going
to
be
dealing
with
as
more
and
more
things
require
digital
authentication.
So
I
appreciate
you
thinking
about
it.
I
wonder
whether
you
have
any
perspective
on
the
the
hotel
example
and
sort
of
the
valet
or
housekeeper
example.
I
think
are
interesting,
where
you
have
different
authorities
that
are
there.
F
I
can't
imagine
that
a
hotel
doesn't
want
me
to
share
my
key
with
the
five
folks
that
I
met
at
the
bar
last
night,
but
at
the
same
time,
if
I
want
to
give
somebody
access
to
my
car,
so
they
can
drive
me
home.
I,
don't
feel
like
I
need
to
share
that
information
with
the
car
manufacturer,
so
the
car
manufacturer
might
disagree.
So
I'm
wondering
what
your
perspective
is
on
the
on
whether
the
framework
that
you're
building
will
like
who,
who
controls
knowledge
about
the
different
parties
that
are
involved
in
your
framework.
C
So
all
all
of
that
is
owned
by
the
credential
Authority
at
the
end
of
the
day
and
based
on
the
use
case,
the
credential
Authority
could
be
you
know
the
hotel
chain
or
for
car
key.
It's
your
you're,
the
credential
Authority,
and
so
it's
really
it's
out
of
scope
for
this
working
group.
What
the
credential
Authority
does
we're
just
facilitating
the
transfer
of
the
provisioning
information
that's
used
to
before.
A
Before
we
go
on
because
there's
been
a
little
bit
of
confusion
in
the
chat
about
this
working
group,
this
is
in
not
in
fact
a
working
group
pouring
both
it's
a
working
group
right.
F
To
understand
what
what
we're
thinking
this
scope
is
here
perfect
because
I
mean
I
can
imagine
there
being
car
manufacturers
and
I
won't
have
to
I,
won't
name
them,
but
I
could
imagine
there
being
some
car
manufacturers
who
think
they
are
the
credential
Authority
for
their
cars
and,
if
I
own,
a
car.
I
would
like
to
think
that
I
am
the
gradual
Authority
for
my
car
and
how?
F
How
will
this
architecture
that
you're
designing
here
make
that
ownership
level
clear
and
and
will,
will
it
allow
someone
to
say
I
would
like
to
take
ownership
over
this
car
from
the
from
the
manufacturer.
C
No,
so
this
great
question
by
the
way
this
protocol
would
not
make
any
Distinction
on
who
the
credential
Authority
is
or
enforce
any
opinions
on.
It
I
think
the
entire
relationship
between
the
sender
and
receiver
device
and
the
credential
Authority
we're
hoping
not
to
tackle
with
this
working
group.
B
Yeah
and
in
addition
to
your
question,
just
to
provide
additional
context
for
those
of
you
that
don't
work
with
digital
credentials
every
day,
so
those
relationships
between
like
the
actual
device
that
has
a
secure
credential
and
then
that
credential
Authority,
if
they're,
not
in
an
open
standard
like
the
car
contact
car
connectivity,
Consortium
the
CCC,
then
it's
up
to
that
device
OEM
to
really
communicate
with
that
a
credential
authority
to
figure
out
what's
their
technology
and
what
their?
What
is
their
needs.
B
So,
each
time
you
talk
to
them,
it's
like
it's
like
each
each
one.
You
have
to
basically
do
your
own
battle,
make
sure
those
privacy
pieces
and
those
ownership
pieces
are
like
maintained
as
much
as
possible
on
our
those
things
are
so
complicated,
and
we
definitely
don't
want
to
tackle
that
within
this
transfer.
But
it
is
something
we
think
about
a
lot.
H
Sam
Weiler
I'm
concerned
about
that
answer,
and
the
word
I
would
have
used
is
permissionless,
as
the
user
I
want
to
be
able
to
do
these
things
without
seeking
the
permission
of
the
relying
party
or
the
ca,
whether
it's
giving
out
keys
to
my
hotel
room
or
giving
out
keys
to
my
car
or
and
here's
the
question
for
you
about.
How
do
you
see
this
relating
to
Fido
web
authen?
Pass
Keys
pick
your
name
up
them?
How
do
you
see
it
relating.
E
Thank
you
for
a
question.
That's
an
awesome
remark
and
we
specifically
mentioned
that
we
want
to
distinguish
the
credential
transfer
from
provisioning.
A
lot
of
your
questions
will
be
covered
with
the
provisioning,
the
relation
between
sander
receiver
and
credential
Authority
right.
So
that
part
is
out
of
scope
for
us,
because
let
me
say
why,
because
there
are
variety
of
different
protocols,
some
of
them
are
open
standard,
some
of
them
proprietories.
E
I
H
I
think
this
is
this,
isn't
quite
answering
where
I'm
going
in
my
head
with
a
use
case
which
is
I
want
to
give
someone
else,
access
to
a
particular
website,
usemyunite.com,
credential
and
United-
wants
to
stop
me
from
doing
that.
I
want
to
do
be
able
to
do
that
without
seeking
their
permission.
Will
this
help
me
that's
disappointing.
B
Yeah,
so
this
might
not
be
the
answer
you
want,
but
this
cannot
help
you
with
that
and
that's
actually
in
a
sense
by
Design.
We
wanted
this
system
to
know
nothing.
You
know,
especially
after
the
share
and
you'll
see
you
saw
in
those
in
the
Privacy
requirements.
We
wanted
to
make
sure
this
system
could
not
create
that
sort
of
like
couldn't
know
anything
about
that
user.
Anything
about
that
share
or
created
like
a
share
Network
between
everyone.
B
I
just
think,
basically
to
to
do
the
things
that
you're,
saying
I
think
you
would
actually
need
to
go
away
from
some
of
those
privacy
requirements
and
have
this
be
a
much
much
smarter
system
than
what
it
really
is
to
like
to
be
able
to
con
like
know
to
control
that
stuff
from
the
sender
versus
what
it
is,
is
really
just
transferring
that
one
piece
of
data
from
sender
to
receiver
and
hopefully,
when
we
go
over
the
solution
when
Dimitri
presents
the
solution,
so
it'll
make
a
little
bit
more
sense.
J
Hi
Michael
B,
UK
ncsc
I've
got
a
question
about
the
architecture
that
relates
to
the
relay
server,
specifically
we're
sort
of
implying
that
we
definitely
need
it
in
this
problem
statement
and
discussing
the
goals.
Do
you
think
a
lot
of
this
could
be
accomplished
without
the
use
of
the
relay
server
in
the
middle
okay?
J
E
Yes,
potentially,
you
could
use
like
different
solutions,
but
this
one
is
specific
for
this
narrowly
defined
problem
and
we
implemented
certain
mechanisms
to
address
the
goals
and
the
requirements
out
to
these
different
problem.
You
could
use
some,
maybe
S3
buckets
with
some
extra
mechanisms
over
the.
K
J
Thanks
I
was
just
just
thinking
that
you've
got
already
got
a
secure
channel
from
the
sender
to
the
recipient.
So
there's
an
awful
lot
you
could
put
in
that,
but.
L
J
E
M
Hi
Erica
squirrel,
Mozilla,
so
I
guess
two
points,
one:
a
visual
Point.
M
This
is
not
working
before
it's
not
about
here
correct,
but
also
this
presentation
is
not
the
thing
they're
chartered
this
presentation
is
in
is
a
is
their
view
is
their
view
of
the
thing
discharger,
and
so
so
the
questions
are
out
of
scope
are
only
the
ones
that
are
really
removed
by
the
chart,
not
by
this
presentation,
so
I'm
not
seeing
anything
wrong
with
your
presentation.
I
just
want
to
clarify
whether
it's
Up
For
Debate
and
what
is
not
so.
Can
you
go
back
to
security.
K
L
A
Think
you
need
to
give
permission.
M
K
E
Is
but
why
is
that
a
problem
in
this
case?
So
the
problem,
let's
say
you're
sure,
since
we're
passing
credential
flight,
brings
in
the
information
separately
from
the
link
right,
that
link
can
be
copied
and
sent
to
whoever
want
to
whoever
want
to
provision
that
credential
right
and,
let's
say
10
people
at
the
same
time
want
to
provision
the
same
pass
in
their
wallet,
and
we
definitely
want
to
prevent
that.
Sorry.
E
Okay,
so
yeah
understand
the
question:
why
do
we
want
to
prevent
a
replay
attack
so
and
recently
also
obvious?
We
don't
want
the
same
credential
to
be
added
to
10
different
people
without
the
original
intent
of
the
sender.
So
if
the
sender
wants
to
send
it
to
their
partner,
we
want
only
Department
to
be
able
to
redeem
that
sure
Sydney.
M
Again,
what
I'm
trying
to
drill
into
is
that
by
the
time
I've
received
the
credential.
It
is
mine
to
send
around
and
so
and
so
so
you,
you
absolutely
can
ensure
that
there'll
be
only
one
or
only
one,
interaction
between
the
receiver
and
the
gradual
Authority,
but
that
does
not
ensure
the
only
copy,
the
credential
and
so
I'm
sure
you're
about
to
tell
me
it's
a
trusted
Hardware
module
on
the
receiver,
but
that's
not
like
I'm
pointing
at
that
as
like
that's
an
assumption
you're
making.
That
does
not
like
necessarily
a
valid
assumption.
C
I
think
another.
Another
reason
that
we
wanted
to
avoid
anti-replay
attacks
is
a
security
requirement.
Is
that
if
there's
no,
if
we
have
that
security
requirement,
then
we
can
have
more
of
an
easy
user
experience
around
the
actual
security
of
the
transfer.
If
the
link
is
short-lived
and
the
mailbox
is
short-lived,
no.
H
M
Well,
I
guess
what
I'm
trying
to
say
is
that
I
think
there
is
an
implicit
assumption
in
this
entire
entire
presentation
that
these
credentials
are
embodied
and
some
sort
of
pieces
of
trusted
Hardware
are
not
available
to
people
who
own
the
device
and
like
that
may
be,
will
be
true
but
like
that
should
be
documented
and
I
have
to
decide.
If
that's
something
that
you
want
to
assume
or
not,
because.
G
Matt
I'm
I'm
happy
to
help
try
to
answer
this
I
think
I
think
we
should
separate
out
the
constructs
here
right
and
I'll
try
to
keep
this
short,
but
I
don't
think
it's
related
to
Hardware
in
any
way
shape
or
form
right.
The
way
that
the
credential
is
housed
on
the
device,
whether
it's
in
a
secure
chip
or
not,
is
not
the
question
I.
Think
specifically
what
we
want
to
avoid
here
or
what
we're
trying
to
guarantee.
G
Actually,
when
a
sender
wants
to
share
a
credential
with
the
receiver
right,
there's
there's
the
ability
for
a
single
receiver-
and
that
is
the
goal
of
this
of
this
Charter
is-
is
to
share
it
with
a
single
person
to
to
to
have
that
transfer
of
the
credential
only
be
redeemable
for
a
credential
by
one
party
that
does
not
preclude
that
party
from
not
further
sharing
the
credential
and
that
is
encapsulated
in
the
design.
G
If
that
makes
sense,
what
we
don't
want
to
have
happen,
though,
is
the
sender,
initiate
a
transfer,
obtain
the
necessary
material
from
the
credential
authority
to
facilitate
that
transfer
and
let
more
than
one
receiver
receive
that
transfer
that
that
is
I,
think
more
than
more
than
an
assumption.
That
is
a
distinct
goal.
E
E
Precisely
when
we
established
that
channel
between
two
devices,
The
Binding
right,
it
enforces
the
fact
that
only
a
single
receiver
can
read
that
you.
M
A
M
Just
helps
but
I'm
asking
for
the
threat
model,
actually
I'm
asking
about
the
threat
model,
yeah
and
so
I
mean
I,
guess
my
point
is
that
you're
sending
a
link
around
and
so
like?
If
you
want
to
sit
down
okay,
but
if
you're
sending
the
link
around
like
like
how
does
it,
how
does
the
link
get
redeemable
people
if
you
don't
provide
the
security
medicine,
you
claim
you
provide?
M
Ahead
I
mean
so
I
wanna,
I
wanna
share
with
the
credential,
with
dkg
and
I
shared
link
with
EKG
and
and
so
well,
okay,
but
you
could
just
put
the
key
up
on
the
slides.
That's
my
point,
and
so
I'm
trying
to
understand
is
aside
from
dkg's
malfeasance,
which
you've
all
which,
which
already
allows
the
key
to
be
shared.
What
what
is
the
attack
model.
G
Well,
I
think
to
Casey's
point:
I
think
we
need
to
separate
security
mechanisms
that
would
prevent
that
individual
from
sharing
the
key
itself.
One
sharing
is
complete
from
a
Potential
Threat
in
the
sharing
itself,
so
for
the
actual
transfer
of
the
credential.
What
you
want
to
avoid
specifically,
is
you
send
a
link
to
your
friend
and
that
friend
posts
it
online,
and
anybody
with
that
link
could
then
redeem
for
a
credential.
G
M
A
Up
later
so
it
it,
this
discussion
kind
of
does
beg
a
question
that
the
chairs
have
been
meaning
to
bring
up,
and
that
is
maybe
that
the
working
group
does
need
a
separate
problem
statement
draft
and
that
could
include
a
clear
threat
model
discussion.
So
I
think
it's
something
to
keep
in
mind
here
that
that
it
maybe
is
a
document
that
doesn't
exist
today,
but
needs
to
be
written.
Remember
the
working
group
doesn't
actually
have
any
adopted
working
group
drafts
yet
right.
A
So,
but
it's
a
good
point
that
you
make
Eric
that
a
good
threat
model
is
a
sort
of
integral
part
of
this.
Now
Michael.
Do
you
wanna
Michael?
N
Hey
this
is
Wayne
from
Spruce
I
just
wanted
to
confirm
some
understandings
I
think
I
have
about
this
and
ask
if
something
could
be
possible.
So
one
thing
is:
it
seems
that
the
model
relies
on
appreciating
symmetric
encryption
key
for
the
mailboxes
right
and
that's
that's
been
so
far.
So
the
setup
is
kind
of
out
of
scope
right.
You
would
have
to
use
some
other
protocol
whatever.
That
is
right.
E
Yes,
and
no
so
we,
depending
on
the
security
model,
like
we
defined
that
certain
credential
verticals
may
require
more
secure
solution.
What
we
propose
for
the
solutions
which
are
not
that
important
to
attach
the
secret
to
the
URL,
which
probably
Eric,
is
calling
out
here,
but
for
some
use
cases
that
might
be
secure
enough,
given
that
the
channel
being
used
to
transfer
that
sure
is
is,
is
trusted.
N
Okay
and
the
follow-up
is
a
little
different
direction
so
intentionally
it's
an
opaque
token
format,
so
it
can
potentially
conform
to
other.
N
Bodies
out
there
across
different
verticals
right
and
that's
good
and
I,
guess
that
also
would
not
preclude
like
an
authorization
credential
model
that
could
be
like
down
to
a
different
key
or
something,
for
example.
Instead
of
sharing
the
private
key
material
through
this
protocol,
you
could
share
a
delegation
to
a
different
key
that
opens
the
hotel
room.
Is
that
model
possible.
H
Talking
about
definitely.
O
P
Hi,
it's
Peter
from
DEC
yeah,
so
the
proposal
doesn't
deal
with
the
credential
logic
itself
right.
So
what
the
credential?
What's
the
name
Authority
or
something
does
is
out
of
scope,
so
are
any
problems
that
may
be
resulting
from,
for
example,
sharing
a
secret
symmetric
key.
It's
a
lot
of
scope
which
is
fine,
and
so
we
just
assumed
that
there
already
is
a
credential
and
it's
an
opaque
set
of
data
fields
and
that's
somehow
the
combined
set
of
credential
information
and
provisioning
information.
P
E
I
think
that's
a
very
valid
question.
So,
if
we're
comparing
that
to
the
problem
with
sending
an
encrypted
message,
so
we
need
to
split
it
into
two
pieces
right,
so
establish
and
secure
Channel
and
then
like
send
encryption
message
there,
sorry
in
the
secret,
pretty
sure
in
secret
and
then
encrypting
data
here.
What
we
want
to
achieve
is
to
share
the
encrypted
content
and
the
link
to
that
content
like
separately
secret
and
the
content.
They
go
through
different
channels
and
we
don't
want
to
use.
E
We
don't
want
to
introduce
a
mechanism
of
pre-shared
secretly
if
it
explains
it,
and
this
is
very
narrow.
Scoped
for
credential
transfer
like
we
have
let's
say
some
provision,
information
which
in
kind
is
a
token
right,
and
we
want
eventually
that
information
be
passed
to
and
from
between
two
quarries
like
a
ping
pong,
and
we
want
to
make
sure
that
only
two
actors
can
exchange
that
information
for
a
given
mailbox.
P
Okay,
so
you
just
mentioned
some
kind
of
Link
that
there's
one
thing
and
then
there's
another
thing.
So
I
didn't
see
that
requirement
in
your
list
of
requirements.
It
would
be
cool
if
you
could
add
it.
K
A
A
And
I
have
we
have
a
few
people
on
the
Queue
and
we're
gonna,
stop
the
queue
right
after
Victor
and
and
let's
try
to
have
a
little
bit
of
time
left
for
the
rest
of
so
Ian.
I
F
I
Okay,
Ian
Williams
with
AWS
I,
noticed
that
your
protocol
here
implies
a
certain
amount
of
trust
between
the
sender
recipient
and
the
relay
I'm
wondering
like.
Is
there
any
consideration
for
if
the
relay
agrees
to
be
a
part
of
this
operation,
for
example,
if
I
as
a
sender
tell
the
recipient,
my
mailbox
is
at
Mom
and
popburgershop.com
they
might
not
enjoy
if
the
recipient
starts,
asking
them
for
keys
or
for
this
credential.
So
I'm
wondering
like
what
kind
of
considerations
might
be
made
there.
E
That's
a
great
question:
I
appreciate
it.
Yes,
there
is
a
consideration
specifically
for
sure
initiation
ran
a
sender
device
creates
the
mailbox
right.
So
we
don't
want
to
trust
anyone.
There
is
a
regulation
between
the
sender
device
and
the
daily
server,
which
means
the
sure
and
the
release
server
probably
would
be
implemented
by
the
same
party
to
establish
that
trust.
So
we
have
a
mechanism
of
attestation
which
covers
the
whole
content
of
the
mailbox
and
release
server.
E
They
need
less
trust,
let's
put
it
this
this
way
to
the
delete
server,
because
they
have
a
link
coming
from
the
front
over
a
separate
Channel,
and
they
probably
know
that
Trend
right,
they
know
their
phone
number
URL.
They
can
make
a
call
to
the
friend
and
there
are
additional
mechanisms
which
we
propose
in
the
draft
document,
such
as
Verification
codes
that
can
be
communicated
using
Voice
or
other
mechanisms.
Yeah.
I
I
saw
the
the
the
Verification
codes
that
may
be
used
between
sender
and
recipient,
but
I
didn't
see
how
that
would
again
connect
to
the
relay
server,
because
that
seems
to
be
kind
of
the
mutual
body
between
the
three
of
them.
Here
again
using
the
you
know,
Mom
and
Pop
burger
shop
as
an
example.
They
would
probably
not
enjoy
the
added
traffic.
E
Yeah
yeah
so,
as
I
said,
the
regulation
between
sender
device
and
the
release
server
is
covered
because
we
have
that
trust
established
during
using
of
device
attestation
block
which,
which
carries
the
certificate
specific
to
the
device
and
the
root
of
trust.
It
is
shared
between
sender
and
the
UV.
E
We
find
that
it's
less
important
to
establish
the
same
level
of
trust
between
the
relay
and
the
receiver.
Let's
put
it
this
way,
but
we
are
open
to
discussion.
If
you
find
really
good
arguments
to
establish
the
same
level
of
trust,
we
have
an
option
to
introduce
the
same
level
of
authentication
attestation
between
recipient
and
regulation.
L
Sorry
this
is
Nick
also
from
alphabet
I
want
to
just
chime
in
for
your
concern
about
maybe
like
the
mom
and
pop
shop
server.
Just
getting
all
these
inundated
like
traffic
for
it
and
I.
Think
maybe
that's
where
you
were
headed
I'll.
Take
on
like
the
recipient
side.
This
will,
you
know
very
per
vertical.
Of
course
you
know,
depending
on
they
want
to
use
the
relay
server,
but
at
least
when
it
comes
to
things
like
the
the
CCC
and
for
the
digital
car
keys.
L
There
is
an
allow
list
of
different
known
relay
servers
that
we
would
want
to
use,
so
the
recipient
would
have
to
choose
from
one
of
those
relay
server.
Otherwise
we
will
not
just
simply
reach
out
to
any
any
kind
of
you
know:
random
URL
that's
been
sent
from
from,
even
if
it
was
from
linked
owner.
I
M
All
right,
I
just
want
to
put
a
pin
in
this
describe
that
part
of
the
discussion,
because
actually
I
don't
really
understand
why
there
should
be
a
law
list
of
automated
servers,
because,
as
far
as
you
can
tell
them
on,
the
security
properties
depend
on
that.
So
it
seems
like
some
other
property
which
is
unclear
to
me.
So
let's
just
say
that
that's
not
not
decided
there
are,
it
seems
to
me.
M
There
are
two
assumptions
being
made
here
that,
like
perhaps
people
are
having
trouble
in
this
busy
stages,
one
might
like
one
is
that
the
channel
That,
the
sender
and
receiver
have
to
them
available
to
them
is
not
sufficiently
capable
to
deliver
arbitrary
amounts
of
data,
so
it
is
encrypted,
but
it
cannot
deliver
arbitrary
amounts
of
data.
Is
that
correct?
Yes,
okay,
so
that's,
hence
the
relay
server,
because
otherwise
you
would
just
like
spin
up
your
WhatsApp
Channel
and
then
the
whole
thing
or
Whatsapp
right.
M
Okay,
and
the
second
is
that
the
sender
is
not
able
to
transfer
the
credentials
directly
to
the
recipient,
because
it
requires
the
cooperation,
the
credential
server,
correct,
yes,
good,
okay,
so
I
think
that's
like
without
saying
that
I
agree
with
everything
here:
that's
how
we
get
to
this
design,
there's
those
two
constraints,
because
otherwise,
otherwise,
as
Jim
Fenton
says,
it
would
just
like
spit
up
signal
and
like
shift.
The
entire
thing
over
like
like,
like
a
verb
signal
right.
Okay,.
B
Q
So
Paul
and
Jake
says
I
think
my
question
I
think
Ecker
more
or
less
asked
it.
But
can
you
say
a
little
bit
more
about
what
the
constraints
on
that
out
of
band
channel?
Are
that
you're,
you're,
assuming
and
and
what
we
need
I
mean.
Is
that
something
we
can
be
discussed
in
this
requirements
trying
to
get
just
a
better
feel
of
what
you
see
the
limit
of
that
so
that
we
can
design
to
it.
C
You
try
not
to
so
we've
we've
been
thinking
about
the
constraint
for
that
messaging
Channel
as
any.
We
want
to
be
able
to
use
any
messaging
channel
that
users
can
talk
over,
including,
like
writing
the
URL
on
a
piece
of
paper
and
giving
it
to
someone
so
any
missing
any
messaging
channel
that
can
transfer
you
know
100
characters
or
less
kind
of
as
our
constraint
or
lack
of
constraints.
Q
I
mean
makes
sense.
Can
you
say
a
little
bit
more
about?
What's
driving
you
to
that
sort
of
size
or
the
ways
you
imagine
it's
being
transferred
that
would
that
would
put
to
that
I'm
just
trying
to
pull
out
the
reverse
out
the
requirements
here.
C
Q
Yeah,
what
messaging
channel
does
so,
obviously,
that's
already
way
too
long
for
me
to
type
in
okay,
so
they're
not
being
shared
that
way
from
a
user
experience,
obviously
so,
which
message
channel?
Is
it
that's
in
that
you
that
would
practically
be
used,
that's
putting
that's
causing
a
limit.
What's
that
limit,
looking
like
like
100
is
pretty
small
yeah
I
think.
C
One
of
the
common
ones
was
like
SMS,
has
240
characters
yeah
this
one.
That
was
one
of
the
main
MMS.
Q
A
O
I
wonder
how
much
attention
is
being
paid
to
potential
abuse?
Is
this
a
kind
of
a
standardized
fishing
channel
effectively
where
somebody
can
start
soliciting
credentials
from
me
and
if
I'm,
a
naive
user
I
will
start
giving
them
away
to
all
kinds
of
parties
whom
it
misrepresent
who
they
are
or
what
they
want,
or
why
I
should
give
the
credentials
to
them?
What's
the
story
on
protecting
the
mostly
naive
audience,
that's
likely
to
encounter
this
facility.
C
So
because
the
relationship
between
the
sender
and
the
credential
authority
to
get
the
provisioning
information
is
happens
before
this
protocol
comes
in,
we
don't
think
there
could
be
much
or
any
fishing
on
the
sending
of
a
credential
side.
It
would
only
be
sharing
credentials
to
someone
that
maybe
they
didn't
necessarily
want.
O
Right,
well,
that's
the
key
question
right
I
mean
sure
I'm
I
have
a
pre-established
relationship
with
the
relay
Bank
car.
My
car
company,
whoever
now
somebody
encourages
me
to
share,
do
I,
really
know
who
they
are.
How
easy
is
it
to
misrepresent
what's
going
on
to
me
and
so
on?
You
know
it's
how
much
thought
or
our
attention
needs
to
be
paid
to
this.
E
Great
question:
so,
potentially
there
is
a
risk
like
when
we
generate
that
mailbox
and
we
generate
a
share
URL
to
that
mailbox
right,
as
Nick
previously
said,
the
least
of
the
relay
address
is
trusted.
The
address
is
it's
limited
by
the
allow
list.
Second,
the
content
of
the
preview
which
I
will
discuss
later.
The
content
shall
be
trusted
by
really
server,
so
it
shall
originate
from
a
trusted
server
for
us,
it's
a.
K
E
Manufacturer
server,
so
the
picture
that
they
will
see
in
the
preview.
It
won't
come
from
Bob
and
mom.com,
whatever
flowers.com
it
will
come
from
a
trusted,
server
and
I.
Think
it's
it's
one
of
the
security
considerations
mentioned.
O
C
This
is
this
is
something
worth
thinking
about
a
lot,
but
I,
don't
think
it's
part
of
The
Proposal,
at
least
at
this
point.
Maybe
that
should
be
something
that
we
look
at
further.
B
Yeah,
the
one
piece
over
that
is
the
bond
to
the
solution
yet,
but
we
have
a
delete,
mailbox
API
and
the
idea
is
that
you
could
call
that
at
any
moment.
Not
just
so.
If
you
were
to
send
that
share
link,
you
know,
oh
no,
even
if,
like
you're
kind
of
talking
about
malicious
situation,
but
even
on
an
accident,
you
sent
it
to
the
wrong
person
you're
able
to
go
delete
that
mailbox
before
that
recipient
has
provisioned.
B
So
that's
from
from
our
perspective,
how
we
could
have
a
little
bit
of
security
about
that
in
the
relay
server
and
then,
from
a
larger
perspective
that
credential
Authority
is
in
charge.
So,
like
worst
case
scenario,
everything
goes
wrong.
You
could
talk
to
that
credential,
Authority
and
say
hey.
This
was
wrong.
Please
revoke
that,
and
we
have
that,
like
third
party
outside
the
relay
server
that
could
handle
that
situation.
E
So
just
wanted
to
confirm
whether
a
part
of
the
question
is
the
trust
relationship
between
the
sender
device
and
the
delay
and,
what's
the
attack
here.
E
O
System
feature:
it's
to
what
extent
will
I
know
who
I'm
really
sharing
with?
It
applies
more
broadly
really
than
this
particular
thing,
but
naming
is
hard
and
this
thing
really
automates
it
to
a
degree
where
the
attacks
become
easier.
I
think-
and
you
know,
do
I
really
know
who
I'm
sharing
with?
How
strong
is
that,
when
it's
intermediated
by
a
third
party,
especially.
L
Yeah
I
want
to
just
chime.
In
again
this
is
Nick
from
alphabet
again.
I
think
this
whole
identity
of
sender
receiver,
especially
on
the
receiver
side.
Maybe
this
is
a
little
bit
more
difficult
to
solve,
and
definitely
out
of
scope
for
the
working
group
that
we're
we're
trying
to
propose
here
for
the
solutions
the
the
relay
server
here.
Is
it's
not
an
Arbiter
of
like
identity
here
and
we're
really
trying
to
not.
You
know
at
least
right
now,
maybe
in
the
future.
L
You
know
we
may
have
ideas
around
this,
but
not
not
trying
to
solve
the
identity
issue
or
be
the
authority
of
that.
G
Yeah
I
think-
and
this
is
Matt
again
I-
think
just
to
add
on
to
what
Nick
said.
You
know
when
you
really
come
down
to
it:
you're
initiating
the
transfer
over
credential.
Let's
pretend
you
use
SMS
or
email,
just
just
just
to
you
know,
use
an
example.
G
You
know
you
don't,
as
the
sender
really
have
confirmation
of
the
identity
of
the
recipient.
You
only
know
that
you
know
you
know.
For
example,
I've
been
texting
this
person
at
this.
You
know
SMS
number,
for
you
know
five
years
technically,
you
know
one
minute
before
you
issue
that
share.
They
could
have
gotten
a
new
phone
number
and
that
phone
number
could
have
been
reassigned
from
the
carrier
and
in
possession
from
somebody
else,
and
so
I
think
you
know
to
Nick's
point
and
to
you
know,
Dimitri's
point
it
really.
G
The
onus
is
really
on
the
sender
to
make
sure
that
they're
sending
the
credential
to
a
channel
that
is
tenured
from
their
perspective
and
that
they
have
confidence
of
who
is
on
the
other
end
of
whatever
Communication
channel
they
choose
to
send
it
through
and
that
that
doesn't
really
have
anything
to
do
with
the
relay
server.
In
my
mind,
at
all.
A
I
I
we're
at
the
point
today
where
we're
going
to
switch
over
to
talk
a
little
bit
about
the
proposed
solution.
Lathe.
R
A
R
S
L
A
H
E
My
name
is
Dmitry
I
I
will
present
to
you
a
proposed
solution
to
the
problem
of
transferring
credential
digital
credential
securely.
So
thank
you.
The
Crux
of
our
proposed
solution
is
a
release.
Server
that
facilitates
a
short-lived
Communication
channel
between
sender
and
receiver
devices.
Sender
and
receiver
devices
will
communicate
over
that
agility
server.
Using
a
single
mailbox.
E
All
the
messages
will
be
encrypted
using
asymmetric
encryption,
key
or
Secret
communication
over
a
release.
Server
is
completely
decoupled
from
the
provisioning
logic
and
the
content
of
the
messages
is
opaque
to
delay
server
English
cell
no
have
any
visibility
to
the
content
or
sensitive
information
within
the
encrypted
provisioning
information
and
the
content
shall
never
be
revealed
to
it.
Some
metadata
may
be
visible,
such
as
a
format
type,
which
is
required
to
define
whether
it's
stateless
or
status
flow.
E
Let's
walk
through
the
solution
at
a
very
high
level,
so
the
standard
device
initiates
the
transaction
by
uploading
provisioning
information
to
the
delay
server,
creating
a
mailbox
uniquely
identified
by
mlbox
identifier,
and
then
it
sends
a
share
URL
containing
secret
over
a
separate
Channel,
SMS
email
WhatsApp
to
the
receiver
device,
a
receiver
device
downloads.
The
content
decrypts
it
using
the
secret
and
Provisions
a
new
credential
to
the
device.
E
E
Status,
facilitates
a
single
unidirectional
data
transfer
from
sender
to
relay
to
a
receiver.
New
credential
is
generated
by
credential
Authority
here
in
a
stateful
flow
again,
a
server
facilitates
multiple
data
transfers
to
prepare
credential
data
and
for
registration
or
provisioning
by
receiver.
E
The
new
credential
scheme
material
is
generated
by
a
receiver
device
according
to
CCC
spec,
for
instance,
for
example
here
and
it
needs
to
be
authorized
by
sender.
Hence
an
additional
round
trip
is
required.
The
details
will
be
provided
later
on
in
a
couple
of
slides
when
I
go
through
the
data
flow.
E
Now
we're
going
to
discuss
our
Solution
on
the
API
level
for
our
solution,
we
describe
degree
storage
as
mailbox.
Are
there
simple
data
stores
along
to
be
written
to
enter
up
from
so
to
begin?
We
create
a
mailbox,
it
would
be
at
the
beginning
of
the
transfer
flow.
A
standard
device
would
call
again
a
server
to
create
a
mailbox,
storing
encrypted
provision
and
information.
E
Degree
server
will
generate
a
unique
mailbox
identifier
and
now
for
that
data
and
return
Azure
URL,
pointing
to
that
mailbox
when
it's
even
sure,
you're
well,
most
messaging
applications
will
perform
a
get
request
to
read:
display
information
preview
in
open
graph
data
format.
The
messaging
application
on
the
receiver
will,
if
it
supports
open,
grab
format,
it
will
generate
a
credential
preview
in
a
messaging
app
so
that
the
user
can
realize
what
they
are
accepting
before
they
add
the
credential,
and
this
is
mostly
for
a
user
experience,
better
user
experience.
E
When
a
user
has
clicked
on
the
link
and
accept
the
sure
the
receiver
device
will
go,
read
the
secure
information
from
the
real
email
box.
In
order
to
fetch
encrypted
provision
information,
it
will
use
the
secret
past
industry
URL
in
order
to
decrypt
it
and
provision
the
credential
to
the
device
for
situations
that
require
multiple
round
trips
to
the
delay
server.
We
have
an
update,
mailbox,
API,
I,
hear
sander
and
receiver
devices
could
upload
and
update
the
same
mailbox
in
a
limited
time
in
accordance
to
the
protocol.
They
are
following.
E
You
can
imagine
a
back
and
forth
between
sender
and
the
receiver
device
where
each
device
reads
and
updates
the
information
with
their
own.
Once
the
transfer
is
complete.
There
is
a
delete,
mailbox
API.
In
order
to
clean
up
this
way,
we
can
ensure
that
mailbox
are
purged
after
the
transfer
process
is
finished.
E
E
E
E
E
The
receiver
device
there
is
a
messaging
application
which
sees
the
incoming
message.
It
makes
a
get
request
and
redisplay
information
generates.
A
preview
shows
it
to
the
user.
User
sees
a
new
message
as
a
credential
preview
in
a
messaging
app
and
decides
to
accept
the
sure
clicks
on
it.
Sure
URL
is
forwarded
to
the
platform
specific
credential
management
application,
for
instance,
wallet.
E
E
It
gets
the
prison
information
as
a
result.
Seventh
slide,
please,
seventh
receiver
device
makes
a
call
to
provisioning
Authority
in
order
to
redeem
provision,
information
for
credential
information
and
then
Provisions,
a
new
credential
to
the
device
and
final
step.
8
receiver
deletes
the
mailbox
and
this
concludes
the
stateless
flow.
E
In
a
stateful
flow,
there
is
no
credential
Authority
per
se.
Instead,
a
pair
of
sander
and
receiver
device
act
together
as
a
credential
Authority,
generating
new
credential
information
and
authorizing
it
for
a
new
device,
and
second
flow
has
additional
steps
after
step
6
comparing
to
the
previous
stateless
flow.
So,
let's
start
with
seven.
E
A
receiver
device
generates
a
new
key
material
for
the
receiver
updates,
provisional
information
with
key
sign
in
the
request
and
uploads
the
content
to
the
delay
server
using
update,
mailbox,
API,
eight
sender
device
against
updated
provision,
information
from
the
mailbox
and
receives
key
signing
request.
E
9.
sender
authorizes
new
receiver
scheme
material
in
a
key
sign
and
response
and
updates
the
provision
in
info
uploads
it
to
the
mailbox
with
update
mailbox,
call
and
receiver
device
downloads
the
updated
provision
info,
decrypts
it
and
Provisions
the
new
credential
locally
done.
Finally,
the
receiver
device
deletes
the
mailbox
and
this
concludes
the
status
flow.
E
G
E
Presented
to
you,
the
problem
and
the
solution
to
the
transferring
digital
credentials
securely
between
two
devices,
as
we
stated
in
the
beginning,
the
proposed
solution
is
based
on
the
transfer
of
authorization,
information
or
provisioning
information
that
we
call
it
previously
between
two
devices
in
order
to
obtain
new
credential
from
the
credential
Authority,
rather
than
transferring
original
credential
with
all
related
cryptographic,
material
redress,
both
privacy
and
security
concerns
and
requirements
to
the
solution.
Using
mechanisms
defined
in
the
draft
document.
Please
feel
free
to
read
the
document
at
the
following
URL.
E
So,
thank
you
very
much
for
showing
interest
to
this
working
group.
I
really
hope
that
more
people
will
participate
in
this
working
group
and
we
hope
our
proposal
will
be
adopted
by
ITF
community
and
now
we
move
on
to
q
a
session.
A
Right
before
everybody
rushes
to
the
mics
again,
I
want
to
ask
who
quick
show
answers.
Read
the
draft?
A
Well,
that's
that's
good
you're!
You
can
raise
your
home
like
kind
of
like
this
right,
all
right,
that's
good!
It's
a
good
size
number
of
people.
All
right!
Victor
is.
O
Hi,
the
the
protocol
looks
a
lot
like
GSS
API,
embedded
in
HTTP
with
the
credentials
of
the
receiver
sent
asynchronously,
so
they
can
participate
in
the
ongoing
conversation.
Is
this
roughly
correct?
Have
you
looked
at
GSS
API,
because
in
some
sense
the
state
machine
is
sort
of
indistinguishable
from
what
goes
on
GSS.
E
M
Your
scroller
I'm
just
trying
to
tease
apart
the
pieces
here
so
suppose
we
relax
the
requirement
that
you
have
to
go
over
Channel.
That
only
cares
multiple
bites.
How
much
this
is
left.
E
That's
very
good
point:
we
do
consider
that
different
credentials
may
have
different
value
and
based
on
that,
they
may
have
different
requirements
and
additional
mechanisms
that
we
can
enforce.
In
addition
to
that
search,
Channel.
E
I
believe
part
of
them
will
be
enforced,
as
let's
say,
for
the
car
key
enforced
by
a
CCC
standard
at
the
time
of
provisioning.
There
are
multiple
mechanisms
that
we
can
utilize
additional
Verification
codes.
Second
factor
and
such
no.
M
M
G
I
think
this
is
Matt
Byington
again,
I
think
there
are
some
really
simple.
You
know
borderline
non-technical
reasons
as
well.
Eric
like
like
you,
don't
want
to
see,
like
you
know,
like
an
x509
encoded
public
key.
You
know
coming
through
on
a
on
a
communication,
Channel
That's
shown
to
end
users.
That
would
be
very
confusing
to
them
right
in,
like
an.
M
M
I
mean
I
mean
well,
but
when
you
say,
like
you
say,
like
ignore
user
experience
right,
but
you
know
you
already
have
to
modify
the
like.
M
There's
a
bunch
of
modifications
being
made
in
various
places
and
like
the
operating
system
is
completely,
is
completely
able
to
like,
for
instance,
have
some
SMS
messages
bypass
the
SMS
viewer
and
go
directly
to
something
like
doesn't
entirely
when
the
scope
of
the
operating
system
so
like
I'm
trying
what
I'm
trying
to
push
on
is
like
the
requirements
of
the
system
is
like
you're,
creating
this
like
kind
of
like
weak
sauce
replica
of
web
dev.
That
then,
like.
K
M
Then
is
being
used
and
I
mean
I'm,
like
we
have
like
a
zillion
ways
to
like
send
messages
back
and
forth
from
people
and
so
I'm,
trying
to
figure
out
like
like
why
we're
creating
like,
like
this,
involves
creating
like
a
new
messaging
system.
That,
like
has
this
drop
weird
kind
of
Dropbox
metaphor
and
trying
to
figure
out.
Why
we're
doing
that
and
so
and
is
any
other
reason
other
than
the
channel
has
narrow
capacity,
and
that
and
that
you
think,
before
the
message
out
of
the
users
like
mlx.
G
Yeah
I
mean
just
to
reply
to
your
operating
system.
Comment
I
mean
the
operating
system
is
not
in
control
of
the
UI
on
the
screen.
If
it's
like
a
you
know,
third-party
Standalone
messaging
app
like
WhatsApp
or
WeChat,
or
something
like
that
right,
how
would
the
operating
system
help
help
the
experience
there.
K
N
K
If
the
receiver
is
going
to
engage
in
some
special
protocol
here,
the
receiver
has
to
have
some
smarts
already.
It's
got
to
treat
these
URLs
in
the
correct
way,
or
is
the
receiver
just
doing
a
normal,
get
request
to
this
and.
G
Yeah
I,
I
I,
don't
think
it'd
be
possible
to
do
special,
UI
logic
in
an
application
that
controls
its
own
UI
when
it's
being
drawn
on
the
screen
like
an
email,
client
or
Whatsapp
or
WeChat,
or
any
of
those
type
of
you
know,
programs,
it's
worth
noting
those
programs
would
do
a
simple
HTTP
get
on
that
URL.
G
In
fact,
they
do
that
on
every
URL,
at
least
with
the
HTTP
protocol,
and
and
that's
where
you
would
get
some
of
this
open
graph
preview
coming
into
play
right
that
you
know
they
would
do
that,
but
but
they
you
know,
those
operating
systems
would
need
special
logic.
Yes
to
actually
receive
the
share,
ingest
it
and
get
the
credential
provisioned
totally
agree
with
that.
M
M
M
E
Wouldn't
say
so,
why
it's
a
protocol
to
solve
this
given
problem
to
transfer
provision
information
from
one
device
to
another?
That's.
K
Maybe
I
could
draw
a
different
analogy
here.
There
was
a
bunch
of
discussion
in
dispatch
on
Monday
of
file
transfers
over
limited
channels.
You
know,
like
you,
see
this
all
the
time
in
messaging
systems,
where
you
transfer
a
URL
to
a
file,
that's
stored
somewhere
else,
you
send
it
the
URL
and
the
messaging
Channel,
and
then
the
receiver
goes
and
downloads
the
thing
and
people.
You
know
commonly
augment
this
with
a
little
bit
of
crypto
so
that
the
URL
either
you
know,
has
a
key
embedded
in
it
or
has
a
key.
K
Alongside
of
it,
the
server
where
the
file
lives.
It
doesn't
see
the
plain
text
concept,
so
it's
largely
similar
to
what
we're
doing
what
we're
doing
here
so
I
guess
what
I'm
wondering
is
to
what
degree
is
this
kind
of
an
instantiation
of
that
design
pattern
in
the
sense
of
being
a
way
to
transfer
some
sensitive
data
over
a
you
know
where
you
have
a
limited
Channel
that
you,
maybe
you
have
less
trusted,
maybe
slightly
less
processing,
if
you're
still
sending
the
key
over
it.
K
But
maybe
you
you
entrust
the
server
threats
and
access
controls
or
something
and
to
what
degree
is
it
specific
to
this
credential
use
case.
K
So
to
reset
that,
like
it
seems
like
you're
talking
about
using
this
transfer
protocol
to
transfer
credential
related
information,
could
I
not
use
the
same
mechanism.
You've
laid
out
here
to
send
cat
pictures
or
nuclear
submarine
designs
or
whatever
sensitive
thing.
I'm
trying
to
send
to
hacker
foreign.
E
Distributed
file
system
right
when
we
can
store
something
and
then
the
reader
can
read
it.
E
It
wasn't
the
goal
of
this
solution
to
transfer
generic
files,
and
we
we
had
a
number
of
the
goals
like
which
were
defined
in
the
very
beginning.
We
needed
it
to
be
a
short
like
token
right,
personal
information
we
needed
to
that
token
to
be
delivered
to
one
device,
and
we
wanted
the
transfer
process
to
be
limited
between
one
sender
and
a
receiver.
So
once
the
transfer
started,
we
wanted
that
limitation.
One
receiver
can
read
that
or
update
that
and
provision.
E
Third,
we
wanted
that
temporary
storage
not
to
be
able
to
look
into
what
was
transferred
like
not
to
be
completely
completely
unaware.
It's
it's
opaque
for
them.
That's
that
was
goal
number
two.
E
Third,
we
were
heavily
trying
to
solve
problem
of
mobile
devices,
not
always
having
cellular
coverage
all
of
the
time,
and
we
still
wanted
the
problem
to
be
solvable
under
those
conditions,
and
there
are
additional
limitations
due
to
the
nature
of
those
mobile
devices
such
as
we
added
potential
push
notifications
in
order
to
react
as
soon
as
the
data
was
updated
right
on
the
Gili
server.
So
it
is.
This
problem
is
very
negative,
focused
on
a
given
use
case.
We
didn't
want
it
to
be
a
generic
solution
for
file
transfer.
Q
So
let
me
just
follow
into
that
Richard
here
Association
before
the
I
want
to
ask
about
something.
Q
You
actually
just
said
in
your
last
thing
and
I
stood
up
before
to
ask
about
which
you
push
notifications
because
well
before
we
even
started
on
the
boff
of
this
one
of
the
things
that
made
me
think
this
was
quite
different
than
many
of
our
other
mailbox
protocols
at
ITF
was
a
requirement
for
the
relay
to
be
able
to
or
the
mailbox
to
be
able
to
send
push
notifications
to
clients,
and
that
hasn't
been
mentioned
in
the
stuff
today
and
I
was
wondering.
Is
that
still
an
extension
you're
looking
at?
Q
C
That
is
definitely
still
something
we're
looking
at
and
it's
included
in
our
draft
proposal.
Right
now
we're
thinking
about
it
pretty
generically
where
the
push
notification
type
can
be
specified
and
then
each
relay
server
operator
can
work
with
different
device
oems
to
interact
with
their
push
notification
infrastructure,
but
that's
definitely
a
requirement
for
the
mobile
devices.
T
So
I
heard
I've
heard
half
a
dozen
to
a
dozen
different
requirements
that
weren't
explicitly
mentioned
in
the
first
presentation
and
I
think
you've
got.
You
know
the
reason
you
have
many
people
asking
questions
is
they're
kind
of
trying
to
poke
around
and
ask
basically
requirements
questions,
it's
very
traditional
for
a
new
working
group
or
even
for
a
boss
to
start
off
with
requirements
and
then
to
and
then
to
go
to
a
protocol,
and
if
you
do
start
with
some
pre-existing
notion
of
what
your
protocol
should
be.
T
I
didn't
read
the
complete
document,
but
I
did
like
scan
through
quite
a
bit
of
it
and
there's
no
real
mention
of
the
protocol.
So
I
would
like
to
recommend
that
you
please
do
a
document
that
said
that
gives
those
nice
use
cases
that
you
had
in
your
in
your
presentation
and
lists
requirements,
including
these
subtle
requirements
and
then
I
think
that
you're
going
to
get
some
people.
Some
people
are
going
to
push
poke
at
those
requirements.
Some
people
are
going
to
add
requirements
or
propose
new
ones.
T
B
Just
to
add
to
that,
I
think
that
your
point
is
really
good
and
I
think
that
a
large
answer
to
a
lot
of
your
questions,
which
might
not
be
as
satisfactory,
is
just
when
we're
looking
at
all
these
different
existing
applications
or
ways
that
we
could
have
transferred.
We
just
always
found
something
that
was
missing.
It's
like
like.
Oh,
this
is
almost
what
we
needed.
Oh,
but
we
need
to
miss
one
requirement.
So
hopefully,
whenever
we
create
that
requirements,
document
I'll
make
it
clear.
E
B
E
Just
to
add
to
that,
we
seriously
considered
it's.
It
was
a
problem
where
we
tried
to
find
the
right
balance
between
security
and
usability,
as
it
is
always
the
case
in
us
with
Security
Solutions.
So
we
tried
to
provide
the
best
possible
user
experience.
That's
why
the
lacks
sometimes
relax
security
requirements,
and
there
is
a
security
considerations
section
at
the
end
of
the
draft
document.
It
might
address
some
of
the
questions
departments.
Okay,
point
taken.
Thank
you.
U
So
crystalman's
Comcast,
it's
not
clear
to
me
that
it
is
possible
to
develop
a
solution
that
works
for
credentials
specifically
without
specifying
what
kind
of
credentials
and
making
them
completely
opaque
without
making
it
also
just
as
useful
for
cat
pictures,
and
so
so
I
mean
I
to
me,
the
messaging
protocol
comments
are
exactly
on
point
and
so
I
I
find
myself
wondering
what
kind
of
relationship
does
the
relay
server
have
with
both
the
sender
and
the
receiver
of
the
credentials?
Does
it
know
their
identities?
Does
it
keep
track
of
them?.
C
So
the
sender
and
the
sender
has
a
relatively
tight
relationship
with
the
relay
server.
They
have
they're
able
to
generate
access
stations
to
prove
that
they
have
rights
to
create
mailboxes,
but
those
attestations
are
Anonymous
and
it's
a
very
important
feature
of
the
relay
server
that
they
don't
know
any
identifiable
information
about
senders,
okay,.
E
Nothing
is
now
the
question
is
what
makes
the
sender
to
start
using
that
daily
server.
So
there
should
be
certain
level
of
trust
between
the
sender
and
the
release
server.
So
the
sender
starts
using
given
release
server,
mm-hmm.
U
E
U
E
E
That's
why
we
precisely
mentioned,
and
a
DOT
document,
that
we
want
to
enforce
the
elite
server,
not
to
see
anything
sensible
like
any
sensitive
information.
That's
why
we
mentioned
device
attestation
potential
like
optional
device
attestation
and
that
device
attestation
is
the
basis
of
trust
between
sender
and
receiver.
If
sander
covers
his
cat
picture
with
the
device
at
the
station
and
a
release,
server
trust
that
sender
trust
that
device
attestation,
which
is
anonymous
potentially,
which
doesn't
reveal
any
user
information
to
the
relay,
really
trust
that.
L
L
The
only
kind
of
thing
is
the
sender
or
the
user.
Are
they
okay
with
the
Restriction
that
is
sent
I
mean
that
are
set
for
this
messaging
Channel
and
and
that
that's
really
the
Restriction
that's
applied
here
right?
Are
you
okay,
with
having
a
short-lived
TTL
to
send
your
cat
pictures
or
you
know,
are
you
okay,
with
just
sending
this
information
just
to
one
other
party
and
not
not
to
like
one
to
many
messaging
Channel
things
like
that,
so
the
the
idea
is
like?
Yes,
you
could.
L
You
could
use
this
channel
outside
of
the
intended
purpose,
but
are
you
okay
with
the
Restriction?
That's
that's
going
to
be
set
forth
in
in
that
relay
server.
B
Yeah
and
just
one
other
little
piece
is
that
you
could
configure
your
mailboxes.
You
know
this
is
dependent
on
whoever
is
implementing
this,
but
you
could
configure
your
mailbox
to
have
to
be
really
small.
So
for
us
you
know
like
this.
Provisioning
information
is
going
to
be
quite
small,
so
less
than
a
cat
picture.
So
then
you
make
it
so
unusable
that
no
one
would
want
to
use
it.
Except
for
your
purpose,
not
to
say
that's
like
100
like
you
know
foolproof,
but
it
gets
a
little
closer.
A
K
I
just
want
to
make
a
brief
amendment
to
my
earlier
comments
and
be
clear
that
I
didn't
mean
to
be
be
negative
on
this
work.
I
I
was
actually
kind
of
yes
ending
like
clearly
I
think
that
it
seems
clear.
This
is
an
okay
starting
point,
at
least
for
for
the
credential
use
case.
I
think
all
I
would
meant
to
suggest
is
that
it
could
be
useful
to
some
other
parts
of
the
ietf.
K
If
we
look
and
clarify
those
boundaries
and
see
if
it
can
be
expressed
in
a
way
that
would
be
useful
in
some
other
folks,
just
to
think
about
how
to
express
things
more
generally,.
M
C
The
protocol
defines
the
attestation
pretty
generally
and
then
leaves
it
up
to
held
the
sender
and
the
receiver
device
want
like
what
type
of
attestation
they
want
to
use,
but
generally
it's
just
around
the
user
and
the
device
being
authentic
and
not
like
a
device
Farm.
M
L
L
This
one
sorry
Dmitry
I,
think
the
the
the
protocol
or
like
the
relay
server
proposal,
has
this
attestation,
which,
which
is
very
very
generalized
right,
I,
think
it's
kind
of
left
up
to
the
implementation
of
it
to
create
this
relationship
of
what
that
testation
really
means,
and
it
doesn't
necessarily
have
to
be
an
identity
Source.
It
could
just
be
a
very
generalized
like
even
just
like
key
pair,
where
you
have
like
a
root
key
that
you
could
identify
some.
L
You
know
Hardware
that
that's
been,
that
has
like
the
public
key,
that's
stamped
in
from
the
manufacturing
process,
or
something
something
as
simple
as
that,
so
that
you
trust
that
this
device
has
some
form
of
authority
to
create
this
mailboxes
on
your
relay
server.
But
this
again
is
it's.
You
know
it's
for
implementation
detail,
rather
than
it
is
a
restriction
on
the
The
Proposal
itself.
So.
L
F
L
Oh,
if
you,
if
you
deem
that
you
don't
need
this
kind
of
you
know,
security
like
if
you
are
implementing
this
really
server
yourself
or
for
whatever
other
purpose
that
you
want
to
use
for
your
own
proprietary
kind
of
like
transfer
credential,
and
you
know
you
want
to
make
it
open
and
you
don't
have
to
use
that
attestation.
If
you
don't
want
to.
L
Yes,
yeah
I
think
I
mean
it
can
be,
it
can
be
right.
You
know
it
depends
on
the
implementer
and
and
on
the
person
adopting
the
the
credential
right
you,
you
might
have
a
home
key
and
you
want
to
use
a
relay
server.
You
you
have
many
different
choices
of
using
either
implementing
your
own
or
or
just
using
something
that
has
been
implemented,
but
it
all
kind
of
depends
on
the
implement
or
of
all
of
this.
M
I
I
I'm
not
really
following
so
you
know:
I
have
the
Hilton
app
hypothetically
and
I
like
push
the
button,
because
I
want
to
share
my
room.
Key
with
dkg
and
I
met
him
in
the
bar
earlier,
as
he
mentioned,
one
of
the
five
people
and
the
and
so
like
I
push
a
button.
That's
got
to
go
somewhere
right,
like
I.
Don't
choose
some
reason:
I'm
not
going
to
raise
her
right
so
like.
Where
does
it
go
and
who
decide?
Who
makes
the
decision
and
what
Creations.
L
If
you're
seeing
a
Hilton
I
think
the
short
short
you
know
answers
if
you're
staying
at
Hilton
Hilton
would
try
to
decide
which,
where
that
that
relay
server
will
be
at
right,
they're,
the
one
who
wants
to
do
the
transferring
of
that
hotel
Key,
they
would
be
the
domain
owner
of
that
now
they
might
have.
You
know,
options
at
the
Genesis
of
light
trading
that
the
application
of
which
relief
server
to
use,
whether
they
host
their
own
or
maybe
use
one
that
already
exists.
That
would
be
entirely
up
to
like
Hilton.
M
If
security
security
requirements,
the
system
depend
on
having
that
Define.
So
so,
maybe
like
the
answer,
is
it
doesn't
matter
and
it
doesn't
matter
what
the
server
it
is.
But,
like
that's
like
an
input
like,
then
we
need
to
know
that
so
and
so
the
second
reason
I'm
pushing
on
this
is
because
it
seems
like
one
of
the
consequences
of
this
potentially.
M
Is
that
because
this
is
if
every,
if,
if
like,
if
every
relay
server
creates
its
own,
if
every
application
has
a
relay
server,
then
this
creates
a
new
locus
of
of
tracking
of
what
credentials
are
being
shared
with
other
people.
Besides
the
credential
server,
and
so
that
seems
like
a
personalizable
property
as
opposed
to
some
more
generic
system,
so
is
there
some
way
to
remove
the
property?
If
this
creates
a
graph
of
everybody
who
shared
with
everybody
else,.
L
M
M
But
how
what
aircraft
has
created
right?
How
is
it
not
created.
C
D
E
So
a
simple
question,
like
simple
answer
to
a
question:
it's
up
to
credential
authority
to
manage
whoever
owns
the
key
at
the
moment,
make
any
connections
with
them.
That's
specifically
why
we
put
the
credential
management
out
of
scope
for
this
solution
for
us
for
the
email
server.
It's
just
a
set
of
calls
right.
Http
calls
coming
from
different
IP
addresses,
and
the
IP
addresses
is
what
we
are
supposed
to
be
able
to
track
the
only
piece
we
shall
not
be
able
to
see
the
content
what's
inside
right.
E
What
kind
of
credential
is
there
any
sensitive
info
there,
and
that
was
the
the
goal
of
the
solution
and
the
security
requirement?
If
it
I
don't
know
if
it
answers
your
question.
A
P
P
I'm
not
sure
if
I
understand
right,
so
my
understanding
was
that
when
I
want
to
share
a
credential,
the
credential
is
already
there
and
then
I
decided
to
share
it.
So
at
that
point,
when
I,
somehow
upload
the
share
to
the
relay
server,
the
credential
Authority
is
not
involved.
P
I
thought
I
thought
it
just
uploaded
anywhere
like
one
one
server
that
supports
this
relay
protocol,
so
that
made
me
wonder
why
that
would
have
to
do
with
the
relay
sorry
with
the
credential
Authority
operating
that
relay
server,
and
so
that
made
me
wonder
one
more
thing.
So
how
is
it
supposed
to
work
in
practice
like
on
my
device
and
on
the
recipient's
device?
P
Am
I
supposed
to
have
an
app,
for
example,
so
I
receive
a
credential
from
somewhere,
then
I
hit
share
this
credential,
then
an
app
pops
up
and
it
will
will
upload
it
to
some
relay
server
that
perhaps
I
can
select,
or
perhaps
it
is
specific
to
the
app
I.
Don't
know
that
then
I
will
get
a
link.
Then
I
will
share
this
through
some
other
Channel
with
the
recipient,
and
then
what
happens?
The
person
clicks
on
the
link
and
then
how
does
the
retrieval
of
the
content
work?
P
It's
a
post
request,
so
I
can
imagine
two
ways
either.
The
recipient
also
has
the
app,
in
which
case
that
may
also
be
tied
to
this
relay
server
and
only
work
with
certain
ones
or
it
may
just
fire
up
the
browser,
in
which
case
for
decryption
it
would
be
necessary
to
fetch
some
some
JavaScript,
which
is
actually
from
the
relay
server.
P
So
there
is
a
like
circular
thing
going
on
regarding
trust,
so
the
two
questions
I
have
in
this
regard
are:
is
this
open
to
me
operating
my
own
relay
server,
for
example,
and
if
so,
how
would
that
fit
in
with
this
app?
Would
the
app
be
specific
to
one
operator
and
how's
the
retrieval
working
with
this
JavaScript
thing?
So
that's
the
first
set
of
questions
I
have
after
that,
I
have
a
different
comment.
E
Awesome
question:
we
definitely
tried
to
solve
that
problem
and
number
one
in
order
to
be
able
to
manage
credentials
on
the
device
you
need
some
software.
You
definitely
need
either
application
like
a
like
wallet
or
third-party
application
that
recognizes
this
is
credential.
This
is
our
credential
provider
and
it
is
aware
of
the
process
like
how
do
we
generate
that
provisional
information?
How
do
we
like,
which
relay
server
to
call
in
order
to
store
that
info?
How
do
we
pass
the
share
URL
as
a
link
at
the
same
time,
on
the
receiving
device?
E
What
you're
receiving
is
basically
just
a
URL.
You
make
a
get
call
right.
You
get
HTTP
page
with
open
graph
in
the
header
and
if
your
messaging
app
understands
open
graph,
it
will
generate
you
preview.
The
next
thing,
when
user
clicks
on
that,
like
in
the
message
and
app
Messaging
App,
should
be
aware.
E
P
E
E
If
you
want
to
enforce
the
requirement
that
there
is
a
certain
level
of
trust
between
your
application
and
a
giveaway
server.
As
we
mentioned
the
attestation,
you
need
to
be
able
to
share
some
some
trust
right,
a
number
of
certificates
to
be
able
to
realize
this
is
valid.
This
is
trusted,
so
there
might
be
some
limitations
if
you
want
to
establish
that
level
of
trust,
if
it
makes
sense.
B
Just
to
answer
your
your
question
about
like,
if
you
were
to
create
your
own
app
and
like
wanted
to
run
your
own
relay
server,
so
I
think
what
would
probably
happen
is
that
you,
as
the
sender,
are
effectively
choosing
the
relay
server
you
want.
So,
if
you're
running
your
own
app,
that
would
probably
give
you
one
option,
which
is
that
apps,
like
you
know
that
the
apps
really
server.
So
then
you
send
that
link
over
to
your
recipient
device
and
say
that
recipient
doesn't
have
your
new
app
like
ITF
for
fun.
B
Then,
when
you,
when
you
click
on
the
link,
you'd
be
doing
a
get
and
you'd
probably
just
be
showing
a
like
it'd
pop
into
whatever
web
browser.
You
have
on
that
device
and
you'd
probably
have
to
have
information
about
how
to
actually
gather
that
you
know
credential
information
off
that
relay
server,
so
you
probably
have
to
download
that
app
and
then
that
app
would
know
what
to
do
with
that
link.
So
it's
handled
very
similarly
for
us
between
wallets
and
Etc.
B
P
Okay,
if
you
had
some
other
pattern
in
the
URL
that
would
allow
this
kind
of
URL
to
be
recognized
as
a
share
link
independently
of
the
relay
server.
That's
used
independently
of
the
hostname,
for
example,
by
introducing
a
scheme
the
schema
prefix.
For
that,
then
you
could
have
a
recipient
app
that
works
for
all
relay
servers
and
I.
Think
that
would
make
things
easier,
for
example,
also
address
the
concern
that
was
there
earlier.
When
somebody
mentioned
resources
from
from
people.
P
So
that's
the
first
sort
of
thing
that
I
want
to
say,
and
the
second
is
just
a
comment:
I
think
the
term
mailbox
is
a
contradiction
of
terms
because
it's
not
for
arbitrary
mail
and
it's
just
for
credentials
in
this
proposal
and
also
in
the
mailbox
I
would
expect
that
I
can
have
several
messages
which
I
can
delete
independently,
but
the
delete
semantics
here
delete
the
whole
mailbox.
P
So
it
doesn't
seem
like
a
mailbox
to
me,
and
so
it's
more
like
a
single
exchange,
Point,
somehow
and
I
would
recommend
renaming
this
term.
B
We
can
definitely
bring
that
into
the
email
thread
and
make
one
about
what
to
update
instead
of
mailbox
and
to
your
previous
point,
I
think
that,
as
we
gather
more
interest
and
participation
through
this
working
group,
we
can
definitely
figure
out
hey.
Maybe
there
is
just
a
prefix
or
some
format
that
all
sharing
links
for
any
relay
server
should
follow
at
the
moment
we
don't
have
as
much
of
that
participation
we're
looking
for
that.
U
Chris
lemon's
Comcast,
so
you
said
at
one
point
and-
and
we
just
we
just
touched
on
a
number
of
these,
but
you
said
at
one
point
that
the
expectation
is
that
for
a
given
type
of
credential
from
a
given
credential
Authority
that
the
most
the
expected
relay
server
would
be
operated
by
the
same
sort
of
entity
that
operates
that
Authority
and
that
certainly
a
conceivable
scheme.
U
U
Or
is
the
choice
of
relay
server
100
within
the
within
the
grasp
of
the
sender.
C
So
the
choice
of
relay
server
is
really
up
to
the
credential
Authority,
making
the
share
not
up
to
the
sender.
E
I
think
what
Alex
manned
there
should
be
level
of
trust
between
credential
Authority
and
ascendant
application.
So
that's
obvious
right
because
no.
E
That's
out
of
scope:
let's
put
it
this
way
out
of
scope
for
this
working
group.
Now
the
level
of
trust
between
sender
and
degree
server
is
up
to
the
implementer.
If,
let's
say
I
want
to
be
able
to
trust
based
on
the
hardware-based
certificates
or
on
like
some
sort
on
pki
level,
we
need
to
establish
that
and
we
need
to
implement
mechanism
covering
the
content
which
is
uploaded.
E
It
very
much
depends
on
the
implementation
on
the
security
policy
on
of
the
second
Glacier
work,
waiter,
to
trust
that
sender
and
the
same
holds
true
to
the
sender,
application,
someone,
May
Crack,
the
Code
of
that
credential
Manager
application
and
redirect
them
to
a
different
relay
server.
So
that
combination
might
not
necessarily
work
both
depends
on
the
implementation.
That's
why
we
mentioned
that
such
scenes
as
device
attestations.
They
are
optional,
based
on
the
security
level
selected
by
each
implementation.
Right.
U
U
But
what
I
don't
see
is
how
how
Cas
can
influence
and
I
realized
that
the
definition
of
CAS
outside
of
the
scope
here
but
but
I,
think
it's
important,
because
I
think
we
might
be
relying
on
it
for
something
here,
because
the
I
don't
understand
how
the
ca
influences.
U
U
L
Hi,
this
is
Nick
again
I
just
want
to
it.
Doesn't
matter,
I
think
you're
right,
it
doesn't
matter
so
CA
does
not
enforce
what
really
server
gets
used.
So
you
know
you
have
the
you
know,
credential
provisioning
information
that
just
gets
sent
between
two
devices
and
and
it
doesn't
care
how
that
was
done.
L
The
only
time
I
make
here
is,
at
the
very
you
know
end
when
the
the
receiver
maybe
tries
to
provision
a
a
credential
with
the
provision
Authority
that
the
right
information
is
present
there,
so
that
Communication
channel
that
occurs
to
deliver
that
you
know
provisioning
information
does
not
matter
and
is
not
opinionated
by
the
the
the
ca
I
believe,
that's
how
it
is
in
terms
of
the
open.
L
You
know
if
you
you,
as
like
a
pub
you
know,
private
entity
wants
to
to
have
some
form
of
you
know
security
around
like
which
which
really
serve
a
consent,
then
sure,
surely
you
could
try
to
have
like
enhancement
that
you
could
put
around
it
to
ensure
that,
but
that's
not
what
we're
baking
into
like
the
proposal
in
terms
of
like
which
release
server
gets
used
and
it's
controlled
by
and
it's
not
controlled
by
the
the
ca.
U
Okay,
so
so
there's
no
technical
or
even
policy
reason
why
I
couldn't
run
my
own
relay
server.
Configure
my
devices
to
use
my
relay
server
other
than
the
people
receiving
the
links
might
be
confused
when
they
receive
a
you
know,
lemons.example.com
address
instead
of
a
carkey.com
example.com
yeah.
L
L
U
Right
and
so,
and
so
that
brings
me
to
the
the
last
question-
I
had
I
hope,
which
is
that
when
you
receive
one
of
these
things,
how
do
you
know
that
it
is
a
credential,
because
I
just
got
a
link?
L
Right,
so
you
know
that
that
is
yeah.
So
in
the
URL
itself
we
do
have
a
you
know.
We
call
a
vertical
it's
a
very
it's
a
it's,
a
query
parameter
that
tells
you
the
type
of
vertical
it
is
like.
If
you're
using
a
car
key
for
transferring
car
keys,
Hotel
keys,
there
may
be
something
to
denote
that
this
is
a
credential
transfer
for
like
a
car
key
and,
furthermore,
sorry
you
you
could
reach
out
to
that
relay
server.
L
There
are
information
that
you
couldn't
look
at
after
you've
decrypted
the
message
to
see
the
type
of
credential
that
you're
trying
to
transfer
here.
So
there
are,
there
are
more
information
in
the
encrypted
portion
after
you,
decrypted
absolutely.
U
Once
I
got
it,
decrypted
I
have
an
object.
I
could
probably
figure
out
what
to
do
with
it.
Are
you
suggesting
that
I'm
going
to
read
the
URI
and
there's
going
to
be
special
format
for
the
URI
and
if
the
URI
is
in
a
particular
format
and
has
magic
query,
parameters
that
are
registered
somewhere,
that
that's
going
to
do
a
different
thing,
so
I
think.
N
E
C
R
Huff-
and
this
may
actually
be
a
lead
into
the
what
happens
next,
but
I
heard
and
by
the
way
I
have
not
read.
The
draft
I
was
interested
in
the
topic,
but
I'm
like
way
out
of
my
depth
here,
but
I
heard
a
lot
of
people
asking
questions
with
you
guys
saying.
Yes,
we
should
add
that
to
requirements,
we
should
add
that
to
the
requirements,
but
then
I
heard
Romans
say
there
isn't
going
to
be
a
requirements
document.
So
are
we
talking
about
putting
the
requirements
in
the
solution
document
say
here
were
the
requirements.
R
A
Right,
I'm
going
to
unlock
the
queue
for
the
sort
of
what
happens
next
discussion.
So
you
know
there
are
many
ways
to
do
this
right
as
Roman
points
out.
This
actually
has
is
in
the
charter,
but
you
know
there
if
I'm
correct,
there's
nothing
stopping
us
from,
for
instance,
from
having
a
separate
working
on
use,
requirements
and
problem
statements
in
a
separate
draft
and
I'm
folding
it
into
the
finished
product,
as
we.
S
Yeah,
that's
exactly
right.
I
would
urge
us
strongly
not
to
over
index
on
where
we
put
the
requirements.
We
heard
a
long
discussion
that
we
want
requirements.
Let's
write
some
text
and
you
know
those
of
us
kind
of
concerned
on
the
process
kind
of
side,
we'll
figure
out
what
the
right
way
is
to
make
sure
that
it
appears
and
manifests
in
the
right
way.
M
Think
we're
hopeful
to
me
would
be
like
here's
the
requirements
and
then
here
are
some
of
the
obvious
things
you
might
try
to
do,
and
this
is
why
they
don't
work
because
I'm
like
requirement
19.,
because
I
think
what
you're
hearing
a
lot
of
is
like
people
sort
of
looking
at
this,
and
maybe
not
seeing
the
complete
picture
that
you
seem
to
see
and
saying
like
well,
why
don't
you
do
this
and
so,
like
I,
think
we're
helpful
if
you
could
like
I,
don't
think
I
mean
I,
don't
think
it
has
to
be
like
R1
or
2r3
R4,
but
I
think
it's
describe
enough
for
problem
space.
M
Q
Challenges
I
think
also
like
these
are
great
slides
and
presentations.
Helped
a
lot
like
this
has
been
really
good
today.
I
think
it
also
would
help
some
people.
Certainly
myself.
You
could
just
show
the
stuff.
That's
like
here's,
how
we
Imagine
One
Way
like
this
is
a
small
piece
of
a
solution
right.
This
is
a
much
broader
thing,
so
take
one
instance
of
it
like
the
car
unlock
case
or
the
hotel
room
case
and
say,
like
look.
Q
Here's
sort
of
what
one
possible
deployment
of
the
full
solution
might
look
like
with
all
the
pieces
and
here's
where
the
pieces
with
that
the
itfs
defining
fit
in
like
right
here
in
this
little
bit,
but
I
mean
people
are
getting
lost
on
like
what
the
OS
does,
what
which
is
it
the
Hilton
app?
Is
it
the
wallet?
Q
You
know,
there's
a
lot
of
different
things
floating
around
here
and
different
apps
and
different
relay
servers
and
not
to
say
that
we're
trying
to
Define
that's
the
only
way
to
deploy
it
or
every
way
to
deploy
or
anything,
but
just
give
people
a
flavor
of
here's,
a
possible
implementation
and
deployment
that
uses
this.
For
the
whole
system
and
here's
all
the
pieces
and
what
they
look
like
I
think
that
would
help
people
understand.
Q
L
I
think
that's
a
really
good
feedback.
I
think
you
know
we
kind
of
index
a
little
bit
on
on
the
other
side,
where
we
we
want
to
make
it
so
agnostic
that
we
didn't
want
to
bring
in
specific
use
cases
to
explore.
But
I
think
that's
a
really
great
point
in
in
trying
to
like
have
like
a
projection
of
how
this
works
right,
given
like
an
actual
use
case.
Q
O
Just
one
comment
on
anti-replay:
my
impression
is
so
far
that
it's
implemented
by
the
relays,
rather
than
by
the
final
credential
issuer
that
completes
the
credential
provisioning.
If
that's
the
case,
then
I
can
create
a
downstream
relay
that
memorizes
messages
and
makes
it
possible
to
duplicate
the
conversation
to
as
many
parties
as
I
want.
So
that's
something
worth
thinking
about
if
it's
important
somehow
to
avoid
replay
is
that
the
system
can
be
extended
in
such
a
way.
That
replay
becomes
something.
B
Yeah
so
it's
kind
of
built
in
in
two
different
ways,
so
one
the
relay
server,
because
the
mailbox
is
actually
deleted.
But
also,
if
you
remember
in
the
first
graph,
we
get
that
provisioning
information
from
the
credential
Authority.
So
you
can
think
of
it
as
a
token
that
the
credential
Authority
is
storing.
So
when
that
credential
Authority
then
sees
that
token
it'll
say
like
okay,
that's
the
person
and
then
say
that
you
got
the
provisioning
information.
B
O
But
my
recipient
can
be
an
actual
Downstream
relay
that
facilitates
replayability,
so
I
can
deliver
the
credential
to
my
own
relay,
which
unbeknownst
to
the
real
relay
is
actually
a
relay
that
memorizes
messages
and
then
that
thing
can
not
delete
messages
and
allow
them
to
be
replayed
and
all
kinds
of
fun.
Stuff.
L
Yeah
I
think
I
think
there's
different
layers
of
security
that
we
have
to
be
aware
of
right.
I,
think
you
know.
The
relay
replay
attack
here
for
the
Relay
server
is
something
that
we'll
try
to
sufficiently
address
on
that
relay
server
part,
but
ultimately,
I
think
there's.
There
needs
to
be
an
additional
security
when
it
comes
to
the
actual
credential
and
how
that
is
specked
out
like
for
one
example,
I'll
give
is
that
for
CCC
there's
also
an
addition
of
something
called
an
immobilizer
token.
L
So
you
know
this
is
some
a
unique
token
that
you
need
to
be
presented
with
the
car
for
for
to
accept
the
key
and
to
operate
the
vehicle.
So
you
can't
just
use
the
same.
You
know
immobilizer
token
twice
so
I
think
this
is
a
combination
of
not
just
relying
on
the
release
server
itself
being
like
the
end.
All
for
for
all
replay
attack,
I
think
we'll
do
what
we
can
on
the
the
messaging
side
of
it.
L
A
All
right,
Nick,
thank
you,
I
think
we
have
with
the
last
five
minutes.
I
want
to
get
to
a
couple
of
administrative
stuffer,
including
possibly
get
if
if
we
can
adopt
the
the
draft
as
a
working
group
document,
so
that's
no
I'm
gonna
ask
for
adoption
of
the
working
group
document
as
a
draft
as
a
working
group
document
completely
seriously,
and
if
you
want
to
be
against
that,
you
can
do
that
right,
but
I'm,
not
joking.
No
okay,.
A
Well,
you
thank
you.
Well,
you
can
have
again
right.
It's
perfectly
reasonable
type
of
opinions
right,
but
oh
thank
you
so
again.
If
I
will
still
ask
the
working
group,
whether
you
are
whether.
G
A
A
They're
about,
let's
hear
the
number
of
people
in
the
room
kind
of
seem
to
match
the
the
people
who
have
raised
their
hands
at
this
point,
we're
still
getting
one
or
two
people
chiming
in,
but
it's
I
mean
it's
about
50
50
at
this
point,
which
is
I,
guess
a
little
bit
too
rough
consensus
to
to
to
go
ahead
and
adopt
the
work,
the
current
draft.
So
what
we'll
do
here
is
that
we'll
ask
the
working
groups,
the
the.
A
Exactly
it's
not
consensus
total
all
right,
which
means
that
we'll
and
ask
the
waters
to
re-spin
the
document
and
keep
working
on
it
then
we'll
come
back
to
it
to
a
later
version.
I
think
what
we've
heard
here
is
a
clear
consensus
for
some
sort
of
requirements.
Document
them
I
think
it's
a
good
idea
to
put
that
in
a
separate
document
for
now
and
then
we'll
we'll
see
if
that
gets
merged
into
whatever.
Whatever
this
turns
out,
it
turns
into
all
right
and
that's.