►
From YouTube: IETF-SECRET-20220210-1700
Description
SECRET meeting session at IETF
2022/02/10 1700
https://datatracker.ietf.org/meeting//proceedings/
A
C
B
I
should
I
should
probably
unmute
helps
all
right
welcome
to
the
secret
buff,
I'm
one
of
your
secret
chairs.
If
you
want,
along
with
sean,
I
think
we'll
make
maximum
use
of
the
silly
name
during
the
proceedings
all
right
and
we're
gonna.
This
is
sort
of
pre-itf
113-ish
as
usual.
This
is
run
under
itf
note.
Well
so
note
the
note
well
well,
if
you
haven't
been
to
an
itf
buff
for
a
meeting
before
go
read
this
carefully.
B
A
B
B
I
think
we're
going
to
spend
just
a
couple
of
minutes
talking
about
what
we're
going
to
do
here.
What
is
a
both
and
what?
What
are
we
trying
to
achieve
we're
going
to
get
a
presentation
from
like
the
both
proponents
here,
matthew
and
his
team
are
going
to
talk
about
the
you
know,
the
problem
of
secure
credential
transfer
and
we're
going
to
try
to
keep
that
sort
of
item
3
relatively
short,
so
we
have
a
lot
of
time
for
discussion.
B
We're
gonna
keep
as
much
time
for
discussion
and
then
we're
gonna
try
to
do
a
little
bit
of
a
charter
discussion.
Afterwards,
we
have
some,
maybe
some
words
meeting
to
do.
Look
at
charter
text
and
we're
gonna
be
as
chairs
we're
going
to
be
asking
a
couple
of
questions
at
the
end
to
make
sure
to
understand
whether
we
actually
have
what
it
takes.
What's
needed
to
establish
a
working
group
out
of
this.
B
D
A
We're
trying
to
do
is
make
sure
that
you
know
that
the
the
problem
and
statement
in
the
use
cases
are
kind
of
well
understood
by
people,
and
that
this
is
work
that
the
ietf
you
know
it's
the
right
place
to
do,
and
not
just
that
there
are
actually
people
that
are
willing
to
read
the
drafts
participate
in
writing
them.
You
know
the
whole
nine
yards
and
for
this
particular
group
I
guess
one
of
the
points
that
was
raised
in
the
dispatch
area.
A
It's
the
art
area
and
on
their
dispatch
list
was
to
make
sure
they
had
enough
security
chops
involved
in
the
let's
develop
an
apps
thing,
and
I
think
we
can
get
that.
We
just
have
to
make
sure
that
we
might
specifically
ask
like.
Are
there
enough
security
people
in
the
room
to
actually,
you
know,
lend
some
eyes
to
read
and
then
the
after
that,
after
we
figured
out
that
there's
enough
people
that
are
actually
interested,
it's
you
know
can,
can
we
get
it
done?
Do
we
think
we
have
enough?
A
I
guess
we
gotta
have
enough
people
you
know.
Can
we
can?
Are
we
happy
with
the
words
which
essentially
the
in
the
charter,
which
is
the
pack
that
the
working
group
would
be
making
with
the
isg
to
get
their
work
done
and
then
other
deliverables
clear?
And
so
we
actually
do
have
some
words
that
are
proposed.
I
personally
hate
reading
the
words
out
during
a
block,
but
sometimes
that's
what
you
got
to
do
and
then
people
want
a
wordsmith
on
the
fly.
A
My
attitude
is
we
get
to
that
point
and
people
are
relatively
happy
with
things
that
we'd
switch
to
hedge
docs
and
we'd
cut
and
paste
the
charter
text
and
go
to
town.
Otherwise
we
can
just
do
that
later
because
to
me
I
think
it's
kind
of
like
if
people
have
a
general
sense
of
you
know
kind
of
the
size
of
the
square.
B
Right,
I
think
what
we're
going
to
do
now
is
to
let
matthew
run
his
slide
deck
and
I
know
sean.
Are
we
gonna
ask
people
to
hold
questions,
or
are
we
gonna
break
for
questions
during?
I
I'm
inclined
to
think
we
should
let
the
presentation
go
through
and
then
have
have
as
much
have
discussion
and
and
questions
at
the
end.
A
F
F
F
This
is
a
topic
that
you
know
myself
and
the
other
proponents
are
obviously
you
know
very
passionate
about
solving,
and
so
it's
really
exciting
for
us
to
see
people
come
together
and
talk
about
it
in
terms
of
questions,
I
think
you
know
I'm
happy
to
follow
leif
and
sean's
guidance
to
kind
of
hold
questions
towards
the
end.
I
guess
the
only
caveat
there
would
be.
F
You
know,
maybe
if
there's
a
clarification
like
something
in
the
slide
or
something
that
I
say
that
doesn't
make
sense
or
that
folks
want
to
clarify
what
I
mean
by
that
I'm,
you
know
totally.
Okay.
If
you
know
people
want
to
jump
in
and
ask
for
clarification,
but
for
further
discussion.
You
know
at
the
end
that
you
know
that
would
be.
You
know
totally
fine,
so
we'll
go
through
the
slides
here
myself
and
a
couple
of
other
proponents
as
well,
we'll
be
speaking
to
other
slides
in
the
deck.
F
F
F
You
know,
as
I
mentioned,
come
from
different
verticals,
so
it
could
be
a
car,
a
home,
a
hotel,
a
place
of
business.
You
know
in
the
access
realm
you
know
could
even
be
something
to
do
with
transit
like
riding
a
subway
and
the
the
real
meat
of
the
problem
statement
that
we
want
to
solve
in
the
working
group
that
we
hope
to
establish
is
to
allow
users
to
share
these
digital
credentials
with
other
individuals
and
we'll
go
through
some
of
the
detailed
examples
in
the
use
cases
section
today.
F
You
know
no
such
standardized
method
exists
that
works
completely
cross-platform,
meaning,
regardless
of
what
company
manufactured
the
the
actual
phone
or
and
what
you
know,
which
company
manufactures
the
operating
system
and
then
cross
vertical,
just
meaning
that
we
want
this
to
solve
for
different
types
of
credentials.
As
mentioned
earlier,
like
you
know,
access
credentials,
transit
credentials
and
things
like
that.
G
Yeah,
I
just
want
to
make
a
quick
clarifying
question
here
when
you
talk
about
credentials.
Obviously
you
know
that
can
imply
a
bunch
of
different
stuff,
but
it
sounds
like
a
particular
property
from
a
kind
of
security
point
of
view
of
a
credential
is
that
it
has
some
secret
stuff
that
the
the
credential
transfer
service
is
probably
not
authorized.
G
F
Yeah
great
great
point
I'll
touch
on
that
real
quick,
so
there
are
different
types
of
credentials,
namely
symmetric
based
from
a
crypto
perspective
and
asymmetric.
Let
me
give
you
an
example
of
both
one
common
example
of
a
symmetric
credential
is
a
my
fair
death
fire
applet
running
on
a
you
know,
mobile
device,
and
there
is
a
symmetric
key
that
was
derived
for
that
user.
It's
derived
from
an
intermediary
symmetric
key
for
a
specific
property.
F
If
you
look
at
hotels,
a
lot
of
them
use
my
fair
desk
fire
and
that's
you
know,
obviously
an
applet
technology
type
and
a
protocol,
and
that
is
a
symmetric
credential
that
cannot
leave
the
device
and
the
handshake
between
the
device
and
the
actual
terminal.
There's
some
crypto
there.
You
know
you
know,
there's
a
mac,
there's
there's!
You
know
lots
of
crypto
in
that
interaction
that
the
door
that
that
allows
the
door
to
verify
that
credential.
That's
that's!
That's
one
example
of
a
symmetric
one.
F
An
example
of
an
asymmetric
credential
could
be
a
digital
car
key
that
complies
with
the
ccc
standard,
which
we'll
talk
about
a
little
bit
later
in
this
deck.
Those
are
asymmetric
credentials
in
that
you
know
you
have
a
private
and
public
key
on
the
private
part
of
which
lives
on
your
device
and
that's
how
you
get
into
the
vehicle.
You
also
see
this
in
iso
18013
for
mobile
drivers
license
that's
an
existing
public
standard,
that's
pretty
recent,
so
there
are
examples
of
both
symmetric
and
asymmetric
credentials.
F
I
think
it's
safe
to
say
that
you
know
for
asymmetric.
You
never
can
have
the
private
key
leave
the
device
that
owns
it
for
obvious
reasons
and
the
same
thing
for
symmetric
right,
and
so
you
know.
Obviously
the
crypto
is
very
different,
but
that's
one
of
the
reasons
that
in
sharing
a
credential,
you
can't
just
lift
this
thing
off
of
the
the
the
individual
who
endeavors
to
share
and
give
it
to
somebody
else.
F
F
We
we
don't
endeavor
to
dictate
how
these
are
provisioned,
managed
or
used
from
a
transaction
perspective
on
the
different
devices
and
platforms
we
only
endeavor
to
solve,
for
how
they're
actually
shared
and
so,
for
example.
The
solution
that
we
want
to
come
up
with
inside
of
the
working
group
would
not
dictate
how
a
credential
was
ultimately
provisioned
onto
the
recipient's
device
that
would
be
up
to
that
platform.
We
only
want
to
cover
the
transfer
aspect
of
it.
F
Secondly,
in
in
this
you
know
very
highly
mobile
world
that
we
all
live
in.
We
really
do
not
want
to
require
both
devices,
so
the
sender
and
receiver
to
have
to
have
an
active
internet
connection
concurrently
for
the
transfer
to
be
successful.
Let
me
give
one
quick
example:
there
digital
car
key
adhering
to
the
ccc
spec
cryptographically,
if
I
want
to
share
to
sean
my
existing
private
key,
that
the
vehicle
trusts
must
sign
a
public
key
and
associated
attestation
from
one
that
sean's
device
will
generate
on
the
fly
during
this
sharing.
F
For
that
to
work,
I
need
to
get
that
public
key
from
him,
sign
it
and
give
it
back
to
him
and
obviously
with
devices
being
in
airplane
mode
or
coming
online
and
offline
at
different
times.
That's
a
challenging
thing.
So
you
know
we
just
want
to
say
that
we
do
understand
that
there's
a
back
and
forth!
F
That's
needed
it's
kind
of
impossible
to
get
around
that,
but
we
don't
want
to
require
both
devices
to
be
online
at
the
same
time,
and
the
best
example
of
that
is
if
sean
is
out
hiking
in
the
woods,
with
no
connection,
I
should
be
able
to
initiate
a
transfer
to
him
that
completes
when
his
device
comes
back
online.
That's
the
simple
version
of
it,
and
then
it's
probably
obvious,
but
you
know
these
credentials
are
very
sensitive.
Some
of
these
credentials.
You
know
let
you
into
somebody's
home
or
hotel
room
or
vehicle.
F
Also
I
mentioned
this
earlier,
but
there
are
security
primitives
that
are
guaranteed
by
the
hardware,
and
you
know
I
kind
of
use
guaranteed.
Loosely
I
mean.
Obviously,
tamper
resistant
is
a
better
way
to
put
it.
We
don't
know.
If
anything
is
tamper,
proof
it's
not
possible
to
just
transfer
the
credentials
themselves,
and
I
also
mentioned
briefly
earlier
that
cryptographically
that
would
be
undesirable.
Even
if
it
was
possible
you
you
never
want
a
private
key
owned
by
two
different
parties
right.
F
We,
you
know,
we
want
the
recipient
to
generate
their
own
key
pair
and
have
similar
permissions,
for
example.
So
we
want
the
sender
to
authorize
the
receiver
to
provision
or
to
register
a
new
credential
with
whatever
privileges
and
entitlements
that
the
sender
has-
and
I
say
subset
because
I
could
own
a
vehicle
and
share
it
with
my
partner,
and
I
want
him
or
her
to
have
the
same
exact
privileges
that
I
do.
F
We
co-own
the
vehicle,
or
I
might
endeavor
to
share
it
with
a
valet
individual
at
a
hotel
or
restaurant,
and
I
want
them
to
have
fewer
privileges
like
maybe
they
can't
open
the
trunk,
for
example,
and
then.
Lastly,
we
talked
about
this.
That
protocols
like
ccc
do
require
specific
cryptographic,
data
from
the
sender,
so
we
you
know
we
do
need
to
comply
with
that.
If
we
want
this
to
work
for
credentials
that
adhere
to
the
ccc
open
standard.
F
F
B
F
Well,
I
think
it
depends
on
who
the
blind
party
is
in
the
case
of
digital
car
keys,
the
the
actual
verifying
party
is
actually
the
vehicle
itself
right
and
and
and
that's
a
little
bit
different.
I
do
think
in
the
ietf
specification
that
we
ultimately
come
up
with.
If
we're
able
to
establish
the
working
group
and
work
on
the
solution.
F
Yeah,
the
the
sender
and
receiver
will
have
to
have
software
baked
into
their
devices
to
adhere
to
the
transfer
protocol
and
perform
the
necessary
exchange
of
data
back
and
forth
to
facilitate
the
transfer,
and
that
is
required,
and
it
is
different
for
different
credentials.
It
will
look
a
little
bit
different
for
ccc
in
terms
of
what
actual
data
is
being
transferred
than
it
will
for,
like,
for
example,
a
micro
desk
fire
hotel
key.
There
are
some
credentials
that
already
adhere
to
an
open
standard.
F
The
best
to
do
as
an
example
is
iso
18013
and
the
ccc
digital
car
key
spec,
and
there
are
other
proprietary
ones
that
use
public,
open
standard
technology
like
my
free
desk
fire
or
some
other
technology,
but
that
the
the
file
system
on
that
applet
is
proprietary
to
whatever
company,
whether
it's
a
corporation
or
a
hotel.
I
don't
know
if
that
helps
answer
your
question
or
not.
F
I
Sounds
good,
please!
Let
me
know
if
you
hear
me,
I
was
just
trying
to
start
my
microphone
and
everything
crashed,
I'm
back
so,
first
of
all,
yeah.
Okay,
awesome!
So,
first
of
all,
we'll
be
talking
about
the
vehicle
use
case.
Matt
described
a
little
bit
of
this
in
the
previous
slides
so
but
I'll
go
into
a
little
bit
more
detail.
I
I
I
Sorry,
I'm
like
kind
of
weird
next
imagine
I
have
a
car
with
a
digital
car
key
and
I've
gone
to
a
fancy,
dinner
or
hotel,
and
I
would
like
to
give
my
car
to
valet
I'd
like
to
give
them.
Maybe
some
restricted
access
for
a
short
period
of
time,
and
maybe
they
can
only
drive
up
to
25
miles
per
hour
and
they
can't
enter
into
the
trunk.
They
only
need
to
be
able
to
drive
it
and
park
it
matt
next
slide.
G
A
question
before
we
go
to
the
next
one:
yeah,
just
one
quick
clarification
here:
kind
of
as
looking
at
the
kind
of
reverse
of
the
partner
case
where
you
had
access
before
someone
else
and
you
granted
them
access.
Is
there
also
a
need
here
to
have
a
revocation
where
you
know
say
things
go
badly
between
my
partner
and
I
and
we
go
our
own
ways?
Can
I
is
there
a
need
in
this
protocol
to
be
able
to
revoke
access
as
well.
F
F
Yet
we
do
think
that
there
is
a
revocation
needed
after
the
share,
but
it's
almost
separate
from
the
transfer
flow
in
a
way,
and
I
think
the
reason
that
we're
kind
of
thinking
that
and-
and
obviously
we
could
talk
about
this
further
in
the
working
group,
of
course,
but
is
that
the
the
actual
revocation
really
depends
on
the
way
that
the
credential
is
used
and
the
kind
of
you
know
credential
authority
right
and
so
like
here's.
Here's
one
example
in
the
case
of
transit.
F
Those
turn
styles
are
not
online
they're,
they're,
fully
offline
right
and
so
to
actually
rescind
that
that
company-
let's
say,
for
example,
jre
japan,
rails
east
right.
They
need
to
push
a
new
credential
to
this
deny
list,
and
that
needs
to
make
it
to
all
of
their
turn.
Styles.
This
is
actually
how
it
works,
and
they
do
that
once
per
day.
F
G
I
Okay,
so
in
the
last
slide
we
were
mainly
talking
about
the
different
time
scenarios
or
exact
entitlements
you
might
want
to
transfer
and
as
part
of
the
share,
but
we
also
deem
to
solve
these
different
online
offline
scenarios
as
matt
started
to
discuss.
So
I
will
talk
about
two
different
scenarios.
We
were
thinking
of
say
I
own
the
vehicle,
and
I
want
to
share
it
with
my
friend.
My
friend
is
currently
out
hiking
and
don't
have
seller
or
service.
I
So
I
want,
but
I
still
want
to
share
my
key
with
them,
so
I
initiate
this
share
and
send
them
this
the
share
link
and
once
the
device
comes
back
online,
they're
able
to
receive
and
accept
this
share,
and
there
should
be
no
issue
with
the
fact
that
they
weren't
online
at
that
time.
So
you
know
this
should
be
able
to
be
asynchronous
say.
On
the
flip
side,
I
own
the
vehicle-
and
I
want
to
share
to
my
friend-
I've
sent
a
share
invitation,
but
then
I
myself
has
gone
out.
I
Hiking
we're
hiking
a
lot
in
this
group,
and
now
I
would
like
my
friend
once
once
the
user.
The
recipient
has
accepted
my
share.
It
should
be
able
to
to
finish
the
share.
Complete
should
be
able
to
complete
once
my
device
has
come
back
online,
so
there
should
be
able
to
be
situations
where
the
sender
or
receiver
device
can
go
online
and
offline
throughout
the
transaction,
but
continue
to
work
once
the
devices
are
online.
I
So
now
we
will
talk
about
the
home
use
case
so
say
I
own
a
single
family
home
and
have
a
a
smart,
lock,
a
digital
key
on
my
front
door.
I
have
a
dog
walker
that
comes
on
thursdays
to
walk.
My
dog
skipper
he's
very
active
and
when
I'm
at
work
I
need
the
help.
I
would
like
my
wa
dog
walker
to
be
able
to
help
to
enter
my
home
on
thursdays
between
8
a.m
and
12
p.m.
Only
they
should
only
have
access
to
that
front
door.
I
I
I
would
share
for
a
short
term
and
that
they
can
get
into
the
front
door
only
as
well.
Next
say
I
have
a
housekeeper
that
comes
on
fridays.
They
don't
have
a
consistent
schedule,
it's
not
clear
exactly
when
they're
going
to
get
there
or
when
they're
going
to
leave.
So
I
want
to
give
them
access
for
every
friday.
Just
throughout
like
a
large
window
during
fridays,
I
want
to
be
able
to
send
them
a
key
that
will
unlock
the
front
door
on
that
day.
I
Lastly,
say
I
own
a
home,
and
I
want
to
share
a
digital
house
key
with
an
individual,
renting
my
home
for
a
period
of
time,
so
in
this
scenario,
maybe
a
larger
period
of
time
than
these
short
short
term
access
points,
and
maybe
I
want
to
share
a
front
door
lock,
but
maybe
I'll
keep
the
garage
locked
so
that
they
can't
have
access
to
that.
These
should
all
be
possible
through
our
mechanism.
I
Lastly,
we're
going
to
talk
about
a
hotel
use
case
so
say
I'm
staying
at
a
hotel
next
week
and
this
hotel
does
support
digital
access
credentials.
So
I've
made
a
reservation
and
I've
provisioned
the
credential
onto
my
phone.
However,
my
significant
other
is
also
joining
me,
but
they
don't
arrive
until
the
day
after
I
do
so.
I
would
like
to
be
able
to
send
them
the
hotel
key
digitally
so
that
they
can
access
the
room
as
soon
as
they
arrive
and
off
chance
that
I'm
not
there
when
they
get
there.
J
J
You
know
separate
locks
right
like
yeah,
I
assume
you
were
assuming
that
the
those
systems
all
support
this
kind,
there's
a
very
fine
grain
authentication
fragmenting,
because
I
know
first
but
some
hotel
locks,
don't
support
any
kind
of
fine
grain
authentication
fragmenting
right.
So,
like
you
know,
I
I
like
well.
I
guess
I
pointed
your
this
is
these
are
use
cases
just
to
make
sure.
J
I
understand
that
this
is
like,
within
the
bounds
of
what
the
existing
authentication
system
supports,
with
the
assumption
that
each
key
is
profiled
to
some
like
each
key
is
already
is
like
already
pre-existingly
profiled
to
some
like
to
some
set
of
uses
or
that'll
be
out
of
scope
or
whatever
so
like
like
for
it's
like
it's
a
concrete
matter
like
we
don't
have
to
like
lug
around
the
does.
This
system
have
like
lug
around
like
the
axle
as
well,
or
is
that
all
out
of
band.
I
So
I
just,
I
think,
what
what
you're
saying
at
first,
I
think
is
very
true.
So
all
of
these
use
cases
are
kind
of
describing
exactly
what
would
happen,
but
all
all
within
their
own
protocols.
So
within
the
ccc
for
digital
car
keys,
there's
already
predefined
use
cases,
and
you
know
these
different.
Sometimes
you
call
them
entitlements.
So
whether
or
not
you
can
drive
quickly
or
or
if
you
can
have
access
to
a
trunk
or
just
to
the
to
drive
the
car
or
to
get
in
those
kinds
of
things
have
been
predefined.
I
If
that
helps
so
the
protocol
itself,
that
you
know
we're
trying
to
get
a
working
group
for,
is
just
making
a
flexible
mechanism
that
allows
a
sender
to
send
these
over
to
a
recipient,
but
less
so
about
why
a
hotel
can
have
this
kind
of
fine-grained
support
and
why
a
car
can
have
a
different
level.
Those
shirts.
K
J
J
Sure,
let
me
try
this
question
differently
on
on
me.
That
may
be
more
instructive.
So,
like,
let's
take
the
example,
you
had
previously
the
valet
right
and
so
like.
I
want
to
give
the
valet
a
key.
You
know
it
says
you
can
only
drive
the
car.
You
know
you
know
25
miles
an
hour
or
whatever
right
and
is.
J
Is
the
remit
of
this
protocol
scoped
to
passing
that
key
around
and
there's
some
other
mechanism
that
is
used
to
instruct
the
car
that
it
can
only
go
25
miles
an
hour
or
does
this
protocol
have
to
include
a
mechanism,
although
presumably
just
a
hole
and
a
hole
for
an
opaque
blob
that
says
that
somehow
gets
communicated
to
the
car
along
with
the
key
and
authorizing
the
files
that
are
like?
Which
one
is
it
so.
I
F
F
Look
at
single-family
home,
where
the
the
the
owner,
unlocking
the
the
door
with
their
phone,
takes
place
over
an
nfc
transaction
with
the
iso
18013
protocol
for
secure
credentials.
All
iso
1803
compliant
credentials
is
basically
a
public
key.
That's
signed
by
some
authority
that
the
lock
trusts
that's
how
it
works
right.
F
Inside
of
the
payload
that
the
authority
signs
there.
There
is
space
already
in
the
iso
18013
protocol
for
things,
like
dates
and
times
schedules
limitations.
All
of
that
exists
inside
of
the
iso
1803
definition
today
right.
So,
if
casey
wanted
to
share
to
a
dog
walker
for
thursday,
what
we
would
be
facilitating
is
getting
let's
say,
she's
sharing
to
you
eric
getting
you
a
credential,
that's
signed
by.
You
know
the
correct
private
key
of
the.
F
J
But
I
guess
I'm
still
a
little
puzzled
about
is
like
someone
has
to
there's.
There's
some
there's,
as
you
say,
there's
a
trust
anchor
that
signs
the
key
right
and
someone
has
to
tell
the
trust
anchor
when
you
issue
to
this
person,
like
you
know,
issue
them
for
the
for
the
following
hours
right,
I'm
trying
to
figure
out
if
this
protocol
has
to
convey
that
information
or
if
that
will
be
done
in
some
separate,
separate
unspecified
way.
That's
what
we're
talking
about.
F
Yeah,
there's
there's
there's
two
variants.
It
depends
if
the
credential
authority
is
what
we
call
kind
of
quote:
unquote
local
and
quote
unquote
remote.
So,
for
example,
digital
car
key,
like
casey,
said
you
own
the
vehicle.
You
are
the
credential
authority
like
it's,
it's
you
right,
so
you
would
be
signing
some
data
that
that
does
get
sent
over
this
transfer
protocol.
It
absolutely
does
in
the
case
of
a
remote
credential
authority.
Let's
say
casey
sharing
a
hyatt
hotel
key,
it's
actually
hyatt
that
has
to
sign
not
not
not
the
sender.
F
The
sender
is
authorizing
app
right
and
hyatt
is
the
one.
That's
issuing
a
new
credential.
The
sender
would
just
tell
hyatt
hey
for
this
new
credential
that
you're
issuing.
This
is
the
restrictions
that
I
you
know
that
I
would
like
to
see
and
how
it
would
respect
that
and
the
the
sender
would
authenticate.
However,
they
do
so
like
you
know
could
be.
Fido
could
be
something
else
too
high,
so
it
really
depends
on
if
the
credential
authority
is
local
or
remote,
but
we
do
want
to
support
both
of
those
variants.
G
But
even
in
the
local
case,
so
it
sounds
like
from
a
credential
transfer
point
of
view.
I
do
whatever
local
operation
to
make
the
sign
blob.
The
car
is
going
to
parse
and
then
I
put
that
into
the
credential
transfer
protocol.
So
the
credential
transfer
protocol
is
only
dealing
with
the
thing
that's
signed
at
the
end
of
the
day,
however,
you
created
the
scientific.
F
I
I
So
these
are
the
the
main
use
cases
we've
been
discussing.
As
we
just
talked
about
a
moment
ago.
We
are
expecting
that
some
sort
of
you
know.
Sometimes
we
call
it
like
a
token
of
what
exactly
this
credential
should
do
will
be
the
thing
traveling
over
this
protocol,
but
we
won't
necessarily,
as
part
of
this
protocol,
we're
not
defining
how
how
a
user
would
decide
or
how
a
user
would
just
work
with
their
credential
authority
to
choose
what
access
the
the
recipient
would
have
really
just
getting
that
choice
over
to
the
recipient.
L
Thank
you
very
much
casey.
I
hope
not
everyone
can
hear
me.
My
name
is
benitri
and
I'm
gonna
present
the
requirements
section.
Some
of
the
requirements
are
already
defined
by
the
assumed
constraints
presented
by
matt
and
explained
in
the
use
case.
Sections
are
presented
by
casey
so
hopefully
like
most
of
them
make
sense
now.
So
the
first
requirement
says
that
the
solution
should
utilize
should
apply
security
measures
to
transfer
the
credentials
to
intended
recipient.
L
This
may
include
channels
with
various
degrees
of
security
such
as
instant
messaging
applications,
whatsapp
sms
email
and
the
first
requirement
about
the
security
of
the
solution
must
consider
the
second
environment
that
we
should
be
able
to
utilize.
That
is
the
the
channels
with
various
degrees
of
security.
L
L
Some
people
don't
necessarily
might
have
connectivity
to
internet
because
of
weak
coverage
or
because
they
just
activated
airplane
mode
on
their
devices,
but
for
sender
to
initiate
them
sure
they
might
be
able
to
connect
to
internet,
create
the
share
and
go
offline
so
later
on.
When
the
receiver
goes
online,
they
they
have,
they
receive
the
share,
they
should
be
able
to
provision
it
to
their
own
device.
L
Thank
you,
matt.
So
the
fourth
requirement
says
that
solution
should
support
multiple
types
of
credentials:
for
instance
a
key
to
a
car,
a
key
to
a
hotel
room,
a
key
to
a
multi-family
home,
so
everything
which
was
explained
by
casey
earlier
and
which
also
should
support
both
open
specification,
open
standard
solutions
such
as
iso
18013
or
card
key
digital
key
or
proprietary
apis,
such
as
myfur
deskfire,
based
on
symmetric
and
asymmetric
key
types
requiring
logs
to
be
online,
having
a
connectivity
to
credential
provider
or
offline
having
built-in
cryptographic
mechanisms
to
verify
credentials.
L
L
J
You
like
sort
of
like
expand
on
that
requirement
a
little
bit
more.
I
think
you
know
sorry,
like
I
mean
at
the
very
limit
like,
for
instance,
does
that
could
see
all
the
ip
addresses
of
the
people
that
are
that
are
transferring
the
credentials?
You
know
I
guess
like
I'm
trying
to
get
you
know,
does
that
have
to
conceal
the
public
keys,
I'm
trying
to
get
a
sense
of
like
like
how
how
you
scope
out
this.
This
requirement.
H
H
L
L
L
N
Yeah,
I
think
I'm
confused
by
this
last
requirement
with
what
I
saw
earlier
in
the
slides
and
that
it
was
both
parties
did
not
need
to
be
online
during
the
transfer
simultaneously
right.
So,
if
like,
for
example,
the
sender
is
not
online,
how,
how
exactly
is
the
cancellation
expected
to
be
done?
I
I'm
just
tripped
up
by
the
the
online
offline
requirement
here
and
the
desire
to
be
christopher.
Is
this
a
clarifying
question
or
are
we
in
the
discussion
land?
No,
I,
I
think
that's
a
clarifying
question.
L
L
The
same
holds
true
with
the
sure
relocation.
So
obviously,
if
I'm
the
sender
in
order
to
revoke
the
share,
I
need
to
connect
to
the
internet
right
to
pass
some
requests
and
get
some
response
from
from
the
solution
yeah.
So
it's
all
true
the
only
point
here
we
don't
want
both
parties
to
have
simultaneously
a
connection
to
internet.
F
F
F
And,
and
and
just
to
you
know
christopher
just
to
reiterate
on
what
dimitri
said,
the
short
answer
is
you:
100
have
to
be
online
to
cancel
that's
the
short
answer
as
the
sender
right
we
just
as
dmitry
mentioned.
We
don't
want
sender
and
receiver
to
have
to
be
online
concurrently
and
but
any
operation
such
as
initiating
a
share
or
canceling
a
share.
The
device
performing
that
action
needs
to
be
online
to
complete
that.
Okay,
I
think
richard
was
first
there.
G
Right
yeah,
I
was
going
to
just
relay
patrick's
question
for
him,
because
I
also
thought
it
was
a
good
question.
The
question
was
whether
the
sender
there's
a
requirement
here
for
the
sender
to
be
able
to
get
an
indication
that
the
recipient
has
accessed
the
resource,
which
I
guess
would
mean
you
could
no
longer
be
canceled,
etc.
O
Yeah,
actually
it
I
would
say
also
that
depends
on
the
use
case
for
for
car
keys.
For
example,
the
car
the
car
maker
is
involved,
and
the
car
maker
needs
to
get
the
information
that
the
key
is
active
now
and
a
new
key
has
been
created
because
they
need
to
register
that
for
insurance
purpose.
They
always
need
to
keep
track
of
how
many
keys
exist
for
a
given
vehicle.
O
So
they
are
necessarily
in
the
loop
and
they
will
send
a
notification
to
the
owner
device
in
that
case
that
the
everything
is
good
on
on
receiver
side
and
they
have
now
a
key
that
they
can
use
on
the
vehicle
and
sweet
following
that.
They're
also
involved
in
revoking
the
key,
so
either
the
we
call
that
friend,
let's
say
or
the
receiver
deletes,
that
key
on
their
own
device.
O
Then
in
that
case
the
friend,
secure
element
would
generate
a
termination
attestation
to
prove
that
the
key
is
now
unusable.
That
will
be
registered
also
by
the
car
maker
to
delete
that
key
from
the
list
of
keys
issued
for
that
vehicle
for
insurance
purpose
and
then
also
the
owner
could
request
deletion
and
there
it
needs
to
go
first
to
the
car,
oem
or
the
car
maker,
because
there
are
security
requirements
for
many
car
makers
that
you
can't
just
delete
the
key.
While
the
friend
is
driving,
for
example,
so
the
vehicle
will
decide.
B
B
G
B
G
Thank
you,
my
name
is
so
I
think
the
question
was
actually
simpler.
Simpler
than
that
you
know
the
the
base
interaction
we're
talking
about
here
is
sending
a
credential
from
one
device
to
another
device
and
because
of
the
async
requirement,
that's
in
two
operations,
there's
the
sending
operation
and
there's
the
receiving
operation
right,
and
so
the
question
is
you
know
if
I'm
the
sending
device,
I
know
when
I've
done
sending
operation
and
presumably
the
receiving
operation
happens,
but
do
I
can
I,
as
the
sending
device
know
through
this
protocol,
somehow
whether
that
receiving
operations
happened?
G
O
P
I
I
was
just
going
to
add
to
alex's
point
for
a
second
just
that
just
receiving
the
information.
The
credential
information
doesn't
necessarily
mean
that
that
user
has
then
accepted
that
share
or
is
actually
able
to
use
that
access
credential.
Yet
until
we
have
some
information
or
not,
we
as
in
you
know,
the
center
device
knows
that
that
partner
has
actually
communicated
to
us
and
said
yes,
that
that
recipient
has
accepted
the
share
and
successfully
provisioned
or
got
that
credential
onto
their
device.
G
F
I
have
another
question,
I
think
no,
it
sounds
good.
I
I
think
the
way,
the
way
that
at
least
I
do
it
in
my
head,
it's
kind
of
like
a
like
a
triangle
where
the
sender
and
the
receiver
just
picture
kind
of
the
bottom
two
nodes.
The
transfer
between
them
is
necessary,
but
not
sufficient
for
the
full
ecosystem
of
sharing
in
terms
of
revocations.
F
O
O
You
would
redeem
at
hired
and
hide,
will
push
your
credential
into
your
receiver
device
and
for
car
keys
it's
the
other
way,
so
the
owner
is
actually
giving
the
actual
credential
to
the
to
the
receiver
and
it
is
yeah
push
and
pull
depends
on
the
direction
it
is
registered
by
by
the
credential
authority,
which
is
the
vehicle
oem,
but
it
is
not
issued
by
them.
So
that's
that's.
I
think
the
the
main
difference
here
and
it
needs
to
work
for
both
cases.
A
J
I
understand
what
responsibilities
are
in
scope
here
and
what
are
not
so
let
me
start
with
easy
case,
which
is
the
the
case
where
you
know
I
I
I
give
return
my
car
keys
for
the
next
month
and
then,
like
two
weeks
from
now,
I
decided
she
wasn't
driving
my
car
and
I
want
to
deal
with
that.
That's
not
we
have
to
deal
with
that.
That's
like
that
was
someone
some
unspecified
mechanism
where
I
like
called
tyler
right.
J
I
push
a
button
on
my
app
or
whatever
I
could
good
and
and
then
so.
The
it's
a
people
lie
their
heads
to
confirm
that,
like
that's
what
everybody
thinks
and
then
it
is,
and
then
in
the
and
then
the
case
where
the
thing
is
in
flight
and
he
has
not
you
retrieved
it.
The
situation
is
that
once
again,
like,
I
somehow
notify
toyota
or
whatever,
but
then
toyota
does
not
officiate
the
transfer
when
he
comes
to
pick
up
the
pick
up.
The
key
right.
That's
like
that's!
J
F
Yeah,
I
don't
think
so
I
mean
there's
there's
one
case,
that's
kind
of
in
the
middle
of
the
ones
that
you
just
described
eric,
oh-
and
this
is
not
speaking,
which
is
there's
actually
three
back
and
forths
needed
for
car
key
right
number,
one:
the
owner
of
the
vehicle
initiates
the
request
to
the
recipient
number
two,
the
recipient
generates
a
key
pair
and
sends
the
public
component
of
that
key
pair
back
to
the
owner
and
number
three,
the
owner
signs
that
with
their
private
key
and
sends
that
back
to
the
recipient.
Right.
F
If
those
three
don't
happen,
it
won't
work
and
so,
for
example,
after
the
first
one
that
happens,
you
could
just
initiate
a
cancel
on
that
on
that
transfer
directly
from
your
sending
device
to
the
you
know,
server
managing
this
stuff
and
that
would
successfully
cancel.
But
your
earlier
statements
were
also
correct
for
transfers
that
have
already
successfully
completed.
G
F
Yeah
this
has
been
tricky
I'll.
I'll
be
honest.
This
has
been
tricky
when
we've
been
thinking
about
it,
because
not
only
are
those
things
somewhat
at
odds
with
each
other,
but
anyways
it's
a
hard
problem.
I
don't.
I
don't
want
to
like
prescribe
anything
about
our
solution
that
that's
up
in
the
draft,
because
I
know
we
want
to
focus
on
the
requirements
here
in
the
problem
statement,
but
I'll
just
say
like
some
of
the
things
that
we
have
done.
F
F
They
then
put
that
data
onto
this
transfer
service.
The
transfer
server,
cannot
decrypt
it
for
obvious
reasons
and
they're
sending
the
symmetra
key
in
a
uri
fragment
of
the
url
that
they're
sending
to
the
receiver.
You
know
to
the
recipient
and
the
idea
there
would
be
the
recipient
can
download
the
data
from
the
relay
server
and
then
only
that
recipient
can
decrypt
the
data.
So
we've
we've
sealed
off,
or
we've
attempted
to
seal
off
the
oh
sorry
richard
go
ahead.
F
All
right
go
ahead:
okay,
we've
attempted
to
seal
off
one
potential
attack
vector
which
is
a
malicious
transfer
service,
or
somebody
who
has
compromised
the
transfer
service.
There
remains
additional
attack
vectors,
for
example,
if
I
sent
it
through
sms
and
somebody
captures
that
sms.
Of
course
now
they.
F
As
a
you
know,
solution,
that's
you
know
amazing,
but
these
are
the
kind
of
things
that
we're
thinking
so,
like
the
short
version
is
have
the
data
field
level
encrypted
such
that
the
transfer
service
cannot
read
it
kind
of
you
know,
one
primitive
have
the
the
key
that
needs
that's
needed
to
decrypt.
It
only
sent
between
the
sender
and
receiver
no
server
and
that
helps
kind
of
seal
that
off,
and
we
have
some
other
ideas
also
for
the
protection
of
that
channel.
F
There
are
some
interesting
things
that
we've
been
thinking
about
like
a
potential
second
channel
with
the
pin
code,
so
you
have
to
compromise
two
channels
in
order
to
truly
compromise
the
link,
like
maybe
sms,
and
then
you
call
the
person
and
say
hey.
The
pin
code
is
one
two
three
four
or
you
know
whatever
the
case
may
be.
I
don't
know
if
this
is
more
appropriate
for
the
working
group
discussion
rather
than
here,
but
I
just
wanted
to
share
some
insight
as
to
what
we've
been
thinking
about
with
privacy
and
security.
G
F
Yeah
absolutely
fully
concur
with
what
you
said
and
eric
just
before.
I
I
hand
it
off
to
you,
because
I
see
you
have
your
your
hand
up.
I
also
just
wanted
to
add
that,
like
I
mean
one
of
the
things
that
we
think
is
that
the
the
the
identifier
of
this
transfer
that
is
kind
of
established
when
the
sender
first
initiates
should
be
large
enough
and
with
high
enough
entropy
that
it's
for
all
intents
and
purposes
impossible
to
guess
right.
F
J
And
I
guess
I'd
like
you
to
talk
a
little
bit
about
why
you
think
that
the
what
requirement
you
think
gets
you
that
the
mailbox
has
to
have
a
secret
identifier,
name
except
it's
like
here,
like
here's
like
here's,
the
superdom
version
right,
which
is
to
say
that
the
mailbox
is
entirely
public
and
like
anybody
can
read
it
and,
like
you
know,
they're
just
enumerated
one,
two
or
five,
and
that
the
symmetric
key
is
sufficient
to
crypt.
And
you
you
travel
the
crypt
and
it
works.
J
F
Yeah
yeah,
that
that's
a
great
question
I
mean
in
my
mind
there
are
two
or
three
things,
I'll
I'll
state,
those
and
then
you
know
I
you
know
I'll
close,
my
mouth
so
that
other
you
know,
proponents
can
also
answer
as
well,
whether
it's
dimitri
casey,
you
know
matthias
or
others,
because
I'm
sure
people
have
their
own
opinions
here
too.
But
you
know
one
one.
One
opinion
would
be
that
that
this
mailbox
is
relinquishing
encrypted
data
right
and
obviously
the
only
person
that
should
be
able
to
decrypt.
F
That
is
the
recipient,
with
the
symmetra
key.
Typically
in
cryptography.
It's
a
bad
idea
to
you
know:
have
your
encrypted
data
be
open
and
available
for
anybody
to
look
at
because
they
can
typically,
you
know
determine
some
ways
that
it's
encrypted
and
things
like
that,
but
I
think
more
importantly,
it
also
allows
the
transfer
service
to
do
things
like
rate
limiting
right
basic.
You
know,
you
know
ddos
attack
prevention.
You
can
limit
on
the
mailbox
identifier
itself,
for
example,
and
that
that's
more
practical
than
theoretical,
but
I
think
I
think
that's
that's
helpful.
F
You
know
whatever
you
are
sharing
with
anybody
in
the
world,
you
kind
of
don't
know
who
they
are
sending
them
some
kind
of
a
secret
that
you
know
in
this
case.
It
could
just
be
this
uuid
that
that
you
mentioned,
is
you
know
you
know
having
possession
of
that
it?
You
know,
in
my
opinion,
should
be
a
requirement
for
them
to
download
the
data
it
helps.
It
helps.
Prove
is
the
wrong
word,
but
it
helps
towards
them.
F
J
You
look
like
this.
What
surprises
you
state?
This
is
a
cryptographic
principle,
because
I
typically
operate
the
opposite
assumption,
which
is
the
data
transmitter
network,
is
equivalent
to
anybody
and
they're
trafficking
protects
it.
Hence,
like
you
know,
tls
or
mls
or
whatever
right
so
so
I
think
that's
I
think
I
mean
I
think
if
we
don't
assume
that
the
cryptography
is
sound,
we
have
much
more
search
problems
totally
yeah.
I
think
you
know
the
part
of
the
thing.
J
This
goes
to
the
threat
model
against
the
against
the
relay
server,
which
is
like,
what's
the
trust
model
against
the
relay
server.
So
you
know
I
guess
like
I
would,
I
guess,
I'd
be
uncomfortable,
a
system
that
did
not
provide
security
for
the
system,
even
assuming
the
relationship
was
entirely
compromised
right.
So
I
think
that
probably
like
has.
K
J
J
So
I
just
think
trying
to
do
it
that
would
be
helpful
going
forward.
The
second
thing
I
wanted
to
say
is:
I
think
we
probably
need
to
like
nail
down
the
implied
sort
of
properties
of
the
center
recipient
channel
a
little
bit
more,
and
richard
was
kind
of
poking
around
a
little
bit
a
little
bit
in
particular.
J
So
you
know
so
we
to
understand
what
we
have
to
work
with
right.
I
think
in
particular
you
know
trying
to
lay
out.
I
think
what
the
minimum
like
like
effectively
like
the
minimum
mtu
of
this
channel
will
be
like
very
helpful.
I
mean
sms
is
large
enough
to
have
any
possible
trafficking,
but,
like
just
like
it
doesn't
have
to
work.
You
know
it
doesn't
have
to
work
if
it
can't
contain
participants
or
something
I
think
has
to
be
like
or
maybe
500
bits
or
whatever.
P
O
I
think
the
relay
server
itself
has
very
little
security
properties,
so
the
probably
the
most
important
one
is
to
release
the
credentials
that
have
been
deposited
there
only
one
time
to
one
receiver,
so
it
needs
just
the
first
receiver
grabbing.
The
link
is
the
one,
and
once
this
is
done,
it
should
not
be
possible
for
any
other
receiver
to
to
copy
the
credentials
meaning
to
to
duplicate
them.
O
The
encryption
is
indeed,
as
you
said,
it's
a
secure
channel.
The
cryptography
is
chosen
to
be
strong,
but
the
one
who
has
the
key
can
decrypt.
So
I
think
the
that's
mainly
for
privacy,
but
not
really
security,
because
it
depends
more
on
who
has
the
key,
then?
Can
anyone
crack
or
break
that
encryption
right
and
then
how
does
the
key
get
to
the
right
person?
And
that
is
unfortunately,
a
very
hard
problem
to
solve.
O
I
think,
especially
if
you
talk
across
cross
cross
device
platform
within
apple
and
I'm
sure,
within
google
within
samsung.
There
are
proper
proprietary
methods
where
you
can
bind
much
stronger
the
identities,
and
you
can
be
much
more
sure
that
it's
going
to
the
right
person
and
for
universal
sharing
mechanism
you
there
needs
to
be
second
factor
or
there
can
be
a
subset
where
you
can
do
some
identity
binding,
provided,
for
example,
the
receiver
has
an
email
account.
That
is
second,
that
is
already
verified
and
maybe
the
email
account
owner
could
attest
to
something.
O
But
that
would
not
work
generally.
So
I
think
we
can't
really
put
that
in
scope.
So
it's
a
very
simple
mechanism
and
to
recall
the
main
problem
to
solve
is
it
needs
to
work
independently
of
the
device
platform
because
we
could
do
imessage
airdrop,
whatever
google
could
do
something.
Some
samsung
could
do
something,
but
for
really
universal
thing
we
don't
have
real,
really
good
identity
binding,
and
we
need
a
simple
protocol
that
is
open
for
basically
everyone
to
to
participate.
M
F
Yeah
we
would
envision
that
the
sender
the
sending
device
would
be
the
one
that
selects
which
relay
server
they
would
initiate
the
share
or
the
transfer
to,
and
it
would
typically
be
you
know
I
mean
it
could
be
any
relay
server,
but
it
would,
it
would
most
likely
be
a
relay
server
hosted
by
the
you
know,
the
company
that
manufactures
that
operating
system.
Although
you
know
you
could
kind
of
use
whatever
relay
server
you
want,
you
could
also
envision
third-party
applications.
M
Q
O
O
I
share
my
key
with
friend,
family
member,
etc.
So
that's
then
very
likely.
The
sender
device
oem
will
set
up
the
relay
server
just
for
practical
reasons.
It's
there's
no
obligation
or
any
technical
reason.
It's
more
practical
reason
that
generally
a
device
oem
if
they
set
up
their
own
relay
server,
they
can
bind
the
device
the
sender
device
very
strongly
to
that
relay
server
and
have
very
little
danger
that
it
connects
to
a
fake
relay
server
and
restricted
something.
O
If
we
think
about
business
sharing
use
cases,
that's
I
think
we
haven't
discussed
that,
but
it
would
apply
there
as
well.
For
example,
you
have
hertz
or
avis,
who
has
a
whole
fleet
of
vehicles,
and
they
there
there
would
not
be
a
hurts
employee
running
around
with
an
iphone
or
google
phone
to
to
be
the
owner
of
all
these
vehicles.
It
will
be
a
server.
So
there
is
another
use
case
where
the
server
or
the
owner
is
basically
a
server
a
device
on
the
server.
O
K
O
And
so
that
that's
a
use
case
also
to
consider
and
there
there
might
be
other
ways
to
bind.
For
example,
let's
say
there
is
a
security
company
who
is
really
specialized
in
secure
servers.
They
will
offer
that
service
and
they
will
very
strongly
bind
the
hertz
server
that
owns
the
cars
to
transfer
the
ownership
to
that
secure
server
that
that
is
really
the
the
owner.
Sorry
and
then
the
relay
server
there
will
be
a
contractual
relationship
and
it's
very
well
identified.
O
G
I
was
just
going
to
just
to
touch
on
the
last
point.
I
think
that
flexibility
around
who
the
relay
service
is
does
underscore
the
the
identity
point
that
matthias
made,
because,
especially
when
you
have
multiple
verifying
parties
like
multiple
transfer
services,
it's
tough
to
come
up
with
an
administrative
service.
G
What
I
was
in
queue
to
ask
was
more
about,
and
you
get
more
scoping
around
what
we
need
to
support
here.
It
seems
like,
in
the
schemes
we've
discussed,
you
have
multiple
different
credential
schemes
running
around
that
may
or
may
not
be
supported
on
a
given
device
participating
in
these
transactions.
G
L
Can
I
take
this
up,
please
sure
sure
dmitry
so
richard?
This
is
a
great
question
and
we
were
thinking
about
that
a
lot.
So
let's
say
I'm
sending
my
credential
to
my
friend,
but
he
receives
them
on
desktop
device
which
doesn't
have
the
secure
element.
So
we
cannot
use
that
device
as
a
car
key
or
as
a
key
to
the
hotel.
L
So
we
we
need
to
establish
a
mechanism
to
relinquish
so
at
the
time
when
they
connected
to
the
mailbox
they
bound.
They
claimed
that
mailbox.
Now
we
need
to
establish
a
mechanism
to
relinquish
the
mailbox
for
them
so
that
now
they
can
forward
that
link
to
the
proper
device
to
their
iphone
to
the
phone
or
anything
that
has
the
secure
element
on
it.
F
Yeah,
I
I
also
want
to
say,
like
I
think
we
don't.
I
don't
think
for
privacy
reasons,
that
we
should
create
some
kind
of
a
system
that
acts
as
an
oracle,
where
you
can
send
a
transfer
out
and
see
what
somebody's
device
does
and
doesn't
support.
We've,
we've
kind
of
distinctly
set
that
as
a
non-goal
just
for
privacy
reasons
you
know.
Instead,
the
major
manufacturers
of
these
of
these
phones
would
have
an
error
message
on
device
that
says:
hey.
You
know
richard
just
shared
with
you
a
car
key.
F
G
G
Especially
from
the
privacy
point
of
view
about
being
able
to
create
an
oracle
here,
it
sounds
like
that
we
probably
at
least
have
a
requirement
to
articulate
what
sort
of
credential
is
being
offered
when
you
go
to
receive
one
so
that
you
can
make
an
intelligent
decision.
You
can
present
an
intelligent
error
message
that
says
you
need
you've
received
a
key
and
you
know
we
know
we
can't
use
that.
I
It
could
be
that
you
know
you
sent
this
to
your
friend
and
you
knew
they
had
a
the
correct
device
and,
as
matt
said,
they
opened
it
on
the
wrong
device.
So
that's
one
thing
or
it
could
be
that
the
device
is
on
the
wrong
operating
system.
They
just
need
to
upgrade.
So
that's
another
scenario
we
have
to
like
explain
to
the
user
of
how
to
fix,
and,
lastly,
it
could
be
that
they
are
completely
up
to
date
on
the
correct
device.
However,
their
operating
system
hasn't
created
connectivity
or
work
to
implement.
I
F
And
we
did,
I
think,
between
version
zero,
two
and
zero
three
of
the
draft.
We
did
add
some
sort
of
enumeration
like
stuff
to
show
what
type
of
credential
was
being
shared
richard
to
to
so
so,
if
you
haven't
already
version
three,
I
I
believe
contains
some
metadata
that
that
will
so
that
will
help
the
receiver
determine
what
was
shared.
B
All
right,
I
just
want
to
remind
people
that
at
some
point
in
the
like
soon
we're
going
to
bring
up
the
chair
slides
again
and
start
talking
about
sort
of
both
questions.
So
if
you
have
any
outstanding
questions
about
sort
of
the
presentation
and
scoping
and
issues
related
to
that,
please
step
up
now.
J
All
right
eric
go
ahead.
Yeah
I
just
like
probably
useful
to
have
for
the
record
some
sense
of
like
which
major
players
in
this
in
this
ecosystem
are
participating,
which
ones
are
not.
You
know,
there's
something
that
it's
know
a
lot
about
and
happy
to
see
us
we'll
do
work
here,
but
like
it'd,
be
good
to
like
make
sure
that,
like
we're
not
missing
a
bunch
of
people
like
are
important
that
are
not
going
to
want
this.
G
B
R
Yeah,
I
do
want
to
comment
on
it.
This
is
nick
from
google
and
yeah.
I
think
we
are
one
of
the
other
proponent
of
this
proposal
here
and
I
think
it's
fair
to
say
that
this
being
adopted
by
something
that
we're
working
to
get
adopted
by
ccc,
so
we
have
vehicle
manufacturer
that
are
also
interested
in
this
kind
of
proposal.
F
A
I
I
just
want
to
say
that
I
think
that
any
statement
that
has
just
been
made
now
or
a
minute
ago
is
not
meant
to
imply
that
the
manufacturers
are
absolutely
positively
going
to
release
this
in
the
next
version
of
their
whatever.
So
I
want
people
to
be
able
to
to
say
whether
they're
they
think
their
company
is
interested
without
being
like
having
their
feet
held
to
the
fire
absolutely
later
like.
Oh,
you
didn't
do
it
in
version
12
or
whatever.
So
thanks.
C
Two
small
procedural
comments,
one,
which
is,
I
hope
we
can
really
avoid,
calling
this
secret
and
introduce
even
more
confusion
by
people
outside
the
atf
about
what
on
earth
our
acronyms
are
connected
to
and
the
other
is
that
substantially.
Every
substantive
comment,
I've
heard
in
the
last
hour
and
a
half
has
been
about
security
issues
and
not
about
applications
issues.
C
B
All
right,
yeah
thanks
john
obviously
right
names
aren't
set
in
stone.
If
this
becomes
a
working
group,
then
it
can
be
changed
to
cool
to
be
called
whatever,
and
I
I
think
the
second
question
is
more.
Like
a,
I
think,
more,
a
question
for
our
various
ads
on
the
call,
and
you
know
if
any
of
them
want
to
step
up
to
the
mic
and
talk
about
you
know
potential
homes.
For
this
then
go
right
ahead
in
the
meanwhile.
I
think
richard
wants
to
say
something
and.
G
G
I
think
this
has
more
application
design
than
than
security
design
in
terms
of
how
things
get
indicated,
how
the
bits
get
moved
around
there's
a
bunch
of
kind
of
how
do
we
arrange
application
transport
stuff
that
the
security
area
is
not
going
to
be
great,
for
I
think
we
can
get
the
right
security
folks
in
the
room.
Obviously
echo-
and
I
are
already
here
so
I
think
we
can
get
the
security
model
right
and
then
that
that,
but
that's
that's
just
kind
of
the
core
of
the
protocol.
G
If
you
will
there's
a
bunch
of
stuff
wrapped
around
that
that's
going
to
need
application
attention,
so
I
think
you're
right
this
straddles
the
boundary,
but
I
think
applications
is
is
slightly
the
better
place
for
it.
While
I'm
here,
though,
the
the
reason
I
enqueued
is
actually
continue
that
discussion
of
the
you
know
do
we
have
the
right
community.
G
I
think
nick
mentioned
the
ccc,
potentially
some
interactions
there.
So
you
we
talked
something
about
the
the
device
vendors
who
are
involved.
I
was
wondering
if
anyone
from
this
kind
of
credential
ecosystems,
any
of
the
kind
of
credential
issuers
or
something
needed
to
be
engaged
in
this,
and
if
so,
we've
kind.
C
Yeah
richard
the
applications
argument
convinced
me
when
I
raised
the
question
on
the
list
and
got
an
answer,
but
again
empirically
at
least
as
far
as
this
off
call
is
concerned,
I
haven't
started
single
applications,
comment
or
question.
I've
heard
nothing
but
security
issues
and
that's
just
something
to
keep
in
mind.
Well,
I
asked.
K
C
C
K
B
D
D
I
would
respond
to
that
by
saying
that
we're
not
talking
about
security
mechanisms,
we're
talking
about
security
requirements
and
that,
once
the
sort
of
requirements
of
the
application
protocol
identify
what
security
properties
we
need,
then
the
cryptography
to
use
to
get
those
security
properties
is
pretty
straightforward
and
so
like
it's
not
really
a
question
of
defining
the
security
mechanisms.
It's
a
question
of
defining
the
security
requirements
and
identifying
them.
J
I
am
entirely
indifferent
under
which
area
this
sits,
but
but
I
I
do
think
that
john
is
making
an
important
point,
which
is:
are
we
going
to
get
enough
interest
from
application
area?
People
to
you
know
to
be
able
to
effectively
execute
on
the
application
pieces,
which
I
think
are
significant,
as
I
know
in
my
review.
So
I
think,
like
I
guess
what
I
would
encourage
is
the
chairs
the
ads
to
during
this.
J
You
know
the
traditional
call
for
you
know,
call
for
you
know,
interest
or
whatever,
to
attempt
to
just
in
some
way
measure
the
temperature
of
both
the
applications
and
the
security
people
independently
to
make
sure
that,
like
you
know
to
make
sure
that,
like
we
want
people
who
understand
like
webdav
or
whatever
it
is
like
our
email
john
suggested.
So
it's
like
you
know,
so
we
don't
like.
I
don't
end
up
designing
like
misdesigning
the
application
components.
So
I
I
don't
think
yeah
like
the
case,
but
I
think
we
should
make
sure.
A
A
B
B
C
Voice,
the
the
questions
about
boundaries
between
certificate
transfer
and
certificate
management,
and
a
number
of
other
things
leave
me
somewhat
confused
about
where
the
boundaries
are
and
what
the
work
is
and
consequently
I'm
not
certain.
I
understand
the
question
and
if
anybody
else
is
clear
about
that,
then
fine.
B
B
E
B
B
Call
this
one
all
right
and
all
right
this
seems
like
for
for
for
for
us.
This
seems
like
we're
we're
sort
of
we're
on
track
here
that
to
to
be
able
to
say
to
the
isd
that
this
is
worth
a
working
group.
The
next
couple
of
questions
is
sort
of
about
resource
available
resources.
Here
and
in
order
to
have
a
successful
working
group,
we
really
need
people
who
are
willing
to
edit
and
review
drafts
and
editing
drafts
is
often
sort
of
you
know.
It's
not.
B
There
are
some
who
say
that
they
won't
be
able
to
do
that.
We're
going
to
ask
the
follower
quest
quick
question
in
a
next
about
reviewing
drafts,
which
is
almost
as
important
towards
a
successful
working
group,
but
we're
looking
at
about
eight
people
who
are
willing
to
edit
drop.
So
let's
go
ahead
and
do
the
next
one
who's
willing
to
review
drafts
even
more
important.
I
would
say
to
get
good
reviews
and
lots
of
reviews
is
kind
of
the
backbone
of
our
working
group.
A
B
B
Now
my
math
says
that
there
were
more
people
who
were
willing
to
review
drafts
as
categorized
people
than
as,
but
I'm
maybe
a
little
bit
off
in
my
map.
But
it
still
looks
good
to
me,
like
sufficient
number
of
people
in
the
art
area
and
security
area
are
clearly
willing
to
put
in
the
work.
That's
very,
very,
very
helpful
and
I
we
haven't
sort
of
gone
through
the.
So
maybe
we
should
sort
of
we
still
have
about
a
quarter
of
an
hour
to
go.
B
B
M
Yes,
the
of
convergence
out
of
scope-
I
think,
is
a
bit
unclear-
needs
a
bit
work
the
language,
but
I
couldn't
quite
follow
exactly
what
was
being
said
and
then.
Secondly,
I
think
I'm
not
clear
to
what
extent
this
work
requires
understanding
the
security
and
privacy
properties
of
the
credential
mechanisms
themselves.
M
The
the
thing
about
out
of
scope
is
that
I
just
think
the
phrasing
is
odd,
so
I
didn't,
I
couldn't
quite
pass
it
correctly.
It's
on
the
couple
of
slides
ahead
of
the
one
you
have,
I
think
that's
just
wordsmithing,
probably
but
more.
I
think
the
the
more
interesting
question
for
me
is
that
I
don't
I'm
unclear
to
what
extent
doing
this
work
requires
a
full
understanding
of
the
privacy
and
security
properties
of
the
credential
mechanisms.
B
F
Yeah
no
problem
yeah,
I
I
think
I
think
we
can
clarify
the
language
a
little
bit.
I
I
don't
think
to
to
to
work
on
or
review
the
charter
or
the
draft.
I
I
don't
think
you
have
to
have
intimate
knowledge
of
the
actual
credential
types
and
how
they
work.
I
think
I
forget
who
mentioned
it
earlier,
but
the
the
the
purpose
of
the
protocol
is
that
largely
the
transfer
service
is
sort
of
unaware
of
the
details
of
the
the
actual
credential
and
the
information
being
shared.
F
So
in
my
personal
opinion
that
would
not
be
a
requirement
and
then
you
know
definitely
heard
you
on
the
wordsmithing.
I
should
also
note-
I
think,
we've
gotten
a
couple
comments
before
this
about
specifically
about
the
word
multidisciplinary
in
the
last
sentence
of
that
first
paragraph.
So
we
may
need
to
wordsmith
that
a
little
bit
as
well.
M
F
Yeah,
I
do
think
I
mean
I
do
think
you
know,
knowledge
of
them
would
be
useful.
I
just
don't
think
it
would
be
required
in
terms
of
like
comparing
my
fair
classic
to
my
fair
death
fire
understanding,
how
you
know
ccc
credentials.
You
know
work,
I
it's
just
my
opinion,
but
I
don't.
I
don't
see
that
as
a
prerequisite
to
you
know
meaningfully
contributing
to
to
the
transfer
just
because
we
wanted
to
be
relatively
agnostic
and
work
for
a
very
wide
variety
of
credentials.
M
J
My
sense
is
also
that
we
don't
need
to
understand
this
in
detail,
but
I
think
it
would
be.
It
is
important,
maybe
like
just
briefly
some
so
at
some
point.
Someone
should
briefly
write
down
what
they
like.
What
the
underlying
assumptions
about
these
credentials
like
might
be,
and
what
they
what
they
require
myself.
My
impression
is
very
little,
but
just
like
what
you
know
like,
I
think,
like
a
perhaps
a
non-normative
document
with
a
with
a
couple.
You
know
a
couple
diagrams
that
showed
like
how
these
things
were
supposed
to
work.
J
G
H
D
F
A
J
Hi,
I
could
probably
just
send
these
as
prs,
but
I
think
these
last
two
are
not
super
helpful.
I
think
they're
good
things
that
are
good
things
to
happen,
but
they're,
not
protocol
considerations,
they're
that
they're
they're
they're
operational
considerations
and
we
can't
guarantee
that
the
relay
server
will
will
do
any
of
them.
So
the
I
think
the
the
the
privacy
goals
are
for
protocol
design
and
so
and
so
like.
J
If
we
think
the
real
server,
for
instance,
should
not
have
the
identity
should
not
be
able
to
persist
at
any
central
receiver,
then
we
have
to
have
to
deny
it
that
identity
not
not
tell
about
the
story
right.
So
so
I
think
like
just
in
general.
Probably
these
two
need
to
be
rephrased
in
some
way
that
that
is
more
protocol-oriented.
J
Yeah,
I
think
this
and
then
on
the
on
on
the
on
the
lower
right
hand,
one
allow
center
and
device
to
quickly
perform
around
multiple
communications.
I
think
we're
gonna
need
some
more
some
more
understanding
of
what
this
context
really
means.
So
I
just
like
just
you
know,
relooking
your
draft,
I
see
you
know
diagram.
One
which
involves
a
run.
J
Trip
between
you
know
involves
around
trip
and
start
does
not
evolve
around
trip
and
diagram,
two
which
doesn't
evolve
around
trip
and
trying
to
flesh
out
like
what,
in
some
requirements,
language
what's
acceptable
in
those
cases
and-
what's
not,
I
think,
is
probably
important,
so
I
mean
just
a
concrete
example.
You
said
initially
that
they
don't
be
online
at
the
same
time
and
they
sort
of
said
later
and
then,
but
then
they
share
the
thing
with
around
trip,
but
those
are
a
little
confusing
right,
because
exactly
what
exactly?
What
the?
J
B
J
So
I
I
guess
I
I'm
going
to
buy
a
pr.
My
pr
is
going
to
be
removing
these
first.
The
second
two
bullet
points.
The
last
two
bullet
points
under
privacy
calls
and
maybe
replacing
them
with
some
language
about
like
denying
information.
Yes,
I
can
find
some
stuff,
this
lower
right
hand,
one.
I
think
the
proponents
have
to
like
help
out
with,
because
I
don't
quite
I
just
I
still
like
struggling.
J
I
guess
with
like
what
the
communications
requirements
of
this
channel
are
in
particular,
like
you
know,
it's
like
the
solution
is
extraordinarily
different,
if
I,
if
like,
if
like
I'm,
always
willing
to
have
at
least
one
round
trip
between
between
the
sender
and
the
receiver
and
versus
I'm
not,
and
so
I
think
would
understand
what
that
like
what
what
has
to
work
under
both
cases.
You
know,
I
think
it's
gonna
need
to
be
fleshed
out
somehow.
But
it's
not
it's
not
a
charter
issue
perhaps,
but
we'll
need
it
eventually.
B
But
yeah,
I
agree
some
of
the
language
here.
It
kind
of
approaches
more
like
a
requirements
draft
rather
than
a
shorter
text,
but
it
the
question
is
whether
maybe
removing
charter
text
in
order
to
clarify
it
and
in
order
to
make
it
sort
of
more
clear.
It
could
also
be
a
good
thing,
and
I
I
think,
we're
at
the
point
in
the
timeline
here
for
for
today
that
we're
not
going
to
be
able
to
fully
bang
all
of
this
out.
B
A
I
I
haven't
heard
it.
I
don't
think
anybody
willing
to
get
to
the
microphone
to
be
like
this
horrible
go
away.
This
is
the
absolutely
wrong
thing
to
do
so.
My
advice
to
the
area
directors
at
this
point
is
that
you
know
wherever
this
is
wherever
the
charter's
getting
banged
on,
whether
it's
on
github
or
dispatch
or
dispatch
or
wherever
the
secret
mailing
list
that
it
moved
to
that
four
and
basically,
we
start
zeroing
in
what
a
what
a
good
charter
would
be
for
the
ist.
B
G
A
I
think
it
does.
I
think
you
can
add
another
paragraph
at
the
bottom
and
say
the
other
working
groups
that
we
will
you
know
interact
with,
including
itfr
blah
blah
blah
and
also
to
note
that
some
of
the
credential
we
can
also
you
know,
liaison
not
liaise,
don't
liaise.
You
know
communicate
with
the
other
sdos
that
are
developing.
A
E
I
I
Asked
that
mainly
because
I
think
that
that
part
of
the
reason
are
the
protocol,
we're
trying
to
design
is
different
than
existing
ones.
It's
because
we're
working
within
we're
trying
to
make
a
very
generic
protocol,
but
within
bounds,
I've
already
been
predefined,
and
I
think
that
makes
it
so
that
we're
limited
to
existing,
like
we
can't
use
as
many
existing
protocols
because
of
these
other
limits.
J
On
this
last
slide,
but
I
I
don't
wanna
flag,
I
think
probably
this
last
line
is
not
actually
appropriate.
In
this
case
often
we
do
start
the
charter,
we're
assuming
there's
gonna,
be
a
given
draft,
but
like
I
I
I
distracted
a
number
of
good
points,
but
I
think
it's
like
also
fairly
far
from
like
what
I
think
probably
is
exactly
right.
Starting
point.
So
I
think,
like
perhaps
that's
your
question
for
the
working
group
in
their
initial
meetings
rather
than
being
defined
in
the
charter
link
this
year.
D
J
I
mean,
I
guess
I
guess
I
don't
think
that
that's
doing
very
much.
I
mean,
like
the
the
usual
reason.
The
usual
reason
to
like
have
this
textbook
starter
is
to
like
foreclose
the
question
of
what
like
foreclose.
You
know
a
bunch
of
like
discussions
about
the
overall
architecture
protocol
because
we're
assuming
you're,
starting
with
one
thing
right
and,
and
so
like.
Essentially
you
have
a
you
know,
essentially
instant
adoption
of
about
rather
than
a
lot
of
discussion
and
input
needs
me
to
say
nothing
like
like
like.
J
Like
you
know,
you
know
it's
gonna,
it's
gonna
use
the
message
of
the
mailing
with
this
input,
so
I
don't
that
really
helps
very
much.
I
think
that
the
question
is
like.
Are
we
gonna
bake?
I'm
happy
to
have
it,
I
suppose,
but
if,
if
we're
gonna,
my
my
objection
is
to
making
the
assumption
that
this
will
be
the
starting
point
and
effectively
immediately
working
productive
like
into
the
charter,
because
I
don't
think
it's
quite
ready
for
that.
Yet
sure.