►
From YouTube: IETF115-TIGRESS-20221110-1700
Description
TIGRESS meeting session at IETF115
2022/11/10 1700
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
Hey
Apache
are
you,
you
should
do
an
audio
test.
People
are
just
sort
of
leaving
the
room
from
the
previous
working
group.
They
run
late.
B
A
Why
don't
you?
Why
don't
you
start
sharing
the
slides
unless
you
want
me
to
do
that.
A
It's
just
there.
There
is
there's
supposed
to
be
a
oh
I
see
the
problem.
The
the
chair,
the
slides,
are
they're,
not
yeah.
They're
hang
on
I
think
there
is
a
I,
don't
know
the
final
name
isn't
doesn't
end
with
that
dot,
PDF
and
I
think
the
meat
Deco
doesn't
recognized.
A
Let's
see
if
I
can
just
sort
of
share
my
my
that
slide
window
and
I
can
just
do
that.
A
B
B
Apologies
for
the
technical
difficulties
you're
having
next
slide.
Please.
B
All
right,
the
note
12
as
it
said
in
artland,
knows
the
note
12
well
so
I'm
sure
you
all
are
pretty
aware
of
it.
It's
almost
last
day
of
ITF.
Second,
last
day,
yep,
this
session
is
being
recorded
just
a
few
disclaimers
and
then,
if
you
are
an
in-person
participant,
please
make
sure
to
sign
into
the
session
using
the
QR
code
and,
if
you're
remote,
make
sure
your
audio
and
video
is
off
unless
you
are
sharing
or
presenting,
and
please
use
the
result
tool.
B
When
you
have
questions
the
resources
are
all
linked
here:
the
agenda,
the
medical
information
and
how
to
report
any
issues
next
slide.
B
So
the
agenda
for
today
is
pretty
brief
until
I
know
we're
gonna
hand
it
over
to
the
authors,
we're
going
to
walk
through
all
the
draft
updates
they
have
made.
They
have
taken
all
the
feedback
they
received
from
114
and
over
the
mailing
list
and
we'll
just
go
over
through
some
of
the
updates
they
have
made,
and
then
we
can
move
on
to
the
questions.
Please
a
couple
things
which
I
wanted
to
know.
B
We
do
have
an
unfortunate
conflict
with
sectors
patch
today,
so
hence
the
low
attendance
and
then
one
more
administrative.
You
think
when
you
come
up
to
the
mic,
please
identify
yourself.
It
helps
the
note
tickers
and
everybody
else
in
the
room
and
on
WE
deco.
Do
we
have
a
note
taker
for
today?
Is
there
anybody
who
would
like
to
volunteer.
A
I
I
say:
oh
I,
kindly
volunteering,
so
yes,
we
have
a
note
taker,
you're
gonna,
do
it
in
the
the
the
thing,
the
tool
right,
yeah,
that's
perfect!
Thank.
C
A
Yeah
all
right,
I
I
switched
slides
over
to
the
the
let's
see.
If
I
can
just
do
that,
and
we
can
I
think
that's
okay
right,
all
right,
I
think
we're
good
to
go.
Yes,.
D
D
Okay,
I
have
three
presenters.
My
name
is
Casey
asses
and
I'll
be
presenting
with
Brandon
Leventhal
and
Dimitri
Vena
karov,
but
we
also
have
some
additional
authors
and
a
lot
of
them
should
be
on
the
call
as
well,
but
that's
the
full
list,
we'll
we'll
be
representing
Apple
alphabet
as
well
as
Mercedes-Benz.
D
Okay,
so
today's
agenda,
we're
gonna,
do
a
quick
overview
of
the
problem
statement.
We
went
over
this
a
little
bit
more
in
depth
in
itf114,
but
for
those
that
didn't
join,
we
just
wanted
to
go
over
that
for
the
majority
of
the
time.
We
want
to
talk
through
our
requirements,
so
this
is
additional
documentation
that
we've
done
in
the
last
three
months
and
then
overall
talk
about
what
the
next
steps
for
the
working
group
are.
D
So
with
that
we
have
the
problem
statement.
So
in
today's
world
there
are
lots
of
different
ways
to
add
digital
credentials
to
your
device
and
walk
around,
especially
with
access
to
hotels,
cars,
home
Etc,
and
while
there
has
been
some
solutions
for
sharing
within
a
single
year
platform
or
maybe
within
a
certain
type
of
credential
right
now,
there
is
no
widely
accepted
way
of
transferring
a
digital
credential
securely
between
digital
wallets
of
different
software
and
Hardware
manufacturers.
D
So
our
main
goal
is
to
find
a
solution
that
works
for
all
types
of
these
digital
credentials
as
well,
as
you
know,
all
platforms.
So
there
are
three
main
entities
as
part
of
the
sharing
process
that
are
depicted
above.
We
first
have
the
sender
device.
This
is
the
person,
that's
originating
the
share
and
they
already
have
some
sort
of
digital
credential
on
their
device,
and
then
we
have
the
receiver
device.
This
is
the
person
or
device
that
we're
trying
to
share
too
to
give
that
additional
access.
D
D
D
D
D
So
therefore,
the
hotel
or
the
provisioning
partner
will
provide
me
with
the
provisioning
information
required
to
give
to
my
spouse
so
that
they
can
then
provision
their
own
hotel
Key.
So
the
nice
part
about
this
is
a
lot
of
com.
A
lot
of
hotels.
These
days
require
you
to
make
accounts
with
them
like
a
high
account,
for
example,
in
order
to
provision
or
have
access
to
their
app,
and
so,
when
you
share
to
your
receiver,
they
shouldn't
have
to
have
access
to
the
app
or
create
another
account
Etc.
D
They
should
just
have
that
provisioning
information
and
that
should
be
sufficient
to
redeem
and
get
that
hotel
Key.
Lastly,
at
the
end
of
your
stay,
the
producing
partner
will
manage
the
key,
delete
it
off
your
devices
and
you're
good
to
go.
No
stopping
at
the
lobby
so
now
I'll
be
handing
off
to
Dimitri
to
go
through
our
requirements
and
start
the
discussion.
E
Thank
you
Casey.
Thank
you
for
showing
interest
to
our
working
group.
E
So
in
the
previous
conversation,
IDF
conference
represented
the
solution
and
the
work
questions
and
the
feedback
that
we
received
was
we
were
trying
to
propose
something
without
defining
formal
requirements.
We
decided
to
step
back,
write
a
draft
containing
formal
requirements
to
the
solution
and
another
draft
with
sample
implementation
threat,
modeling
and
present
it
to
the
community
during
this
conference
and
right
now,
we're
going
to
go
over
several
slides,
which
show
assumptions
that
we
made
and
then
a
requirements
grew
into
certain
groups
like
slide
on
the
slides
next.
D
E
E
So
the
assumptions
to
the
solution:
we
have
some
knowledge
about
the
credential
digital
credentials
and
based
on
that
knowledge,
we
come
here
to
ask
for
advice
from
Community
whether
these
assumptions
and
requirements
look
valid.
We
come
here
to
for
help.
Basically,
the
first
assumption
is
revision.
Partner
may
not
allow
for
two
users
to
use
the
same
credential
or
cryptographic
material.
E
This
assumption
is
based
on
the
fact
many
of
the
digital
credential
providers
they
own
the
infrastructure,
as
Casey
mentioned
on
her
slides
they
own
it
and
they
want
to
distinguish
between
two
credentials
with
different
indictments
access
rights
and
even
the
time
the
credential
can
be
used
to
access
property.
E
Second,
assumption
user
may
not
have
the
ability
to
revoke
a
credential
that
a
provision
partner
has
issued
again.
This
assumption
is
based
on
the
fact
that
the
property
is
owned
by
Hotel
chain
or
a
private
owner,
and
people
who
have
access
in
the
digital
wallet
to
the
property
they're,
just
given
a
right
to
access
temporarily
or
maybe
for
a
longer
time.
E
Third,
is
user
may
have
not
ability
to
create
new
digital
Keys,
Without
provisioning,
Partners
interaction
so
again
in
order
to
receive
an
access
to
a
hotel
room.
I
first
need
to
request
a
property
owner
to
issue
a
new
credential
security
communication
between
sender
and
receiver,
and
provisioning
partner
should
be
trusted.
So
obviously,
when
the
new
credential
is
issued,
the
channel
needs
to
be
trusted.
E
The
next
is
the
choice
of
integumentary
shall
be
defined
by
application
initiating
the
credential
transfer,
so
our
solution
proposed
an
integumentary
server.
We
understand
it's
just
one
of
the
way
to
approach
this
problem
and
we
specifically
propose
that
intermediate
survey
in
our
solution
in
order
to
achieve
some
goals.
E
If
I
have
a
key
in
my
wallet
and
I
want
to
initiate
a
sharing
process
with
my
friend
I
want
to
offload
that
revisioning
information
in
encrypted
format
and
store
it
temporarily
for
the
time
of
the
transfer
and
that's
what
our
integumentary
server
is
intended
for,
and
there
should
be
certain
level
of
trust
between
me
as
initiating
under
transfer
and
the
intermediary
server,
who
temporarily
stores
the
content.
E
The
next
one
is
sander
and
receiver
shall
both
be
able
to
manage
the
search
credential
at
any
point
by
communicating
with
the
packaging
partner.
Credential
life
cycle
management
is
out
of
scope
for
this
proposal,
which
means
the
credential
which
I
have
in
my
wallet.
In
order
to
be
managed,
it
needs
to
be
managed
by
the
revision
partner.
E
So,
let's
say
Hotel
chain
that
owns
the
rooms
in
the
hotels
and
all
the
logs
and
the
hotels
and
I
can
only
issue
requests
for
them
to
change
the
access
rights
or
maybe
life
cycle
of
the
credential,
and
the
final
assumption
is
any
device
OEM
with
a
digital
credential
implementation
adherent
to
Tigris
so
be
able
to
receive
shared
provisioning
information,
whether
or
not
they
can't
originate
provisioning
information
themselves
or
host
their
own
intermediary.
E
We
want
to
separate
the
credential
initiation
and
the
credential
provisioning.
So,
if
I
receive
a
link
from
my
friend
invite
from
my
friend
in
form
of
URL
to
my
Digi
to
my
device,
I
shall
be
able
to
provision
that
accept
the
link
and
provision
a
pass
to
my
wallet
and
basically
that's
it:
separation
between
initiation
by
sender
and
provisioning
by
the
recipient.
E
And
now
we
go
to
the
requirements,
so
there
was
a
lengthy
process
discussing
this
in
both
private
GitHub
repository
and
on
a
maven
group
with
both
co-authors
and
all
people
interested
in
this.
In
this
work
group,
and
as
a
result
of
that,
we
tried
to
formalize
requirements
to
the
solution
that
we
propose.
E
So
I
will
read
the
groups
of
the
requirements
and
then,
if
there
are
questions
we
can
discuss
it
either
at
and
or
at
the
end
of
this
slide.
So
first
requirement
says:
requirement
connectivity,
sender
and
receiver
devices
shall
be
allowed
to
be
online
at
different
times.
E
Both
devices
shall
never
need
to
be
online.
At
the
same
time.
So
simple
example:
I
want
to
share
a
key
to
to
my
home
or
to
my
car,
with
my
friend,
so
I
initiated
sure
I
send
them
a
URL
which
points
to
that
temporary
storage,
provisioning
information
and
my
connectivity
shall
be
limited
just
for
that
time.
E
My
friend
may
be
offline
at
the
time,
but
when
they
receive
an
SMS
or
email
or
encrypted
message
with
that
link
with
that
URL,
they
shall
be
able
to
provision
that
credential
to
their
wallet
haven't
connected
to
internet.
At
that
time,
the
initiator,
the
sender
don't
need
to
be
online.
E
E
So
again,
going
back
to
our
proposing
a
proposed
solution
temporarily
store
the
provisioning
information,
the
voucher,
which
allows
our
friend
to
provision
that
information
to
the
wallet,
restore
that
temporarily
on
integumentary
server,
and
we
can
share
the
link
pointing
to
that
provisioning
information
with
our
friend
over
multiple
channels
over
a
simple
SMS
which
has
a
limit
of
140
characters
over
email,
WhatsApp,
iMessage
or
any
other.
Maybe
signal
protocol.
E
P2P
means
means
that
we
are
trying
to
focus
presenting
this
particular
Solution
on
person
to
person,
share
a
process
of
credentials,
so
I
want
to
share
my
credential
with
a
single
person
and
the
goal
sharing,
which
means,
if
I
wanted
to
share
it
with
multiple
people
at
the
same
time
is
not
in
focus
for
given
particular
solution,
even
though
we
do
not
preclude
that
goal
in
the
future.
E
A
A
E
Appreciate
it
all
right,
transfer
data,
so
first
requirement
is
arbitrary
format.
Since
there
is
multitude
of
different
credential
types,
let's
say
some
of
them
are
digital
car
key.
So
it's
a
credential
which
allows
you
to
operate
your
car
open.
It
start
the
engine
drive
it
Etc.
Other
types
of
credential
can
cover
digital
keys
to
your
hotel
room.
E
Other
types
of
credential
can
allow
you
to
open
an
apartment
door
in
a
multi-family
home
or
maybe
a
private,
a
door
in
a
private
home.
So
all
these
may
be
regulated
by
different
specifications.
Some
of
them
can
be
published
as
carcon
Integrity
Consortium,
some
of
them
or
are
proprietary
to
certain
hotel
chains.
So
we
want
our
solution
to
try
to
approach
and
handle
all
these
type
of
credentials
to
try
to
allow
users
to
share
them
to
transfer
these
credentials
from
one
person
to
another.
E
The
next
requirement
is
round
trips.
Again,
some
of
the
credential
types
require
multiple
Communications
between
two
devices
using
intermediary
server,
for
instance
in
a
car
key
world
when
I
want
to
share
a
cover.
E
A
key
to
my
car
with
my
friend
I'm,
getting
deeper
into
details
now,
but
when
I
want
to
do
that,
the
actual
keys
are
generated
on
my
friend's
device
and
then
the
friend
will
send
back
to
me
key
import
request
in
order
to
be
signed
by
me
as
a
car
owner,
and
then
I
need
to
sign
that
key
import
request
and
send
it
back
to
my
friend
and
only
then
friend
can
provision
the
new
credential
which
was
generated
on
their
device.
E
That's
why,
for
some
protocols
we
need
multiple
round
trips
between
two
and
the
third
requirement
is
preview.
This
is
mostly
for
user
experience,
the
better
user
experience.
So
as
a
friend
when
I
receive
a
URL,
the
short
credential
I
want
to
be
able
to
understand
what
I'm
trying
to
provision
to
my
wallet.
E
A
solution
should
provide
security
of
the
provisioning
data,
transferred
confidentiality,
integrity
and
availability
simply
said
depression
in
data
that
we
temporarily
store
on
integumentary
server
needs
to
be
secured
and
I'm
here,
making
a
reference
to
the
security
triangle.
E
Second
requirement
is:
revocation
Solutions
shall
maintain
Access
Control,
allowing
sender
to
revoke
before
the
share
has
been
accepted
and
for
receiver
to
and
transfer
at
any
time
since
sometimes
transfer
can
include
multiple
steps.
Bow
sender
and
receiver
shall
be
able
to
control
entrybook
like
cancel
shocking
process.
At
any
step
we
can
move
on.
Please
actually.
B
G
Hi,
just
the
one:
that's
on
the
slide:
there
requirement
security,
so
confidential
integrity
and
availability.
Do
you
mean
Authentication
seems
that's
bundled
up
with.
E
Security
I'll
get
to
there
not
purely
authentication
in
the
Forum.
We
normally
okay
understand
that.
It's
not
strong
authentication
by
any,
like,
like
digital
certificates,.
G
Okay
and
is
availability,
a
security
property.
Would
it
not
be
better
to
have
it
as
a
separate
requirement.
E
Right
so
availability.
Normally
it's
a
recommendation
to
implement
her
to
to
provide
to
implement
some
measures
to
guarantee
availability
of
that
intermediary
server.
Yeah.
G
G
Okay,
yeah
I
I
would
say
have
it
as
a
separate
requirement,
but
okay
of.
E
E
Now,
I'm
moving
to
the
requirements
by
referring
to
our
integumentary
server.
So
again,
our
solution
proposes
a
temporary
storage
in
the
form
of
integrated
server.
So
we
can
see
that
we
often
refer
to
that
as
a
mailbox
storage.
So
we
create
some
tamper.
Your
place,
a
store
that
provision
information
in
encrypted
form
in
that
temporary
place,
and
both
devices
can
use
it
to
exchange
that
so
first
requirements
is
privacy.
E
An
integumentary
server
shall
not
be
able
to
correlate
users
between
exchanges
or
create
social
graph.
It
shall
never
be
an
Arbiter
of
identity.
So
it's
a
very
strong
requirement
because
we
don't
want
our
solution
to
collect
information
about
user
identity,
store
that
sell
it
use
it
in
any
form,
and
due
to
that.
E
Our
requirement
to
Authentication
cannot
use
strong
authentication.
We
cannot
send
user
identity
to
that
integumentary
server
because
it
can
be
collected.
E
Second,
is
requirement
notified.
So
again,
it's
mostly
for
the
ease
of
user
experience.
So
in
that,
in
the
use
case,
when
there
is
a
multiple
exchange
like
round
trips
between
sender
and
the
receiver
devices,
and
whenever
each
device
updates
the
content
stored
on
intermediary
server,
we
want
push
notification,
some
automatic
notification
to
be
sent
to
a
appropriate
party
in
order
to
notify
them
to
come
and
fetch
an
update,
and
the
next
requirement
is
opaque.
E
So
the
message
content
I'm
referring
to
that
provisioning
information
that
we
store
temporarily
on
our
integumentary
server,
so
not
I
shall
be
opaque
to
that
server
so,
which
means,
if
I
Implement,
that
integumentary
server
I
shall
not
be
able
to
look
into
what's
stored
there
or
use
it.
E
H
Your
answer
for
so
first
of
all,
privacy
is
mentioned
in
the
draft,
but
very
sparsely
there's.
Only
one
requirement
and.
H
H
In
the
case
of
a
hotel
room,
it
makes
sense-
and
in
fact
Casey
mentioned,
that
the
hotel
needs
to
know
about
it
and
needs
to
have
the
identity
of
the
second
person.
So
those
are
two
different,
very
different
use
cases
and
I
don't
see
how
they
can
coexist,
but
appreciate
that
clarification.
E
Thank
you
for
a
question.
It's
a
really
good
one
and
we
actually
received
that
question
in
some
forms
previously.
E
So
the
state
is
that
currently
access
to
a
car
using
digital
credential
is
it
has
only
one
published
standard
which
comes
from
CC
body
and
it
defines
how
a
digital
credential
can
be
used
in
order
to
provide
access
to
the
car.
If
there
were
other
standards,
let's
say
Open
Standards,
which
would
regulate
those
we
would
be
gladly
and
using
them.
Unfortunately,
there
is
only
one
standard
and
it
requires
communication
to
so-called
vehicle
om
server,
so
simply
put
I.
Can
I
can
do
that?
E
Exchange
between
two
devices
generate
a
new
credential
and
add
it
to
the
wallet
on
the
receiving
device,
but
there
is
always
that
last
step.
So
in
order
for
that
credential
to
work,
the
CCC
requires
a
request
to
be
sent
to
the
vehicle
or
M
server
in
order
to
register
that
newly
minted
credential,
so
that
the
car
recognizes
it.
We
try
to
argue
in
one
of
the
CCC
meetings
and
the
answer
was
since
modern
cards,
especially
those
who
Implement
that
standard.
They
are
very
expensive
assets
and
car
manufacturers.
A
H
E
I
think
that's
a
very
good
command.
The
only
thing
I
want
to
mention
is
that
this
is
a
requirement
for
for
our
particular
solution,
and
our
particular
solution
basically
covers
just
the
transfer
part
and
CCC
defines
the
provisioning
part.
So
once
the
credential
is
provisioned
to
the
wallet,
what
are
the
next
steps
to
start
using
that
credential
right?
So
we
have
a
key
to
the
wallet
in
the
wallet.
So
how
do
I
open
the
car
with
that
new
key?
E
But
it's
it's
a
great
question
and
we
realize
the
sensitivity
of
that
matter.
We
do
realize
again
if
there
is
a
standard
and
if
anyone
is
willing
to
start
working
on
the
standard
which
would
be
which
would
control
the
access
to
the
car,
we
would
be
willing
and
glad
to
adopt
that.
I
I
think
Dimitri,
as
you
mentioned,
this
is
Alex
speaking
Alex
Peltier.
The
distinction
here
is
that
this
privacy
requirement
is
for
the
intermediary.
If
there
is
one
and
that
it
doesn't
track
it,
but
the
provisioning
partner,
credential
Authority,
always
needs
to
know
who
is
in
control
of
the
keys,
so
whether
that
is
a
non-device,
credential
Authority
or
a
hotel,
they
they
need
to
know
who
is
shared
to
who,
and
so
there's
not
privacy.
In
that
sense,
this
is
privacy
for
the
transfer
protocol.
H
E
If
you
have
time
we
have
that
document
published
in
at
GitHub
and
at
the
end
of
the
presentation,
there
is
a
link,
all
the
URLs
to
the
documents.
If
you
could
come
and
leave
your
feedback,
it's
or
maybe
in
the
mailing
Group,
which
is
better
probably,
we
would
very
much
appreciate.
A
It
I
would
suggest
that
you
open
an
issue
on
on
this
particular
topic,
so
we
don't
forget
to
can
I
clear
it,
and
then
we
can
address
that
later.
E
All
right,
continuation
of
our
requirements
so
again,
this
is
about
our
integrity
server,
and
we
want
these
in
technology
server,
to
implement
some
mechanisms
to
prevent
abuse
by
sharing
shaking
device.
We
find
that
the
device
is
in
good
standing
and
the
content
generated
by
the
sender
device
can
be
trusted
by
integumentary.
E
Simply
put
we
want
to
establish
since
share
initiation
is
the
crucial
part
of
the
transfer
process.
We
want
to
establish
special
trust
mechanisms
between
sender
device
and
integumentary
server.
Both
of
these
need
to
start
to
trust
each
other,
and
the
way
we
propose
is
by
using
attestation
not
linked
to
the
user
identity.
E
So
whenever
sending
device
creates
a
mailbox,
the
content
can
be
covered
by
the
attestation
blob,
which
incognitively
server
can
verify
following
defined
rules
and
make
a
decision
whether
to
trust
the
content
or
not,
and
the
next
requirement
covers
the
receiving
device.
So
for
the
case
of
receiving
the
device,
the
level
of
trust
the
level
of
requirement
is
lower.
So
we
don't
want
the
receiver
device
to
provide
attestation
or
any
strong
authentication.
We
just
wanted
to
trust
a
list
of
integumentary
servers.
E
It
can
work
with.
So
whenever
I
receive
that
URL
to
that
temporary
storage
on
the
integumentary
server,
we
only
want
we
only
propose,
so
the
receiving
device
has
a
low
list
of
intermediary
servers
so
recognized
by
device
manufacturers,
and
if
that
integumentary
server
in
the
list,
we
make
an
assumption.
It
can
be
trusted
again.
We
are
not
enforcing
strong
authentication
here
because
of
the
Privacy
requirement
which
we
covered
before
and
these
concludes
all
the
requirements.
C
E
Good
question
so
when
I
say
device,
what
I
actually
mean
is
a
digital
wallet,
the
application
that
manages
credentials
on
your
mobile
device
right
and
if
someone
implements
the
digital
wallet,
they
have
a
control
over
what
integumentary
servers
they
can
interact
with
and
who
can
be
included
in
that
trusted
list
and
I.
Believe
it's
the
details
of
implementation,
so
it
can
be
a
done
by
allowing
users
add
new
intermediary
service
into
that
list,
or
it
can
be
hard-coded
or
in
some
form
programmed
onto
your
application.
E
So
in
the
solution
that
we
propose,
we
have
a
list
of
intermediary
servers
which
includes
one
two,
three,
four
five
right
and
we
as
Developers
as
the
owners
of
that
digital
wallet
application.
We
make
decision,
Who,
We,
Trust,.
C
Well,
in
iitf,
we
develop
protocols
that
can
be
implemented
in
many
ways
and
assuming
that
only
you
as
a
device
owner,
is
in
control
of
that
list
and
for
users
using
the
protocol
in
another
situation
that
you
think
shouldn't
be
able
to
manipulate
and
edit
that
list
or
add
to
that
list.
If
I
mean,
if
I
want
to
add
an
intermediary
to
my
phone,
I
should
be
able
to
do
that,
because
that
intermediate
handles
the
credentials
that
I
need,
and
your
list
doesn't
so
be
careful
here.
E
Thank
you.
That
was
great
question
again,
it's
very
sensitive
matter.
Let's
say
I
want
to
develop
my
application
and
it's
my
responsibility
to
define
the
rules,
the
security
rules.
My
application
is
following:
when
we
interact
with
the
user
I,
don't
know
if
you
agree
or
not
with
that.
A
So
I'll
I'll
go
on
the
I'll,
go
on
the
cube
as
an
individual
and
and
say
that
I
mean
the
the
in
the
EU
wallet
space
right
that
the
EU
is
taking
more
or
less
the
same
approach
as
Apple
does
here
right
so
you're,
it's
kind
of
up
to
the
wallet
application
to
Define
what
its
trust
list
is,
and
so
you
I
think
the
deployment
model
you're
going
to
see
is
possibly
multiple
wallet,
applications
you
know
and
and
that
they
will
kind
of
vary
with
ecosystems.
D
Also
talked
about
this
kind
of
issue,
I
think
in
114,
we've
talked
about
potentially
having
a
list
of
these
existing
intermediary
servers,
maybe
not
in
the
actual
Solutions
spec,
but
maybe
in
an
implementation
guide.
So
for
whatever
ones
that
are
considered
accepted,
you
know,
or
the
working
group
would
get
to
accept
them
and
add
it
to
the
spec.
A
Just
going
to
make
an
administrative
decision
to
stop
sharing,
because
people
can
easier
to
can
find
the
QR
code
and
and
get
on
the
speaker
list.
G
The
other
point
made
about
users
being
able
to
add
intermediaries
if
they
want
that
it
shouldn't
be
something
that
apps
unilaterally
decide
for
their
users.
The
other
thing
I
wanted
to
raise
was
throughout
the
requirements.
You
stated
if
an
intermediary
is
required
for
the
solution
and
I
think
you've
demonstrated
some
cases
where
actually
genuine
is
required
and
Cloud
manufacturers
don't
seem
to
want
to
delegate
permissions
to
people
who
own
things
and
yeah
I.
Think
that
says
something
about
the
way
but
ownership
Works.
G
Nowadays,
if
the
intermediary
is
required
in
some
solutions,
will
it
be
possible
to
use
this
protocol
without
an
intermediary?
Does
that
make
sense?
I
I
realize
that
intermediate
is
sometimes
required,
but
if
that
means
those
protocol
always
means
they
need
to
be
intermediably
required.
I
think
that's
a
step
backwards.
J
Not
like
not
necessarily
required
for
even
for
the
car
key
stuff,
that's
more
of
like
communication
with
the
car
OEM
is
required
in
theory
like
you
could
implement
the
intermediary
on
a
device
itself,
so
you
know
there
could
be.
J
This
could
be
extended
to
a
place
where
it's
just
a
device
to
device
communication,
and
if
you
go
to
OEM
that
even
supported
you
know
provisioning
that
they're
creating
that
key
from
the
sending
device
like
in
theory,
you
could
do
all
this
offline
without
you
know,
having
anyone
or
like
any
third
party
interact
with
you
I.
Imagine
that
if
you
even
took
a
step
further-
and
you
know
you
did
it
over
like
a
protocol
like
Bluetooth
or
something,
then
you
could
do
it.
A
B
So
I'll
just
ask
the
authors
to
kind
of
summarize
the
status
of
all
the
drafts
you
have
currently
so
that
everybody
understands
Where,
We,
Are,
so
Dimitri
Casey.
Anyone
can.
D
Sure
no
problem,
so
since
114
at
114,
we
had
a
proposed
solution
draft
that
we
voted
on
and
then
have
worked
on
a
little
bit
since
so
now
we
have
a
requirements
draft
and
a
sample
implementation
and
threat
model
draft
that
are
all
published
a
data
tracker.
So
we've
I'm
really
excited
we've
gotten
a
lot
of
feedback
on
the
requirements
draft
in
the
last
couple
of
weeks
from
different
members.
D
I
think
a
lot
of
them
are
probably
in
the
security
dispatch
meeting,
but
that's
in
a
much
better
spot
than
it
was
even
a
couple
months
ago
and
a
sample
implementation
is
probably
the
newest.
So
definitely
take
a
look
at
it.
If
you
have
a
moment
so
yeah,
that's
the
status,
then
they're
all
obviously
on
GitHub
and
the
links
are
on
our
slide.
Deck.
B
All
right
so
I
think
for
the
authors.
We
still
have
some
feedback
that
we
need
to
incorporate
in
the
requirements.
Draft
I
think
right
before
this
email.
We
got
some
comment
from
Ecker
as
well,
so
the
next
steps
would
be
for
you
all
to
go
back
and
incorporate
those
feedbacks
and
publish
a
new
version
of
the
draft
requirements
draft
and
then
we
can
probably
do
an
adoption
call.
B
Does
that
sounds
like
at
forward
yeah
leave?
Do
you
have
anything
to
add
to
that.
A
I
think
that's
a
I
mean
it
kind
of
allows
you
to
iterate
a
little
bit
quicker
right,
we're
we're
getting
a
lot
of
feedback
and
as
while
the
draft
is
kind
of
under
your
editorial
control.
You
you
it's
kind
of
up
to
you
how
you
process
all
of
the
the
your
your
your
your
own
change
requests
basically
on
the
document,
but
you
know
we're
I.
A
Think
we're
also
getting
to
the
point
where
it's
it
makes
sense
to
kind
of
move
it
into
the
working
group,
because
that's
kind
of
where
we
want
them
to
be.
But
once
we
get
to
that
point,
we
have
to
start
getting
consensus
sort
of
in
a
different
way
and
the
the
documents
were
willed
by
their
by
that
nature
move
a
little
bit
slower.
A
So
I
think
we
in
in
for
practical
reasons.
It
actually
helps
if
we
can,
if
we
see
that
there
isn't
a
lot
of
contention
on
the
list
around
the
comments
that
is
coming
in
I
I.
Don't
think
we're
seeing
that
I
just
think
we're
seeing
like
good
content
and
good
suggestions
is
sort
of
incorporate
those
and
then
we're
at
the
point
where
all
right,
let's
fine-tune
the
resulting
document
in
our
in
as
a
working
group
document,.
D
Yeah
and
one
last
piece
I
wanted
to
note
that
I
don't
think
we
mentioned
this
at
114,
but
we
do
have
two
parties
that
have
implemented
our
solution
and
We
Know
It
Works,
which
is
a
good
thing
and,
of
course,
we'd
love
to
keep
incorporating
comments
and
tweaking
it,
but
I
think
at
least
we
have
good
proof
of
Concepts,
which
is
exciting
and
I.
D
Think
that
we've
also
had
just
some
discussion
in
the
working
in
the
working
group,
email
list
and
I
get
about
different
solutions
and
I
think
we
were
a
little
bit
too
fast
to
say
that
other
Solutions
wouldn't
work
I,
think
it's
true,
other
Solutions
might
have
worked
for
this
I
think
we
were
just
looking
for
a
nice
straightforward
way
that
it
would
work
and
that
anyone
would
be
able
to
implement
so
I
just
wanted
to
add
that
and
definitely
acknowledge
that,
because
I
feel,
like
we
weren't
acknowledging
that
very
well
in
our
last
meeting.
A
B
A
A
K
Yes,
yeah
I
was
just
having
to
wait
for
audio
to
kick
in.
So
you
know,
I
I've
been
following
this
work,
both
from
IAB
standpoint
as
well
as
a
person
at
apple
and
a
while
ago.
We
did
have
a
conversation
with
CCC
about
this
and
talking
about
the
fact
that
there
are
these
essentially
early
versions,
where
we're
testing
interop
now
and
may.
Even
you
know,
we
can
have
deployment
that
works
between
the
different
things,
but
the
protocol
is
expected
to
evolve.
K
Based
on
the
discussion
in
the
working
group,
and
even
you
know,
if
we're
looking
at
the
direction
that
some
people
are
pointing
to
like
okay,
maybe
it's
going
to
be
a
profile
of
web
dev
or
you
know
something
else.
It
could
like
take
a
very
sharp
turn
as
far
as
the
implementation
and
what
I'm
wondering
when
we're
talking
about
hackathon
or
are
these
early
implementations
he's
kind
of
like
what
is
do?
K
We
have
a
strategy,
that's
formalized
for
how
we
evolve
from
an
early
implementation
and
saying,
like
Okay,
the
client,
when
it
knows
it's
trying
to
share
a
credential
or
receive
a
credential
knows
what
version
it's
on.
Like.
Oh,
this
is
on
the
early
proprietary
version.
How
will
those
clients
migrate
to
what
it
ends
up
being
and
I
think
that
that
answer
could
be
different
depending
on
like?
K
F
Yeah
I
don't
know
if
this
is
a
great
answer,
but
I
think
one
of
the
takeaways
we
got
from
the
quick
experience
is
thinking
about
versioning
early
on
in
the
protocol.
Development
allows
you
to
make
those
like
very
sharp
pivots,
and
maybe
that's
what
you
were
trying
to
get
at
Tommy,
but
I
I
do
think.
That's
an
area
that
we
need
to
start
thinking
through,
as
we
start
to
move
into
the
working
group.
K
Right-
and
you
know,
quick
is
a
good
example.
I
think
it
started
with
you
know,
there's
a
variant
of
like
this
is
a
packet
over
UDP
and
like
this
first
little
bit
will
tell
you
the
version
and
that's
the
thing.
What
is
I
guess
I'm
asking:
what
is
it
in
this
case?
Is
it
a
URL
that
we
get
and
the
URL
that
tells
us
where
to
point
to
as
the
intermediary
that
that
is
the
thing
that
tells
us
the
version
or
is
it
something
within
the
TLs
connection,
Etc.
I
K
Okay,
so
essentially
we're
assuming
that
everything
bootstraps
off
of
a
URL
that
begins
with
https
colon,
slash,
slash
and
there's
something
in
it
that
can
indicate
the
version
and
I
guess.
Even
if
it's
even
if
we
decide
hey
this
is
SMTP,
we
could
just
have
a
different
scheme
in
the
URL
and
you
could
key
off
of
that.
So
so
the
URL
is
our
negotiation
mechanism.
Here,
yes,
okay,
great.
B
H
J
Yeah,
that's
a
good
question.
I
think
we'll
need
to
think
on
that
a
bit
yeah,
especially
if
we
want
to
have
it,
be
available
to
expand
into
like
device
to
device
communication
or
something
like
that.
L
Hi
this
is
Nick
I
just
want
to
comment
on
that
as
well.
You
know,
proprietary
solution
does
not
need
to
use
URLs
at
all
if
it
doesn't
want
to
go
through
the
intermediary
server,
so
that'll
be
just
left
up
to
just
you
know
the
proprietary
solution
and
its
own
versioning.
If
it
wants
to
negotiate
that,
so
you
could
do
it
over,
you
know
like
nearby
sharing
or
you
know,
whatever
Bluetooth
or
uwb
or
whatever
it
is
that
you
want
to
do
foreign.
A
B
Are
yeah
all
right,
I
think
then
we'll
close
it
off
and
thank
you
everyone
for
coming.
We
have
some
action
items
that
we'll
take
from
here
and
we'll
continue.
The
discussion
on
the
meaning
list
have
a
great
idea
week.
Thank
you.