►
From YouTube: IETF109-RATS-20201117-0900
Description
RATS meeting session at IETF109
2020/11/17 0900
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
A
A
Okay,
so
I
think
most,
everyone
should
be
well
aware
of
the
note.
Well
so
we'll
do
that
pass
on
quickly
and
I
will
say
thank
you
to
panway
and
thomas
for
helping
ned.
With
the
note
taking,
I
wanted
to
do
a
quick
test
since
you're
all
on
meat
echo,
I
figured
you're
you're
all
knowledgeable
on
how
to
use
the
system
and
the
minutes
and
notes
are
being
taken
in
codium
d.
A
A
A
A
C
C
A
I'm
gonna
count
yep,
I'm
gonna
count
to
five
and
I'll
end
the
session
one
two
three
four
five,
it's
interesting,
I
would
have
presumed
more
people
would
have
known
how
to
ski
so
25
of
35
participated.
15
said
they
know
how
to
ski
10
said
they
do
not
all
right.
So
in
case
I
I
need
to
have
a
show
of
hands.
You
now
know
how
to
use
it.
A
So
let's
continue
on
okay,
so
for
today's
agenda,
and
actually
I
didn't
have
many
requests
for
time.
So,
even
though
I
have
time
allocated
here,
if
the
sessions
run
long,
so
I'm
going
to
be
a
little
loose
with
the
time
what
we
can
do
is
we
can
spill
over
the
discussions
to
thursday
unless
there's
any
objections
to
do
that.
C
C
A
Sounds
good,
I
asked
you
about
that.
You
said
you
weren't
going
to
be
ready,
okay,
so
I've
I've
noted
it
for
the
end,
any
other
comments
or
feedback
going
once
going
twice
all
right.
So
next
on
the
agenda
is,
I
don't
know
if
michael
is
on
for
the
architecture
draft,
I
don't
see
him
so
I
issued
a
working
group
last
call
for
the
draft.
A
C
E
Hello,
hello,
can
you
hear
me,
can
you
hear
me
yes
now
I
can
hear
you?
Okay,
sorry,
okay,
so
we
have
a
big
review.
That's
still
outstanding,
but
I
will
spend
some
time
in
the
afternoon
trying
to
collect
all
the
comments
that
we
have
and
and
and
you
know,
either
create
prs
or
or
make
a
big
mail
to
the
list.
A
A
A
A
A
G
G
D
Okay,
great
so
all
I
was
trying
to
say
earlier
was
just
that
same
as
hank.
I
have
not
received
any
private
mails
just
what's
on
the
list.
Okay,
the
so
I've
obviously
read
it
and
I
think
it's
good,
but
maybe
it
can
be
better
if
problems
and
folks
have
questions,
but
the
one
thing
that
may
be
the
your
comments,
the
one
thing
that
the
working
group
may
want
to
agree
on
is
there
anything
we
should
do
differently
based
on
the
ipr
declaration,.
B
B
B
A
Well,
I
I
would
suggest
kathleen
that
we
all
check
with
our
respective
corporations,
so
the
fact
that
there's
ipr
in
china
right
different
countries
may
treat
their
ipr
differently
right.
So
if
you
have
products
that
go
into
china,
the
fact
that
there's
prior
art
listed
in
the
us,
how
does
that
compare
to
china?
I
I
don't
know:
okay,.
D
C
This
is
a
rat,
I'm
sorry,
by
the
way.
This
is
the
year
of
the
rent
in
china
at
the
moment.
So
that's
a
current
topic
and
also
you
were
asking
me
something,
and
that
is
why
cued
it
was
about,
I
think,
review
and
how
I
actually
forgot
the
question,
but
I
I
what
I
remembered
to
say
was
that
I
will
do
after
the
pull
in
of
agreed
upon
changes
from
from
thomas
and
others.
A
A
A
B
B
G
Yes,
all
right,
I'm
a
little
bandwidth,
limited
or
I'd.
Send
you
a
video
of
my
dark
room,
so
I'm
just
going
to
go
with
audio,
I'm
speaking
with
half
the
authors
for
the
char
draft,
and
we
have
only
a
small
update
since
the
interim
that
we
gave
just
a
few
short
weeks
ago,
but
we
do
have
some
updates.
G
G
G
In
addition,
there
is
the
rats
interaction
model
and
it
also
has
a
relationship
to
the
interaction
model
as
well,
because
you
can
do
interactions
such
as
getting
remote
activation
out
of
the
device.
The
device
the
model
as
well
is
also
based
on
the
document
which
has
gone
through
working
group
last
call
before,
and
that
is
the
network
device,
a
test
which
defines
the
use
cases
and
operational
prerequisites.
G
G
G
G
Slide
open
issues,
as
I
mentioned,
there
are
an
xpath
expression
which
needs
to
be
built
to
validate
some
extra
data
integrity,
and
these
will
need
reviews
by
the
young
doctor
mahesh
as
part
of
the
yang
doctor
review,
agreed
to
help
complete
the
xpath
expression
review
and
after
the
yang
doctors
are
done
with
the
comments
we
want
to
go
ahead
and
address
any
of
those
comments.
We
have
to
wait
till
those
come
in.
G
G
We
have
asked
several
times
for
an
expert
in
tpm
1.2
to
go
ahead
and
help
us
to
confirm
that
our
understandings
are
correct,
but
as
to
date,
we
do
not
have
a
tpm
1.2
expert
who
is
able
to
or
who
has
yet
agreed
to
provide
the
details
needed
to
say.
This
is
exactly
the
kind
of
quote
information
we
made
out
of
tpm
1.2.
G
We
did
close
the
issue
that
we
brought
up
during
the
interim
name
about
including
tpm,
node
and
node
id
into
the
rpcs
and
we've
gotten
responses
to
the
query
that
we
made,
and
that
is
that
there's
no
objection
to
reducing
the
minimized
form
of
the
rpc,
which
is
using
certificate
name
as
an
input
to
a
multi-tpm
device
in
order
to
identify
which
devices
you
want
to
get
the
quotes
from.
So
it
looks
like
we've
closed
out.
This
particular
issue
from
the
last
interim
next
slide.
G
So
next
up
well,
we
gotta
wait
the
yang
doctor
comments
in
order
to
get
through
yang
doctor
review.
We
need
to
make
sure
we
get
that
xpath
scrubs
done.
We
need
to
validate
the
1.2
structures
and
once
we're
there
we're
going
to
propose
working
group
last
call,
and
so
that
is
where
we
are
at
any
thoughts
or
questions.
G
Not
as
good
as
I
would
like,
I'd
hope
that
somebody
who
is
a
true
expert
in
1.2
would
be
willing
to
make
comments.
We
had
some
initial
movement
on
the
list,
but
we
did
not
close
those
queries,
so
I
personally
don't
know
somebody
that
I
think
would
be
somebody
who
is
involved
with
building
and
using
those
tpm
1.2
structures,
there's
always
the
option
of
removing
tpm
1.2
from
the
from
the
from
the
architecture.
G
That'd
be
great,
and
if
we
can
get
somebody
there,
I
mean
you
and
I
and
others
who
who
know
I
guess
yang
and
and
sheriff
and
whatnot.
You
know
it
could
always
be
a
group
meeting.
It
doesn't
have
to
be
just
an
email,
interaction
to
train
them
on
how
to
read
yang,
because
most
normal
people
don't
read
yang.
C
C
C
It's
on
the
very
fire
side
of
things
and
thomas
is
apparently
very
familiar
with
this
because
he's
a
big
contributor
to
this
open
project.
It's
about
a
goal,
implementation
of
the
verification
side
of
remote
station
here
and
therefore
it's
an
essential
building
block
for
the
interaction
model.
It's
a
consumer
of
evidence,
for
example,
and
the
consumer
of
attestation
appraisal
policies,
for
example.
So
that's
worth
to
highlight
here
in
a
quick
spotlight.
C
C
C
C
No
content
was
added
anymore,
so
I
think
we
are
at
the
moment
beyond
that
phase,
unless
someone
comes
up
with
a
yet
another
interaction
model
which
is
after
we
were
talking
about
this
in
the
architecture
on
a
very
abstract
level,
relatively
unlikely.
So
that's
that's
the
current
things
that
have
happened
now
coming
to
the
things
that
are
happening
on
the
next.
C
Slide
so
I
issued
a
a
formal
request
for
some
review
on
two
sections
of
the
draft.
Explicitly,
of
course,
general
review
is
always
welcome,
but
to
focus
attention
a
little
bit.
There
was
the
section
section,
six
and
section
seven
here
which
include
normative
language.
This
will
be
elaborate
on
the
next
slide.
So
first
item
is:
there
are
some
prerequisites
it
has
to
be.
Probably
it's
it's
assumed
to
be
a
good
list,
but
maybe
there
is
some
inconsistency
there.
C
So
feedback
is
nice
about
what
you
actually
need
to
start
an
interaction,
what
what
the
tester
has
to
satisfy
on
requirements
side,
so
that's
covered
in
section
six,
and
if
someone
is
not
able
to
find
themselves
or
their
use
case
or
a
anticipated
or
worked
on
solution
draft
here,
that's
that
would
be,
and
that
would
not
be
ideal.
So
feedback
on
that
front
is
always
welcome.
Same
goes
to
the
generic
information
elements
that
are
required
to
interact,
for
example,
between
a
tester
and
verifiable.
C
That's
a
a
very,
very
concise
set
of
information
elements
that
you
probably
always
will
need
if
you
run
a
protocol
between
these
two
rows
for
conveyance
of
information
over
the
internet,
but
maybe
something
is
confusing
phrased
here
or
you
think
no,
I
can
live
without
that.
Why
is
this
mandatory
or
something
like
that?
That
would
be
nice
feedback.
Also
next
slide.
C
C
Okay,
yeah
and
then
then
this
is
probably
on
me.
There
should
be
another
slide
that
is
talking
about
track
so
that
the
imagine
a
topic
that
is
track
and-
and
so
the
ideas
is
categorized
as
informational.
Currently
it
nevertheless
uses
normative
language.
So
that's
not
a
problem
itself,
but
I
think
at
the
virtual
interim
that
the
the
question
was
raised.
Should
this
be
considered
to
be
standard
strike
or
not?
I
actually
at
the
moment,
don't
think
so,
but
there
might
be.
It
might
be
opinions
about
that.
A
D
D
If
you
want
to
do
that,
but
I
do
think
it's
informational
and
that's
because
I
don't
think
an
implementation
implements
or
you
know,
implements
and
directly
conforms
to
the
interaction
model
spec
it
implements
and
conforms
to
a
protocol
document
which
in
turn
uses
an
interaction
model.
So
it
only
implements
it
indirectly
by
some
other
spec
that
would
be
normative
and
that's
why.
I
think
that
informational
is
the
right
thing.
J
So
this
is
a
kind
of
a
picture
of
the
claims
and
a
few
other
things
that
are
not
exactly
claims
that
I'm
aiming
to
have
completed
in
the
eat
draft.
So
this
would
be
the
the
sort
of
the
list
of
topics
I'm
expecting
expecting
to
cover
in
eat.
So
you
kind
of
get
to
a
working
group
last
call
when
all
these
topics
are
covered.
J
J
By
each
topic,
so,
starting
with
the
top
left
on
hardware
identification,
the
the
thing
that's
missing
there
and
is
some
hardware
version
information.
So
there's
some
pull
requests
there,
but
they're
not
quite
complete
yet,
and
it's
been
a
need
a
little
bit
more
work.
There
then
coswood
software
identification.
J
My
I
believe,
there's
consensus,
that
we
want
to
use
coswood
for
this,
but
I
think
there's
some
work
to
be
done
to
sort
of
figure
out
exactly
how
it
fits
in.
I
felt
some
some
comments
on
the
coast,
wood
draft
itself,
around
tagging
and
seaboard
tagging,
and
some
other
things
like
that.
So
I
don't
think
I
have
any
discussion
for
that
today,
but
the
basic
message
on
that
is
that
I'm
assuming
we're
going
to
integrate
coast
with
and
then
that
would
be
a
normative
dependency
on
co-sued.
J
J
J
A
J
J
Context,
purpose
and
profile:
geary
has
got
a
pull
request
for
contacts
that
needs
some
discussion.
Some
of
the
armed
folks
have
proposed
a
profile
this
I
have
maybe
the
least
handle
on
for
all
of
these.
So
again,
comments
and
discussion
needed
there
relative
to
the
pull
request,
and
I
didn't
have
that
on
the
list
for
today.
J
So
sub
modules
and
nested
eats
there's
a
pretty
good
pull
request
for
that
that
I
haven't
integrated
yet
that
I
think
is
close
to
being
ready.
I've
been
working
a
lot
on
an
implementation
of
that
in
c,
so
really
getting
to
understand
how
that
fits
together,
somewhat
complicated
to
to
do
some
of
the
nesting
stuff.
So
it's
taking
a
little
bit
of
while
there
just
because
of
the
way
the
sea
water
works.
Nothing,
nothing!
J
J
J
J
J
J
C
Hi
again,
this
is
hank
yeah
hi
laurence.
Thank
you.
I
think
the
this
watermark
indicators
here
are
super
helpful
to
convey
a
sense
of
where
we
are.
Thank
you
for
that
explicitly.
I
want
to
pick
a
item
that
is
identify
verifier
input,
so
from
the
current
I
don't
know,
go
with
the
flow
vibe.
I
I
think
that
the
heat
has
a
strong
focus
on
this.
This
core
eat
the
base
eat
as
a
as
a
strong
focus
on
being
generated
by
their
tester.
C
So
my
first
assumption
is
that
the
tester
comes
with
some
kind
of
endorsement
or
comes
with
some
kind
of
their
own
ids
and
such
so.
So
that's
my
question.
Basically,
that's
the
start
for
my
question.
Do
you
anticipate
this
being
generated
by
the
tester
still
or
is
this
probably
because
endorsements
is
a
standalone
thing
could
be,
of
course,
being
created
by
the
endorser,
for
example
as
another
source?
For
this
conceptual
message.
J
C
J
C
J
C
Basically,
I
was
going
to
just
make
reference
to
that,
so
the
premise
that
I
was
illustrating
a
little
bit
so
basically
all
of
this.
Each
content
claims
here
at
the
moment
are
tester-centric
and
I
think
we
should
maybe
if
we
would
agree
with
that,
we
should
point
that
out
early
in
the
text.
At
some
point,
I
think.
A
A
D
It
just
happens
to
include
it
in
the
evidence
in
the
option
we're
using
the
a
tester
to
pass
the
endorsements
rather
than
getting
the
endorsements
directly
from
the
endorser
to
the
verifier,
and
so
that's
why
I
think
lawrence's
slide
is
perfectly
fine
and
so
yeah.
I
support
the
list
of
things
on
here,
there's
one
or
two
things
that
I
have
a
question
on
too,
but
offhand
it
looks
good.
So
thanks.
J
C
Okay,
excellent,
so
yeah,
so
that's
that's
that's
and
yeah.
So
that
is,
you
have
to
do
some
planning
here.
Maybe
so,
of
course,
the
each
structure
is
very
suitable
for
every
other
conceptual
message,
like
attestation
results
as
we
will
see
in
the
slides
or
endorsements,
and
I
think
we
also
have
the
notions
of
a
composite
evidence
that
was
beforehand
always
the
as
an
example
and
evidence
that
includes
the
stage
results
so
to
relay.
C
So
that
would
be
like
it,
and
so
so
that
it
is
a
modular
thing
and
you
can
you
can.
That
would
be
as
a
group,
for
example,
but
also
you
with
your
work,
could
move
forward
and
then
putting
the
lid
of
one
thing
going
with
the
testers
based
claims
and
highlighting
yes,
there
will
be
claims
in
other
complementary
drafts
about
including
actual
endorsements
that
are
pre-deployed
on
the
testers
for
offline
use
and
convenience,
for
example,
or
for
domain
specific
applications
and
then
stagger
and
stage
this
work.
C
J
Well,
I
mean
I
for
first
I
don't
consider
the
endorsements
a
claim
and
my
intent
was
to
put
them
in
a
separate
place.
Basically
in
the
cose
header.
I
think
you
can
do
the
same
with
jose,
so
it's
not
a
claim,
and
but
that's
maybe
just
just
a
semantic
thing.
I
I
don't
you
know
my
interest
is
in
eat
being
fairly
comprehensive.
C
C
Sorry
come
back
to
the
topic,
so
the
the
problem
I
see
personally
is
that
when
we
are
basically
dancing
on
three
weddings
at
the
same
time,
which
are
attestation
results,
evidence
and,
for
example,
endorsements
here,
this
will
take
a
while
still-
and
I
don't
know
how
long
you
think
this
you
anticipate
this
is
to
be
in
the
in
the
works
so
to
speak,
because
if
we
wait
for
our
attestation
results
claims
here
and
finalize
them
to
a
concise
set
that
might
take
quite
a
while.
Don't
you.
J
A
C
C
J
J
Okay,
so-
and
I
have
several
several
discussion
points
here-
I'm
just
going
to
go
on
these
discussion
slides
until
we
run
out
of
time,
I'm
not
sure
that
we'll
complete
them
all
I
didn't
intend
to
complete
them.
All
just
was
wanted
to
have
discussion
on
these
things,
so
so
this
is
framing
for
some
discussion,
so
my
understanding
is,
there's
pretty
clear
interest
and
consensus
that
heat
can
be
used
for
attestation
results.
J
The
eat
draft
must
discuss,
discuss
attestation
results,
but
maybe
only
briefly,
that's
kind
of
the
question
is
do
how
far
do
we
go
with
it?
If
we
decide
to
go
not
very
far,
we'll
just
put
a
little
note
that
says
you
know,
eat
can
be
used
for
attestation,
results
see
other
draft
or
something
like
that.
J
Now,
I'm
getting
into
some
more
interesting
stuff
here,
I
believe
a
lot
of
eat
claims
are
going
to
pass
through
the
verifier
into
attestation
results.
Just
just
you
know.
Some
of
this
comes
from
before
we
we'd
even
split
the
verifier
from
the
relying
party
so
in
in
that
context,
we
want
to
reuse
as
many
claims
as
possible.
So
we
don't
want
to.
You
know,
have
the
verifier
having
to
to
translate
claims
that
came
from
the
a
tester
into
you
know.
A
station
result
style
claim.
J
J
J
J
J
So
I
I
didn't
have
don't
have
a
bullet
here
for
it,
but
there's
definitely
claims
that
are
coming
from
the
endorser.
I
mean
I
don't
know
if
you
call
them
claims
when
they're
in
an
endorsement,
but
claims
that
come
from
the
endorser
from
the
endorsement.
That
would
kind
of
be
bundled
up
in
the
very
in
the
attestation
results
by
the
verifier.
J
D
D
I
can't
agree
with
the
question
because
I
have
opinions
on
the
questions,
but
I
agree
with
all
the
statements
on
there
other
than
I
would
make
one
wording
amendment
for
which
I
think
is
along
the
lines
of
what
you're
actually
mean.
When
you
say
many
e
claims
will
pass
through
the
verifier
under
attestation
results
right.
What
what
gets
passed
through
is
really
up
to
the
verifiers
policy,
and
so
many
each
claims
will
pass
through
subjective
verifier
policy.
D
Applied
yeah.
Yes,
so
I'm
going
to
argue
yes
in
the
eat
document
to
the
bottom
question
and
regardless
of
whether
it's
more
work,
it
is
the
case
I'm
personally
most
interested
in,
and
so
he
just
most
useful
to
me
once
the
attestation
result
claims
that
you
have
on
the
slide
there,
like
new
claims
for
attestation
resulting
needed
once
those
are
done.
That's
when
this
document
becomes
useful
to
me.
D
One
of
the
reasons
that
I
wouldn't
like
to
see
them
elsewhere
is
specifically
because
I
agree
with
your
points
about
reusing
as
many
claims
as
possible
right
that
the
differences
between
what
claims
are
evidence
only
versus
attestation
results
only
should
be
the
minority
of
claims
right
most.
The
claims
could
be
passed
through
and
because
of
that,
the
document
I
think,
is
mostly
common.
D
There's
going
to
be
a
couple
things
that
are
different
and
which
is
why
you
say,
perhaps
only
briefly,
and
so
my
hope
is
well,
maybe
those
new
claims
if
we
can
get
them
to
be
brief,
I
would
rather
get
those
done
sooner
because
I
personally
probably
won't
use
it
until
those
are
done,
and
so
I'm
all
in
favor
of
getting
those
done
soon.
The
other
things
that
you
mentioned
are
new
claims
are
needed.
D
D
Results
sometimes
is
that
the
verifier
also
needs
to
include
its
own
claim
set
as
if
it's
in
a
tester
to
say
I
verified
this
stuff
and
here's
something
that
proved
that
that
proves
or
vouches
for
the
fact
that
the
verifier
is
the
right
thing
and
then
the
relying
party
will
receive
that
act
on
the
evidence
from
the
verifier
and
say
yep.
I
trust
this
and
now
I
can
act
on
the
attestation
results
so
that
shouldn't
be
required.
D
Obviously,
but
that
should
be
one
of
the
options
because
and
it's
sort
of
like
having
a
composite
or
a
layered
attestation.
In
other
words,
your
attestation
result
needs
to
have
nested
the
eat
claim
set
for
the
verifier
itself,
and
so
that
would,
I
would
add,
a
bullet
to
your
list.
You
say
other
question
mark
that
should
be
another
thing:
that's
an
option,
but
I
think
that
the
structure
already
supports
that,
and
so
I
don't
think
there's
a
whole
lot
to
do
for
that.
So,
okay,.
D
There's
many
different
ways:
you
can
do
evidence
tpm
vlog.
I
am
the
one
that
is
the
least
expert
on
that
one
there,
and
so
I
may
not
use
that
in
any
example
or
recommend
it,
because
I
don't
know
what
it's
best
for
there's
other
things.
So,
for
example,
if
it
was
sgx,
I
used
to
look
at
ned,
because
you
know
things
like
open
enclave
and
other
projects
use
sgx.
It's
not
a
tpm
lock
right.
It's
an
sgx
quote.
G
On
using
attestation
results
and
for
you
station
results,
I
love
the
idea.
I
do
think
that
there
is
some
stuff
that
we
can
match
other
drafts
here
on
the
trustworthy
path.
Routing
draft
there
is
a
set
of
about
10
different
claims
that
could
be
considered
as
straw
for
attempt
station
results,
which
likely
would
be
portable
between
different
environments.
G
These
include
things
like
boot,
verified
hardware,
authentic
file
repudiated,
so
I
would
be
interested
in
your
opinion
on
those
trustworthiness
levels
and
their
relevance
or
possible
use,
as
at
the
station
result
claims
now.
I
know
you
might
not
have
read
it
here,
but
maybe
on
list.
I
would
love
to
hear
if
you
think
that
those
are
the
types
of
claims
that
you
believe
could
be
adopted
in
this
space.
J
C
Yeah
hi,
I
think
what
dave
said
is
encouraging,
because
that
was
my
primary
concern
that
this
would
stall
due
to
that.
So,
if
dave
is
very
involved
and
we'll
have
a
look
on
this-
and
everybody
is
basically
asserting
here
right
now-
yes,
we
can
do
this
right.
Now,
I'm
pretty
aware
of
the
trustworthiness
vectors.
I
am
aware
of
some
other
requirements
with
the
attestation
results
that
might
take
longer,
but
still
if
this
is
a
if
the
group
agrees
this
is
we
can
do
this
right.
C
Now,
I'm
very
happy
about
this,
and
this
is
not
a
blocking
comment.
It
was
never
intended
to
be.
It
was
just
a
concern,
so
I
like
what
I
hear
and
under
the
light
of
that,
I
think
or
in
the
light
of
that,
I
think
it's
it's
rather
suitable
to
reuse
stuff,
of
course,
in
the
same
document
again
for
the
sake
of
readability.
Also-
and
so
my
my
my
voice
is
contributors
now
in
favor,
and
if
we
actually
can
pull
this
off
thanks
laurence.
A
A
J
A
J
Yes,
okay,
so
we've
had
a
lot
of
this
discussion
already
when
hank
brought
it
up.
So
this
is
this:
was
the
the
planned
work
on
identifying
verifier
input,
so
I
was
going
to
add
some
discussion
on
key
identification
to
the
eat
draft,
so
this
is,
you
can
do
it
by
a
kosai
kid
or
by
the
kose
x.
509
draft.
J
J
Then
I
was,
you
know,
planning
on
headers
to
identify
endorsements,
but
no
definition
of
any
content
type
for
endorsements
and
then
perhaps
headers
cos
a
headers
to
identify
reference
values.
You
know
a
place
to
to
get
reference
values,
so
perhaps
a
url,
but
no
definition
of
the
format
or
the
content
type
for
reference
values.
J
J
Iot
onboarding
does
this
and
I
know
geary
and
the
the
fido
so
there's
fido
user
user
authentication,
but
there's
also
a
fido
iot
working
group.
That's
working
on
fido
iot
onboarding
that
gary
will
discuss
after
I'm
done
here,
so
that
uses
a
public
key
inside
an
attestation
and
then
android
attestation
is
very
much
about
public
keys.
J
A
J
Thing
with
them
is
that
the
the
semantics
of
what
that
public
key
means
varies
a
lot
by
the
use
case,
and
when
I
tried
to
to
sort
of
write
that
down,
I
realized
that
it
didn't
really
seem
to
make
sense
to
put
those
semantics
inside
eat.
You
know,
for
example,
fido
binds
the
phytoauthentication
binds
a
public
key
to
a
triple
of
a
user,
a
device
and
a
relying
party
that
that
you're
authenticating,
for
so
that's
very
authentication,
specific
and
very
phytospecific
and
really
does
not
belong
in
eat.
J
J
J
J
J
The
semantics
of
that
are
in
the
confirmation
claim.
Oh
no
yeah,
the
semantics
of
a
confirmation
claim
in
eat
are
not
defined
again.
That's
left
up
to
the
use
case.
So
that's!
What's
in
the
in
the
pull
request,
there's
a
few
of
the
things
that
I
that
might
be
interesting
to
to
add
we
might
want
to
put
in
the
security
level
of
key
protection.
J
Whether
biometric
authentication
is
required
to
use
a
key.
That
is
something
that
is
common
to
fido
and
android.
That's
something
else
that
we
might
want
to
put
in,
but
it
is
a
fairly
large
can
of
worms.
I
mean
I
know
the
rules
for
user
authentication
and
fido
are
pretty
pretty
complicated.
You
know
you
know
how
how
the
biometric
authentication
controls
the
use
of
key
when
you
start
thinking
about
fingerprints
versus
pins
versus
face
id
and
all
of
that
stuff
and
enrollment.
J
J
C
Hi
lauren,
sorry
for
for
being
on
the
microsoft
yeah,
very
tentatively
and
very
carefully.
I
went
to
raise
a
question
I
raised.
I
don't
know
about
two
or
three
years
ago
when
when
chartering-
and
it
was
shot
down,
harsh
solely
and
so
so
I'm
very
very
carefully
erasing
this.
So
if
you
include
a
public
key
here
in
each,
you
basically
are
proving
the
possession
of
the
private
key
right
that
that's
some
point
to
it,
or
is
that
not
the
intent
here.
C
J
C
Yeah
there
are
flavors
for
this.
I
I
basically
I'm
referring
to
the
work.
I
think
that
was
once
done
in
ace,
actually
I'm
not
sure
of
the
current
status
of
pop
there,
but
there
is
a
proof
of
procession
draft
somewhere
here
in
the
idev,
and
I
think
it's
covering
some
of
the
problems
that
maybe
part
of
the
discussion
of
public
key
inclusion.
J
F
I
F
J
So
so
I
think
this
just
highlights
the
point,
and
you
know
the
conclusion
I
came
to
was
that
we
can't
really
say
what
all
of
these
things
are
of,
whether
you
need
to
show
proof
of
possession
or
not
or
what
the
key
means,
because
the
those
semantics
are
highly
dependent
on
the
use
case.
So
mostly,
what
the
the
pull
request
says
is:
please
use
cosec
key
format
or
jw
key
format.
F
Okay,
so
and
like
if
you
say
that
I
think
it's
fine,
it
follows
the
same
style
as
the
87
47,
which
also
just
says:
here's.
If
you
want
to
pass
the
key
along
a
public
key
for
example,
then
here's
how
you
do
it,
but
then
you
need
to
explain
in
a
profile
or
in
application
specific
use
case
on
what
this
means
in
the
bigger
system
context.
J
J
A
J
J
J
Some
field,
or
some
kind
of
decoration
for
keys
that
would
indicate
the
level
of
protection
they
they
have.
So
we
could
use
the
the
same
security
levels
we
use
for
the
security
level
claim
and
say:
well,
this
key
is
protected
by
tee.
This
claim
is
protected
by
like
a
secure
element,
and
this
claim
was
is
predicted
that
the
you.
E
E
J
J
These
six
categories
on
demand,
registration,
provisioning,
certificate,
issuance
and
proof
of
possession,
so
they,
this
all
seems
to
be
kind
of
getting
to
use
case
some
specifics
about
use
case,
so
I
kind
of
lump
them
together
here,
so
maybe
comments
or
discussion
on
this.
I'm
I'm
actually
not
quite
sure
what
to
write
on
some
of
these.
These.
H
D
D
Yeah
yeah
at
station
would
be
an
example
of
a
potential
eku
value.
That's
like
it's
a
term
that's
used
in
existing
rfcs
and
I'm
trying
to
figure
out
whether
profile
was
the
same
thing,
in
which
case
I
don't
know.
If
there's
an
iana
numbering
space
and
one
of
the
things
we
can
just
use
or
or
not
or
if
it
just
happens,
to
be
a
similar
concept.
But
you
need
a
special
numbering
space
because
you
need
to
be
an
integer
compressible
or
something
or
whether
it's
an
unrelated
concept,
then
I
can't
tell.
E
J
E
D
E
C
Yeah,
so
this
is
saying
sorry
for
just
grabbing
the
mic
snatching
it.
So
I
I,
when
you
talk
about
claims
and
then
you
are
illustrating
how
these
claims
are
to
be
used
in
certain
contexts,
so
the
user
of
these
claims
is
the
verifier
and
if
you
tell
a
verifier
how
to
do
stuff,
it's
a
policy
to
me.
This
really
sounds
like
an
attestation
policy
to
me
right
now,.
J
E
E
E
J
I
So
we
talked
about
key
attestations,
so
I
think
I
I
can
give
a
specific
example.
We
actually
have
a
case
that
we
sometimes
call
internally
and
describe
this
on
the
github
repo
hardened
tls,
where
in
a
trusted
execution
environment,
a
client
certificate
is
actually
is
actually
requested
for
a
key
pair,
that's
contained
within
trusted
environment,
to
be
used
as
part
of
the
airplane
part
of
client
auth.
I
For
for
for
tls
connection,
and
in
that
case,
for
instance,
a
csr
would
actually,
the
contact
claim
would
be
set
to
indicate
that
it's
primarily
being
used
for
csr
can
be
used
for
other
purposes
too.
As
a
seen
in
the
description
that
lawrence
is
provided
on
the
slide,
I've
already
created
the
pull
request.
I
think
it's
fairly
straightforward
to
include
in
the
spec.
I
didn't
really
feel
there
was
a
need
to
actually
put
it
in
a
profile
and,
as
we
know,
all
claims
are
optional.
I
C
Yeah
hank
again,
so
this
context
claim
now
that
I
heard
something
about
it
like
like
explained
it
to
me.
Thank
you
for
that
how's
that
different
and
really
different
from
from
the
audience
claim
that
it
comes
with
web
tokens.
So
if
you
would
assign
principal
roles
to
all
these
things
like
on
demand
or
or
provisioning
or
popular,
how
is
that
different
to
the
audience
claim.
I
C
Yeah,
so
the
audience
claim
requires
you
to
identify
the
intended
consumer
and
that
is
typically
a
principle
with
a
at
the
end.
That
has
a
specific
duty,
and
so
if
the
duty
is
that
this
is
a
list
of
duties
here
or
tasks
or
the
things
you
want
to
achieve,
or
they
can
show
something
like
provision
or
do
something
like
bruising
that,
then
I
think
it's
quite
similar.
C
You
are
you're
skipping,
the
association
of
the
duty
with
the
principal
and
you're
just
highlighting
the
duty,
so
that
that's
that's,
I
guess
that's
it's
more
loosely
defined,
then
so
semantically
a
little
bit
weaker
and
I
wonder
what
would
it
be
of
benefit
to
actually
use
the
audience
claim
then?
And
that
forced
you
to
think
ahead
and
understand
what
the
role
of
the
consumer
is
here
beforehand.
I
A
I
C
Yeah
or
the
other
way
around
sorry
for
still
speaking
up
making
this
a
little
bit
more
precise,
adding
a
principal's
duty
here
as
a
principle
to
the
duty
here
and
then
you're,
basically
at
audience
claim.
So
that
would
be
the
other
way
around
and
I'm
not
saying
it
has
to
be
so
I'm
just
giving
food
for
thought
that
this
is
probably
already
possible
with
the
existing
claim.
J
So
there's
no
enforcement
here,
like
you
know
what,
if
you
use
a
registration
token
for
proof
of
possession,
is
that
there's?
No!
It's
not
like
a
key
use
thing
that
you're
supposed
to
use
it.
This
way,
it's
just
a
it's
it's
more
of
a
hint
of
like
well,
I
I
put
the
right
fields
in
here
for
registration.
So
if
you're
going
to
use
for
proof
of
possession,
you
might
be
confused.
J
A
I
J
I
I
J
J
I
I
The
attestation
will
be
signing
across
public
key.
The
attestation
will
be
signing
across
a
fido
concept
called
client
data
which
is
associated
with
the
authentication
credential
and
the
relying
party
that's
created.
That's
requested
creation
of
the
credential,
so
that
would
all
be
associated
with
registration.
That
would
be
the
one
the
time
where
attestation
is
actually
most
likely
to
be
used
in
the
fighter
context.
I
Right
is
registration,
I
think,
with
fido.
If
fido,
if
you've
looked
at
the
502
specification,
more
specifically
the
web
authentication
specification,
they
don't
really
have
a
concept
of
runtime
attestation
associated
with
the
credential.
It's
generally
expected
to
you
get
an
attestation.
When
the
credential
is
created,
you
can
re-request
it.
A
A
C
A
I
A
J
J
J
J
C
Yes,
I
just
inside
this
thing.
Yes,
so
there's
a
question
here
about
coast
with
that's
why
I'm
queueing?
Yes,
so
cosmic
can
report
measurements,
there's
actually
a
complete
set
of
tags.
That
is
called
an
evidence
tag
literally.
That's
not
that's!
What's
created
by
iso
that
type,
and
so
these
evidence
tags
have
a
certain
hardware,
specific
scope,
it's
a
device
scope
of
course,
or
it
could
be
a
component
scope
of
a
composite
device
and
they
they
are
used
to
report
on
a
snapshot
so
to
speak
of
the
device.
J
C
That
is
a
little
bit
of
an
abstract
description,
so
it
sounds
like.
Are
you
talking
about
evidence,
quotes
or
event
logs
that
complement
that
complements
them?
So
that
would
be
my
first
question
here,
but
this
is
a
little
bit
of
a
specific
tpm
ish
language,
I'm
using
now
just
to
make
a
specific
request
on
on
how
what
you
actually
mean
with
this
text.
J
So
the
the
the
program
text
is
loaded
into
you
know
ram
it's
it's
the
the
linux
kernel,
the
program
text
of
the
linux
kernel
and
you
say
from
you
know,
memory
starting
this
address
to
that
address.
I
expect
the
the
sha-256
hash
of
this
range
of
memory.
That's
the
linux
kernel
code
text
to
have
a
specific
hash
if
the
device
is
not
rooted.
C
I
see
now
in-memory
measurements
are
possible
with
code
switch.
There
is
a
process
id
identifier
for
a
resource
here.
I
think
it
is
underspecified.
So,
for
example,
if
you
have
a
certain
process
in
execution,
sorry
code
and
execution-
that's
a
process,
then
it
is,
I
think,
underspecified
to
identify
specific
register
pages
here
memory
pages
here.
So
that
is,
I
think,
a
gap.
Also,
it's
very
specific
and
it's
beyond
I'm
way
beyond
ima.
I
think
but,
but
I
would
not
say
that,
because
I
want
to
in
memory
that
sorry.
A
J
I
Okay.
Okay!
Yes,
thank
you
also.
If
I
I,
if
I
can
request
the
chairs,
I'm
having
a
little
bit
of
difficulty,
seeing
who
is
adding
themselves
to
the
queue
on
my
local
meet
echo
client,
it's
probably
a
user
error,
not
media,
echo
itself.
So
if
somebody
gets
on
the
cube,
please
let
me
know
so
just
to
give
a
little
background.
I'm
actually
coming
in,
not
as
a
in
making
his
presentation,
not
as
an
co-editor
of
the
e
document,
but
as
a.
H
I
So
I
think
many
people
already
know
this,
but
in
case
there
are
people
that
don't
just
to
give
a
very
brief
intro.
The
fast
identity
online
alliance
is
a
standards
and
certification
body.
That's
primarily
focused
on
passwordless
authentication,
and
there
are
several
standards
that
are
that
have
already
enabled
interoperable
user
authentication,
including
biometrics,
and
then
there's
associated
security
and
functional
certification
programs.
F
I
I
I
Thank
you.
So
there
are
three
steps
by
the
way.
This
is
my
definition,
but
I'm
sure
other
other
parties
have
absolutely
different
slightly
different
takes
on
this
concept,
but
basically
it's
where
an
oem
completes
manufacturing
of
the
device
and
ships
the
end
user
purchases.
The
device
puts
it
in
its
final
in
its
intended
location
for
operation
and
powers
it
up.
For
the
first
time,
then,
the
end
user
is
able
to
establish
an
ownership
relationship
with
the
device,
whereupon
they
can
actually
manage
the
device
going
forward
during
its
life
cycle.
I
So
it's
almost
a
transition
between
a
manufacturer's
ownership
to
into
the
intended
end
user.
Zero
touch.
Onboarding
is
the
goal
for
most
manufacturers.
It's
it's
debatable
as
to
whether
anybody's
actually
able
to
achieve
it
and
that's
basically,
where
the
user
powers
up
the
device
for
the
first
time
and
is
able
to
establish
ownership
with
minimal
intervention.
I
So
there
are
several
different
approaches
to
onboarding
one
one.
One
approach
I
described
below,
for
instance,
installing
an
app
on
a
on
a
smartphone
using
that
app
to
connect
to
a
cloud
service
where
which
the
user
can
authenticate
to
using
that
same
app
on
the
personal
device
to
connect
to
the
iot
device,
and
then
ownership
is
established
via
the
cloud
service.
So
you
sometimes
see
this.
I
For
instance,
in
home,
automation
like
connected
connected
devices,
maybe
may
be
attached
to
an
ownership
to
a
credential,
that's
associated
with
a
cloud
service
that
the
user
uses
an
example
could
be
the
google
password
with
nest
thermostats
as
being
as
being
one
that's
fairly
common.
Okay.
Now
we
can
go
to
the
next
slide.
I
So
this
is
the
fido
iot
system
architecture.
So
starting
from
the
left,
the
iot
on
board
device
is
the
primary
active
actor.
It's
the
device
to
be
onboarded,
the
device
may
or
may
not
have
ip
connectivity,
in
which
case
it
may
have
to
you.
If,
if
it
only
has
local
connectivity
such
as
a
bluetooth
such
as
only
bluetooth
or
nfc
access,
they
may
it
may
have
to
make
use
of
an
intermediary
to
contact
the
two
entities
on
the
right.
The
two
entities
on
the
right,
the
first
one-
is
a
rendezvous
service.
I
So
there
are
four
protocols
defined
in
the
fido
specification.
The
first
one
is
device
initialization,
which
is
how
the
manufacturer
actually
provisions
the
iot
device
with
all
the
necessary
security
related
information.
It
needs
during
manufacture
time.
This
could
include
even
the
attestation
keys.
I
Then
there's
three
transfer
ownership
protocols.
The
first
one
is
to0
which
the
in
which
case
the
device
owner
sees
information
into
the
rendezvous
server
about
the
device
to
be
onboarded
and
the
primary
information
regarding
that
device
is
the
unique
id
or
that
we
call
it
a
good
in
production
in
the
iot
stack
t01
the
device
contacts
and
identifies
itself
to
a
rendezvous
server.
This
is,
as
I
mentioned,
it
can
be
done
on
first
power
up
after
manufacture
or
after
a
factory
reset.
I
Okay,
so
in
the
phyto
specification,
currently
to1
and
t02
leverage
eat
the
minimum
requirement.
The
required
claims
are
the
nonce
in
the
ueid.
Our
intentions
are
to
complete
standardization
and
complete
the
standard
and
launch
an
interop
and
certification
program,
and
this
is
where
we're
running
into
a
bit
of
an
issue.
The
each
standard
is
not
complete.
I
This
is
mainly
because
certification
has
to
be
done
on
a
finished
product
and
vendors
will
actually
prefer
to
productize
with
registered
claims
and
not
the
private
space.
So
when
those
registered
claims
become
available,
veterans
would
like
to
actually
move
forward
and
and
leverage
them,
rather
than
rather
than
doing
something
that
that
may
not
be
interoperable.
I
I
I
That
that's
actually
the
set
of
claims,
that's
required
for
fido
to
move
forward.
I
don't
want
to
actually
be.
We
didn't
want
to
be
so
prescriptive
as
to
just
say
those
two
claims.
So
if
there's
any
other
claims
that
the
group
feels
comfortable
on
the
each
stack,
then
you
know
we
would
also
like
to
see
see
it's
move
forward
with
the
registration
of
them.
B
A
Yeah
I
was
going
to
add.
I
think
we
would
have
to
have
some
kind
of
review
process
too,
to
ensure
that
we're
not
we
need
to
create
the
structure
for
the
iana
registry.
I
guess
is
what
I'm
trying
to
say
right,
yep,
so
so
gary,
I
think
to
me.
The
request
is
a
little
too
open-ended,
especially
because
you're
setting
a
timeline.
I
think
it
would
be
good
if
you
requested
the
specific
claims.
This
goes
back
to
lawrence's
question.
F
A
J
B
F
C
A
Yep,
okay,
so
we
are
well
out
of
time.
So
can
we
take
this
to
the
list
and
have
the
discussion
so
that
we
can
figure
out
the
way
forward
and
defining
our
iana
registry
yeah
in
the
cwt?
Yes,
okay?
So
with
that,
I
think
everyone.
I
guess,
given
that
we
completed
the
agenda,
we
I
will
go
ahead
and
cancel
the
thursday
session.