►
From YouTube: IETF114-RATS-20220725-1400
Description
RATS meeting session at IETF114
2022/07/25 1400
https://datatracker.ietf.org/meeting/114/proceedings/
A
C
C
D
F
G
C
F
C
D
C
C
D
D
I
just
a
note
that
we're
well
in
terms
of
just
a
review
of
what
the
ib
rules
are
for
participation
in
itf.
I
think
everybody's
familiar
with
this
a
few
meeting
tips
as
we
get
started,
so
we
have
both
in-person
and
online
participants
and
so
as
a
reminder
to
the
in-person
participants
just
to
make
sure
that
you're,
you
know
when.
D
D
C
D
C
D
I
H
I
I
I'll
talk
through
them
as
we
get
going.
The
first
slide
as
this
comes
up
is
just
the
same
thing.
We've
shown
in
many
ietf's
for
the
last
couple
years
that
talks
about
the
relationships
of
the
giraffes,
the
relationship
between
the
architecture,
draft,
the
relationship
to
the
reference
model
draft
and
the
relationships
between
the
charge
raft,
the
subscription
draft
and
and
r4c.
I
H
I
I
I
A
Go
yeah,
so
this
is
hank
yeah,
so
the
review,
I
think
most
reviews
have
been
done
on
the
yang
side,
of
course,
because
it's
so
there
are
some
tooling
issues.
So
if
you
see
errors,
these
are
okay
unless
they
are
not
okay
anymore,
but
I
think
we
will
establish
this
on
the
list
twice,
that
it's
a
local
tool
chain
problem
and
not
a
problem
with
the
actual
young
module.
So
don't
be
scared
by
that.
I
Basically,
our
4c
is
also
progressing.
There
have
been
a
number
of
dialogues
that
have
occurred
for
various
areas.
One
of
the
big
things
that's
happened
happening
is
outside
of
the
working
group
and
we
have
dave
taylor
who's
in
the
room
right
now,
we're
hoping
to
get
some
stable
terminology
out
of
the
confidential
compute
consortium
and
we're
hoping
to
go
ahead
and
update
the
r4z
using
the
terminology
that's
been
discussed
over
in
the
confidential
computing
consortium.
We
don't
see
a
need
to
rush
to
get
the
closure
until
that's
closed,
then
we'll
update
the
draft
there.
I
So
that's
one
of
the
things
we've
been
trying
to
do
with
r4z.
Second
thing:
we've
been
trying
to
do
with
our
foresee
is
continue.
Dialogues
with
the
eat
draft
on
a
couple
of
different
topics.
This
includes
things
like
security
level,
which
has
been
sort
of
going
back
and
forth
for
a
long
time
as
people
know
following
the
group
and
one
of
the
things
that
has
happened,
which
is
a
plus
is
we
agreed?
I
I
There
is
dialogue
going
for
what
is
the
right
way
to
integrate
with
eat.
I
do
think
that
we're
awaiting
some
of
the
disposition
on
some
of
the
questions
in
there
we've
proposed
at
least
a
skeleton
for
what
it
would
take
to
put
our
4z
claims
in
each
syntax,
and
there
was
some
stuff
going
in
the
last
slide
talking
about
what
those
syntaxes
might
look
like,
but
we're
going
to
wait
on
the
closure
of
some
of
the
other
larger
questions
with
eat,
which
I'm
sure
we'll
hear
about
in
future
slides.
I
I
We've
had
a
lot
of
comments
early
on
it's
revved
a
number
of
times
early
on
in
the
last
three
months.
It's
really
big
just
been
iterating
on
overlaps
with
the
eat
side.
So
I'd
say
that
there
are
some
rel
now
we're
there.
I
think
there
have
been
some
substance
comments.
As
I
mentioned
we
introduced
or
want
to
introduce
some
new
stuff,
as
it
relates
to
hardware
types.
There's
been
comments
and
iterations
on
stuff.
I
A
A
I
And
probably
slide
before
this
one
is
the
one
to
end
on,
because
that
was
kind
of
what
we
were
just
talking
about.
Future
integration
based
on
you
talked
about
comments.
We
had
the
drafts
that
I'd
look
is
to
look
for,
for
substantive
comments
would
be
some
claims
and
evidence
and
results
threads
and
the
profiles
threads,
which
are
very
relevant
to
how
do
we
determine
integration
over
time?.
J
K
J
So
this
may
be
answered
in
there,
but
I
am
one
of
the
people
that
yes,
I
will
review
this
one
and
may
in
fact
use
it.
My
question
has
to
do
with
the
use
of
profiles
and
what
the
current
thinking
is.
If
you
can
summarize
that
so,
for
example,
in
teep
teep
defines
a
profile
there,
because
it
has
a
relying
party
and
the
profile
and
teep
says
here's
what
the
relying
party
needs
in
attestation
results.
J
I
It's
a
very
good
question.
The
question
on
profiles
is
a
slightly
different
perspective
for
how
we
took
the
definition
of
the
claims
versus
let's
say
the
way
it
does.
The
definition
of
the
claims
we
from
the
r4c
standpoint
take
the
perspective
that
the
definitions
of
the
claims
will
always
be
in
attestation
results
and
they
should
not
require
a
profile
for
any
variation
in
the
meaning
of
the
claims.
I
So
we're
hoping
that,
where
our
forza
is
used,
they
would
be
pretty
much
the
same
definitions
as
used
in
any
use
case
with,
in
other
words,
they're,
not
really
varying
their
meanings
based
on
the
profile
or
so
that
you'll
be
able
to
pick
up
the
claims
in
a
particular
profile,
and
that's
the
the
prerequisites
for.
I
guess
the
next
slide,
which
talks
about
design
considerations.
I
J
Okay,
so
I
just
want
to
make
sure
I
understand
the
answer
that
you're
saying
the
answer
is
still
a
bit
flexible
if
needed.
But
you
see
this
is
replacing
the
need
for
other
profiles
for
people
that
use
attestation
results
that
you'd
use
this
or
some
custom
profile.
If
this
didn't
work
for
you,
you
wouldn't
try
to
use
them
both
together
and
sort
of
subclass.
This
or
something,
I
think,
is
your
answer
correctly.
I
J
Because
a
neat
profile
does
a
lot
more
than
you
specify
which
claims
they
are
right,
there's
a
whole
bunch
of
other
axes
that
are
part
of
the
profile
right,
and
so
is
your
intent
to
dictate
those
there,
because
the
other
variation
would
be.
You
take
the
claims
out
of
this
one
and
you
use
a
different
variation
of
like
whether
it
supports
the
what
detachable
or
whatever
the
term
is
or
the
other
variations
that
are
in
the
profile.
Yeah.
J
I
If
you
knew
the
slide
previous
I'll
just
close
on
this
question,
as
you
can
see
when
it's
clear
how
profiles
we're
going
to
be
very
happy
to
add
a
section
showing
eating
codings
in
that
case,
to
be
very
open
to
be
used
in
profile.
So
I
see
no
conflict
for
any
of
these
claims
to
be
used
as
claims
we're
just
waiting
to
see
how
profiles
plays
out
before
putting
the
text
in.
L
L
So
the
profile
really
comes
in
comes
in
because
of
variability
in
sibor
variability
in
choosing
seaboard
versus
json
variability
in
cosec,
because
of
all
the
algorithms
that
you
can
choose
variability
in
jose
because
of
all
the
variability
there
and
the
requirement
or
non-requirement
where
it
does
really
apply
to
claims.
It's
it's
a
a
prohibition
of
claims
or
a
requirement
of
claims
and
possibly
a
refinement
of
claims,
but
really
it's
about
a
lot
of
the
other
stuff.
Then
then,
the
actual
semantics
of
a
claim.
I
This
is
really
an
eat
question
rather
than
an
or
forcy
question,
so
I'm
happy
to
defer
it.
I
do
think
that
the
meaning
of
a
claim
such
as
security
level,
changes,
whether
it's
coming
from
an
attester
or
endorser
or
lying
party
and
there's
still
a
namespace
question
of
how
do
you
interpret
the
object.
L
L
A
A
C
J
J
J
Whenever
there's
actually
issues
to
discuss,
we
had
tuesday
morning
meetings
and
we
had
a
long
list
of
people
that
showed
up
at
various
types
of
meetings
and
stuff.
Some
of
them
are
in
the
room.
Some
of
them
are
remote,
a
couple
of
them
are
co-authors,
but
I
think
we
probably
had
like
15
people,
not
necessarily
on
the
same
meeting
but
collectively
discussing
the
various
issues
that
were
specific
to
this
document.
J
So
we
had
issues
and
put
requests
that
have
changed.
Okay
here
we
go
yeah,
that's
the
stuff
I
was
just
talking
about.
You
can
see
all
the
list
of
names
on
the
left,
so
we
believe
the
design
team
being
people
that
show
up
at
the
meetings
to
talk
about
the
specific
issues
right
is
on
the
left
there.
That
is,
of
course,
not
working
group
consensus.
That's
confirmed
on
the
list,
but
this
is
the
set
of
people
that
were
involved
in
presenting
what's
the
dot.
What
was
in
the
coming
up
with
the
text?
J
J
Most
of
them
are
editorial
things
that,
including
you
know,
some
actual
wording,
suggestions
from
roman,
which
we
thought
were
great.
The
the
non-text
version
now
has
the
nice
svg
diagrams
right.
So
you
have
some
pretty
printed
diagrams,
which
you'll
actually
see
two
of
those
on
the
slides.
We
made
some
minor
adjustments
to
the
terminology
in
terms
of
the
definitions
of
things.
To
be
more
clear,
an
example:
we
changed
integrity
protection,
which
was
also
a
section
of
heading
to
the
term
conceptual
message:
protection
because
it's
not
just
about
integrity.
J
Those
are
examples
of
things
right.
All
those
are
minor
editorial,
there's
no
technical
differences,
there
really
other
than
maybe
some
clarifications
to
to
say
what
we
meant
about
those
technical
things
so
go
on
to
the
next
slide.
Okay,
so
there's
only
one
remaining
issue
in
the
80
review
before
things
going
on
gone.
Okay-
and
this
is
split
between
two
slides
because
it's
in
discussion
on
two
different
diagrams-
and
this
is
a
long
ways
away
from
this
mic.
So
I
need
to
be
able
to
see
one
of
these
slides.
J
So
I
can
point
to
stuff
because
there's
some
small
print
in
the
diagram's
there
that
people
remote
can
see
but
not
local
yeah.
I
think
I
can
see
that
okay
yeah,
that's
probably
out
there
all
right.
So
the
little
speech
bubble
there
is
michael,
is
kind
of
how
we
think
about
things,
but
everything
else
on
the
slide,
that's
up
above
in
italics,
and
the
diagram
is
literal
in
the
document.
J
Okay
and
so-
and
I
know
roman-
is
here
right,
and
so
I'm
going
to
kind
of
summarize
this
and
roman
can
correct
me
because
I'm
trying
to
channel
what
roman
said
and
then
kind
of
our
discussion
about
it
right.
So
the
diagram
there
we
see.
This
is
the
passport
model
diagram
and
it
shows
an
attestation
result
line
coming
down
to
an
attester
and
then
an
attestation
line
going
to
the
right
over
to
the
line
party.
Okay
and
roman.
J
Looked
at
that
and
said
well
that
looks
like
the
attester
does
something
with
those
attestation
results
for
some
definition.
Does
something
right
and
wanted
to
have
more
discussion
about
that,
and
so
the
text
in
italics
is
actually
what
the
document
says
about
that
diagram.
Okay,
so
it
says
the
tester
does
not
consume
the
attestation
result,
but
might
cache
it.
Okay.
J
In
other
words,
there
might
be
a
time
delay
between
the
line
coming
down
the
line
going
to
the
right,
where
it's
just
an
opaque
blob,
that's
cached
in
storage
and
then
sent
off
in
at
an
appropriate
time.
The
attester
can
then
present
the
attestation
result
and
possibly
additional
claims
if
that's
encapsulated
in
some
larger
message
right
to
a
relying
party.
J
But
of
course
those
additional
claims
are
not
in
the
attestation
result.
The
attestation
result
is
signed
can't
be
modified.
It's
an
opaque
blob
to
the
to
the
attester
right
it
can,
which
then
compares
its
information
against
its
own
appraisal
policy.
The
attester
may
also
present
the
same
attestation
result
to
other
aligned
parties
right.
So
it's
an
opaque
blob
he's
got
this
ticket
that
he
can
kind
of
present.
Just
like
a
human
hexa
has
a
passport.
You
can't
modify
your
passport,
but
you
can
go
to
one
airport.
You
can
present
it.
J
J
Okay,
so
that
was
the
intent
of
this
text.
Okay,
and
what
and
so
that's
why
the
line
isn't
just
a
pass
through.
It
actually
stops
there,
because
it
can
be
cached
can
be
modified,
that
it
can
be
cached
and
it
can
be
then
be
represented
to
different
relying
parties
over
time
as
this
opaque
blob.
Okay,
that's
what
we're
trying
to
accomplish
with
this
diagram
and
with
this
text.
J
Okay,
so
the
question
is
whether
roman,
whether
you
think
or
anybody
else
in
the
working
group
thinks
that
additional
text
changes
are
necessary
to
convey
that
concept.
Okay,
as
we're
trying
to
explain
why
that
line
terminates
there
with
that
text
right
there.
This
is
what
what
the
current
document
says:
yeah
yeah,
please
go
to
the
mic,
because
our
goal
is
that
by
the
end
of
this
meeting,
we
want
to
be
done
with
this
document
right.
G
Yeah
hi
roman
junior,
we're
talking
about
my
comments.
I
I
get
that
there's
multiple
semantics
that
we're
talking
about
here.
My
read
of
section
four:
is
that
you
that
that
text
is
primarily
the
statutory
definition
of
the
information
flow.
I
think
perhaps
a
happy
compromise
of
the
text
in
section
5
in
section
4
is
not
to
change
the
text
in
section
5,
which
is
talking
about
the
caching
behavior
and
the
rest
of
it.
G
Perhaps
some
text
at
the
end
of
section
4
is
to
explicitly
say
this
is
about
documenting
the
the
the
whatever
producer
and
kind
of
consumer
behavior
that
does
not.
It
is
that's
not
intended
to
constrain
the
fact
that
I
guess
arbitrary
rats
elements
can
share
stuff
as
long
as
they're,
not
consumer,
considered
production
producers.
J
Or
consumers.
So
if
I
understand
right
you're
saying
you
have
no
problems
with
this
section,
but
there's
a
section
that
comes
before
this,
which
I
have
on
the
screen
right
section,
four
or
whatever
that
you
saying
that
one
could
be
more
clear,
would
adding
a
forward
reference
to
say,
see
section
5
for
more
details
of
what
the?
How
of
how
it's
used
or
well.
J
In
a
sense,
yes,
in
the
same
sense
as
a
router
right,
so
just
like
routers
pass
packets
without
knowing
what
the
payload
is.
So
yes-
and
that's
because
I
mean
that
the
reason
I
say
yes,
that's
talked
about
in
the
document
where
it
says
all
the
roles
and
the
conveyance
mechanisms
are
conceptual
right.
You
could
have
one
of
the
other
roles
that
send
the
intermediary
in
any
of
the
lines
here,
when
you're
actually
designing
a
protocol
right,
you
can
have
some
other
role
that
is
actually
intermediary
in
between
these
lines
here.
J
Well,
that
doesn't
affect
the
architecture.
That's
just
a
protocol
instantiation.
It
says:
oh
yeah,
it
kind
of
bounces
off
this
one
as
a
router
kind
of
thing,
and
so
it
doesn't
preclude
that
it
actually
allows
that
elsewhere.
So
that's
why?
Yes,
to
your
answer,
because
it's
consistent
with
other
statements
in
the
document
that
say
that
the
conception
of
the
message
goes
between
these
and
here
the
tester
is
involved
only
in
the
conceptual
diagrams,
because
he's
actually
allowed
to
cache
it
and
have
multiple
different
line.
J
G
J
In
a
sense-
yes,
okay
yeah,
so
I
guess
perhaps
but
but
you're
right
about
the
fact
that
the
the
def
when
you
said
about
the
definition,
part
yeah.
That
is
absolutely
correct.
It
says
you
would
not
call
it
evidence
if
it's
actually
consumed
by
something
other
than
the
verifier
right
if
it
was
actually
consumed
and
parsed
by
a
relying
party
or
whatever
it
would
never
be
called
evidence.
And
so
in
that
sense
yes,
you're
exactly
right
in
saying
that
the
producing
and
consuming
is
part
of
the
definition
yeah.
G
Yeah
so
again
I'll
go
back
to
what
I
said.
I
think
the
the
fix
for
this
is
leave
five
as
five
is
and
then
four
I
think
I
would.
I
would
benefit
from
additional
language
that
says
something.
The
effect
of
you
know,
consume
or
produce
actually
means
this.
There's
there's
this
definition
and
that's
what
we
mean
by
that
and
then
there
are
other
ways
in
which
they
can
be
passed,
which
is
not
produce
and
consume,
and
that's
in
scope
for
all
all
the
elements,
no
attempt
to
constrain
and.
J
Okay,
I
don't
know
if
a
note
taker
probably
couldn't
have
captured
that
fast
enough,
we'll
probably
have
to
go
back
to
the
recording
to
see
if
we
can
capture
some
of
that
that
wording
or
whatever,
okay,
so
next
slide.
Now
we're
on
the
second
diagram,
basically
the
same
kind
of
comments
in
the
second
diagram.
So
here's
the
this
is
the
diagram
for
the
background
check
model.
Okay
and
ooh.
Look
you
notice
the
pretty
printed
version
of
the
of
the
diagrams
here.
J
Okay,
so
here
you
have
the
attester
and
you
see
the
the
evidence
line
goes
over
to
their
lying
party
and
there's
a
little
curvy
thing
that
goes
through
it
and
then
goes
up
to
the
verifier
okay.
So
this
one
is
drawn
a
little
bit
differently
and
that's
because
the
text
below
it
have
a
little
bit
of
different
considerations.
It's
not
because
it's
not
the
case.
The
relying
party
takes
that
and
then
presents
it
to
different
verifiers
right,
so
that
concept
just
doesn't
occur
here.
J
So
the
the
lines
are
a
little
bit
different,
because
the
the
the
way
things
are-
maybe
you
know
cached
or
whatever
a
little
bit
different.
So
here's
what
the
text
says
and
this
model
and
a
tester
conveys
evidence
to
relying
party
which
treats
it
as
opaque
and
simply
forwards
it
onto
a
verifier.
So
in
the
sense
it
really
is
more
like
a
router
right.
It
doesn't
do
anything
with
it.
It
doesn't
even
say
anything
about
caching
right,
the
verifier
compares
the
evidence
against
its
appraisal
policy
and
returns.
An
attestation
result
to
the
allowing
party.
J
The
relying
party
then
compares
the
attestation
result
against
its
own
appraisal
policy
and
the
resource
access
protocol.
That's
the
horizontal
line
there
between
the
attest.
Unlying
party
includes
evidence
rather
than
an
attestation
result
that
evidence
is
not
processed
by
the
relying
party
right.
So
the
main
part
is
the
first
sentence
and
the
end
of
the
last
one
okay.
J
So
here
it
really
is
just
a
just
a
pass
through
okay,
and
so
it
terminates
at
the
transport
layer,
but
so
the
end-to-end
connection
just
goes
all
the
way
through
it,
and
so
that's
why
it
kind
of
curves
straight
through
there,
because
it's
more
like
in
the
routing
sense.
It's
like
a
layer,
two
termination,
wherever
three
just
forwards
right,
that'd,
be
the
analogy
here.
G
Yeah
roman
did
you.
I
guess
same
comment
just
to
be
very
kind
of
explicit.
I
think
if
you
have
the
the
appropriate
caveat
weasel
words
in
section
four
that
says
again
any
rats
rats,
architectural
element,
it
can
opaquely
transfer
the
things
that
it
has
to
kind
of
other
rats.
That
would
cover
it
as
well,
and
if
you
want
to
talk
about
additional
semantics
inside
the
box,
like
caching,
the
rest
of
it
c.
G
J
Works
for
me
thanks:
okay
gotcha,
so
the
summary
that
I'm
hearing
is
section.
Five
is
okay,
section:
four,
we
explain
and
I'm
going
to
kind
of
up
level
what
you
said
details
are
in
that
that
section
four
says
this
is
part
of
the
definitions
and
the
definitions
are
based
on
producing
and
consuming,
and
other
rat's
roles
may
be
involved
as
part
of
the
conveyance
process.
For
those
okay.
F
C
J
J
I
think
that
was
the
last
slide,
so
I
think
the
last
one
is
just
any
other
question
anything
else
that
we
missed,
because
we
believe
that
if
we
do
this,
we
are
done
and
then
it's
past
80
I
mean
we
do
this
and
then
roman
pushes
it
on
to
the
next
stage
as
past
80
review
right
so
because
it's
already
gone
through
like
multiple
working
group
last
calls
and
everything.
So
all
right
thanks.
G
L
L
L
L
A
couple
of
the
sections
were
moved
to
appendices,
so
the
core
of
the
document
now
is
is
substantially
shorter.
These
were
some
things
about.
There
were
really
good
discussions
earlier
on
about
designing
claims
and
about
keys
and
endorsement
and
how
that
sets
up
so
they're
not
really
critically
normative
to
reading
the
documents
so
they're
in
appendices
now,
but
they
were
good
work
and
they
didn't
want
to
lose
them.
L
So
that's
the
document
organization,
then,
in
terms
of
actual
changes
to
the
specification
for
manifests
and
software
evidence
claims.
Those
are
plugable,
meaning
you
can
put
a
lot
of
different
formats
in
there
and
I
switched
to
co-app
content
identifiers
rather
than
cbor
tags
because
of
the
json
support
and
other.
So
sorry,.
L
Okay,
I'm
gonna
keep
going
so
that
that
was
the
you
know:
the
switch
to
co-op
content
types
that
seemed
like
a
better
solution
overall
for
the
pluggable
software
evidence
and
manifests.
So
we
added
the
spddx
and
cyclone
dx
manifest
types.
So
the
ma
the
manifest
claim.
You
know
it
can
be
a
a
coast
width
or
a
suit
manifest.
Now
it
can
also
be
an
spd-x
or
a
cyclone
dx.
This
is
also
pluggable,
so
it
can
be
extended
by
other
documents.
It's
just
it's
open-ended.
L
We
can't
really
pick
a
winner
here
on
on
manifest
type.
So
it's
a
general
plugable
thing
and
we
have
the
specification
for
how
to
do
spd-x
and
cyclone
dx
the
measurement
results
which
is
just
describing
the
results
of
measurements,
not
the
results
of
a
verification
that
claim
was
reworked
and
it
works
a
little
better.
Now
it's
more
general
can
can
represent
measurements
of
things
other
than
just
software.
L
L
You
know
we
had
a
discussion
in
vienna
about
where
to
define,
claim,
set
and
dependency
on
uccs,
that's
resolved
by
just
putting
a
definition
of
claim
set
in
an
appendix
in
eat
and
saying
that
you
know
there's
other
definitions
of
this
in
other
documents,
and
you
know
they
should
all
stay
in
sync:
it's
not
a
controversial
definition
or
a
difficult
one.
So
I
don't
see
any
issue
here.
I
mean
that
was
based
on
carsten's
suggestion
that
it's
fine
to
replicate
cddl.
L
So
then
all
definition
of
uccs
is
removed,
but
there
is
a
socket
cddl
socket
into
which
other
heat
formats
can
be
plugged
and
then
there's
just
a
a
lot
of
cddl
improvements.
It's
actually
validating
jason
and
sibor
examples.
So
the
so
the
examples
in
the
eat,
spec
are
all
validated
in
the
built
document,
build
process
with
the
cddl
tool
and
then
there's
just
lots
of
wording
improvements.
The
profile
section
was
the
biggest
one
based
on
comments
from
elliot.
L
I
I
want
to
note
there
that
one
of
the
things
I
really
did
there
was
make
reference
to
what
are
almost
profile
sections
in
sibor
and
in
cose
I
mean
there's
actually
documents
kose
documents
that
are
profiles.
I
don't
remember
the
thing,
but
they
actually
call
them
as
profile
call
themselves
a
profile
document,
ned.
L
A
L
And
then
there
was
a
bunch
of
yeah
yeah
go.
I
wasn't
quite
finished
with
the
previous
slide,
but
mostly
just
I
think.
I
think
the
profile
thing
was.
The
main
thing
I
wanted
to
mention
here.
The
rest
of
it
is
just
oh,
the
last
the
last
bullet
there,
the
relationship
of
evidence
to
attestation
results.
Basically,
can
you
know
what
it
means
to
forward
claims
that
are
in
evidence
in
attestation?
Results
you
take
a
claim.
L
That's
an
evidence,
goes
through
the
verifier
and
gets
sent
to
the
relying
party
and
attestation
results.
So
there's
a
there's
text
in
there
that
describes
what
that
should
mean
and
basically
says
you
need
to
understand
the
verifiers
policy
to
know.
What's
going
on
there,
you
can't
just
I
mean
it
doesn't
mean
that
that
you
can
automatically
trust
those
or
or
that
they
automatically
mean
something
so
and
that
was
again
an
outcome
of
discussions
at
ietf113.
L
L
I
don't
see
any
need
for
big
discussion
on
those,
then
there's
just
two
possible
minor
improvements
that
are
kind
of
standing
open
right
now,
one
is
about
the
nonce
right
now
it
says
nonces
are
absolutely
required,
but
there's
the
time
stamp
based
freshness,
that's
in
the
rats
architecture,
and
it
seems
like
each
should
accommodate
that.
It's
probably
not
a
difficult
thing
to
do
and
that
would
make
nonce
optional
if
you're
doing
the
time-based.
L
I
H
Okay,
I
think
I've
said
this
before,
but
but
generally
from
the
semiconductor
manufacturer
perspective
in
the
armed
ecosystem,
for
for
nowadays
not
just
arm,
but
attestations
generally,
don't
treat
endorsements
the
way
the
tcg
does
so
really.
I
want
to
make
sure
that
we
have
our
terminology
correct.
Are
you
using
endorsements
the
way
the
tcg
is
defining
it,
because
the
way
I
understand
it,
an
endorsement
of
the
tcg
as
defined
as
tcg
and
ned?
I
By
the
terminology,
I'm
not
really
trying
to
be
strict
to
one
or
another,
I'm
just
trying
to
figure
out.
How
do
you
deliver
claims
that
really
should
not
be
generated
by
in
a
tester?
So
I'm
trying
to
find
the
logical
way
where
things
that
can
come
from
elsewhere
are
meaningfully
delivered,
and
that's
the
open
question
that
I
I
didn't
understand.
The
closure
of.
L
L
A
So
yeah
gary,
I
I
understand
from
the
eat
point
of
view.
That
is
true,
but
as
arm
is
a
co-author
of
korim
and
they
definitely
do
not
treat
endorsements.
Like
you
just
highlighted,
I
would
not
give
arm
as
an
example
here,
because
I
think
I'm
definitely
uses
what
includes
at
least
the
definition
of
endorsement
from
tcg.
A
A
Also
dave's
maybe
get
that
this
action
brunch.
I
actually
wanted
to
come
here
because
time-based
freshness,
there
are
few
interaction
models
we
planning
on
maybe
an
ayanna
regis
before
it's
a
very
fresh
idea
from
yesterday
and
that
might
go
into
the
reference
interaction
model.
So
if
you're
doing
nonce
and
time
based,
you
might
also
do
epoch
id
and
then
you
would
be
interoperable
with
this
ayana
iterations
of
how
to
do
things,
and
maybe
dave
has
something
to
say
for
them.
M
Okay,
so
the
chairs
will
be
compiling
a
list
of
what
we
see
as
the
open
issues
where
we
don't
see
closure
and
working
group
consensus
so
that
we
can
help
make
chair
decisions
on
that
to
help
this
document
progress
further,
we
may
hold
an
interim
meeting
soon,
depending
on
the
the
length
of
that
it's
probably
likely
to
be
able
to
help
process.
This.
J
I
got
up
here
to
say
that
I
think
the
eat
document
other
than
the
work
in
the
queue
or
whatever.
I
think
the
document
is
okay
with
respect
to
their
questions
that
have
come
up,
meaning.
I
think
there
are
things
that
not
necessarily
even
endorsements
right,
whether
you
can
do
endorsements
in
the
eat
format
or
not.
You
don't
have
to
change
the
original
for
each
document.
If
you
were
to
say
I'm
going
to
do
an
endorsement
in
any
format,
you
can
do
that.
J
J
When
er
lawrence
talked
about
this,
he
said
it
was
a
socket
okay.
At
the
table,
we
came
up
with
a
request
to
have
a
different
type
of
format
in
the
manifest
where
the
manifest
right
now
says,
it's
the
entire
manifest,
not
a
reference
to
one,
and
we
said:
okay
gosh,
it
sure
would
be
nice
if
you
could
have
a
reference
to
a
manifest
okay,
but
we
said
this
is
a
socket,
which
means
you
can
do
that
in
an
extension
document
which
does
not
hold
up
the
eat
spec.
J
K
K
Right,
okay,
I
will
okay,
so
this
is
a
document
that
lauren
sank
and
I
have
put
together
to
register
a
bunch
of
media
attacks
that
are
applicable
to
hit
payloads,
and
this
is
in
a
separate
document
from
the
spec,
because
at
the
time
we
discussed
the
topic
on
the
mailing
list
a
few
months
ago.
Now
the
fear
was
this
would
cause
cope,
creep
and
delay
it,
and-
and
so
we
packed
the
definitions
and
the
registration
into
this
separate
dock
that
has
normative
dependencies
on
both
it
and
uccs
without
bloating.
K
K
K
Next,
please
next,
please,
because,
and
I
have
a
table
yeah
exactly
with
all
the
types
and
and
the
name,
so
we
have
cot
and
jot.
So
we
have
the
two
debs
and
the
two
target
claim
sets
all
under
the
standards
three
with
a
type
application
and
a
nice
subtype
that
starts
with
eat,
dash
and
all
but
all,
but
the
web
tokens
also
have
the
plus
json
plus
super
suffix
and
cotton
jots.
Don't
because
jot
is
not
plus
json
and
we
wanted
symmetry
yeah.
K
Right
and-
and
on
top
of
that,
we
also
define
a
media
type
parameter
for
the
profile.
This
is
completely
optional,
so
certain
apis
may
entirely
disregard
this
existence,
and
some
other
may
instead
want
to
to
use,
make
use
of
it.
For
example,
as
I
said
before,
it
can
be
used
to
pass
the
content
of
the
heat
profile
claim
to
the
upper
layer
processors
while
while
in
transit
right
so
to
help
the
api
routing
infrastructure
and
more
generally
it
it.
K
K
So
next,
please
yeah
here
is
a
successful
negotiation,
where
the
client
is
submitting
some
evidence
for
verification
and
yeah
everything
goes
okay,
so
the
the
content
type
of
the
of
the
of
the
evidence
is
okay.
The
attestation
results
format
are
acceptable
and
therefore
everything
is
finalized
with
with
the
200
okay
in
another
example,
that
is
in
the
next
slide
again
we're
yeah.
Here
we
have
a
the
same
client
submitting
evidence
for
verification,
but
this
time
the
content
content
negotiation
goes
wrong.
K
C
H
I
have
no
objection
to
adoption.
I
think
it
should
be
adopted
this
thomas.
This
is
a
question
for
you,
so
we've
at
least
in
phyto
alliance.
We've
done
interops
with
the
existing
media
types
using
each
and
its
cw
in
its
cot
form,
and
I've
recommended
that
I
recommend
it
to
the
working
group
there
that
we
stick
to
existing
media
types
in
the
case
that
there
are
content
filtering
middle
boxes.
K
H
Okay,
but
I
think
if
there's
some
existing
implementations
that
if
there's
some
existing
implementations,
that
that
maybe
don't
recognize
these
media
types
and
and
and
a
tester
is
producing,
then
then
that
may
fail.
So
I
think
there
may
be
some
interoperability
issues
from
that.
From
that
perspective,.
K
I
don't
know
gary
because
you
know
if
you're
using
an
api,
you
have
to
stick
with
the
rules
of
that
api.
You
have
to
know
what
the
you
know.
Your
urls
are
what
the
media
types
are,
what
what
kind
of
you
know
interaction
model,
you're,
you're
supposed
to
to
use
when,
when
talking
to
that
server
endpoint,
so
I'm
not,
I'm
not
sure
it's
it's
the
case
that
someone
and
a
tester
can
just
create
evidence,
wrap
it
in
the
media
type
and
send
it
over
to
a
a
url
and
okay.
H
Yeah
now
understood
thanks
the
other
reason.
The
other
reason
I
recommended
against
it,
though
I
didn't
put
this
in
writing-
was
that
there
are
content,
filtering
mailboxes
and
particularly
the
dangerous
ones
that
actually
can
intercept
tls
connections.
They
may
it
might
actually
be
better
to
disguise
attestations
in
a
more
general
media
type.
Have
you
thought
about
that?
H
So,
for
instance,
if
the
media
type
is
actually
available
to
the
middle
box,
they
may
say:
oh,
this
is
an
attestation
media
type,
and
if
it's-
and
if
it's
engaging
in
some
money,
it
is
some
under
undesired,
unexpected
behavior,
they
may
actually
drop
it.
Even
though
the
attestation
might
be
very
important
to
the
media
to
the
to
the
communication
session.
K
That's
an
interesting
consideration
and
I
haven't
thought
about
that,
but
I
think
this
will,
you
know,
become
apparent
when
we
use
it.
You
know
I.
We
cannot
say
that
it's
gonna
happen
up
front,
we
we
need
experience
and
if
we
say
that
you
know
in
some
specific
environments
or
deployments
that
is
is
the
case.
Then
you
know
given
based
on
the
experience
we
can.
We
can.
K
H
J
The
teep
working
group,
the
t
protocol
now
has
a
dependency
on
this
document
and
that's
because
it
defines
a
neat
profile
and
it
has
to
have
a
way
of
communicating
that
in
you
know,
content
type
and
accept
headers,
and
so
if
this
could
be
expedited
so
that
this
could
actually
get
to
rfc
before
the
t
protocol
right.
The
t
protocol,
I
would
say,
is
not
imminent.
J
D
C
A
K
K
K
So
this
is
the
junction
between
testation
verifiers
and
the
supply
chain
that
creates
the
attester
whose
evidence
these
verifiers
are
supposed
to
verify
right.
So,
if
you
look
at
the
the
yellow
object
there,
that's
what
column
does
and
the
and
the
red
arrows
the
rest
is
completely
out
of
scope
of
chrome
in
particular.
Appraisal
policies
are
not
are
not
in
scope.
K
So
next,
please,
okay!
So
we
we
we
presented
karim
a
couple
of
times
previously
and
and
we
asked
for
adoption
and
the
working
group
response
was
was
pretty
positive
but
for
unfortunately
ref
values
and
endorsement
we're
not
in
scope
of
charter
zero
one,
and
so
we
had
to
update
the
chartered
for
for
expanding
scope
enough
that
supply
chain
provisioning
was
covered
next,
please.
K
So
the
good
news
is
that
now
we
have
a
main
deliverable.
Two
standardized
interoperable
data
formats
to
declare
and
convey
endorsements
and
ref
values
and
a
related
milestone
too,
and
thanks
to
everybody
for
the
discussion
and
for
the
big
part,
push
for
to
get
the
update
over
the
line,
thanks,
particularly
to
roman,
for
being
instrumental
in
this
work.
K
J
So
I
haven't
reviewed
this
document
before
or
since
ief
113,
but
I
reviewed
it
when
hank
and
I
talked
about
it
before
113.,
and
I
think
I
made
this
comment.
I
think
then,
and
that
I'm
being
consistent,
that
I
support
adoption
for
the
purpose
of
reference
values.
This
was
previously
not
allowed
by
our
charter
or
whatever,
and
now
it
is,
I
think,
and
so
in
that
sense
I
support
adoption.
I
am
a
little
bit
skeptical,
given
that
I
haven't
read
it
that
it's
actually
appropriate
for
use
for
endorsements.
J
Okay,
where
I
think
something
that
is
eat-based
is
probably
better
for
endorsements,
but
I
don't
think
that
should
affect
its
call
for
adoption.
Okay,
but
that's
my
constraint
on
the
scope.
The
reason
that
I
have
a
difference
there
is
that
reference
values,
the
reference
value
provider,
is
typically
providing
a
set
of
reference.
J
A
C
It
would
be
good
if
they
could
provide
that
feedback
and
comment
for
support
on
the
mail
list
right.
So
that's
another
one
that
we
need
more
reviewers,
so
you
know
as
cheers.
We
look
for
at
least
three
reviewers
to
provide
feedback
comment.
You
know
the
usual
questions
of
you
know
willing
to
review
interoperability,
implementation
and
so
on.
So
we
can
do.
E
We'll
talk
about
the
concise
ta
store
spec
next,
if
you
haven't
read
it,
which
I'm
guessing
is
probably
most
link,
is
here
editors
copies
and
that
github
repo
and
I
did
fork
the
the
quorum
guys
work,
which
was
really
good
work
to
implement
this.
So
that's
available
in
my
repo,
depending
on
how
the
strap
goes
we'll
see
if
I
send
a
pr
for
considering
to
merge
next,
oh
actually,
one
thing
on
that.
E
E
So
some
of
those
issues
are
listed
here.
The
life
cycle
of
tas
and
reference
data
is
not
necessarily
the
same.
The
use
cases
for
for
trust
tankers
and
our
viewer
broader
than
the
use
cases
for
core
m
and
then
where
the
keys
would
fall
in
a
quorum
structure,
is
tied
to
co-mids,
and
we
didn't
really
see
a
good
way
to
bend
that
to
support
non-commit
use
cases.
Next.
E
So,
at
the
outermost
level,
the
structure
is
an
array.
It's
an
array
of
ta
stores,
which
is
the
structure
shown
here,
which
has
an
optional
language
type,
an
optional
store,
identity
required
environments,
then
some
constraints
expressed
as
purposes
and
permitted
or
excluded
claims,
and
then
the
keys
themselves
next
slide.
E
So
the
store
identity
was
the
last
thing
added
to
the
spec,
and
that
came
after
talking
to
the
quorum
folks.
This
was
included
to
allow
other
artifacts
in
aquarium
to
reference
a
ta
store,
so
the
structure
we
use
here
is
straight
from
core
m.
You
can
name
a
store
instance
within
that
array,
using
a
uuid
or
text
and
with
an
optional
version.
Next.
E
Attempts
to
the
this
is
what's
most
roughly
analogous
to
the
phytoauthenticator
id
where
we're.
In
that
case,
there
was
a
very
narrow
target
to
use
to
look
things
up
here.
It's
fuzzier,
so
we
pulled
in
a
definition
from
comed.
That's
the
environment
map
we
pulled
in
a
definition
from
co
suid
and
that's
the
abbreviated
squid
tag,
and
that's
really
just
it's.
The
concise
swood
tag,
definition
with
all
the
fields
made
optional,
except
for
one
and
then
a
free
form
text
name.
E
So
next,
in
terms
of
constraints,
you
know
overt
constraints.
The
environments
are
kind
of
a
constraint
too.
We
have
this
eku-like
ta
purpose.
Where
we
list
out
different
things,
you
might
verify
with
a
trust
anchor.
We
do
have
a
draft
written
for
lamps
that
we
didn't
submit
before
this
ietf
that
maps
all
of
these
to
voids.
E
Here
we
have
just
permitted
and
excluded
claim
values,
and
that's
just
using
the
definition
straight
from
heat
next
slide
and
then
keys.
This
is
kind
of
the
meat
and
potatoes
we
require
at
least
one
trust
anchor,
and
then
you
can
include
ca
certificates.
If
you
want
the
trust
anchors,
we
define
three
different
formats:
a
certificate,
a
bear
public
key
encoded
as
a
subject,
public
key
info
and
an
rfc
5914
trust
anchor
info
structure.
E
E
As
far
as
high
level.
Questions,
in
my
mind,
is
the
quorum
extension.
The
way
forward
had
two
voices
on
the
list
that
that
support
doing
this
as
a
quorum
extension
I'm
on
the
fence
about
how
the
environments
are
defined,
whether
or
not
we
could
squeeze
out
some
common
identity
characteristics
from
the
co-mid
and
coast
with
instead
of
having
the
environment
map
and
the
abbreviated
squid
tag
and
then
question
similar
questions
around
the
constraints
mechanisms.
Do
they
adequately
cover
what
we'd
want
to
use
to
set
up
these
limitations?
Are
they
overkill?
E
J
E
J
Just
if
it's
not
specific
to
rats,
I
think
we
might
actually
reference
and
use
this
from
teep
and
we
might
actually
be
able
to
reference
and
use
it
from
suit,
for
which
one
of
the
co-authors
is
a
co-chair.
And
so
I
don't
know
if
rats
is
the
best
working
group
for
this,
but
I
think
it's
very
interesting
work.
So
that's
why
I'm
asking
these
questions.
M
I
I
was
also
unaware
kathleen
moriarty
as
a
participant.
I
was
also
unaware
of
the
draft.
I
should
have
been
aware.
Sorry,
I
was
not
as
tall
as
everybody
else
now
one
thing
so
I
would
like
to
follow
it
wherever
it
winds
up,
but
in
terms
of
like
coast
with
how
is
adoption
of
that
is
that
the
right
choice.
J
M
E
Leave
trust
anchors
wide
open
like
web
pki,
for
example,
we
don't
have
as
tight
of
a
target
as
fido,
which
is
what
we
looked
at
and
figuring
out
what
the
right,
environment,
expression
and
constraint
expression
is
kind
of
the
work
to
be
done.
We
took
this
shot.
If
I
mean
we
don't
want
to
target
things
that
aren't
used
that
way
us
down.
E
M
M
E
M
C
E
A
So,
first
a
lot
of
things.
Unfortunately,
this
is
hank,
so
first
I
saw
the
cd
there
I
already
saw.
I
read
the
draft.
I
see
the
high
synergy
and
reuse
of
types
and
I
see
how
that
helps
your
work.
So
I'm
absolutely
fine,
this
being
an
extension
of
column,
as
speaking
as
a
one
of
the
authors
of
korean
right,
because
that
is
just
there
and
reinventing.
That
would
be
like
weird
and
I'm
happy
that
you
find
reuse
in
some
of
these
structures
so
excellent.
A
Thank
you,
be
it
close
with
or
something
else,
I'm
pretty
agnostic
too.
I'm
very
involved
as
a
contributor
to
spdx
for
two
years
now,
and
they
just
recently
for
the
2.30
version
put
in
a
pointer
to
to
it,
because
pspdx
is
not
really
good
at
being
small,
and
so
they
were
like.
Okay.
If
you
want
to
have
small
file
system
references
and
such
as
characteristics,
you
you
that
can
point
to
there.
A
A
G
E
There
may
be
extensibility
points
we
need
to
add
here
and
there
you
know
that
the
keys
already
came
up
that
way
and
so
they're
probably
a
couple
a
couple
of
those,
but
I
also
don't
want
to
have
extensibility
everywhere,
because
then
it's
I
don't
know
yeah
yeah
all
right.
Well,
that's
it
thanks!
Okay,.
C
So
I
think
what
we
can
do
is
call
for
interest
and
topics.
I
think
there
were
some
questions
raised
with
applicability
and
and
posts
with
carl,
so
we
can
at
least
do
that
and,
as
you
said,
there
were
at
least
two
organizations
and
individuals
that
were
willing
to
think
I
don't
know.
We
were
also
raising
your
hand
to
help
review
and
provide
feedback
and
comments.
E
C
B
Please
I
apologize
for
the
echo.
I
have
no
idea
why.
Let
me
try
and
toggle
the
audio.
Is
that
any
better?
I
can't
hear
you
now,
but
you
may
be
able
to
you
wave
if
that's
better,
we're
actually
fine
simon,
we
weren't
hearing
any
okay,
sorry,
I
was
yeah
okay.
When
I
try
and
take
the
audio
out
from
me,
it
takes
me
oh
well,
okay,
I'm
trying
to
apologize
for
the
feedback.
I
don't
know
quite
what's
happening.
Is
that
any
better
I've
just
lowered
the
volume
from
the
room?
B
B
However,
if
you're
in
a
cloud
server,
that's
that
model
doesn't
work
very
well.
You
end
up
with
nasty
potential
for
bottlenecks,
so
we
wanted
to
cache
the
the
platform
key
and
sign
it
with
a
key
that
is
created
at
various
intervals
in
the
workload
object
and
then
suddenly
the
whole
format,
even
though
your
your
individual
tokens,
don't
really
change
you.
B
So
this
was
this
is
kind
of
nasty,
because
you
then
have
lots
more
code
in
places
you
don't
want
lots
more
code,
whereas
we
actually
wanted
to
be
able
to
just
take
each
of
these
process
each
of
these
tokens
independently
in
a
reference
design.
So,
instead
of
having
to
fully
reformat
the
tokens,
if
each
of
these
elements
is
is
inside
is
that
each
each
of
these
is
an
element
in
the
collection.
B
B
B
So
drafts
series
0
went
to
working
group.
I've
had
various
comments
back,
they
0-1
went
out
addressing
a
few
minor
comments
and
that
had
some
comments,
more
feedback,
which
was
in
things
like
you
know,
please
emphasize
the
security
considerations
and
allowing
for
things
like
one
plus
member,
and
that
is
it
so
I'm
actually
you
know
what
I
didn't
comment
is.
I
would
like
to
pursue
this
for
for
adoption,
but
I'm
both
interested
in
comments
and
review,
and
that
was
it.
K
L
Yeah,
so
I've
spent
some
time
looking
at
this
and
just
a
couple
of
comments
that
I've
made.
I'm
not
sure
I
made
them
publicly,
but
I'll
make
them
publicly
now.
One
of
those
is
that
you
know
I
looked
at
whether
eat
sub
mods
or
the
deb
could
address
the
things.
The
the
issues
that
are
listed
here
and
I
think
they
actually
cannot.
L
One
of
the
use
cases
that
I
understand
here
is
that
I
think
simon
didn't
go
into
is
kind
of
nested
tokens
where
you
know
one
token
is
kind
of
attesting
to
the
to
the
next
token.
I
think
that's
similar
to
dice
the
what
the
way
the
ice
works.
I'm
not
deeply
familiar
with
that,
but
that
was
clearly
something
that
is
not
handled
well
by
eat.
C
M
C
J
So
now
I
wanted
to
come
back
to
the
point
that
hank
made
earlier
at
the
mic,
which
came
up
with
a
hackathon
about
the
topic.
Here
is
freshness
mechanisms
in
a
registry
okay,
so
the
context
is
that
in
the
t
protocol
the
t
protocol
is
one
that
can
accommodate
multiple
freshness
mechanisms,
in
other
words,
whether
you're
going
to
use,
say
the
nonce
claim
or
the
time
stamp
claim
right.
It
can
be
negotiated.
J
So
the
protocol
lets
you
actually
negotiate
that
and
then
you
use
that
with
your
eats
or
whatever,
whichever
one
it
does
and
so
anytime
that
you
have
capability
negotiation,
you
need
an
identifier
to
say
what
the
thing
is
that
you're
negotiating
okay.
So
currently
the
posted
version
of
the
tea
protocol
spec
defines
a
registry
that
has
currently
three
values,
although
you
could
argue
whether
that's
the
right
number
maybe
show
me
up
two
for
whatever
that
says:
nonce
timestamp
and
epic
id,
although
epic
id
is
not
really
well
defined
yet
right.
J
So
that's
why
you
could
argue,
maybe
that
one
doesn't
go
in
the
registry.
Yet,
okay,
I
ended
in
an
early
review
and
said:
okay,
what
page
should
we
put
this
on
the
protocol
registry?
Okay,
because
there
isn't
a
page
for
like
key
parameters
or
whatever
should
they
create
another
one,
and
so
that
begged
this
question
of
is
teep
really
the
only
protocol
that
might
be
negotiating
precious
mechanisms
should
this
be
on
a
tp
page?
J
Should
it
be
on
a
rat's
page,
and
so
if
it
should
be
on
a
rat's
page
that
says,
here's
any
protocol
that
wants
to
negotiate
once
here's
a
registry
to
have
identifiers
in
okay,
if
that
goes
on
a
rat's
page.
That
means
you
probably
want
to
mention
this
in
a
rats
protocol
document.
So
right,
hank
and
I
talked
at
the
hackathon
and
says
if
we
were
going
to
propose
this-
be
a
rat's
registry.
J
What
document
would
you
put
it
in
and
hank
said
reference
interaction
models
is
probably
the
right
place
for
it,
and
so
that's
why
we
wanted
to
bring
it
up
here
and
see
what
the
working
group
thinks?
Okay,
because
if
the
word
does
not
want
to
do
this,
we'll
do
it
in
t.
But
that
seems
to
me
like
the
wrong
place
and
that
moving
this
registry
definition
into
the
reference
interaction
document
was
what
hank
and
I
would
prefer.
So
we
wanted
the
working
group's
feedback
on
that.
J
Sorry
yeah,
the
freshness
mechanism
is,
you
know
how
you
do
in
say
in
a
need.
For
example,
do
you
use
the?
What
is
it
the
iat
or
whatever
it
is
it's
the
name
of
the
claim
for
timestamp
and
nonce
is
the
name
of
the
claim
for
the
nonce
and
so
on.
It
says
which
one
of
those
am
I
going
to
be
using
right
now
you
could
argue
which
I
will
argue
against
to
say
you
could
put
that
as
part
of
the
eat
profile.
J
You
must
use
one
or
the
other,
and
the
profile
says
that
that's
how
e-profile
is
defined
right
now,
so
you
got
to
use
one
or
the
other
or
whatever,
based
on
whatever
you
negotiate,
but
they're
both
optional,
because
you
gotta
have
one
of
them,
but
neither
of
those
mandatory
right-
and
this
gets
to
lawrence's
point
that
says
maybe
not
shouldn't
be
mandatory.
That
should
be
optional,
and
I
gave
him
a
big
thumbs
up
says:
yes,
because
we
can
negotiate
use
of
timestamp
instead
of
that.
J
But
the
rationale
to
not
put
it
in
mandatory
in
the
profile
is
that
this
is
only
one
of
many
different
axes
in
the
profile.
We
don't
want
to
blow
out
and
have
an
explosion
of
number
of
profiles,
because
it
varies
by
freshness
mechanism
and
varies
by
this
and
various
by
that,
and
so
on.
That
says,
really
should
be
an
orthogonal
parameter
and
a
different
numbering
space,
not
part
of
the
of
the
oid
or
uri.
That's
the
profile
definition.
J
Okay,
I
just
want
to
bring
it
up
here
to
make
sure
nobody
said.
That
is
a
really
bad
idea
that
should
stay
out
of
scope
for
rats
or
whatever
it
sounds
like.
There
would
be
no
objections
that
people
are
coming
up
with
right
now
to
doing
that
right,
we
can
put
it
on
the
list
or
whatever,
but
it
means
we
could
go
ahead
and
put
it
into
the
document.
As
part
of
you
know,
the
document
review
process.
J
M
H
H
M
H
Index
so
the
thing
is
is
that
if
we
define
it
with
the
rats,
there
are
other
specifications
like,
for
instance,
fido
device
onboard
specification
that
use
cwt
in
more
broader
context
than
attestation.
So
that's
what
I
would
be
concerned
about.
The
other
thing
is
when
you
talk
about
registries.
Registries
can
be
in
theory,
extensible
and
the
each
spec.
I
don't
see
any
reason
to
expand
beyond
the
three
freshness
mechanisms
that
are
either
so.
L
C
L
So
so
the
I
I
I
don't
have
a
strong
opinion,
one
way
or
the
other,
but
a
few
questions.
One
question
is:
if
I,
I
didn't
think
that
the
number
of
freshness
mechanisms
was
that
open-ended
like
there
isn't
really
more
than
a
few
two
or
three.
So
why
do
we
need
a
registry?
Okay?
The
other
thing
is:
why
are
we?
Why
are
we
negotiating
freshness
mechanisms
but
not
negotiating
crypto,
algorithms
or
or
something
else?
J
Yeah,
so
just
to
answer
in
the
t
protocol
and
negotiates
both
cypher
suites
and
freshness
mechanisms
and
the
handshake,
so
one
side
says
here's
my
supported
set
of
freshness
mechanisms,
often
just
one
right
and
here's
my
set
of
cypher
suites
and
then
in
the
response.
It
can
then
include
an
attestation
payload,
which
could
be
evidence
or
could
be
at
the
station
results
if
it's
in
the
passport
model
right.
J
Okay,
so
on
the
question
of,
are
there
additional
ones?
Besides
those
three
and
this
gets
the
question
of
the
reference
interaction
models
document
is
technically
not
eat,
specific
and
technically,
neither
is
the
rat's
architecture
right,
and
that
is
because
it
accommodates
proprietary
formats
right
at
the
t
package
on
table,
we
had
people
using
a
proprietary
attestation
format,
meaning
sgx
reports.
Okay,
sgx
reports,
don't
use
suit
or
each
claims
at
all.
Do
they
have
a
freshness
mechanism?
Sure
it's
a
proprietary
one.
That's
existed
for
a
long
time.
J
Right
arm
probably
has
one
too
that
exists
and
they're
already
deployed
attestation
mechanism,
and
so
the
nonce
claim,
for
example,
has
a
specific
set
of
bite-sized
ranges
right.
It
must
be
between.
I
remember
it
was
8
and
64
bytes
or
something
like
that
right.
So
you
can
imagine
someone
that
says.
Well,
I've
got
a
six
byte
one
or
a
60.
You
know
a
72
byte
one
or
whatever.
Therefore,
it's
not
the
same
thing
as
what
knots
would
be
registered
as
because
that
means
it
not
claim.
J
You
could
argue
that
that
needs
a
different
precious
mechanism
number
in
the
registry,
and
so
somebody
like
a
vendor
like
intel
or
arm
should
be
allowed
to
register
a
freshest
mechanism.
That's
the
one
that
they're
already
using
okay,
so
there
might
be
three
standard
ones
or
whatever.
The
number
is
two
four
and
there
could
be
vendor-specific
ones
for
things
that
are
already
deployed
that
are
in
use
right
now.
A
Hi,
this
is
hank,
so
maybe
probably
around
closing
remarks
on
this
topic.
The
interaction
models
basically
are
flavors
of
these
freshness
characteristics
that
we
have,
and
so
that's
why
we
put
it
in
there
because
to
differentiate
those-
and
I
think
again,
as
they've
already
highlighted,
there
are
existing
solutions
that
will
benefit
from
classification
like
that,
and
they
can
easily
tailor
it
around
them
and
yeah.
I
heard
that,
especially
for
the
epoch
id,
for
example,.
C
A
Totally
a
different
topic,
open
mic
topic:
I'm
not
going
there.
We
did
not
provide
an
update
on
the
daa
id,
but
we
just
recently
initiated
by
dave,
had
an
internal
review
around
on
comments
on
special
on
inconsistency
in
the
text.
So
that's
why
we
did
not
provide
an
update
today,
there's
working
on
this,
and
I
think
we
are
pretty
close
to
getting
a
work
first
working
group
last
call,
but
but
let's
find
out
okay,
we
have
to
do
this
internal
round.
A
We
have
to
go
to
the
list,
get
get
the
questions
out
there
you
can
look.
Does
it
look
fine
to
you
and
if
that
is
somehow
stable,
I
think,
maybe
before
november
we
can,
you
can
call
it.
But
but
again
I
wanted
to
just
give
a
small
update
on
dia
was
not
worth
a
slide,
so
yeah,
but
we're
working
on
this.
A
C
Okay,
so
to
recap
from
today
the
device
subscription
draft
we'll
do
an
early
yankee
review.
The
is
it
air
force,
r4c
draft
you're,
waiting
for
closure
on
the
heathcraft
heat
needed
types.
We'll
do
a
call
for
adoption
same
thing
for
the
foreign
draft,
we'll
do
a
call
for
pinterest
on
the
ta
stores,
tara
and
shoot
the
last
one.