►
From YouTube: IETF106-RATS-20191119-1520
Description
RATS meeting session at IETF106
2019/11/19 1520
https://datatracker.ietf.org/meeting/106/proceedings/
B
C
A
A
We're
just
going
to
continue
so
welcome.
Do
we
have
any
new
attendees
in
the
room?
Nope?
Okay,
so
everybody
is
knowledgeable
about
the
note
well
with
the
IPR
issues
and
and
the
code
of
conduct
as
I
say
so
moving
on.
Let's
do
the
administrative
tasks,
so
I
would
like
to
thank
Peter
still
here.
Yes,
so
I
want
to
thank
Peter
for
for
taking
notes.
I
did
set
up
an
ether
pad,
so
I
would
encourage
everyone
to
help
with
the
taking
of
notes,
as
we
are
going
to
have
good
discussions
that
I'd
like
to
have
captured.
A
So
besides
Peter
who's
going
to
be
taking
notes,
offline
can
I
at
least
have
one
other
volunteer
and
would
love
it
if
they
were
using
the
ether
pad
and
I
also
need
a
jabber
scruggs
good-ass,
yes,
okay,
so
I
cannot
move
forward
unless
I
have
one
more
note
taker.
Please
thank
you.
Michael.
Will
you
use
the
ether
pad.
A
A
With
respect
to
the
agenda,
I
have
a
little
bit
of
time
here
just
to
go
over,
so
we
have
a
pact
to
two
sessions
this
week,
I'm
not
going
to
show
the
session
for
Friday,
but
for
today
we
are
going
to
focus
mainly
on
eat,
with
a
little
bit
of
the
conversation
on
Gary's
proposal
on
quests,
which
I
can't
remember
what
the
acronym
stands
for,
but
he
will
describe
that
to
us.
So
are
there
any
objections
for
the
agenda
or
additions?
A
A
D
D
So
the
first
30
minutes
of
this
is
basically
when
is
eat
done.
So
this
is
a
four
kind
of
largest
largest
claims
that
are
areas
of
claims
we
could
add
to
eat.
So
this
is
about
kind
of
future
work,
the
the
after
that
there's
50
minutes
or
40
minutes
about
open
issues
with
the
existing
claim.
So
the
first
parts
proposals
for
new
claims
second
part,
is
working
on
issues
for
some
of
the
existing
claims
in
the
document.
D
Alright.
So
so,
when
is
he
done?
When
do
we
have
enough
claims?
I
think
the
answer
is
kind
of
never,
and
in
that
there
will
always
be
an
INR
registry
for
adding
claims,
and
so
the
question
is
really:
when
do
we
take
the
current
eat
document
and
call
it
done?
You
know
what,
if
the
set
of
claims
we're
gonna
put
in
the
current
eat
document,
because
it
will
always
be
the
opportunity
to
add
documents
later
on,
other
working
groups
can
add
claims
people
can
create,
create
file,
claims
with
Diana
and
and
so
on.
D
D
So
I'm
going
to
describe
the
way
I
want
to
run.
This
is
I'm
going
to
describe
four
areas
or
four
claims
and
I'm
just
going
to
talk
through
all
four
of
them
and
then,
after
that,
I'd
like
try
and
leave
about
10-15
minutes
for
discussion,
about
which
ones
we
think
are
good
and
which
ones
which
ones
are
the
higher
priority,
which
ones
are
the
lower
priority
I'm
only
describing
them
in
a
conceptual
layer,
conceptual
level
to
try
and
understand.
D
If,
if
this
is
something
we
want
to
pursue,
there's
no
there's
little
bits
of
work
done
on
them
here
and
there,
but
there's
not
like
a
pull
request.
Requests
our
proposal
for
these
alright,
so
here's
one
proposed
is
that
we
eat
be
able
to
carry
the
attestation
result.
You
know
so
the
there's,
the
attestation
evidence
that
comes
from
the
attest
ere.
It
goes
to
the
verifier
and
then
the
verifier
outputs,
an
attestation
result.
D
What's
the
format
of
that
can
that
be
eat
and
maybe
the
output
is
eat
even
when
the
input
is
yang
and
comes
from
a
teepee,
the
interaction
is
yang
and
comes
from
a
TPM.
Maybe
the
input
is
is
eat
and
all
that
the
the
verifier
does
is
verify
the
signature
and
says
yeah
I
checked
the
signature,
lots
of
different
ways
of
going
about
this
here
there
may
be
implicit
claims
just
because
we,
you
know
something
was
signed
by
a
particular
key
and
was
known
to
be
from
a
particular
piece
of
hardware.
D
Then
you
might
know
some
other
things
about
that
that
the
verifier
might
not
have
insider
knowledge
or
special
knowledge
about
that
that
so
they
can
add
extra
claims
and
into
the
the
attestation
result.
Basically
making
implicit
claims,
explicit,
I
think.
Another
thing
that's
really
interesting
for
here
to
be
done
here
is
the
verifier
knows
the
known
good
values
of
the
measurements,
so
that
the
verifier
can
look
at
the
look
at
the
input
and
then
translate
the
measurement
values
into.
Yes,
everything
verified,
it's
good,
I
think
another
one.
D
You
know
if
the
verifier
I
mean
we
can
imagine
a
lot
of
different
verifiers.
One
might
be
just
for
our
manufacturer.
There
might
be
also
aggregate,
very
fair
fires
that
work
across
lots
of
different
devices.
If
it's
an
aggregator,
then
you
could,
the
the
certification
result
becomes
more
interesting.
So
there's
a
lot
I
think
there's
a
lot
to
that
can
happen
here
and
I.
Don't
see
Hank
in
the
room.
I
would
imagine
he
would
have
a
lot
to
contribute
about
this,
but.
A
D
E
E
E
E
G
G
D
D
We
put
the
public
key
in
as
a
claim
you
might
put
in
some
conditions
about
how
the
key
was
generated.
For
example,
you
could
say
this
jet
this
key
was
generated
and
inside
a
te
you
might
have
conditions
governing
use
of
the
key
like,
for
example,
in
the
Android
key
store,
there's
a
bunch
of
characteristics
that
say
when
the
key
is
usable
and
when
the
key
is
not
whether
authentication
is
required.
What
kind
of
authentication
so
there's
a
lot
of
put
a
lot
of
conditions
in
governing
the
the
use
of
the
key.
D
So
we
would
need
some
sort
of
a
something
to
hold
the
public
key,
there's,
probably
a
Jose
and
Jose
types
already,
for
you
might
want
proof
of
possession
or
you
might
not
want
group
of
possession.
If
you
follow
that
link
there
you'll
get
go
see
the
three
dozen
characteristics
Android
has
four
are
key
that
was
generated.
Some
of
them
are
sort
of
the
same
as
claims
we
already
have.
Some
of
them
are
different.
D
D
Claire,
just
clarifying
so
the
setup
here
is
we're
going
through
the
going
through
the
four
four
areas
first
and
then
we'll
get
opinions
about
whether
we
want
to
which
ones
we
want
to
pursue.
It's
so
not
a
detailed
design,
because
that's
presumably
we'll
jump
in
to
the
detail
design
after
we
decide
which
ones
we
want
to
do.
Yeah.
Thank
you.
D
So
so
the
software
inventory
I've
had
a
number
of
people
comment
about.
You
know
that
there
should
be
software
inventory.
That's
kind
of
a
major
basis
of
trust
that
this
this
suffer
inventory
is
it's
a
list
of
software.
It's
not
the
same
as
a
verification
of
the
software
like
you
might
get
out
of
TPM.
It's
just
a
list
of
software,
so
you
might
have
the
name,
the
file
path,
type
of
software
version
vendor,
maybe
some
measurements.
D
D
D
I
D
So
you
could
do
this
once
every
day
or
once
every
two
hours
or
once
every
month
and
because
of
architectures
like
t
e's,
you
can
do
stuff
like
that
that
the
TPM
can't
do
to
go
further.
There
are
architectures
where
you
do
the
runtime
check
and
the
te
or
whatever
is
knows
the
expected
values.
So
the
result
reported
is
yeah.
There
was
integrity,
you
don't
have
to
actually
go
all
the
way.
Have
the
known
good
values
the
verifier
doesn't
have
to
know
the
known
good
values,
because
the
te
knows
it.
D
So
these
are
a
couple
of
different
styles
of
integrity
and
measurement.
They
may
not
be
all
of
them,
but
there's
a
some
some
examples
here
that
are
a
little
you
know
from
different
different
places.
So
why
do
we
do
this?
I,
probably
don't
have
to
say
too
much.
Your
TPM
is
widely
used.
Samsung
has
a
product
called
timo,
that's
part
of
knox
that
does
the
runtime
part.
I
think
it's
also
interesting,
because
TPMS
can't
do
the
runtime
integrity
checks,
so
adding
the
runtime
integrity
check
as
another
way
of
doing
it
is
I.
D
D
Maybe
there's
too
many
different
variants.
Here
we
can't
find
a
small
enough
set
of
measurements
games,
I,
think
the
last
one
is
probably
the
most
interesting.
How
do
we
find
the
common
ground
between
the
TPM
and
the
non
TPM
worlds?
I
know
my
conversations,
don't
always
ground
out
or
close
out
when
I
have
what.
H
D
E
D
D
J
So
proof
recession
is
the
mechanism
to
demonstrate
that
you
know
the
private
key,
but
and
maybe
of
course
it's
not
exactly
the
hoops
that
was
a
coffee
cup,
yeah
sort
of
Android,
the
Android
based
I'm,
not
sure,
but
but
the
keys,
the
keys
that
in
general
quite
generic,
but
have
a
look
at
that
because
I,
because
that
has
been
used
in
other
contexts.
So
it
may
be
useful
to
yeah
I
would
expect
there's
a
lot
of
reuse,
possibility.
Yeah.
H
So
this
is
Hank
again
and
I'm
very
sorry
to
say
this
is
take
some
some
pain,
but
there
is
actually
a
defined
format
for
public
Europe
of
a
raw
public
here,
representation
for
DTS-
and
it
is
literally
defined
in
I-
have
to
look
at
my
succeeded,
yeah
exactly.
It
is
seven
to
five
Oh
section
three.
It
is
a
must.
Unfortunately,
it's
a
part
of
a
certificate
cut
out
of
there
without
context,
and
it's
awful
it's
like
the
Papa
key
info
part,
but
that's
how
the
start
is,
and
it
is
not
a
pure
value.
H
So
again,
oh
yeah,
it's
it's
two
asn.1
items
in
a
block
without
context,
so
that
is
the
standard
for
values
for
raw
public
use
for
DTLS,
so
I
think
for
advice.
We
are
pretty
much
set
there
and-
and
this
is
for
being
confused
or
true,
being
okay,
good
I
know.
It's
comment
on
this:
putting
an
ASM
value
into
a
CBO
structure
is
it's
gonna
happen.
I
know.
H
K
L
Think
they
are
I,
can't
keep
all
four
of
them
in
my
head,
but
I'm,
probably
yes
and
all
four
of
them,
but
I
can't
keep
them
my
head
as
I
can't
say
for
sure,
but
I
have
a
clarifying
question
about
the
difference
between
number
three
and
number
four
meaning
I.
Think
I
understand
the
difference,
but
I
don't
know
if
I
understand
it.
If
you
keep
on
that
one,
the
fourth
one
is
about
what's
running:
is
this
one
actually
about
what's
installed,
regardless
of
whether
it's
running
or
is
this
one
about?
L
L
A
L
L
A
I'm
hearing
is,
we
need
clarification,
so
Ned
was
in
the
queue,
so
I'm
gonna,
let
yeah.
M
M
A
M
Clarification
typically
a
coast
would
structure
is
something
that
describes.
You
know
reference
values,
and
so
that's
something
that
a
vendor
manufacturer
would
be
able
to
assert
if
we're
talking
about
it
in
the
context
of
evidence
that
an
a
tester
would
would
create
the
you
know,
what's
the
use
case
context
for
why
or
how
an
eye
tester
would
be
able
to
make
make
that
assertion.
N
F
Hi
Kathleen
hi.
Oh,
can
you
hear
me
yes
great?
So
this
originated
with
me
with
a
review
of
the
coast.
Wit
document
and
I
was
discussed
this
morning
in
sockem
and
essentially
Coast.
Wait
is
currently
defined
to
just
apply
a
cosy
signature
and
in
reading
the
document
it
seems
like
having
a
software
vendor
be
able
to.
Instead
do
a
cot.
F
Cwt
seem
to
make
more
sense
and
you
might
get
more
adoption
and
uptake
where
you'd
have
the
signature
and
claims
and
something
that
developers
may
become
very
used
to
just
seeing
that
a
cot
is
used
as
opposed
to
having
to
look
at
the
structure
of
the
signature
and
apply
it
more
directly
from
code,
which
I
think
will
be
more
of
a
one-off
than
using
an
e
or
cot.
So
you
would
get
additional
claims
in
addition
to
the
the
signature
and
it
would
be
from
the
vendor.
A
H
O
H
Coast
wit
per
design
can
express
runtime
integrity
because
it
has
the
process
and
resource
resource
collection.
Inter
can
do
this
already
with
the
excess
Jack's
every
process
can
be
hashed
and
be
represented
exactly
in
switch
today.
So,
but
this
is
a
this
is
not
the
general
solution
that
every
platform
can
feel
these
items,
but
there
are
some
platforms,
then
can
use
cos
wait
for
runtime
in
territory?
Also,
yes,
net
sweat
question
is
kind
of
valid.
When
does
a
tester
create
a
swig
to
create
evidence
about
its
software
composition?
H
There
might
be
cases
for
us
very,
very
secure
software
inventory.
I
think
the
refuse
case
is
a
little
bit
in
that
domain
when
we
have
to
find
that
out
so
I
just
wanted
to
highlight.
This
is
true.
Also
I
Pam
to
Kathleen's
comment.
I
made
a
small
question
in
sue
today,
because
suit
also
has
a
data
structure
that
is
very
similar
to
coast,
with
its
I,
actually
identical
structure
to
coast
with,
and
they
also
do
not
use.
H
Cwt
and
I
was
asking
Brenton
the
the
primary
author
of
the
manifest
if
it
is
viable
to
use
it
as
CWT,
and
his
answer
was
no,
there
will
be
not
in
adoption
thing
but
and
again
there
might
be
a
different
voices.
Hannes
was
like
more
on
the
neutral
part
and
would
like
to
discuss
this.
So
this
is
a
very
important
point
to
discuss
and
not
to
hum
here
today
they
see
everything.
That's
my
last
comment.
Yeah.
A
A
In
and
then
we
decide
whether
it's
either
a
different
document,
but
okay,
yes,
okay!
So
let's
just
ask
the
four
questions
in
general
and
then
we
can
take
into
the
list
of
how
we
go
about
them:
okay,
okay.
So
the
first
question
is
with
respect
to
providing
attestation
result.
So
will
you
do
the
back
row?
Man
and
I'll
do
the
front
door.
You
want
to
do
side
by
side.
A
P
A
D
A
Q
Q
A
Q
Actually,
not
just
y'all
proof
of
possession
or
even
attesting
necessary.
Your
public
key
Fido
has
a
concept,
something
something
called
credential,
ID
and
I
think
attesting
to
a
credential
ID,
which
is
a
handle
a
unique
handle.
Ideally,
it
should
be
for
a
for
a
key
pair
is
actually,
it
would
actually
be
included
in
this,
so
I
think
anything.
Anything
related
to
attestation
related
to
a
key
pair
would
be
included
in
this
work.
I,
don't
think
that
we've
like
an
example
about
a
credential
ID.
C
D
A
J
J
Is
bound
to
a
key:
that's
why
we
define
claims
that
reference,
a
public
key
or
different
variants,
key
IDs,
blah
blah
blah
blah,
hashes
or
public
keys,
etc.
The
actual
proof
of
possession
requires
the
person
holding
that
dokkan
to
demonstrate
that
it
actually
ignores
the
private
key.
That
is
not
in
a
token
itself.
Quite
naturally,
it
comes
in
a
protocol,
and
we
have
also
defined
different
ways
to
do
that.
J
A
D
D
D
A
A
A
A
D
P
Okay,
if
I
could
really
ask
the
room
we're
trying
to
get
through
a
process,
there's
a
lot
of
cross-chatter.
If
you
want
to
talk,
please
come
to
the
mic.
When
the
chair
wants
to
do
a
consensus,
please
don't
heckle
from
the
from
the
chairs.
If
you
want
to
say
something,
come
to
the
microphone
way
to
be
kind
of
recognize
something
we're
really
trying
to
get
through.
This.
Thank.
A
A
A
Yep,
okay,
all
right!
So
your
now
so.
D
That
include.
That
concludes
the
first
part
now
on
to
pull
requests
and
open
issues.
So
I've
got
three
or
four
that
I
think
are
relatively
easy:
that
I
just
want
to
get
a
cross-check
with
everybody
and
gonna
make
your
wherever
then
I've
got
some
more
interesting
ones
and
I,
don't
think
we'll.
We
may
not
get
through
all
of
them
and
there
are
definitely
other
claims
in
the
works
that
are
not
being
shown
here
today.
D
Okay,
so
the
first
one
is
only
om
ID.
This
is
to
identify
the
OEM
of
typically
the
hardware.
It
could
be
a
chip,
it
could
be
the
device
it
could
be,
a
module
or
a
sub
module
or
any
kind
of
thing
that's
manufactured,
and
it's
typically
hardware,
so
the
the
previous
PR
was
a
pretty
previous
description
of
the
claim
was
pretty
pretty
light.
D
So
now,
I've
added
all
the
correct
references,
and
all
that,
so
this
claim
is
based
on
the
I
Triple
E
assigned
company
names
that
are
used
either
for
MAC
addresses
or
just
company
IDs
and
they're
all
from
the
same
space.
They
don't
they
don't
conflict,
that's
just
the
way.
I
Triple
E
runs
it.
So
the
proposal
is
basically
I.
Triple
E
IDs
these
these
just
to
be
known
as
oh
you
eyes
now.
They're
they're
called
ma
l
ma
M
and
mas
yeah,
so
they've
been.
F
D
A
A
H
D
I'm
gonna
take
that
to
the
I'm
gonna.
Also
at
the
point
of
Jason
is
you
can
look
at
it
and
if
you
basic
ste
for
something
you
can't
it's
no
longer
look,
you
can't
look
at
it
anymore.
It's
really!
It's
really
common!
You
can
tell
what
it
is.
It's
really
common.
If
you
go
into
your
into
you
use
it
use
a
UI
on
a
device
to
see
MAC
addresses
in
this
in
this
EXA
decimal
form.
D
D
D
Well.
What
this
beer
does
is
says
that
the
relying
party,
the
ultimate
consumer
of
the
touken,
should
generate
a
nonce
and
then
that
should
go
into
a
claim
called
nonce.
That
claim
already
exists
in
a
JWT.
The
nonce
claim
does
not
exist
for
CWT,
so
the
the
the
document
proposes,
adding
it
to
the
IANA
registry.
D
Okay,
so
this
one
is
more
Hardware
oriented.
The
previous
PR
had
four
independent
billions
for
whether
well
actually
yeah.
It's
ignore
the
first
one
secure
boot
enable
because
that's
that's
that
hasn't
been
changed,
but
the
next
four
debug
disabled,
debug
disabled
since
boot,
permanent
disabled
and
full
permanent
disabled.
It
had
four
independent
boolean
x'
for
that,
so
you
could
come
up
with
16
different
states,
the
now
the
it's
just
an
enumerated
type
and
you
you
choose
whether
it's
not
disabled,
disabled
and
and
if
you
claim
you
know,
full
permanent
disabled.
D
This
is
really
more
focused
on
hardware
debug
facilities,
not
like
running
gdb
and
you're.
You
know
in
a
process
under
your
own
username,
so
like
like
I
arm
core
site
or
JTAG,
or
things
like
that.
That's
true!
That's
what
this
is
really
aimed
at
and
typically
a
lot
of
times.
The
enabling
disabling
is
going
to
be
by
fuses.
D
So
this
one
I'm
actually
interested
in
in
like
review
comments
from
hardware
manufacturers
like
Intel
arm
and
Qualcomm
of
whether
this
can
work
for
them
and
then
the
here's.
The
train
come
up
with
something
that
is
relatively
independent
of
the
hardware.
So
like
a
relying
party
can
can
know
what
it
is,
rather
than
every
hardware
vendor
describing
boots
state
by
some
register.
That's
proprietary
to
them.
H
Hi
this
is
Hank,
I
really
tried
not
to
come
up
to
here,
but
this
is
not
hot,
fair,
independent.
This
is
platform
specific.
Some
platforms
will
never
ever
be
able
to
map
to
that
and
somewhere.
So
I
think
it
is,
however,
specific
and
that
I
think
there
should
be
a
indication
what
platform
this
is
for
this
I
mean
the
intent
was
to
try
to
make
it
not.
D
H
L
D
H
Can
mean
so
many
things
that
I
would
not
know
how
to
use
this
if
I
would
be
an
implementer
I
know
three
platforms
personally
and
two
of
them
are
debug
and
I
have
no
idea
how
to
use
this,
and
this
is
not.
This
is
nothing
being
keeping
negative
criticisms.
I
I,
just
don't
how
have
you
read
the
text?
I
I
did
not
the
irritates
of
the
new
one
after
yeah.
M
Two
questions,
one
is:
is
the
secure
food
enabled
still
defined
you,
and
that
was
moved
out
of
the
structure,
and
the
second
observation
is
that
that
hardware,
vendors
do
things
differently.
Every
model
potentially
is
different
and
it's
it's
necessary
that
those
each
model
and
vendor
have
some
way
of
specifying
in
detail
what
those
differences
are.
So
we
didn't
need
some
way
to
support
vendor
specific
claims
that
doesn't
mean
that
there
couldn't
be
some
non
vendor
specific
claims
that
everybody
agrees
to,
but
it's
gonna
depend
on
use
case
as
to
how
how
useful
they
are.
D
L
Taylor
I
like
the
bottom
half,
although
I
like
it
better.
If
you
change
one
word,
if
you
changed
the
word
boot
to
the
word
start,
it
is
applicable
to
more
of
my
scenarios
and
the
bottom
partly
disabled
since
boot,
two,
if
that
is
disabled,
since
start
it's
applicable
to
more
scenarios
and
a
particular
area
I'm
thinking
of
is
STX
unclose
we're
on
the
same
processor.
You
can
have
someone
clays
or
debug,
and
some
that
are
not,
and
you
have
them
happen
at
boots.
L
Q
Jerry,
your
ammonium
Qualcomm.
So
since
you
specifically
requested
Qualcomm
feedback
on
this,
and
one
thing
that's
bothered
me
since
we
first
submitted
this
a
year
ago,
was
we
never
had
a
good
reflection
of
our
own
a
modes
in
the
in
this
enumeration,
so
our
may
being
in
term
of
I
returned
material
authorization
so
to
be
specifically
Qualcomm
what
it
when
an
RMA
debug
that
is
enabled
by
Qualcomm
that
is
different
from
when
an
RMA
debug
is
enabled
by
an
OEM
and
both
of
them
have
their
own
specific
considerations.
Q
We
may
not
have
so
as
far
as
as
far
as
what
data
that
the
OEM
may
not
have
may
main
provision
that
we
would
not
want
to
see
and
vice-versa
so
I'm
wondering
how
best
to
handle
that
I,
don't
think
the
states
are
in
accurate,
I
think
the
states
are
fine,
but
I.
Don't
think
we
have
that
we
don't
have
that.
We're
missing
that
granularity
between
the
SSE
manufacturer
and
the
OEM
I'm
wondering
how
we
can
take
care
of
it
in
this
I
mean.
Q
D
A
R
I
Yeah
I
agree
with
Chris
three
valued
boolean's
are
super
valuable
for
this
kind
of
thing
doing
unknown
values
is
really
important,
especially
when
you're
doing
any
kind
of
large-scale
analysis
on
like
large
amounts
of
this
debug
data.
Any
kind
of
unknown
value
is
going
to
greatly
enhance
your
ability
to
get
meaningful
information
out
of
it.
So
I
think
that
would
be
important.
Thank.
O
A
D
All
right,
let's
keep
going
all
right.
So
this
is
the
the
interesting
one,
I
think
generate
a
lot
of
discussion
list,
I'm
hoping
to-
and
it's
probably
one
of
the
areas
I
struggled
with
the
most
and
the
design
here
so
I'm,
taking
as
an
example
here,
a
mobile
phone
that
has
a
bunch
of
subsystems,
so
you
have
the
te
and
the
tester
is
in
the
TE
and
it
has
a
signing
key.
Then
you
have
all
these
subsystems
that
are
truly
independent
subsystems.
They
boot
independently.
D
So
these
these,
the
these
things
are
all
connected
to
each
other
over
a
bus
or
some
sort
of
internal,
very
short
wire,
or
something
like
that.
There's
no
bluetooth
or
YP,
or
anything
like
that
here.
These
are
superzoom
to
be
all
very
tightly
connected
you
in
this
case
you
know
the
the
Android
is
actually
running
on
the
same
CPU
as
the
TE.
It's
just
different
mode,
all
right,
so
you
can
get
information
from
Android.
D
You
might
even
get
information
from
an
Android
app
as
well-
and
maybe
you
might
say
I
should
draw
this
line
that
goes
from
ant,
the
Android
app
to
Android
and
then
and
and
then
to
the
attest
er
I'm,
showing
also
the
the
cellular
modem
and
the
phone
part
of
this
system
as
a
sub
part.
That
actually
has
the
ability
to
sign
and
eat
on
its
own.
So
it's
got
a
signing
key
and
it
has
an
a
tester.
So
what
it
transfers
over
the
bus
here
is
a
full
signed
token.
D
So
this
is
the
you
might
call
this
the
nested
e.
So
a
couple
other
points.
Each
sub
module
here
has
a
string
name.
It
has
a
bunch
of
claims.
It
has
an
indicator
of
how
strong
the
attachment
is.
That's
probably
something
we
can
have.
A
lot
of
debate
about
claims
are
not
inherited,
so
each
one
would
have
to
report
the
butand
debug
state.
Each
one
probably
should
should
report
the
nonce
I
thought
about
having
inherent
incidents
just
felt
like
a
big
mess.
D
So
didn't
do
that
and
then
I've
already
talked
about
the
two
types
here
so
I
think
I
have
so
this
is
you
know
what
changed
about
the
in
the
PR
from
what
was
there
before
to?
What's
there
now
I
think
I
think
the
the
cleans
up
a
bunch
of
stuff,
sub,
mods
and
nested
E
were
separate
things
before
now,
they're
the
same
thing
and
just
two
different
types
of
entries.
D
There
wasn't
really
a
good
way
to
have
more
than
one
nested
eat
before,
without
violating
some
Seaboard
design,
principles
of
duplicate
keys
and
then
the
there
was
a
separate
claim
for
the
sub
mod
name
instead
I'm
using
the
the
label
or
key
in
the
map.
For
that
and
then
there's
the
new
claim
for
a
sub
mod
attachment,
okay
and
and
here's
an
example,
so
I'll
start.
L
Well,
while
you're
reading
that
we
can
start
comments
and
questions
hey,
can
you
go
back
to
the
one
that
had
all
the
fancy
diagram
so
before
this
I
prepared
my
list
of
things
that
I
would
want
and
you've
done
a
good
job
here,
because
almost
everything
that
I
want
is
actually
the
I'm
looking
at
the
each
sub
module
has
bullets
there
right
when
you
say
string,
name,
claims
indicator
of
attachment
strength,
and
so
for
my
list
of
things
that
are
metadata
about
claims.
You
have
a
claim,
that's
about.
L
L
I'm
gonna,
one
of
the
things
I'm
gonna
get
to
here
is
are
all
three
of
those
bullets.
Could
those
all
be
claims,
or
are
some
of
those
things
that
are
not?
You
know?
This
is
a
string
name.
A
claim
is
the
indicator
of
attachment
strength.
Is
that
a
claim-
and
you
just
have
a
bunch
of
claims
with
some
of
them-
are
metadata
brought
all
the
other
claims
in
the
same
set?
Okay
and
my
last
one
is
what
is
the
source
of
the
value,
not
the
source
of
the
claim.
L
In
case
you
got
the
value
from
some
external
entity,
so
let's
say
you're
reporting
geo,
locate
your
claim
a
door
might
be
your
GPS
device,
but
the
source
of
the
value
might
be
satellite
X
or
some
external
entity
that
you
got
it
from
that
kind
of
thing,
and
so
those
are
the
four
things
only
one
I
don't
see
on
there
unless
you
create
the
claim,
for
it
is
what's
the
source
of
the
value.
Okay,
so
I
met.
That
question
is:
can
all
these
be
expressed
as
claims?
If
you
do,
then
it's
more
like
saying
it's.
L
D
D
L
H
So
this
is
Hank,
please
don't
throw
things
at
me
and
I.
Think
most
of
this
is
actually
covered
by
the
provenance
attestation,
provenance
concept
in
the
architecture,
and
it's
not
only
about
age.
Sometimes
it
is
about
the
entity
that,
but
is
the
origin
Providence
and
maybe
there's
a
chain
of
it
but
I'm
doing
with
Dave.
H
That's
the
only
the
only
thing
here
because
assigning
Opaques
things
you
cannot
semantically
check
them
out
of
the
information
model
if
their
own
information
more
typically,
but
it's
a
Justin
it
yeah,
because
otherwise
information
model
in
syntax
you're
using
a
spoke
I
guess.
But
otherwise
this
looks
oh
and
one
good
comment.
It
really
shows
what
is
a
testing
and
what
is
a
tested.
So
why
five
sub
model
is
a
tested
and
the
TE
is
a
testing
it
and
I
think
this
shows
the
demarcation
line
and
the
any
other
sub
I
test
her.
H
M
You're
on
Ned
yeah,
so
just
to
continue
in
that
line
of
thinking,
I
think
it's
still
not
clear
to
me.
The
difference
between
what
is
the
testing
environment
and
what
is
the
attested
environment
and
whether
or
not
and
a
tested
environment
could
be
something
that
signs
something,
but
is
a
tested
tested
by
an
a
testing
environment.
M
Impatiens
is
that
via
testing
environment
has
some
special
ability
to
observe
the
attested
environment
such
that
it
can
make
these
claims
legitimately.
Okay,
it
can
say:
I
have
access
to
the
memory
region.
I
can
look
at
the
memory
region
and
verify
that,
indeed,
it
is
a
sub-module
X
or
sub-module,
Y
or
I
have
access
to
a
bus
and
the
bus
is
is
secure
and
therefore
I
can
with
authority
say
that
that
I'm
observed
you
know
the
Wi-Fi
sub-module,
for
example.
L
F
L
The
cellphone
modem
in
the
bottom
right
is
itself
a
testing.
Some
claims,
the
TE
main
a
tester
is
taking
those
for
granted
because
it
was
signed
by
that
other
Maia
tester
number
two
and
it
may
be,
including
yet
encapsulated
or
inside
of
a
claim
wherever
here's,
this
other
claim
said
I'm
putting
in
mine
but
I'm
not
attesting
the
code,
I'm
just
relaying
this
or
something.
F
D
D
Keep
moving
so
I
want
to
make
another
comment
here
about
this.
This
is
I've
used
a
mobile
phone
here,
but
this
could
be
a
car
and
this
could
be
breaking,
and
this
could
be
entertainment
and
esses.
You
know
some
head
and
and
and
maybe
this
is
the
I-
don't
know
the
the
nav
system,
which
itself
has
many
sub
components.
So
so
you
can
nest
on
all
kinds
of
stuff,
I.
D
D
D
C
D
Q
Q
Sorry
yeah
I'll
just
mention
something
so
I
took
the
first
stab
at
security
considerations.
I
have
no
illusions
on
this.
I
know
that
when
this
document
gets
to
later
stages-
and
it
goes
through
IES
key
review-
it
will
undergo
a
lot
of
revisions,
but
no
there
was
something
there
were
some
things
that
resulted
from
the
last
face-to-face
that
made
a
made
a
security
consideration.
Sections
more
important.
One
of
things
also
started
with
a
disclaimer
we
will
I
will
mean
to
eventually
harmonize
the
terminology
used
in
this
part
section
with.
Q
What's
actually
brought
forward
in
the
rats
architecture
will
be
discussing
the
rats
architecture,
more
Friday,
so
I'll
mention
one
thing
that
came
up
in
the
last
face-to-face
was
manufactured
provision
key
material.
We
decided
very
specifically.
We
would
move
that
out
of
the
main
text
and
move
that
into
you.
Security
considerations,
so
I
put
in
some
descriptions
on
best
practices
for
creation
transport,
a
manufacturer,
key
material.
Now
I'll
mention
this.
Q
It's
primarily
comes
from
my
experience
in
the
semiconductor
industry,
and
this
may
not
be
the
experience
of
many
participants
in
the
IETF,
particularly
creation
of
key
material,
in
what
what
is
what
I'm
defining
is
an
enclave
leveraging
from
the
RFC,
4949
definition,
transport
and
when
I
say
secure
transport.
Here.
That
doesn't
necessarily
mean
transport,
a
train
and
transport
over
some
sort
of
network
communications.
It
could
also
be
through
human.
F
Q
And
there-
and
there
are
a
lot
of
other
interesting
practices
on
there
and
when
I,
when
I
talk
about
encrypted
storage,
I
didn't
go
into
descriptions
on
this,
but
this
could
be
encrypted
flash
drives
that
a
human
courier
takes
from
one
secure
Enclave
to
another.
Secure
Enclave
brings
it
into
you,
as
I
said
in
semi
tanker
into
the
into
the
SOC,
presumably
maybe
encrypted
RTL
takes
that
flash
drive
physically,
destroys
it
and
disposes
of
it
in
a
way
that
the
information
on
there
cannot
be
reconstructed
well,
host
a
party.
So
take
a
look
at
it.
Q
If
you
have
different
ideas
on
this
wait,
please
let
me
know:
Transport
Security
is
another
area
that
I
addressed.
Basically,
we
do
leverage
GWT
and
JWT
quite
a
bit,
so
there's
we
so
in
the
document
we
can
just
point
to
those
relevant
sections.
However,
as
Lawrence
had
discussed
with
the
use
of
nonce
I
did
put
in
a
discussion
an
anti
replay,
particularly
the
act,
whoever
creates
what
I
call
an
actor
here
in
anticipation
of
the
architecture
document.
One
of
the
assertions
I
make
in
there
is
well,
whichever
actor
creates.
Q
The
nonce
should
be
the
same
one
that
consumes
and
knots
that
verifies
it,
and
if
intermediaries
are
being
used,
then
nonce
needs
to
be
able
to
make
it
through
those
intermediaries.
I
think
if
we're
anticipating
more
complex
architectures
in
the
arc,
it
we're
more
complex
uses
of
intermediaries.
In
the
architecture
document
I'd
like
to
see
that
before
I
go
before
I,
give
any
more
recommendations
on
anti
replay
am
I
going
to
excellent.
Q
Okay,
now
we're
getting
into
some
things
in
architecture,
and
this
is
an
area
where
I'm
not
really
sure
whether
it
belongs
in
this
document
or
not.
So
we
just
discussed
sub
mods.
So
a
corresponding
concept
is
what
I'm
calling
multiple
consumers
and
I
don't
like
the
word
consumer
I
would
like
to
replace
that
as
soon
as
possible,
but
but
I
don't
know
what
we
will
call
it.
As
far
as
the
architecture
is
concerned,
one
of
the
things
that
Lorenson
mentioned
was
attestation
results.
Q
So
I
do
have
some
discussion
in
there
about
verifiers
your
crowd,
who
are
providing
attestation
results
downstream.
So
once
I
mentioned,
for
instance,
that
that
those
attestation
results
can
take
the
form
of
an
H
well,
it
could
be
that
a
verifier
itself
may
have
to
attest
to
its
own
security
state
for
Dan
stream,
for
Dan
Stein
recipients,
also
verifiers
for
specific
sub
mods
and
how
that
would
have
that
would
be
considered
and,
like
I
said,
does
this
discussion
belong
in
the
architecture
dog
cam?
Q
Here's
a
little
bit
of
an
interesting
diagram,
I
apologize
for
it
I
created
yesterday
better,
and
it
may
not
be
so
easy
to
see
so.
I'll.
Try
to
give
a
description
at
the
top
ana
testable
device
provides
an
e
to
a
verifier.
The
verifier
in
turn
provides
its
own
eat
to
a
relying
party.
Now
this
rule
is
now
this.
The
eat.
That's
provided
by
the
verifier
could
contain
attestation
results.
Depending
on
how
we
decide
the
attestation
is
all
claim,
related
claims
or
finally
formatted,
but
to
eat
itself
is
clear.
Q
It
is
clearly
recognizable
as
originating
from
the
verifier.
The
second
result
actually
shows
something
different
for
attestation.
Results
from
each
met
is
probably
beyond
the
scope
of
the
normative
text
in
each
which
is
the
attest
device
provides
each
of
the
verifier.
The
verifier
just
conveys
the
attestation
results
directly
to
the
relying
party
and
that's-
and
that
is
possible,
in
my
opinion,
when
the
verifier
and
relying
party
already
have
some
other
form
of
trust
establishment
between
the
two.
Q
So
the
relying
party
clearly
knows
who
the
verifier
is
clearly
trusted
clear,
each
other
trusted
security
state
they
could
be
located.
In
the
same
premise,
for
instance,
in
the
same
in
the
in
the
same
data
center,
they
could
have
already
established,
they
could
have
already
mutually
authenticated
them,
each
other
through
other
means,
and
in
which
case
the
attestation
results
may
be
just
conveyed,
independent
of
a
need,
like
I
said
this
is
out
that's
outside
of
the
scope
of
the
normative
text
of
each
but
I.
Think
it's
perfect
for
security
considerations.
Q
Now
this
final
diagram
down
here,
I,
didn't
find
a
good
way
to
actually
depicted
graphically,
actually
shows
a
eat
with
several
sub
mods
coming
from
the
intestinal
device.
So
the
initial
recipient
of
that
eat
is
what
I
call
the
verifier
the
top-level
eat,
and
if
there
are
sub
mods
that
are
each
that
are
encapsulate
they
eat
they
will
each
go
to
their
associated
sub
posts
of
mod
verifier,
see
somebody.
Q
Some
might
be
verified
and
all
and
all
the
verifiers
will
eventually
pass
their
attestation
results
onto
on
to
the
relying
party.
In
this
case
the
example
shows
each
being
passed.
The
attestation
results
being
passed
in
the
form
of
the
needs
to
the
relying
party.
Now,
as
I
mentioned,
what
the
anti
replay
each
of
those
verifiers
will
own,
the
nonce
will
have
a
I
created
the
nonce,
that's
associated
with
the
eat
that
it's
verified.
Yes,
hi.
H
What
this
assumes
is
that
the
tester
I
really
would
not
call
it
a
testable
device
that
a
tester
knows
which
parties
are
there
will
be
able
to
appraise
the
evidence.
This
is
an
assumption
that
is
not
always
true,
it
might
be
sued
ruin
the
each
scenario
that
comes
from
specific
users
use
cases
that
micah
is
aggregating,
but
I
am
relatively
certain.
Not
every
use
case
is
built
on
the
assumption
that
the
tester
is
aware,
which
verifier
will
be
able
to
appraise
its
evidence.
So
this
next
thing
you
are
proposing
here
is
based
on
an
assumption.
Q
H
I
think
I
think
this
is
can
remediated
by
the
attest
or
giving
a
hint
that
it
thinks
it
knows,
and
the
verifiers
will
then
assess
that
hint
like
you,
have
your
wrong
or
can
follow
this
up.
Also
nonsense:
I
think
are
not
only
there
for
anti
replay,
but
for
providing
freshness
and
if
you
start
to
relay
them
freshness
deteriorates.
So
there
might
be
a
use
of
another
layer
of
nonsense
and.
M
L
They
tailor
so.
The
bottom
case
has
a
whole
bunch
of
complexity,
I'm
undecided
as
to
whether
we
need
it
or
not,
and
I
defer
to
you
if
there's
a
use
case
that
needs
it
great.
Thank
you
for
writing.
It
up.
I,
don't
know
if
there's
a
use
case
that
needs
it.
That's
a
question
that
I
have
what
I
originally
was
going
to
get
up
and
say.
Is
that
those
three
use
case
or
those
three
cases
is
not
the
only
case?
L
Loretta
talked
about
the
other
one
where
the
thing
on
the
left
is
not
an
eat
and
the
thing
on
the
right
isn't
eat,
and
so
in
his
slides
he
talked
about
how
that
might
be.
You
know
a
yang
TPM
thing
on
the
left
and
an
eat
on
the
right,
meaning
the
SS
station
result
part,
and
that
should
be
a
fourth
diagram.
Yes,.
Q
E
E
Q
L
L
F
L
Yes,
and
so
then,
if
that's
the
case,
if
I'm
interpreting
your
answer
right,
then
the
ax
tester
does
not
need
to
know
the
verifier
he's
only
talking
to
the
top-level
verifier,
because
that's
the
only
Nazi
needs
to
include
well
in
because
you
could
do
a
transform
at
the
verifier
there
to
insert
its
own
nuts
in
there
in
the
same
way
as
it's
doing
an
attestation
right.
So
you
could
construct
a
solution
that
way,
whether
you
think
that's
a
good
idea
or
not
as
a
different
question
that
maybe
hamadan
yeah.
H
Q
If
we
go
back
to
sub
mods
in
reality,
I
don't
think
that
the
the
typical
that
it's
typical,
that
you
would
have
four,
if
you
have
three
sub
mods,
you
would
have
three
different
nonsense,
because
I
think
the
same
verify
would
verify
all
three
of
the
sub
mods.
So
I
agree.
I,
agree
that
that,
maybe
that's
that's!
This
could
be
a
Prada,
a
solution
in
say
in
circular
problem,
and
it's
not.
Q
Just
one
more
thing:
any
topics
that
are
missing
you
know,
please
put
it
on
the
PR
and
we
have
to
take
a
look
at
them.
I
think
just
bear
in
mind,
though
particularly
fir
thee
for
the
co-editors
of
the
architecture
document
before
it
bear
mind
that
if
you're
going
to
be
addressing
those
same
issues-
and
we.
Q
Going
on
the
earlier
discussion
or
lauren
started
with
with
with
the
it
with
proposed
claims
to
round
out
eat,
we
decided
parties
meaning
to
submit
a
informational
document
on
something
called
the
quest
token.
So
what
what
is
quite
stand
for
Qualcomm
wireless
edge
services-
and
there
was
a
in
so
it
actually
goes
to
you.
Q
Q
Deploy
at
a
state
and
online
attestation
service
such
that
we
is
such
that
relying
parties
can
take
advantage
of
it
without
having
to
expose
a
lot
of
key
a
lot
of
key
material,
critical
key
material
to
you
to
third
parties,
even
if
they
are
trusted,
and
even
if
you
have
PK
I
play.
So
that's
what
Korres
came
about
at
a
station
was
a
key
service
in
the
attestation
was
codes
a
based,
and
we
call
it
quiz
token.
So
some
of
the
key
commonalities
between
quiz
token
and
eat
we
do.
Q
There
is
a
oh
em,
I
D.
There
is
a
concept
nonce
in
there,
but
there
are.
There
are
several
differences
today,
and
these
are
some
things
that
we
can.
We
can.
We
can
consider
as
far
as
far
as
whether
they
belong
and
eat,
or
whether
they
belong
in
a
profile
like
quest
token,
so
there's
device
ID
is
used
a
little
bit
differently
and
this
is
something
I
discussed.
It
would
discuss
with
Lawrence,
because
it's
a
quasi
token
device
ID
can
be
specific
to
your
service
provider
and
I've.
Q
Looked
at
the
way,
we've
we're
addressing
quest
a
service
provider.
As
far
as
quiz
is
concerned
and
I
believe
I
can
say
it's
identical
to
the
way
service
providers
defined,
antique,
so
I
think
no
Lawrence
it
won't.
The
warrants
may
have
a
proposal
as
to
how
to
reconcile
reconcile
defining
a
defining,
a
ue,
ID,
that's
specific
to
a
service
provider.
Shawn
not
going
to
talk
too
much
about
that.
There's
also
hardware
version,
which
is
the
chip
version
context,
so
this
is
somewhat
so.
Q
This
may
be
related
a
little
bit
to
what
you
were
talking
yank,
and
that
is
the
cotton.
This
is
a.
This
is
a
claim
defining
the
context
of
the
attestation.
So
is
it
supposed
to
be
used
for
authentication?
Is
it
supposed
to
be
used
for
certificate
issuance?
Is
it
supposed
to
be
designated
for
this
particular
bear
fire?
That's
not
something
that
we've
we've
anticipated,
but
that
could
be
another
thing.
Q
Q
Yeah
PK
hash:
this
is
a
hash
of
the
public
key
provision
by
the
OEM
specifically
used
for
authenticated
boot.
I,
don't
know,
I've
been
equivalent
to
eat
on
there.
That
is
that's
not
common
terminology
either.
That's
quite
a
it's
quite
a
common
concept
in
the
semiconductor
industry,
yeah
I.
Think,
okay,.
H
Pk
hash
first,
so
I
assume
that
the
evidence
does
not
come
with
the
public
key,
but
the
hash
of
the
public
key.
And
then
you
go
back
to
the
Asura,
that
is
it
supply
chain
or
vendor
yeah.
F
H
Q
So
the
use
case
in
the
use
case
primarily
is
assume
that
assume
that
I've
done
something
that
you
know
it
seemed
that
I,
let's
talk
about
like
in
a
sweet
suit
context,
suffer
updating
context,
assume
that
I
signed
my
assume
that
I'm,
the
main
factor
I'm
signing
myself
software
updates
with
the
private
key
and
there's
a
public
key,
there's
a
public
key
and
sanchita
in
the
device
or
and
and
I
verify
according
according
to
that
now
suppose
what
happens
that
I
did
is
suppose
that
I
found
out
hope
somehow
the
private
Keys
gotten
lost.
Q
You
know
disgruntled
employee
or
something
like
that.
I
need
to
provision
a
new
public
key
on
all
these
devices
before
I
start
pushing
software
updates
onto
them.
Well,
how
do
I
know?
How
do
I
know
this?
Did
this
device
is
the
tip
of
the
public
key
the
public
key
that
I'm
using
well
I
can
just
query
the
PK
hash
and
get
it
via
a
testable
result.
Why.
H
H
Q
H
D
F
D
The
the
the
the
key
that
you're
going
to
do
to
know
that
the
software
that
you're
gonna,
so
it's
the
thani
key
to
boot,
so
the
the
software
that
you're
going
to
boot
has
to
be
signed
by
something.
So
the
person
that
produces
the
software,
that's
going
to
be
run,
has
the
private
key
and
then
the
the
device
has
the
public
key
so
that
the
device
uses
that
to
verify
the
software.
It's
implicit
at
is
station.
F
D
Q
Now,
there's
another
difference:
the
service
provider
ID
I,
believe
that
that,
like
I
said,
service
provider
concept
and
quiz
is
the
same
as
in
teep.
We
discussed
this
morning
in
the
team
meeting
that
there
will
be
a
t
profile
for
each
so
I,
don't
know
so
I,
don't
believe
this
is
a
candidate
for
common
Aliza.
With
the
software
inventory,
we
just
went
through
the
hum.
We're
gonna
do
the
so
we're
going
to
be
defining
software
inventory
claim.
Q
Quasi
token
has
to
have
two
claims
specific
to
that
there's
something
called
the
QC
version:
Qualcomm
secure
execution
environment,
but
it's
really
two
t
ee
version
there's
also
the
firmware
version
as
well.
So
this
is
firmware
you
specifically
for
bootstrapping
advice,
okay,
I'm
running
out
of
time
here
we
mentioned
earlier
on
the
public
key
claim
certificate
signing
request.
We
actually
have
the
ability
to
carry
pkcs
10
compliant
CSR.
In
the
attestation
token,
you
might
say
why
do
you
did?
Why
are
you
not
sending
it
separately?
Q
Q
Security
state,
so
once
it
talked
about,
you
know,
representation
a
debug,
we
talked
a
little
bit
about
the
representation,
secure
good
state.
Actually,
a
lot
of
that
is
good.
A
lot
of
that
is
controlled
in
a
fuse
or
a
one-time
programmable
memory,
I'm
calling
us
user
a,
but
it
could
but
really
programmable
memory
is
non-volatile
and
it
could
come
in
the
form
of
electronics
user.
A
may
not
security
stayed
in
the
quiz.
Q
Token
is
actually
a
survey
of
the
bit
bit
setting
in
in
that
non-volatile
memory
that
actually
covered
the
debug
state
or
in
a
secure
boot
state
in
the
SSE.
Is
that
something
we
would
consider
for
the?
If
for
this,
for
each
that's
something
we
can
take
offline
app
hash?
Well,
this
is
actually
suitable
for
the
TE
model.
Q
It's
actually
the
hash
of
the
client
app
that's
contained
at
a
station
token,
that
will
be
in
a
T
profile,
so
I
don't
believe
that
it's
really
really
so
is
we
have
to
dwell
on
it
much
further,
so
I,
some
final
questions:
should
security
OTPs
be
sent
directly
or
the
information
should
sure
the
information
be
conveyed
via
representative
claims?
I'll
put
this
back
of
the
man
lists
we
don't
need
to
hum.
Today,
I
mentioned
what
context
was.
Should
we
have
a
context
claim
what
how's
the
attestation
token?
Q
What
are
the
restrictions
on
the
usage
of
the
attestation
token
is
conveyed
by
the
tester.
We
mentioned
software
inventory
and
we
may
I
discussed
a
little
bit
on
device.
I
did
identifiers
te
considerations
I'm
not
going
to
get
into
this
here
because
we
already
said
we're
going
to
do
a
T
profile,
but
these
are
some
things
that
we
could
actually
be
considered
as
part
of
a
teep
profile.
So
yeah.