►
From YouTube: RATS Architecture Design Team Meeting, 2020-08-25
Description
RATS Architecture Design Team Meeting, 2020-08-25
A
A
A
B
B
Hi
everyone-
this
is
hank,
michael,
will
not
be
with
us
today.
C
B
A
Okay,
I
can
try
to
share
here.
Give
me
a
minute
thanks,
hi
dave
good
morning,
my
time.
D
A
A
B
B
B
In
here
right
now,
I
propose.
B
This
one
same
thing
on
fido
alliance:
yep
used
to
match
the
copyright
statements.
Okay
and
the
architecture
document
relying
party
is
capitalized
throughout
yep.
C
Here
all
right.
C
B
But
enough
hank
and
lawrence,
you
guys
want
to
discuss
lawrence's
response
here.
B
B
B
D
A
The
party
typically
in
the
architecture
these
are
at
the
station
results,
but
I
think
lawrence
wants
to
highlight
that
the
thing
that
is,
I.
A
Exactly
produced
by
whom
is
not
something
that
maps
to
an
arrow
in
the
red
architecture
here.
B
A
Hard
time
trying
this,
but
but
I
think,
that's
lauren's
just
so
I
had
read
what
lawrence.
What
you
said
here
is
that
it
was
an
attestation.
B
B
So
there's
there's
two
phases
in
fido:
there's
a
registration
phase
and
an
authentication
phase.
So
in
the
first
phase
there
is
an
attestation
result
and
the
outcome
of
the
registration.
B
Key
that
key
is
the
one
that's
used
to
sign
the
result
of
the
user
verification.
That's
why
I
don't
think
that
that
is
an
attestation
yeah.
It
kind
of
looks
like
a
not
in
the
document,
but
a
diagram
on
our
screen.
C
Would
help,
but
so
I'm
not
sure
if
I
thought
that
but
okay.
C
Just
it's
just
two
phases.
B
You
know
the
the
the
attestation
happens
once
kind
of
in
the
life
of
the
relationship
with
the
relying
party
where
the
authentication
happens.
You
know
multiple
times
every
time
the
user
logs
in
so
in
the
first
phase,
you're
saying
the
attestation
result
generates
a
key
and
then
the
key
is
used
multiple
times
after
that.
Yeah.
Yes,
yes,
yes,
so
in
the
expectation
result
it
includes
a
per
rely,
a
relying
party,
specific
key
that
it
gives
to
the
yes
and
maybe
other
stuff
too.
Yes,
okay,
got.
B
Map
to
the
current
interaction
modes
and
workflows,
and
and
which
is
then
again,
the
fido
add-on,
but
with
the
frosting
in
the
end
that
this
key
is
generated
and
used.
So
let
me
look
at
the
text
here
again
the
relying
party
to
know
that
the
authentication
is
trustworthy.
A
Back
up
okay,
so
it's
not
talking.
B
Attestation,
protocols
and
a
mechanism
by
which
new
ones
can
be
registered
or
added
attestation
is
thus
a
candidate
for
use
in
the
vital
protocol
yeah.
So
it's
I
don't
think
it
needs
to
go
into
the
details
of
keys
and
so
on.
Just
saying
among
the
things
that
it
does,
it
does
use
attestation
yeah,
basically.
B
C
A
If
you
think
brevity
is
more
key
than
the
comprehensibility.
A
B
B
Document
being
part
of
the
fido
alliance
or
part
of
the
ietf,
definitely
not
the
ietf.
Okay.
B
D
B
So
there
is
an
attestation,
so
we
can
use
the
the
results
of
the
remote
attestation
or
something
we
can.
We
can
right
here
where
my
comment
was
evidence
generation
before
and
and
but
I
would
like
to
see
an
example
use
of
that
output
so
that
you
know
what
problem
this
use
case
solves
effectively
and
if
you're
stopping
like
directly
before
the
finishing
line.
I
think
I
mean
like
that.
That's
that
this
this
is
to
split
it
up
here.
So
what
does?
B
C
B
Is
that
conceptual
message
that
message
highlighted
here
in
in
in
the
use
case,
not
with
the
term
conceptual
message,
because
it's
a
newspaper,
but
I
don't-
I
don't
find
it
whether
it's
right
or
not.
I
had
interpreted
that
lawrence's
text
is
saying
there
is
something
that
is
analogous
to
an
evidence
that
goes
to
a
verifier,
and
there
is
something
that
is
analogous
to
an
attestation
result
that
comes
from
a
verifier
to
a
relying
party
or
is
conveyed
in
some
way.
B
I
think
that
letter
is
not
true,
really
it
didn't.
Just
you
mean
for
for
purposes
of
the
authenticator,
okay
yeah,
yes,
okay
lawrence.
B
You
just
explained
that
there
are
two
steps:
two
phases
in
that
first
phase,
you're
gonna
send
some
stuff,
which
is
like
evidence
and
you're
gonna,
get
back
something
that
includes
the
device
that
sorry,
the
the
the
key
that
has
the
three
top
lines
or
whatever
the
three
tuple
specific
key,
and
that
three
sample
specific
key
is
in
the
equivalent
of
an
attestation
result
and
that
attestation
result
is
later
presented
to
a
relying
party.
If.
A
I
got
that
right,
yeah.
B
Yeah
I
mean
the
verifier
is
there's
no
separation
of
verifier
from
a
relying
party
here,
so
that.
A
A
Result
is
kind
of
internal
well,
okay,
so
you're
saying
it's
a
combined
verify
relying
party
and
the
verifier
is
the
part
that
generates
that
key.
A
B
C
B
B
C
C
And
yes,
you're
right
lawrence
that
the
same
suggestion
may
apply
to
other
use
cases
as
well.
C
That
we
may
want
to
do
something
similar
yeah
I'd
have
to
look
at
the
other
use
cases
to
see
if
any
of
them
have
verifier
or
how
they
handle
it
right
now,
yeah
and
I'm
looking
at
them,
and
I
don't
see
that
much
about
them
and
that
has
that.
B
Has
they
do
they
do
describe
the
message
flow?
Sometimes
I'm
trying
to
open
up
an
accepted
tab,
so
I
can
see
also.
A
B
A
And
this
one,
if
I
remember
right
this
one-
is
a
combined
relying
party
verifier
eric
yep
yeah.
I
think
that
is
correct,
so
this
one
would
have
to
also
be
verifier
slash,
relying
party
unless
technically
in
eric
in
your
document,
it
doesn't
have
to
be
in
the
same
device.
That's
just
typical
right.
You
could
have
a
separate
verifier.
A
Yeah,
absolutely
okay,
I'm
not
sure
if
this
is
really
stemming
from
eric's
document,
but
this
is
also
riv.
I
think
right,
yeah,
sorry
you're
right,
it's
a
guy!
Yes,
it's
also
both,
but
it
means
for
the
trusted
path,
and
this.
C
B
B
C
D
D
D
D
Oh
I'm!
I'm
sorry,
I'm
looking
right
if
I
got
the
right
screen.
No,
I'm
saying
you're,
probably
looking
at
the
right
one.
I
just.
I
can't
immediately
click
on
the
link
like
it's
supposed
to
be
here,
because
the
the
tools
site
didn't
generate
the
link
for
it:
okay,
okay,
so
yeah!
I
don't
see
a
test
verifier
in
three
there's.
Nothing
in.
B
Okay,
switching
back
all
right,
so
still
I
I'm
gonna
propose
this
one
and
that
we
then
have
to
do
something
similar
in
each
of
the
other
use
cases.
I
guess
I
should
ask
before
I
do
this
in
the.
D
I
mean
fido,
never
even
thought
about
it
in
that
way.
Okay,
so
got
it
yeah.
I
don't
think
it
really
requires
it.
No
okay,
then
maybe
this
isn't
the
right
way
to
solve
it
here.
Let
me
undo
this
for
a
second
and
see
if
I
can
look
at
anything
else,.
C
D
I'm
thinking
it
would
be
useful
to
just
expand
this
sentence
right
here
to
explain
you
know
in
each
of
these
cases
the
verifier
may
be
combined
with
a
ryan
party
or
in
some
cases,
maybe
a
separate
entity.
Something
like
that
here
as
a
separate
pr
and
then
I
don't
need
to
modify
any
of
these.
C
D
It
seems
good
to
me,
so
I
think
it
was
a
little
bit
excluded.
So
talking
about
the
the
thing
you're
creating
at
the
keys,
I
think,
is
not
wrong,
so
the
use
case
is
we
need
something
the
authentication
based
on
authentication
created
key
materials,
something
like
that,
and
so
that
is
the
thing
you
want.
B
In
the
end-
and
that
is
what
you
do,
you
do-
the
remote
association
evidence,
creation
or
generation
for
and-
and
I
think
I
understand
that
laurence-
if
I
understand
your
primary
goal
for
the
use
case-
is
to
allow
any
claims
used
for
rats
to
be
passed
in
the
photo
evidence
set
of
information.
As
for
a
key
recall
that
that
fido
can
reuse
any
claims
yeah,
but
also,
and
just
in.
B
D
D
Because
the
use
case
means
whatever
rats,
does
this
architecture
protocols
claims
whatever
could
be
used
in
this
use
case
right.
B
B
B
C
B
I
think
this
is
great
to
have
a
fido
use
case
in
here.
So
thanks
for
writing
this
out,
I
mean
the
other
way
to
look
at.
Maybe
is
it's
it's
a
it's
a
user.
It's
a
biometric
authentication,
use
case.
You
could
you
could
generalize
if
you
wanted
to
in
that
way,
because
because
the
you
know
ifa
and
wechat
pay
and
probably
whatever
apple's
doing
internally
probably
looks
pretty
similar.
B
All
right
hank,
what
do
you
think
I
am
fine
with
the
text,
as
is,
although
meaning
with
the
suggestion
that
I
haven't
mentioned
here,
which
is
as
long
as
it
has
attestation,
then
we
are
trying
to
be
consistent
in
this
document
using
the
word
remote
attestation.
A
Yeah
line
two
is
the
open
when
we
use
the
remaining
rotation
there.
Also,
I
was
on
the
wrong
line:
yeah
yeah,
so
there's
also
a
remote
decisions
on
there
yeah
three
three:
two:
oh
you're
right
employees
at
the
station
yeah.
I
didn't
do
the
suggestion
here,
but
I
said,
add
remote
into
that
exactly
yeah
yeah
remote
is
fine.
Okay,
so
let
me
take
some
thinking,
but
if
there
is
a
w3c
or
find
a
document
in
some
future
that
actually
makes
use
of
this
terminology
here.
That
will
be
awesome.
A
C
Think,
as
there
was
always
small
impetus
mismatch
here
about
the
about
the
understanding
how
fighter
really
fits
in
here,
I
I
I
think
it
would
not
hurt
to
be
as
explicit
as.
A
We
want
to
agree
and
can
be
here,
but
but
it's
fine,
if
you
want,
we
don't
want
to
mention
keys
here.
I
think
there
has
to
be
some
yeah
if
we
were
to
be
more.
B
If
we
were
to
be
more
explicit
it
would
be
to.
I
think
it
would
be
to
go
into
more
detail
of
the
mechanism
that
fido
has
for
plugging
in
attestation
mechanisms,
because
that's
that's
that's
fairly
interesting
and
unique,
and
that's
why
I
was
asking
if
there
was
gonna
be
some
other
document
that
would
have
that
glue,
because
I
think
that
would
be
more
appropriate.
Just
like
in
the
network
case.
We
have
the
other
documents
from
a
guy
and
eric
that
go
into
details
yeah.
B
I
I
believe
there
is
a
a
fido
registry
document
that
you
would
modify
to
hook
the
rat
space
data
station
and
say
something
like
you.
You
would
modify
the
phytoregistry
document
to
assign
it
an
identifier
and
that's
that's
this
part
where
you're
saying
it
has
a
mechanism
by
which
new
ones
can
be
registered
and
added
and
you'd
add
a
new
one
and
register
it.
C
C
B
Decisions
are
better
if
you
do
attestation
yeah,
that's
exactly
right,
peter
in
one
of
the
ietf
side
meetings
around
the
time
that
we
were
having
buffs,
I
had
made
a
conjecture
which
is
aligned
with
what
you
just
said,
which
is
that
the
claim
that
I
made
as
it
was
a
please
prove
or
disprove.
The
conjecture
is
that
every
authentication
use
case
is
an
attestation
use
case
yes
and
every
access
control
decision
that
a
remote
action
control
decision
isn't
at
the
same
kid,
because
it's
a
question
of
these.
B
So
in
fido.
The
thing
you
really
are
trusting
is
the
the
biometric
user,
verification
that
to
me
the
the
the
fact
that
it's
a
key
is
just
part
of
the
fighter
protocol.
It's
an
artifact
of
the
fighter
protocol,
the
the
thing
that
isn't
isn't
the
decision
there
really
the
decision
to
create
that
key.
B
C
Of
fido
yeah
there
is
a
user
verification
done
at
both
both
phases.
So
there
is
a
user
verification
done
when
the
key
is
created,
but
but
you're
right,
the
the
the
the
key
is
key.
Anyone
ever
said
that
before
so
all
the
use
cases
have
that
theme.
It's
just
a
question
of
of
calling
it
out
and
and
in
the
when
I
give
a
presentation
on
attestations
and.
C
Something
it
actually
says
that
point
about
the
you
know
it
makes
everything
any
existing
security
decision.
You
know
access
control,
authentication
better.
I
guess
my
question.
B
B
Of
sentences
of
text
that
says
that
that
would
be
a
pr
career,
because
otherwise
somebody
else
can.
But
if
you.
B
Getting
permission
to
do
that?
Okay,
okay,
so
I
I
I
I
could
do
it,
but
it's
gonna
be
slow
and
I'm
trying
to
work
that
problem.
C
So
we
can
have
a
more
you
know.
C
B
D
Have
any
problems
speaking
up
like
this,
but
right
now,
I'm
I
don't
have
all
the
permissions
in
place
just
to
for
me
to
volunteer
text,
no
problem,
all
right,
because
I
I
agree
that
that's
useful
to
point
out
and
I
would
like
to
put
it
up
here.
B
As
like
a
top
level
bullet,
you
know,
as
you
read
through
these
yeah
yeah
yeah.
I
think
all
right,
because
it
is
a
common
theme:
yeah,
yeah,
okay,
so
I'll
take
a
try
I'll
take
a
shot
at
it.
Okay,
thanks
laurence,
so
I've
added
a.
C
B
D
That,
okay.
D
These
so
far,
just
so
that
a
lot
of
these
things
collapse,
if
that's
okay
with
folks
the
ones
that
we've
got
okay.
B
D
D
B
B
B
Now
I
can't
get
the
everything
you
can
do.
Reds
can
do
better
out
of
my
head.
I
don't
know
why,
but
that's
the.
B
D
B
A
original
english,
okay.
D
Last
point
I
was
gonna
capture
was
details
would
be
in
a
dot.
B
B
Next,
michael's,
not
here,
do
people
want
to
look
at
131
or
wait
until
a
meeting
where.
A
The
content,
but
about
the
yammer
structure,
so
I
think
you
can
adjourn
this.
You
mean
wait
until
yeah.
Yeah
join
us,
maybe
just
long
time
so
yeah
all
right,
so
we've
got
three
of
the
complicated
ones.
Is
there
any
of
these?
We
want
to
spend
time
on
today.
A
So
on
on
the
privacy
considerations,
I
mean
I
wrote
that
to
try
to
help
help
out
here
I
don't
have
a
particular
big
agenda
on
it.
I
just
wrote
it
to
help
out
with
the
comments
that
kathleen
made.
I'm
I'm
willing
to
work
on
it,
some
more.
If
you
guys
want
to
want
to
kind
of
go
down
that
whole
thing,
but
it
was,
you
know,
a
substantial
rework
and
there
was
a
couple
people
that
liked
it.
C
B
Posted
it
on
the
list,
but
yeah
it
looks
like
there's
comments
from
people.
B
C
And
ned
and
I
see
comments
from
hank
and
now
yeah,
so
it
looks
like
all
of
us
have
reviewed
it
and
there
hasn't
been
changes
here.
So
it
looks
like
it's
not
ready
to
be
discussed
right
now,
unless
there's
some
question
that
you
have
lawrence
or
if
you
want
to
you,
want
to
continue
working
on
it
or
abandon
it
or
what?
What
are
you
thinking
right
now
I
mean
I
have
plenty
to
do
so:
I'm,
okay
abandoning
it
I
mean.
C
C
I
don't
know
there
may
be
something
in
here,
that's
useful,
but
I
can
see
some
at
least
that
was
just
a
wording
suggestion
and
a
word
in
suggestion.
So
there
are
some
issues
in
here.
B
Okay,
anything
else
you
want
to
talk
about
in
this
meeting,
because
otherwise.
B
B
A
So
I
have
some
some
questions
on
the
endorsements.
Actually,
we
can
also
look
at
issues
yeah.
We
can
look
up
94.
B
But
otherwise
I'll
go
back
to
the
issues
and
look
at
other
things
there
yeah.
So
I
I'd
actually
like
to
ask
individually
where
people
are
on
symmetric
keys
for
attestation.
That's
one
thing
I
can't
I
don't
have
a
read
on.
I
I
pretty
pretty
much
have
an
idea.
What
ned
thinks
he
seems
to
be:
okay
with
symmetric
keys,
but
dave
and
hank,
I
don't
know
michael
seems
to
be
opposed
to
them.
B
C
Attestation
hmac:
no,
I
don't
know
what
it
mean,
what
you
use
them,
how
the
attestation
key
the
the
annotation
key
material
that's
put
into
the
a
tester
is.
C
C
Into
a
device,
yeah
is
a
symmetric
key.
Yes,
and
it's
symmetric
between
what
the
manufacturer
and
the
device
is
that
it's
the
key,
the
key
used
to
sign
out
of
station
evidence.
I
understand,
but.
B
B
And
the
tester
yes
yeah,
I
don't
see
any
problem
whatsoever.
It's
just
a
question
of
policy
at
the
appraisal
end
if
you're,
okay
at
the
appraisal
end
with
a
key,
that's
been
symmetrically,
so
you
have
to.
A
B
Can't
necessarily
do
is
you
can't
assume
that,
since
it's
shared
that
there's
not
a
proof
that
it
came
from
one
end,
because
it
could
have
come
from
technically
either
end
because
it's
sheer,
but
in
that
sense
it's
like
just
a
special
case
where
the
identity
is
two
which
is
often
like
they're.
The
verifier
themselves
case.
C
Two
of
the
what
we
call
the
daa,
the
anon,
the
anonymous
attestation.
You
can't
tell
for
sure
you
just
know
it's
one
of
them.
It's
just
a
trivial
special
case.
C
You
don't
get
any
special
trust
in
a
asymmetric
key,
because
you
have
to
worry.
C
D
Is
never
going
to
happen,
you're,
making
a
decision
outside
of
the
fact
that
it's
an
asymmetric
key
all
right,
so
you
didn't
get
anything
extra
for
having
an
asymmetric
key
by
putting
it
in
the
firmware.
You
know
it
was
a
great
metric
that
was
put
in
there.
I
disagree
because
if
you
have
a
symmetric
key,
that's
in
there
at
least
as
long
as
the
symmetric
key
is
shared
between
two
places.
Then
you
know
it
had
to
have
come
out
of
there
with
an
asymmetric.
C
D
You
can
have
a
guarantee
that
it
never
came
out
of
there
in
the
first
place.
It
never
went
into
there.
It
started
in
there,
but
where
was
that
key
used
and
how?
Where
was
that
key
exposed
and
could
that
key
have
been
extracted
somehow
because
of
a
trust
issue
in
that
device?
So
it's
not
by
virtue
of
it
being
an
asymmetric
key.
It's
by
virtue
of
you,
believing
that,
where
that
asymmetric
key
is
used
is
safer.
D
D
You
don't,
and
so
an
asymmetric
key
can
be
strictly
stronger
than
a
symmetric
key
as
far
as
the
the
level
of
traffic,
but
the
asymmetric
key
has
a
protocol
that
was
used
to
generate
the
key,
that's
being
used
for
the
session,
and
so
it
really
is
not
the
private
sector
but
you're,
assuming
that
that
private
key
is
not
available
or
it's
a
good
quality
private
key
and
there's
lots
of
assumptions
that.
C
B
Other
qualities
of
it
right,
but
I'm
saying
there's
one
quality
this
that
is
demonstrably
better
right,
which
is
the
part
that
you
don't
have
to
have
any
way
of
extracting
it
or
inserting
it,
and
so
all
other
things
being
equal.
That
one
is
is
a
significant.
C
D
Why
I
think
that
it
doesn't
really
matter?
It's
really
the
other
issues
outside
of
the
key
technique,
and
I
think
one
of
the
things
about
the
asymmetric
keys
is
that,
given
that
some
of
the
assumptions
that
we're
making
about
the
environment
are
not
really
valid,
the
asymmetric
key
gets
benefits
based
on
the
kinds
of
things
you're
saying.
B
Back
to
the
maybe
they're
being
equal,
except
for
those
finishes
so
to
lawrence
your
question,
I
don't
think
I
have
any
inherent
problems
with
symmetric
keys.
If
that
answers
your
question,
yeah,
okay,
hank
yeah.
I
think
the
architecture
tries
to
be
agnostic
of
that,
and
that
is
good,
but
I
have
not
skimmed
for
asymmetric
in
the
text
right
now,
so
I'll
make
them
full
text.
Search
no
and
asymmetric
is
not
in
the
text.
So
yes,
I
think
the
type
of
key
used
is
out
of
scope
here.
B
Actually,
I
think,
therefore,
semantics
are
totally
fine.
Also,
yes,
there
being
some
bigots
where
symmetry
has
some
overload
or
some
some
overhead
to
be
done,
because
you
have
to
create
symmetry
asymmetric
keys,
have
some
logistical
advantages
that
might
be
interpreted
as
being
more
a
trustworthy
or
higher
security
assurance
or
something.
But
in
the
end
I
think
the
type
of
key
material
does
not
play
any
role
here
as
long
as
you
treat
it
appropriately
right.
So
I
agree
with
hank's
point
that
it's
that
the
type
of
key
is
actually
out
of
scope
for
this.
C
The
the
one,
whether
it's
a
group
shared
key
or
a
private,
sorry
a
asymmetric
pair
or
a
symmetric
key.
I
think
that
level
of
detail
should
be
out
of
scope.
I
I
I'm
convinced
by
hank's
argument
yeah.
I
I
just
try
to
I'm
just
trying
to
understand
what
people
think,
because
I
I
I
don't
really
know.
Sometimes
I
don't
know
without
asking.
So
that's
you
know,
don't
don't
jump
to
the
conclusion
of
what
I
want
to
put
in
the
document.
C
So
the
one
so
so
then
there's
one
other
aspect
here
is
you
know
it
can
be
that
the
verifier
talks
to
the
endorser,
the
key
is
not
actually
transferred,
but
what
happens
instead
is
the
endorser
runs
a
verification
service.
C
So
basically
the
the
key
identifier
and
the
hash
go
to
the
endorser
and
then
the
endorser
doesn't
let
the
keys
lose.
Doesn't
let
the
verifier
have
the
keys.
Instead,
he
just
gives
a
result
and
says
yeah
that
signature
verifies.
So
it's
a
sort
of
a
signature
verification
service.
Then
I
would
say
it's
not
an
endorser,
it's
a
verifier
yeah,
but
it's
provided
by
the
endorser.
So
now
the
endorse
it's
not
provided
by
the
endorser,
it's
provided
by
the
same
entity
that
provides
the
endorser.
Yes,
sorry,
yes,.
A
Yes,
but
it's
not
part
of
the
endorser
role,
the
endorser
role
is
something
that
just
endorses
things.
It
doesn't
actually
provide
attestation
results,
yeah,
the
two
things
the
attestation
service
and
the
endorser
are
two
roles
that
are
in
the
I
don't
know
upstair
by
bureaucracy
they
they
are
not
none
less
volatile
than
the
attackers
and
the
republican
party,
the
difference
in
the
roles.
Again,
I'm
purely
talking
about
terminology.
C
The
difference
in
the
roles
is
that
the
verifier
is
the
that
the
endorser
never
sees
the
current
values
of
claims.
The
verifier
does.
If
it
sees
it,
it's
called
a
verifier.
If
it
doesn't.
D
See
it
if
it's
just
saying
I
vote
for
the
following
key
so
for
exa,
a
typical
endorsement
would
be.
I
have
a
manufacturer's
key
or
something
like
that
that
then
vouches
for
the
key
embedded
in
the
attester
right.
That
would
be
an
endorsement.
An
endorser
just
provides.
I
endorse
the
following
key
and
and
metadata.
If
it
exists,
I
can't
see
the
current
state,
but
I
endorse
the
following
key
and
some
potential
claims
about
that
device.
C
C
D
The
relying
party
is
doing
another
part
of
the
of
the
verification
yeah.
I
think
that's
accurate
another
example
where
you
could
have
verifiers.
Let's
say
you
have
a
layered
attestation
or
a
composite
device
at
that
station.
We
have
multiple
claim
sets
in
the
evidence.
You
could
have
a
different
entity
that
does
the
verification
for
each.
D
D
C
Complicated,
especially
since
we
have
cases
with
multiple
claim
sets
and
the
evidence
just
like
you
know,
layered
attestation
and
composite
device,
or
you
know
composite
tester
type
stuff,
and
so
you
can't
have
complicated
stuff
on
the
verifier
side
too.
Just
like
we
talk
about
the
document
complicated
stuff
on
the
tester
side,
yeah,
okay,
so
then,
my
next
question
is
back
to
symmetric
keys
is
so,
I
believe,
endorsements
have
to
be
confidential,
sometimes
because
of
the
symmetric
keys.
C
So
they
can't
just
they
can't
just
be
a
signed
document.
They
have
to
have
confidential
confidentiality,
sometimes
because
you
keep
saying
sometimes
I
think
I
buy
your
argument.
Yes,
like
I
would
say,
that's
a
very
much
a
use
case
dependent
question
of
whether
or
not
any
of
these
communications
have
any
confidentiality
concerns.
C
So,
if
you're
going
to
have,
let's
say
a
attestation
that
provides
a
lot
of
detail
about
the
system
from
top
to
bottom.
A
In
other
cases,
maybe
you
don't
especially
if
it's
something
that's
a
a
commodity
device
that
you
don't
gain
any
extra
information
from
keeping
that.
So
why
go
through
the
cost
of
keeping
that
secret
so
part
of
the
use
case
that
you're
you're
defining
wherever
you're
using
the
attestations.
You
have
to
look
at
all
the
different
communications.
B
B
D
B
A
You
need
to
introduce
yourself.
Yes,
there
may
be
different
things
that
you
might
might
be
only
doing
one
and
not
in
the
other,
and
so
there's
a
lot
of
different
variability
in
the
question
that
you
asked.
That
can
only
be
answered
in
the
context
of
the
use
case
right,
but
the
document
goes
into
confidentiality
in
lots
of
different
places,
for
lots
of
different
reasons
already
and
here's
the
sentence
that
that
says
peter
what
you
just
said,
and
at
least
one
person
said
they
were
just
on
the
phone.
Many
claims
and
attestation
evidence.
B
B
Yeah
but
it
doesn't
say
what
I
was
saying,
which
is
that
you
need
confidentiality
for
the
key.
Well,
the
key
is
not
really
part
of
the
opposition
confidence.
I
mean,
I
think
in
general,
you're
saying
that.
D
Used
it
needs
to
be
protected
and,
if
you're
going
to
ever
pass
that
key
over
some
sort
of
wire,
it
needs
to
be
protected.
So
that's
a
confidential
concern
on
the
use
case
of
cryptography,
not
so
much
how
to
efficient
yeah.
I
think
lawrence
a
better
way
to
phrase.
I
think
what
your
question
is
right
is
the
current
privacy
considerations,
text
talks
about
evidence
and
attestation.
C
Results
and
includes
discussion
of
confidentiality
of
attestation,
evidence
and
attestation
results.
Okay,
but
you're,
pointing
out
that
there's
no
text
in
the
privacy
section
that
mentions
endorsements
and
I
think
what
you're
getting
at
is
to
what
extent
should
endorsements
be
mentioned
in
the
privacy
considerations
section.
I
think
that's
the
question,
you're
implicitly
asking
you're
talking
about
a
use
case
where
it
sounds
like
you're
thinking
that
an
endorsement
includes
a
key
itself,
I'm
not
sure
that's
the
case,
but
I'm
not
sure
it
actually
needs
to
be
the
case.
C
You
may
still
have
a
valid
question
about
whether
there's
anything
in
an
endorsement
that
might
be
considered
private
information-
and
maybe
there
should
be
some
mention
in
here
about
you
know
in
some
cases
endorsements
themselves
may
have
some
information
in
it.
That's
that
might
be
considered
pii.
You
know
if
you're
endorsing
a
particular
device
with
more
information
the
endorsement
than
some
other
device
based
on
you
know
the
identity
of
who
purchased
it
or
something
like
that.
Then
it
might.
C
If
you
were
doing
that
in
the
use
case,
then
you'd
have
some
confidentiality
issues
potentially
with
that
use
case,
and
so
it
might
be
use
worth
mentioning
endorsements
in
here.
If
that's
what
you're
getting
at,
I
think
it's
still
bigger
and
maybe
needs
some
sorting.
B
Trust
flow,
primary
trust
flow
being
about
establishing
trust
in
the
device.
That's
the
classic
attestation
problem,
secondary
trust
flow
being
about
confidentiality
on
all
the
different
arcs
in
the
diagram
and
there's
there's.
If
you
look
at
the
trust
section
of
the
document
and
you
can
sort
all
the
paragraphs
into
either,
are
they
discussing
primary
trust,
flow
or
secondary
trust
flow,
or
this
and
secondary
one
being
about
confidentiality?
B
D
That
I
you
know,
maybe
I'll
write
some
text
for
I
I
don't
know,
but
I
I
think
I
think
that
that
you
kind
of
need
to
look
at
each.
You
know
each
message
flow
and
look
at
at.
C
It
for
both
the
confidentiality
and
for
the.
B
We
should
not
imply
it.
I
think
that's
why
you're
hitting
it.
We
should
make
it
explicit,
and
I
think
it's
relatively
obvious-
that
every
use
cat
can
mandate
some
obfuscation
for
a
conceptual
message,
because
it
is
confidential
and
right
and
just
just-
but
you
know
there
there's
a
lot
of
text
in
there
about
this
confidentiality
and
establishing
trust
before
you
know,
so
you
can
have
a
have
the
confidentiality
there's
a
lot
of
text
in
their
paragraphs
and
paragraphs
of
it
I
mean.
So
what
you're
really
advocating
is
a
a.
B
B
B
Question
lawrence,
I
I
think
so
you
got.
D
Yeah,
so
I'm
I'm
I'm.
I
think.
B
I
have
enough
information
now
to
propose
a
change.
Some
some
text
to
run
endorsements,
to
address
the
things.
B
To
address
you
know,
my
my
sense
is
that,
well
your
your
your
insight
that
we
can
split
the
verifier
that
that's
really
helpful
in
reframing.
D
Endorsements
for
me,
okay,
so
what
you
want
to
think
about,
I
think
as
well,
is
in
you
know
the
classic
confidentiality,
integrity
and
availability
aspect
of
all
these
pieces
that
need
to
happen
for
an
attestation
to
be
successful.
Where
do
each
of
the?
Where
does
confidentiality
fit
in?
Where
must
integrity,
be
yeah
question
and
when
must
things
be
available
as
well
yeah,
if
you
can.
A
C
C
B
B
Enough
right
now.
B
C
A
On
that
particular
point,
I
don't
understand
why
an
endorsement
would
ever
carry
a
symmetric
key.
I
could
understand
why
it
might
carry
some
type
of
a
key
identifier,
but
not
the
key
itself,
because
we
have
attestation
provisioning
processes,
and
these
are
out
of
scope
today,
but
the
arrow
from
the
endorser
to
the
verifier
would
at
some
point
have
used
also
for
provisioning
and
then
keys
would
be
flowing
down
that
edge
of
the
graph.
But
at
the
moment
I
think
I
disagree
with
that.
A
Yeah
again,
this
gets
back
to
the
the
question
of
the
attestation
is
about
some
trust
decision
being
made,
the
mechanics
of
installing
a
key
or
something
like
that
is
really
another
kind
of
use
case
inside
the
attestation
mechanism.
Yes,
yes,
I
agree.
It
is
the
key
provisioning
is
not
part
of
the
endorsement
itself.
A
Yes,
but
but
taking
on
lauren's
point
of
view
again,
if
he
looks
sorry
I'm
putting
what's
in
your
mouth
so,
but
what
I
think
when
lawrence
looks
at
the
diagram,
there
is
an
arrow
between
endorser
and
verifier
and
at
some
point
due
to
provisioning
on
this
arrow
keys
travel,
but
not
with
us
with
honda
and
today,
and
so
lawrence
is
worried
that
this
is
out
of
scope.
But
no,
it
is
not
it's
just
another
semantics
put
through
that
arrow.
A
When
we
come
to
the
attestation
provisioning,
rechartering
yeah,
again,
I'm
going
to
make
it
my
terminology
point
here,
which
is
that
the
key
provisioning
does
not
come
from
the
endorser.
The
key
provisioning
may
come
from
the
same
entity
that
runs
the
endorser,
so
just
like,
we
have
you
know
verifier
opener,
that
supplies
the
policy
and
maybe
the
endorser
owner.
That
puts
it
into
say
the
verifier
or
something.
But
it's
not
the
endorser
role.
So
it's
like
the
difference
between
the
purifier
owner
and
the
verifier.
A
I
agree
at
all
with
that
and
I'll
go
one
step
further
and
say
that
it
may
involve
a
little
attestation
unto
itself
that
you
know
that
in
order
to
provision
the
key
you
may
want
to
provision
one
of
our
attest
to
that
device,
which
is
not
the
whole
reason
you're
doing
that
decision
in
the
greater
use
case.
A
So
I
I
think
key
material
and
nonsense
are
the
two
most
critical
things
in
all
of
ata
station.
You
can't
do
attestation
without
key
material
and
the
knots
you
could
do
you
can
have
no
claims,
but
you
or
you
or
the
claim
is
just
one
claim.
That's
a
not
so
I
believe
discussion
of
the
key
material
needs
to
be
in
there.
We
have
pages
and
pages
of
discussion
on
nonsense
already.
A
My
sense
is
that,
because
tpms
come
with
keys
that
there's
some
you
know
need
to,
you
know
less
need
to
discuss
them,
but
in
the
te
world
and
in
the
some
of
the
iot
worlds,
the
the
key
setup
is
still
a
big
deal.
A
So
so
I'm
saying
that
the
keys
come
from
the
verifier
owner,
not
the
endorser.
Now
you
talked
about
a
case
in
the
a
minute
ago,
where
there's
a
verifier
that
might
be
more
complicated.
This
might
be
two
layers
of
verifier
and
one
is
actually
run
by
the
same
organization
that
doesn't
runs
the
endorser,
and
so
it's
that
secondary
verifier,
that's
kind
of
sitting
over
here.
That's
a
verifier
owner
of
that
other
verifier
that
configured
that
does
the
key
provisioning
to
that
other
verifier
by
the
same
entity
that
runs
the
endorser
or
whatever.
A
But
it's
not
part
of
the
endorsements
line.
As
part
of
a
key
provisioning
line
that
comes
from
the
verifier
owner
to
the
verifier,
that's
not
shown
all
of
these
have
a
key
provisioning
line
that
comes
into
h63.
They
keep
provisioning.
Why
isn't
showing
right
now,
because
everything
has
a
key
provision,
how
I
get
it
again?
That's
a
terminology!
I
heard
that
perspective
and
I
think
what
might
complicate
it
is.
A
If
you
have
some
sort
of
proprietary
manufacturing
protocol,
that's
developed,
it
might
blend
some
of
those
lines
together
in
whatever
protocol
is
created,
and
you
know
that
might
be
good
or
bad.
But
it's
it's
common
to
have
keys
in
the
endorsement
right.
A
Does
it
have
a
public
I'd,
say
it's
common
to
have
key
ids?
In
some
cases,
the
key
id
may
in
fact
be
a
public
key,
but
certainly
come
and
have
a
key
id.
I
don't
know
that
you
need
the
full
key
like
endorsement.
May
just
have
the
key
fingerprint
or
something
in
there
just
depends
on
what
your
protocol
is.
A
You
know,
for
example,
the
endorsement
might
be
as
simple
as
I
take
my
endorser
private
key.
I
generate
a
certificate
that
signs
the
attester's
public
key,
but
then
I
don't
put
the
public
key
in
there.
I
put
the
key
the
public
key
fingerprint,
because
I
can
press
that
out
and
the
endorsement
is
a
certificate
or
certificate
chain.
Maybe
well
certificates
have
public
keys
in
them,
that's
really
common
yeah
and
then
in
theory,
your
protocol
might
compress
it
out.
If
the
public
key
is
obtained,
it
can
be
looked
up
from
the
key
id.
A
I'm
just
saying
that
depends
on
the
protocol,
so
yeah
hash
of
pub
key
is
quite
common.
Resolution.
Services
would
even
be
endorsers,
probably
yep.
Well
say
that
again
sorry,
the
the
resolution
service
will
be
provided
by
the
entity.
That's
also
writing
and
also
I'm
trying
to
use
yeah.
That's.
A
Better,
some
organizations
maintain
lookup
services
that
given
a
key
id,
they
will
return.
The
public
key
intel
is
an
example
of
an
organization
that
does
that
that
then
they
call
it
the
pck
service.
If
I
understand
the
terminology
right,
and
so
you
can
say,
here's
this
thing
and
I
can
get
back-
you
know
the
endorsement
of
the
search
chain
or
whatever
for
that
giv.
A
Okay,
I
think
the
thing
to
bring
it
back
to
the
attestation
is
that
this
is
all
implementation
detail
for
use
case,
on
particular
attestations
and
aside
from
the
fact
of
saying
that
you
know,
there's
quality
of
endorsements
and
things
like
that.
We
shouldn't
be
talking
about
the
low-level
mechanisms,
because
there's
so
many
different
ways
that
it
could
be
doing,
and
it
would
be
wrong
to
prescribe
a
particular
way
that
we
think
it
ought
to
be
yeah
we're
not
describing
if
we're
trying
to
take
into
account
the
different
angles.
A
I
wanted
to
cross
very
popular
solutions
that
are
on
this
table
right
now.
So
I
think
that
is
more
like
we
are
talking
about
the
deep
life
here.
It's
not
about
being
prescriptive
but
being
inclusive
and
not
pushing
them
out
by
an
arbitrary
tax
decision.
Yeah
right
and
it's
about
somebody
reading
this
trying
to
figure
out
where
the
keys
are
flowing,
because
the
keys
are
so
important
and
if
someone
doesn't
unders,
you
know
doesn't
understand
all
of
these
details.
A
Yeah,
we
didn't
have
progress
with
the
document
as
much
as
we
could,
but
I
think
this
was
something
that
was
bugging
quite
a
few
attendees
and
I
think
it
was
worthwhile
to
speak
this
out
loud
and
give
author
lawrence
a
chance
to
address
this
three
items
that
he
really
wants
to
have
addressed
here,
because
I
think
this
is
worthwhile.
In
the
end,
it
will
create
better
text,
but
probably
next
time,
yeah
yeah.
Definitely,
okay.
We
need
to
wrap
up
guys.
Okay,
that's
fine!
Yeah!
All
right
talk
to
you
next
week,
yeah
see
you
next
week.