►
From YouTube: IETF112-RATS-20211108-1200
Description
RATS meeting session at IETF112
2021/11/08 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
Okay,
great
I'm
gonna,
let's
dive
into
this,
so
welcome
everybody
to
the
rats
working
group
meeting
the
session
is
being
recorded.
Let
me
go
through
a
little
bit
of
the
note
well
overview
just
for
all
so
we're
all.
On
the
same
page,
it's
participation
in
itf.
You
agree
to
the
following:
ietf
processes
and
policies.
A
Any
anyone,
that's
aware
of
oitf
contributions
that
are
covered
by
patents
or
patent
applications.
There.
You
have
a
duty
to
disclose
that
as
a
participant
in
the
or
an
attendee
to
the
ietf
activity.
You
acknowledge
that
written
audio,
video
and
photographic
records
of
the
meeting
may
be
made
public
personal
information
that
you
provide
to
ietf
will
be
handled
in
accordance
with
ietf
privacy
statement.
A
And
a
few
notes
for
a
meeting
tips
just
make
sure
your
audit,
your
video,
is
off
unless
you're
sharing
the
presentation
mute
your
microphone
using
unless
you're
speaking
use
a
headset
strongly
recommended
a
session
blue
sheet
is
automatically
generated
based
on
the
ietf
data
tracker,
logins
chat
rooms
and
media.
Echo
are
connected
to
the
jabra
chat
rooms
on
ietf
data
tracker
and
there's
more
information
there
as
well.
A
Just
a
quick
review
of
the
code
conduct
right.
Itf
participants
are
expected
to
respect
and
courteously
and
be
courageous
to
their
colleagues.
At
all,
have
ex
participants
are
expected
to
have
impersonal
discussion
participants,
devise
solutions
for
the
global
internet
and
meet
the
needs
of
diverse
technical
and
operational
environments?
A
The
it's
an
information
sheet,
all
all
folks
are
are
available.
Have
that
available
thanks
to
thomas
fasadi
and
michael
richardson,
for
volunteering
to
scribe
and
take
notes
for
this
meeting.
I
will
say
michael
you're
up
your
first
speaker
and
so
we'll
need
someone
else
to
volunteer,
at
least
during
that
first
talk.
So
if
somebody
could
could
do
that,
that
would
be
great.
A
So
we
have
a
full
day
today.
So
please
be
you
know,
sensitive
to
time
the
a
lot
of
time
for
the
various
speakers
and
we'll
try
to
try
to
fit
it
all
in
so.
First
up
is
a
rat's
architecture
overview
with
michael
richardson,
and
I
can
I
believe
I
have
those
slides
here
so
michael.
B
B
Since
april
we've
been
waiting
for
the
shepherd
write-up
to
finish
and
we're
waiting
for
the
isg
reviews
just
to
start
and
the
design
team
hasn't
met
since
april
anticipated
multiple
times
that
we
would
have
to
restart
when
we
got
area
director
reviews,
but
we
haven't
gotten
there
and
we're
not
sure
why
we
haven't
gotten
there,
and
I
guess
there's
another
new
ipr
claim
that
has
been
the
chairs
have
posted
about,
and
I
have
no
particular
opinion
about
it,
and
so
it's
really
just
discussion
of
what
it
is.
B
We're
waiting
for
and
what's
going
on
and
that's
about
it
go
ahead.
Kathleen
good.
C
Morning
so
when
as
shepherd,
I
did
the
call
for
ipr,
I
did
receive
a
message
that
we
need
to
wait
until
around
december,
and
so
that's
what
happened,
and
now
we
have
the
ipr
claim
from
intel
that
the
working
group
has
to
decide
what
their
decisions
are.
As
to
you
know
what
we
do
on
that
go
forward
so
that
that
was
the
hold
up
and
so
that
that
person
didn't
send
it
out
to
the
group
they
sent
it
individually.
It
wasn't
really
my
place
to
put
that
out
to
the
group.
C
B
Okay,
it
would
have
been
great
for
the
group
to
know
that
we
have
to
wait
to
december,
even
if
we
didn't
know
why
that
would
have
been
wonderful
do.
Is
there
still
some
additional
area
reviews
that
we
should
have
been
getting
at
this
point,
though,.
C
The
area
reviews
kick
in
once
it
goes
into
the
adq,
because
that's
how
the
the
various
people
like
tarot,
who
does
the
section
reviews
knows
where
to
kick
it
off
so
so
it
held
it
up
and
I'm
sorry,
I
didn't
feel
it
was
my
place
to
disclose
other
people's
information
or
to
put
some
vague
message
out
on
the
list.
That
would
force
their
hand
to
say
something.
C
B
Yeah,
so
someone
else
has
got
some
stuff
on
the
list
here.
So,
let's
move,
are
you
done
with
that
part?
Kathleen.
B
D
Good
morning
and
good
afternoon,
good
evening
kind
of
everyone
yeah.
I
just
wanted
to
comment
on
a
couple
things,
so
so
nancy
just
put
out
something
on
the
mailing
list.
I
think
yesterday
or
the
day
before
about
the
ipr
stuff
and
just
to
explain
kind
of
how
to
handle
that
yeah.
We
definitely
have
consensus
to
proceed
with
that
document,
but
since
we
got
the
new
information
on
with
kind
of
the
ipr,
I
just
want
to
make
it
clear
about
what
needs
to
happen.
D
So
what
the
working
group
needs
to
do
is
decide
hey.
We
have
some
ipr
claims.
This
may
or
may
not
change
what
we
do
with
the
document,
but
we
need
to
positively
confirm
that
we
want
to
proceed
kind
of
forward
with
the
information
we
have.
So
what
would
be
great
on
the
mailing
list
is
not
to
debate
what
the
nature
of
kind
of
the
ipr
claim
is
it's
to
kind
of
talk
about.
What
is
a
working
group?
We
want
to
do
with
that
document
relative
to
that
ipr
claim
thanks.
B
So
do
we
have
are
all
of
the
claims
actually
now
submitted,
or
are
we
still
waiting
to
december
for
additional
information.
D
I
need
to
help
answering
that
question.
I
believe
that
there
is
something
more
coming
in
and
we
should
definitely
kind
of
characterize
and
have
that
conversation
on
the
mailing
list.
A
So
this
is
ned.
I
believe
that
the
status
is
that
the
for
the
the
ipr
that
intel
is
aware
of
they've
contributed
that,
according
to
the
disclosure
agreement,
which
includes
what
the
terms
are,
the
the
there
was
a
request
that
was
made
by
someone
on
the
list
directly
to
me
to
identify
to
to
be
able
to
go
to
the
patent
office
directory
and
view
the
work
in
progress.
A
B
E
So
hi
everybody
so
whatever
here
now
is
independent
of
content
of
ipr
claims.
The
working
group
should
agree
how
to
move
forward.
I
read
from
the
shepherd
document
and
I
absolutely
agree
with
that.
We
want
to
move
forward.
So
what's
the
vehicle
we
are
using
here
now
is
someone
initiating
a
call
for
do?
We
want
to
move
forward
and
everybody
is
like
yeah.
We
want
to
do
that
and
then
we
just
barge
ahead
until
we
hit
the
road
block.
E
B
I
would
say
that
if
you
can
make
an
a
form,
an
opinion
without
having
read
the
patent,
that
our
app
patent
application
that
you
could
express
a
view,
it
may
be
that
you're
never
going
to
read
the
patent
because
many
of
us
are
advised
not
to,
and
so
all
that
matters
are
the
terms.
B
So
I
would
say
we
don't
have
to
remain
dormant,
but
we
don't
have
to
that.
We
probably
can't
finish
our.
We
can't
form
a
conclusion
until
other
people
who
do
wish
to
read
it
are
able
to
read
it.
E
Okay,
just
a
very
uninformed
and
individual
opinion
here
I
think
the
claim
is
about
section
3
and
3.1,
and
I
have
no
idea
how
that
should
work.
So
I
am
a
little
bit
on
the
side
of
yeah.
Let's
just
proceed
with
that
and
see
how
that
is
tied,
some
ipa.
I
should
be
tied
into
that.
I
I'm
not
sure
that's
a
relevant
blocker.
To
be
honest,.
B
I
guess
it
applies
to
the
layered
attestation
more
than
anything
else
is
what
I
think,
but
I
don't
know
because
I
haven't,
we
don't
know
what
the
content
is
dave.
F
You
guys
hear
me
okay,
yeah,
so
yeah.
I
think
we
should
proceed.
I
mean
I
had
hypotheses
about
what
one
or
more
patents
might
apply
to,
whether
my
hypothesis
is
right
or
wrong
is
not
the
main
point,
but,
for
example,
if
there
were
patents
on
say
the
com,
I
think
there's
two
of
them
right
now,
the
you
know
total.
Let's
say
that
there
was
one
on.
You
know
the
composite
device
section.
Let's
say
that
there
was
one
on.
F
You
know
direct
anonymous
attestation,
even
if
there
was
one
on
layered
at
that
station,
which
would
be
the
hardest,
because
that's
part
of
a
tcg
standard.
But
maybe
but
my
point
is
this-
is
an
architecture
document.
This
is
not
one
that
one
claims
compliance
to
in
an
implementation
per
se
right.
You
do
that
to
you
know,
eat
and
other
documents,
and
the
architecture
document
covers
multiple
different
ways
of
doing
things.
So,
like
composite
device
is
not
you
know,
mandatory
direct
anonymous
attestation
is
not
mandatory,
even
if
an
architecture
document
could
be
mandatory.
F
The
point
isn't
that
all
of
rats
fits
under
this
particular
category.
There's
multiple.
The
point
of
the
architecture
was
to
say
that
hey,
oh,
we
lost
you
dave.
F
You
went
mute
rationale
for
saying
I
think
they
should
go
forward,
because
I
think
that
it
is
very
unlikely
that
any
patent
could
cover
the
entire
document.
You
could
always
find
some
way
of
implementing
a
coin,
a
document
that
would
limit
the
applicability
of
any
particular
patent.
I
am
not
a
lawyer,
but
I'm
saying,
based
on
the
things
you
know
that
I've
seen
so
far
of
applying
to
specific
sections.
I
don't
think
that
should
block
the
entire
document
just
because
one
section
that
would
be
narrower
would.
F
But
again
I
can't
comment
on
the
specific
patents,
but
just
the
general
rule
that
says:
okay.
If
any
patent
covers
one
way
of
doing
things
and
there's
other
multiple
ways
of
doing
things,
that's
one
reason
why
I
should
go
for
it
anyway,
and
the
other
reason
I
should
go
forward
anyway
is
because
this
is
a
it's,
not
something
you
claim
compliance
to
per
se.
So
thanks
that's
my
opinion.
B
I
would
agree
with
you:
roman
go
ahead.
D
Yeah
hi,
just
to
repeat
what
I
put
in
chat,
I
mean
I
I
want
to
make
sure
there
is
an
ambiguity
on
how
we're
supposed
to
handle
this
in
terms
of
the
process.
So
we
have
something
on
the
mailing
list.
Saying
hey.
We
have
these
ipr
claims.
We
need
positive
confirmation
kind
of
from
the
working
group,
so
feedback
here
is
kind
of
great.
H
Can
you
guys
hear
me
yeah
yeah,
so
I
was
a
little
bit
surprised
by
this
by
this
development,
particularly
because
we
have
made
a
lot
of
investment
in
in
the
at
the
station
technology
and
obviously
with
our
contributions
to
open
source,
and
we
were
hoping
that
many
of
the
developers
open
source
developers
either
directly
through
our
code
or
indirectly,
through
other
libraries
utilize
this
and
every
time
there
is
sort
of
patent
claims
on
documents
it
scares
off
developers.
H
Unfortunately,
they
are
not
going
to
make
an
assessment
of
the
patents,
because
that's
typically
something
they
cannot
do
and-
and
in
our
case
we
are-
are
not
allowed
to
look
at
those
patent
claims
or
to
make
any
judgment
about
it.
So
so
that
looks
pretty
bad
for
the
work
we've
been
contributing
to.
Overall,
that's
my
first
remark.
The
second
remark
is
about
the
timing
and
and
the
way
the
procedural
aspect
of
it
it
it.
H
It
doesn't
look,
give
a
or
shine
a
great
light
on
on
the
work
in
the
group
when
the
co-chair
and
who
happens
to
be
document.
Also,
then,
very
late
in
the
process
contributes
a
patent
delays.
The
work
further-
it's
it's
just
it's
just
not
how
things
should
be
done
in
my
opinion,
and
I
wonder
whether
this
whether
we
should
just
take
this
as
an
example
of
not
publishing
the
document
at
all
on
preventing
further
harm
to
the
industry.
In
that
case,
that's
my
view.
A
Okay,
thanks
for
sharing
your
view,
we
are
out
of
time
for
this
topic.
We
can
bring
it
up
again.
On
friday,
there
there's
some
open
mic
time.
B
I
All
right,
I
can
hear
you,
this
is
gonna,
be
a
short
update
because
we
did
get
this
adopted
by
the
working
group
since
the
last
iepf.
I
will
because
it's
gonna
take
a
very
short
update.
I
just
add
one
claim
that
I
put
in
the
note.
I
don't
think
patents
themselves
are
bad.
I
think
it's.
The
ipr
claims
actually
can
protect
from
other
people
down
the
road,
but
we
want
to
make
sure,
of
course,
is
that
there's
nothing
that's
going
to
apply.
I
Royalty-Wise,
so
just
to
answer
at
least
with
a
few
of
my
minutes,
hannah's
claim,
I
don't
think
it's
actually.
I
think
I
think
patents
can
be
good
as
long
as
it's
royalty-free
right
so
jumping
onto
event
stream
subscription.
As
I
mentioned,
we
now
have
a
a
in
ietf
draft
zero,
zero,
there's
a
slide
which
we've
been
presenting
ever
since
the
first
rats
group
that
shows
a
relationship
of
many
of
the
giraffes
together.
I
The
subscription
itself
is
dependent
on
the
chara
draft,
which
is
now
an
a.d
review
and
roman
we're
done
most
of
the
comments
and
replying
to
them.
That
should
be
coming
to
you
in
a
day
or
so,
and
that's
an
ad
review,
as
is
the
basic
attestation
draft
for
routers,
which
guy
is
spearheading
and
that's
also
an
ad
review,
and
you
know
the
working
group
last
calls
we're
just
discussing
is
complete,
so
we
now
have
a
just
adopted
subscription
draft
with
a
lot
of
dependencies
that
go
through
a
number
of
drafts.
I
Basically,
the
idea
here
is
that
the
subscriber
to
a
router
or
switch
or
some
piece
of
network
equipment
will
go
ahead
and
use
a
rpc
to
say,
subscribe
to
the
device
and
go
ahead
and
give
me
pcr
quotes
from
that
device
over
time,
either
periodically
or
let's
say
whenever
something
changes
on
the
pcrs
and
that's
really.
The
the
magic
of
this
draft
is
that
it's
difficult
to
maintain
freshness
of
quotes
if
you're
not
continually
sending
a
a,
not
a
new
nonce.
I
Now,
without
going
through
all
the
specifics,
because
you
can
read
them,
there's
a
number
of
things
in
the
document
and
I
encourage
you
to
read
them
as
we
progress.
It
includes
things
like
sequence,
diagrams
ways
of
measuring
freshness,
looking
at
event
stream
to
make
sure
that
we're
able
to
get
the
signed
quotes
from
the
pcrs,
as
well
as
the
raw
data
that
went
into
the
pcrs
in
terms
of
events
that
are
recorded
in
the
tpms
and
then
talks
about
other
things,
such
as
filtering
the
events
at
the
attester
doing
a
replay
of
those
events.
I
I
So
our
plans
in
the
coming
weeks
and
months
are
to
respond
to
any
changes
if
any
on
the
yang
model
upon
which
is
a
dependent,
because
chara
model
is
going
to
have
some
very
minor
tweaks.
You
know
maybe
nothing
that
even
impacts
this
draft
and
then
once
the
chair
gets
through
the
ad
review
and
the
isg,
then
you
know
see:
if
there's
any
changes
there.
Then
progress
the
itf
part
of
that
into
the
into
the
rest
of
the
process.
I
That
being
that,
once
the
ietf
model
for
shower
is
done,
we
can
go
ahead
and
do
yang
doctor
reviews
and
other
things
for
the
yang
model
for
the
subscription
draft
and
then
add
anything
else,
that's
needed,
and
so
that's
pretty
much
it
we're
just
going
to
continue
through
the
process.
Thanks
for
your
adoption.
A
J
Yeah
hi,
you
are
showing
the
slides.
I
am
good,
so
we
wanted
to
quickly
talk
about
uccs
next
slide.
J
F
J
That
this
tag
applies
and
the
ccs
actually
is
quite
similar,
but
but
not
entirely
the
same
as
a
jwt
claim
set.
So
it's
a
map,
a
video
set
of
something
that
I
called
claims
in
in
jwt
and
which
we
also
call
claims
that
way.
J
But
actually
all
these
claims
together
form
the
the
predicate
part
of
an
assertion,
and
this
is
very
useful
and
it
can
be
used
to
to
make
all
kinds
of
signed
assertions
and
so
on,
and
what
has
turned
out
is
that
sometimes
it's
actually
possible
to
do
the
same
thing
with
some
other
form
of
protection,
for
instance
a
secure
channel
that
makes
clear
who
is
making
that
particular
assertion.
J
That
is
protecting
this
uccs
and
therefore
it
seems
like
a
good
idea
to
to
have
a
tag
for
just
the
the
naked
ccs
itself.
Of
course,
you
cannot
say
naked,
so
we
say
unprotected
next
slide.
J
We
actually
don't
have
anything
normative
to
say,
because
essentially,
we
are
just
defining
a
tag
for
a
data
structure
that
is
already
defined
in
83
92..
So
why
do
we
write
a
document
now?
The
reason
is
that
it's
really
too
easy
to
confuse
the
uccs
with
the
cwt,
and
that
is
a
criticism
that
has
repeatedly
been
made.
J
So
yeah
writing.
A
document
always
provides
some
some
opportunity
to
do
little
things
at
the
side
and
one
thing
that
came
up
but
but
hasn't
been
incorporated
in
the
latest
draft.
There
is
just
a
branch
on
the
the
repo
for
that
we
could
actually
provide
a
cda
specification
for
the
cwe
claim
set.
J
The
the
cwt
rfc
predates
the
completion
of
the
cddl
rfc.
So
at
the
time
it
requires
some
some
special
dance
to
have
cddl
in
in
a
normative
document,
and
we
could
fill
in
that
gap
now,
which
would
make
it
easier
to
use
cwt
in
general.
J
The
other
suggestion
that
has
been
made
is
that
we
could
use
as
use
this
as
an
opportunity
to
do
a
grand
unification
between
jwt
and
and
cwt
and
yeah.
This
is
probably
not
what
we
want
to
do,
and
I
mean
even
if
we
do
start
such
a
grand
unification
project,
we
probably
don't
want
to
put
it
into
this
document,
because
the
timelines
are
very
different
next
slide.
J
We
also
have
a
review
from
thomas
fasati,
with
lots
of
great
editorial
suggestions
that
we
want
to
include
so
that
there's
a
little
bit
more
work
needed.
That
hasn't
happened
yet,
and
the
plan
is
to
submit
a
new
version
with
or
without
the
cddl,
and
with
that
editing
and
working
group
plus
call
that
questions.
E
Click
all
the
buttons
okay,
I
clicked
all
the
buttons.
Thank
you
so
yeah,
thanks
carson
for
that
presentation
of
the
state
of
the
affairs.
I
think
we
are
really
okay
on
the
the
scoping
here
today.
E
That
has
been
discussed
multiple
times
already,
and
I
think
everybody
got
somehow
used
to
the
idea
that
uccs's
are
context
specific
and
I'm
happy
to
see
this
in
rats
as
a
first
iteration.
First
of
all,
and
then
I
I
think
that
yeah,
we
really
have
to
get
our
backlog
of
comments
done
and
and
thomas
already.
E
I
think,
unfortunately,
for
him
is
aware
of
that,
so
I
think
it
will
be
done
in
the
next
course
of
the
next
weeks
in,
in
contrast
to
our
typical
pace,
and
so
what
I'm
I'm
unfortunate
here
is
yeah.
We
will
do
the
update
and
and
please
stay
tuned,
because
that
could
be
the
id
that
will
have
a
working
goobras
call.
Thank
you.
K
A
All
right
so
looks
like
we're
done
with
that
topic.
K
So
I'm
commenting
here
now
about
the
dash
11
version
of
eat
that
was
released
like
a
two
weeks
ago.
It's
a
pretty
large
set
of
changes.
K
F
K
That
yellow
box
down
at
the
bottom
is
claims
that
are
suitable
for
attestation
results,
so
one
of
them
is
the
dloa
which
I
presented
at
the
last
meeting,
and
then
there
is
verification
results
and
then
over
overall
verification
results
and
software
measurement
results
are
also
claims.
F
K
The
only
things
that
are
this
this
shows
a
little
bit
of
a
couple
areas
where
maybe
there's
some
comments
about
whether
it's
ready
for
last
call
or
not.
But
personally,
I
think
that
it
is
all
ready
for
last
call,
so
I'm
going
to
go
through
yeah.
Let's
go
to
the
next
slide.
K
So
one
of
the
this-
this
is
a
slide
I've
been
presenting
for
a
while
of
that
work
was
needed
to
unify
terminology
with
the
rats.
K
And
remove
a
lot
of
the
text
that
that's
that
was
there
before
there
was
rats
architecture.
Some
of
that
text
is
is
like
three
years
old.
So
that's
all
done.
K
We
rely
on
rats
and
cwt
rats
architecture
at
cwt
for
verification
procedures,
so
that
was
removed.
F
K
So
kind
of
this
is
the
kind
of
the
the
laundry
list
of
changes
that
were
done
in
the
dash
11
draft,
I'm
going
to
kind
of
go
through
and
speak
to
them,
one
by
one.
I
don't
have
details
on
each
one,
but
I
don't
think
that's
necessary.
K
So
first
of
all
the
the
technology
is
now
or
the
terminology
is
now
consistent
with
the
rats
architecture
and
cwt
and
jwt
documents.
K
I
added
a
claim,
as
for
a
simple
software
name
and
software
version,
as
an
alternative
to
having
a
coast
width
to
describe
the
software
coast,
woods
have
the
are
fairly
large
and
complicated
when
you
just
want
a
software
name
or
in
software
version
and
cos
widths
are
not
available
in
json.
K
So
that's
why
that's
there
there's
the
dloa's
claim
that
was
presented
last
meeting.
So
that's
all
in
their
detail.
There
is
a
software
software
results
claim.
So
this
claim
is
you
know
the
description
of
the
for
for
attestation,
results
that
describes
the
results
of
comparing
a
software
measurement
to
the
expected
values.
K
That
was,
I
believe,
discussed
last
meeting
as
well,
but
wasn't
in
the
document.
So
now
the
the
oem
id
claim
was
improved.
It's
clarified
that
it's
only
for
hardware.
F
K
It
wasn't
clear
that
that's
what
was
the
case.
It
allows
use
of
the
pen,
the
private.
K
Private
enterprise
enterprise
number
also
allows
a
randomly
generated,
oem
id
claim,
which
could
be,
which
can
be
a
hash
of
something
else.
So
then
there's
a
a
lot
more
examples.
The
lamp
examples
are
all
filled
in
in
in
detail.
K
There's
also
example
of
a
a
measurement
and
a
detached
bundle
which
I'm
going
to
talk
about
in
a
slider
to
here.
Okay,
so
now
has
cddl
in
there
now
for
a
claim
set.
This
was
the
the
same
as
the
claims
that
that
karsten
was
was
talking
about
I'm
going
to
go
into
detail
on
that
in
following
slides,
it
defines
a
ujcs,
the
json
equivalent
of
a
uccs.
K
This
is
what
carson
thought
we
should
not
define.
I
put
it
in
the
document
to
have
a
clear
articulation
of
it.
So
so
I
I
actually
I
see
you,
you
see
the
comments
here.
K
I'd
actually
appreciate
it,
if
you
guys,
let
me
finish
and
go
through
a
lot
of
this
before
you
jump
to
conclusions
and
things
that
would
be.
I
think
that
would
be
really
helpful
to
see
what
what
I
actually
have
to
say
about
this
before
you
are
going
there.
K
K
There
are
a
bunch
of
clarifications
and
improvements
on
nesting
of
one
eat
inside
another
that
and
the
the
work
on
detached
bundles
actually
drove
me
to
a
lot
of
the
structuring
of
the
cdl
to
get
that
all
to
work
and
to
validate.
So
it's
it's
to
me.
It's
kind
of
a
you
know:
it's
a
real
nice
goal
here
to
be
able
to
write
the
cdl
for
the
whole
specification
and
then
have
it
automatically
verify
against
the
the
diagnostic
example.
K
A
That's
in
the
next,
that's
in
the
next
batch.
If
you
want
to
jump
to
that,
we
can
do
that.
K
Yeah
I've
been
yeah,
okay,
I
said
many
times
many
times.
That's
where
I
wanted
it.
Oh,
okay,
yeah!
I
know
that
yeah.
This
is
yeah
because
so
okay,
so
this
is
the
dev
slide.
So
this
is
still
part
of
the
the
dash
11
changes,
and
so
I'm
still
in
my
first
block
of
of
work
here.
Okay,
so
at
the
tax
to
eat
bundle
the
basic
I'm
only
going
to
introduce
the
topic
here
briefly,
just
to
get
you
so
everybody
kind
of
has
some
idea
that
it
exists.
K
The
so
on
the
the
the
picture
on
the
left
shows
and
eat,
which
is
you
know,
a
some
claims.
It
claims
that,
as
carson,
I
believe,
says
a
ccs
if
it's
cbor
format,
which
has
the
cose
headers,
the
coset
payload
and
a
cose
signature.
K
F
K
It
has
a
software
name
and
software
version,
so
what's
what
detached
here
is
that
you
can
take
the
the
claim
set
for
xxx
the
sub
module,
which
is
basically
a
ccs
or
a
seaboard
map
that
has
the
two
claims
and
detach
it.
K
So
it
goes
outside
of
the
eat
and
in
this
particular
and
then
what
goes
in
the
sub
module
section
is
a
digest
of
that
or
a
hash
of
that
that
claims
that
so
you're
in
in
detaching
your
you
know,
you're
able
to
take
the
claim,
set
and
transmit
it
outside
of
the
heat
in.
F
K
Some
other
some
other
way,
so
there
is
the
the
detached.
Bundle
is
a
way
to
take
the
the
eat
and
the
detached
claims
and
send
it
together.
You
do
not
have
to
send
it
together,
but
to
find
a
way
to
send
it
together.
K
So
the
reason
why
you
might
do
this
is
it
allows
you
to
build
a
smaller,
a
tester
that
basically
can
be
kind
of
a
like
an
attestation
hardware
block
where
the
claims
are
built
outside
of
the
attestation
block
and
then
the
claims
that
can
be
the
hash
of
a
claim
set
can
be
fed
into
the
attestation
hardware
block
through
something
like
a
pcr
that
a
tpm
has.
K
Basically,
when
I,
when
I
you
know
for
for
a
long
time,
I've
thought
that
it
would
be
a
good
thing
to
have
a
to
be
able
to
build
such
a
hardware
attestation
block
that
does
eat
any
format.
So
this
is
the
the
way
to
do
that.
So
I
I
don't
want
to
spend
a
huge
amount
of
time
having
the
discussion
on
that
right
now.
I
didn't
there
wasn't
really
time
in
the
agenda
for
that
so,
and
this
is
not.
F
K
Priority
to
get
through
that,
it's
more
the
the
cw
jwt
issue.
Discussion
is
more
important
to
me
here.
So
so
that's
detached
each
bundle,
so
you
can
go
look
at
that
in
the
in
the
latest
draft,
so
that
is
it
for
my
first
part,
so
I
think
we
can
move
on
to
the
next
part
here.
A
L
On
I
see
dave
thaler
on
the
queue
I
didn't
know
david.
You
had
a
question.
F
I
do
have
a
question
but
you're
free
to
tell
me
if
you'll
cover
it
later,
but
I
suspect
not
because
my
comment
is
so.
First
of
all,
I
want
to
say
I
like
what
you
did
with
the
sub
mod
stuff,
so
I
think
that's
very
useful.
Thank
you.
The
comment
that
I
had
was
you
know
you
had
the
slide
that
had
all
the
green
stuff
saying
ready
for
last
call.
F
So
I'll
repeat
my
comment
now,
along
with
a
thank
you
for
another
change
that
you
made,
I
think
the
document
is
ready
when
it.
This
is
a
personal
opinion
when
it
also
meets
the
teep
requirements,
and
since
I've
mentioned
this
at
the
last
two
ietf
meetings,
I'll
mention
it
again
that
the
teep
architecture
had
five
requirements
for
things
that
were
not
in
the
old
eat.
F
Spec
I
and
I
had
asked:
can
we
merge
those
into
the
main
document
and
out
of
the
general
section
of
hank's
draft
suit
rats
claims
because
they're
not
specific
to
teep
or
suit
they're,
just
general
things,
one
of
those
was
version,
and
so
you
mentioned
you
added
software
versions.
Now
you
have
both
software
version
and
hardware
version,
just
a
separate
claims,
and
so
I
think
that
one
is
now
checked.
So
thank
you
for
adding
that.
F
I
think
that
checks
off
that
and
I
think
that
obsoletes,
what
hank
you
had
in
the
in
the
version
claim
there
there's
four
other
ones
that
I
have
not
seen
in
there,
and
so
my
question
is-
and
you
may
not
have
an
answer
right
now
is:
is
there
already
some
other
way
to
do
those
or
do
you
plan
on
adding
those,
because
I
think
that's
what
would
block
going
to
rfc?
K
Yeah,
so
I
wrote
some
emails
about
that.
I
had
some
comments.
B
K
That
and
I
I
don't
remember
what
I
wrote
right
now
in
detail,
I
know
I
I
thought
some
of
them
were
very
much
suit,
specific
and
not
lined
up
with
general
stuff.
F
K
Other
ones
that
aren't
sure
the
the
detailed
discussion
of
some
of
those
those
things.
I
I
think
we
need
to
go
back
to
that
discussion
and-
and
so
just
look.
F
At
that
that,
I
don't
think
it's
ready
for
last
call
in
my
personal
opinion,
until
those
four
are
either
in
there
or
until
there's
an
argument
that
says
there's
already
something
in
there
that
covers
those
four
requirements.
So
that's
my
opinion
so
and
I
see
hank
is
in
queue,
so
he
has
a
different
opinion.
So.
E
I
think
yeah,
it's
also
probably
not
different,
but
the
these,
these
kinds
of
identifiers
and
identities
we
are
dealing
with
in
in
that's
like,
of
course,
on
multiple
conceptual
messages,
and
one
of
these
is
the
reference
integrity
manifest
the
concise
one.
So
I
think
we
can
borrow
semantics
from
there.
E
What
I
really
like
to
have
is
to
us
don't
see
that
semantics
change
anymore,
because
we
took
like
a
year
with
several:
let's
call
them
harvard
of
trust
stakeholders
to
to
get
them
right,
and
so
so,
if
you
want
to
borrow
them,
maybe
that's
not
for
the
current
eat
it,
but,
but
we
can.
We
can,
of
course
I
think
either
includes
a
notion
that-
and
these
can
be
these
claims
for
each-
please
add
them
to
cwt
registry
or
do
another
id
that
says.
E
K
Yeah
my
my
request
here
really
is
for
engagement
that
I
think
that's
the
most
important
thing
I
feel
like.
I
haven't,
had
comments
about
a
lot
of
the
stuff.
F
K
People
haven't,
read
them
or
or
or
and
stuff.
So
please,
like
gary,
said
file
issues
and
follow
follow
up
with
the
comments
I
mean.
That's
that's
what
I
I
think
is
really
important
here.
E
Yeah,
the
the
thing
is
that
that
we
are
not
working
on
each
here.
We
are
working
on
the
other
side
of
the
things
that's
coming
from
supply
chain
and
endorsements
and
such
so
so
yeah.
Our
direct
need
is
not
to
fire
a
issue
on
it,
but
but
maybe
we
should
align
anyway.
So
so
the
synchronization
is,
I
think,
key,
but
I
would
not
put
honors
on
one
of
the
parties
to
to
to
to
jump
into
the
pool
of
the
other.
E
So
so
maybe
we
should
join
and
and
and
some
some
design
meetings
here.
I
think.
L
K
K
All
right,
so
I'm
going
to
talk
about
these
three
things
here,
cddl
for
a
claim
set
that
is,
for
both
stibor
and
jason,
for
on
talk
about
ujcs
and
talk
about
nesting
eats
next
slide.
K
K
K
I
mean
my
sense
is
that
there
is
agreement
that
eat
and
all
the
eat
claims
are
to
be
in
both
seaboard
format
and
json
format,
so
eat
is
either
a
cwt
or
a
gwt.
K
J
Yeah,
I
I
just
wanted
to
point
out
the
difference
between
what
what
other
documents
that
define,
both
sibo
and
and
json
representations
of
the
thing
same
thing
do
and
what
what
you're
trying
to
do
here
cwt
was
never
designed
to
be
a
mirror
of
jwt.
F
J
They
are
not
the
same
thing,
and
so
I
think
we
need
a
slightly
different
approach
to
to
solving
the
formal
description
issue
for
cw3t
and
jwt,
and
I
would
love
to
find
find
a
good
way
to
do
that.
But
we
first
have
to
give
up
on
the
premise
that
these
two
are
just
interchangeable.
Literally,
they
aren't.
K
So
I'm
I'm
looking
for
I
mean
I
again.
I
can
understand
to
some
degree
what
you're
saying
I
don't
know
exactly
what
you're
seeing
as
the
difference
here,
but
I
I
understand
that
I'm
kind
of
looking
for
a
solution
to
be
able
to
do
what
I
thought
we
were
agreed
on,
doing
and
eat
where
eat
was
both
could
be
either
a
cwd
or
a
jwt.
K
So
I'm
open
to
solutions
here
on
how
to
do
this
other
than
what
I've
what
I've
done.
So
I
put
you
know,
there's
a
bunch
of
stuff
in
in
in
the
dash
11
draft.
There
was
stuff
in
the
dash
tender
after
the
dash
9
draft
for
all
of
this
before
the
stuff
in
the
dash.
11
draft
is
much
improved
and
it's
working
with
validation
in
a
lot
of
good
ways.
K
So
so
I'm
going
to
continue
on
on
here
and
because,
because
some
of
the
some
of
what
I'm
doing
here
is
kind
of
problem
statement
and
describing
a
solution
that
I
I've
come
up
with,
and
then
let's
see
what
comes
out
of
that,
so
it
claims
that
I
mean
that's
the
sort
of
the
core
of
the
uccs
carson
referred
to
this
as
a
ccs.
K
So
I
have
defined
cdl
for
a
claim
set
and
I'll
show
it
in
a
few
slides.
So
a
claim
set
is
basically
a
group
of
label
value
pairs
that
that
it,
you
know,
pertain
to
a
device,
a
subsystem,
a
transaction,
a
result,
something
right.
Both
cwt
and
jwt
revolve
around
the
claims
that
they're,
both
groups
or
a
label
value
paris.
Preston
referred
to
that
as
an
assertion.
K
K
The
other
way
to
look
at
it
is
that
it
is
a
really
useful
structure
to
sign
and
or
encrypt
so
the
you
know
the
payload
for
cose
or
jose.
So
so
this
this
part
seems
largely
in
common
between
cwt
and
jwt,
so
seems
very
useful
to
have
cddl
for
a
claim
set.
K
That-
and
that
seems
like
that,
can
mostly
work
for
both
seabor
and
jason,
the
the
definition,
the
cdl
for
claims,
that
is
the
same
in
sea
war
and
jason
I'll
get
to
that
in
more
detail.
K
So
then,
you
go
off
and
define
all
the
individual
claims
in
cdl
and
they
just
plug
right
into
actually
using
a
cdl
socket.
They
plug
right
into
the
claim,
set
cdl
structure.
So
then,
so
that's
when
you're
constructing
claims.
You
write
them
in
the
cdl
to
plug
into
the
claim
set
structure.
When
you
want
to
have
a
pro
when
you're
you're
designing
a
protocol
that
needs
to
have
a
claim
set
in
it,
then
you
just
refer
to
claim
set
and
that
you
can
just
use
all
the
off
off
the
shelf.
E
J
Yeah,
I
agree
that
when
you
design
new
claims
that
are
designed
to
be
both
in
jwt
and
cwt,
it's
certainly
a
relief
to
to
only
have
to
write
the
city
there
once
so.
I
think
that
that's
a
good
thing
and
and
developing
some
some
standards
convention
agreed
way
to
to
write
the
city
is
definitely
a
good
idea.
So
I'm
with
you
on
that,
I'm
just
not
sure
that
we
we
can
retroactively,
apply
this
to
things
that
are
already
out
there.
K
Nest
one
claim
set
in
in
another
so
having
the
you
know
to
write
the
cddl.
For
that
I
mean
I
needed
to
have
the
the
cdl
for
a
claim
set,
and
I'm
going
to
I'm
going
to
tell
you
why
I
even
want
to
put
seaboard
claim
sets
inside
json
claim
sets
and
vice
versa.
K
Okay,
so
here's
the
the
cdl
for
a
claim
set.
The
really
the
important
important
important
part
is
the
first
line
there.
K
So
a
claim
set
is
a
map
or
the
first
entry
in
that
in
that
map
is
a
plug
claim,
set
claims
where
you
plug
more
claims
in
so
then,
and
the
the
second
line
there,
the
with
the
dot
feature
control,
that's
a
kind
of
a
catch-all
to
make
sure
that
anything
that
is
not.
F
K
In
the
in
the
socket
is
in
the
right
format
with
the
label,
but
your
primary
thing
is
the
the
cdl
for
claim
set
claims.
So
then
what
you
do
is
when
you
define
a
claim
in
this
case,
I'm
I'm
giving
an
example
of
the
the
subject
claim
from
both
cwt
and
jwt,
which
is
just
a
text
field.
K
Of
a
claim,
so
if
you're
off
inventing
claims-
and
you
know
some
other
document
in
suit-
or
something
like
that-
you're-
basically
writing
things
that
plug
into
that
socket
that
look
like
that
and
then
because
labels
are
integers
in
seaward
or
you
really
want
them
to
be,
and
that's
kind
of
the
point
you
wind
up
with
assigning
the
label
twice,
you
can
actually
assign
it
with
a
slash
equals
as
well,
so
the
label
can
be
either
the
the
integer
or
the
text
string
and
json
next
slide.
K
Is
that
the
cti
jti
claim
in
its
text
in
jwt
and
bytes
and
binary
in
cwt?
So
this
is
definitely
an
issue
between
the
two.
I
don't
have
a
solution
for
it.
It's
also
an
issue
generally,
where
you
know
a
claim
in
cbor
is
bytes
by
string
and
it
needs
to
be
base
64
encoded
in
json,
and
this
this
comes
up
yeah.
You
know
as
an
issue
with
the
cdl
validation
tool,
so
kind
of
been
skipping
around
that
one,
but
that
that's
an
issue.
K
I
was
kind
of
looking
for
some
solution
to
it.
So
next
slide.
K
There's
hanks
on
the
cube
by
the
way.
Okay,
sorry,
I
keep
switching
between
the
yeah
go
ahead.
E
E
I
would
also
not
have
a
good
solution
how
to
deal
with
bytes
and
if
you're,
going
to
into
the
tech
space
that
that
seems
to
me
that
yeah.
E
K
So
then,
now
that
we
now
that
there
is,
I
mean
this
is
the
cdl.
This
is
all
taken
directly
from
from
the
dash
11
draft.
K
F
K
In
for
ujcs
the
you
know,
the
kind
of
equivalent
of
of
the
uccs
there's
no
tagging
in
jason,
so
all
you
do
is
write.
A
ugcs
message
is
just
a
claim
set,
so
this
is
in
the
dash
11
draft,
as
it
is
right
now.
G
K
K
Okay,
so
here's
why
I
think
ujcs
is
important,
so
jason
is
far
more
widely
used
in
seabor.
If
uccs
is
important,
why
isn't
ujcs
important?
K
I
mean
we're
taking
the
trouble
to
define
uccs.
Why
aren't
we
taking
the
trouble
to
find
to
define
ujcs-
and
you
know
today-
backends
use
json
in
a
huge
way.
K
K
Jwt
has
this
kind
of
null
cipher
thing
that
you
can
do
to
to
have
a
kind
of
the
equivalent
of
a
ujcs,
but
it's
kind
of
lar
a
bit
large
and
awkward.
Basically,
you
have
to
construct
a
a
jose
message
with
algorithm
equals
null,
so
it
seems
kind
of
like.
Why
would
you
do
that?
I
mean,
I
think
the
reason
they
did.
It
is
because
we're.
K
Be
explicit
that
this
this
thing
is
not
signed
and
secured,
so
you
should
know
that,
and
you
should
know
you're.
K
Not
signed
into
outside
insecure,
maybe
it's
the
sort
of
the
the
spiritual
equivalent
of
all
the
security
considerations
that
are
in
uccs,
but
I
mean
to
me
that
is
sort
of
an
unnecessary
and
awkward
overhead.
F
K
The
to
the
rp
is,
usually,
you
know,
b2b
kind
of
back
end
stuff,
so
here
jason's
highly
appropriate
and
people
probably
look
at
us
funny.
If,
if
we
were
saying
you
should
use
seabor
there,
so
that
seems
like
a
place
where
ujcs
is
useful
and
where
we
would
want
to
be
using
ujcs
next
slide.
K
So
maybe
some
people
have
have
disagree
about
the
first
point
about
it
not
being
much
work,
but
it
didn't
seem
too
much
work
to
me.
I'm
certainly
not
talking
about
going
back
through
all
the
the
entire
cwt
and
jw
registries
and,
like
you
know,
making
them
all
retroactive
and
cdl
for
them,
and
all
that
so
just
mainly
the
seven
claims
that
both
cwt
and
jwt
have
writing.
K
Just
writing
cddl
for
those,
because
some
of
those
are
definitely
reused
in
hate
I
mean
we
could
even
not
write
the
cdl
for
some
of
those.
What's
what's
really.
K
Is
that
the
the
central
claims
that
document,
and
then
you
know
if
you're,
if
you're,
writing
a
ujcs
document,
I
think
the
security
considerations
from
uccs
would
be
exactly
the
same.
K
You
know
you'll
be
going,
you
know,
re-encoding
claim
sets.
Sometimes
between
seaport
and
jason,
I
mean
I'm
working
on
a
tool
that
does
that
it
makes
all
the
nesting
constructs
in
eat
the
sub
modules
and
the
detached
claims
that's
more
complex.
K
Okay,
next
slide.
K
All
right
so
now,
this
is
getting
to
some
of
the
reasons
why
I
got
to
to
this
in
the
the
design
work.
So
why
do
you
nest
seaborn
coded
tokens
in
json,
encoded
tokens
and
vice
versa?
Why
do
you
do
that?
K
The
answer
is
com
composite
devices
and
the
testers
so
you're
going
to
have
I
mean
in
that
there's
there's
the
the
diagram
from
the
rats
architecture
document
there
so
you're
going
to
have
the
testers
feeding
tokens
into
other
attesters,
so
you
can
see
a
tester
b
and
a
tester
c
are
feeding.
You
know
fully
full
signed
attestation
evidence
into
a
tester
a
now.
K
You
might
be
assembling
a
a
device
like
a
car
or
a
phone
or
maybe
a
whole
nuclear
power
plant,
or
something
like
that
where
you
have
you're
getting
devices
from
lots
of
different
vendors
and
you
want
to
aggregate
them
all
next
slide.
Please
go
back.
K
Can
you
thank
you
so
you're
gonna
you're
gonna
be
getting
devices
off
the
shelf.
That
happened
to
have
a
testers
and
they
are
not,
as
necessarily
all
going
to
use,
cbor
or
not
all
use
json,
and
you
don't
want
to
when
you're
you
know,
building
a
composite
device
you
and
that
that
you
want
at
a
station
for
the
whole
device
made
up
of
all
the
different
components
you
don't
want
to
have
to
say.
Well,
I
can't
use
that
that
device,
because
it's
a
json,
a
tester
and
I'm
only
using
c4.
K
You
really
don't
want
that.
So
you
that
put
push
puts
us
to
the
point
where
you
need
to
put
cwts
inside
gwts
and
gwts
inside
cwds.
So
you've
got
to
do
that.
So
there's
also
the
scenario
where
all
the
composite
evidence
might
not
be
signed,
so
you
might
be
putting
the
the
output
of
a
tester
b
might
be
a
uccs,
and
that
might
be
okay
for
that
particular
architecture.
K
Because
of
the
way
those
devices
are
put
together-
and
it's
understood
that
you
know
chester
b
is
producing
some
some,
I
mean
actually
the
whole
in
in
this
diagram.
K
Tester,
a
b
and
c
could
all
be
producing
tokens
that
are
not
signed
because
you're
relying
on
tls
to
for
the
verification
to
go
to
the
verifier.
K
K
That's
why
that
seems
like
you
need
the
mixed
now.
One
of
the
things
I
clarified
in
the
dash
11
draft
was
that
this
this
mixed
encoding,
the
only
place
that's
allowed,
is
when
you're
putting
one
token
inside
another.
You
can't.
F
K
You
know
have
a
a
few
claims
and
json
and
a
few
claims
in
cbor
I
mean
the
whole
token
has
to
be
either
siebel
or
jason.
It's
just
when
you're
nesting
tokens
that
you
can
go
switch
between
seabor
and
jason
next
slide.
K
So
here's
the
summary
of
the
all
the
the
six
token
formats,
so
there
are
sign
tokens
in
seaborne
json.
There
are
unsigned
tokens
in
seaport
and
jason
and
there
are
devs
that
are
in
seaboard
adjacent,
so
you
get
you
get
the
fan
out
of
six
different
token
formats
and
any
one
of
these
tokens
can
be
put
inside
the
other
one
of
these
tokens,
because
you
want
the
full
flexibility
of
to
put
stuff
in
so
the
way
the
dash
11
draft
handles.
K
This
is
that
it
uses
seaboard
tags,
so
a
sub
module.
That
is
a
nested
token,
has
a
seaboard,
a
seabor
tag
or
is
a
seabor
tag
that
says
which
it
is,
whether
it's
a
cwt
jwt
and
so
on.
If
it's
a
if
it's
a
json
format
token,
you
know,
how
do
you
put.
K
How
do
you
do
that
in
jason,
because
jason
doesn't
have
tags,
so
I
came
up
with
this.
This
structure,
the
the
cd
cdl
of
which
is
there,
which
is
basically
just
an
array
of
two
things,
a
type
string
and
the
actual
token
so
trying
to
be
as
simple
as
possible
and
also
trying
to
be
make
use
of
seaport
tags
and,
like
you
could
do
this
simple
tagging
thing
in
cbor
as
well,
but
I
decided
to
use
seaport
tags
that
seemed
more
natural
so
than
to
use
the
same
structure
in
both.
K
Towards
the
end
here
next
slide:
yeah,
okay,
so
that
was
it
go
back.
You
can
go
back
so
in
order
to
construct
cdl
for
all
of
these
things,
which
I've
and
and
examples
and
verify
all
of
them.
I
had
to
have
a
that
definition
of
claim
that
works
in
both
jason
and
sabor.
So
I
mean
there's
a
consistent
hole
there
in
the
the
in
the
dash
11
draft,
where
all
of
this
stuff
is
is
working
most.
K
A
We
have
two
more
minutes
for
this
topic.
There's
a
couple
of
minutes
for
this
topic
and
then
we'll
have
five
minutes
for
to
cover.
Last
call,
you
know
issues.
J
Yeah,
I
just
sent
a
couple
comments
to
the
jabba
to
the
message
queue.
I
think
what
what
you're
doing
here
is
some
some
pretty
interesting
on
the
cw20
and
jwt
world
that
I
think,
requires
semantics
and
not
just
the
syntax
how
to
carry
these
things
around.
J
So
it's,
for
instance,
not
quite
clear
what
what
the
claims
within
such
a
detached
thing
or
nested
thing
have
to
do
with
the
claims
in
in
the
main
cwt,
and
I
think
it
would
be
a
good
idea
to
to
understand
this.
J
This
processing
a
little
bit
better
and
I
think
it
should
not
be
a
problem
to
actually
put
a
signed
message
inside
a
claim
set
because
in
in
that
case,
it's
clear
what
what
is
being
signed-
and
it's
also
pretty
clear
that
the
the
signature
of
the
nested
thing
is
not
influencing
any
individual
claims
in
the
outer
claim
set.
But
I
think
putting
information
in
there
that
is
nested
and
even
of
a
different
format
than
the
the
main
claim
said
that
that
is
more
complicated
than
then
may
appear
on.
J
On
a
first
look,
so
I
I
would
be
a
little
hesitant
to
say
we
already
understand
what
that
means.
Tons
of
different
claims
can
be
defined
and
these
claims
interact
with
other
claims
and
come
up
with,
unfortunately,
relatively
complicated,
combined
semantics.
J
What
we
call
feature,
interaction
in
istn
25
years
ago,
is
unfortunately,
coming
up
here
again,
so
you
really
need
to
understand
how
these
things
work
together,
when
they
suddenly
are
hidden
away
in
a
hash
that
you
may
not
even
be
able
to
resolve
at
the
time
when
you
check
the
main
claim
set.
So
all
I'm
trying
to
say
is
this
needs
some
some
significant
analysis
before
we
really
understand
what
what
is
being
designed
here
and
I'm
all
in
favor
of
doing
that
analysis.
K
Yeah,
so
let's
separate
the
semantics
from
the
syntax,
I
mean
the
semantics
of
a
sub
module
and
a
nested
token.
I
mean
that
those
those
are
you
know
that
issue
has
been
there
since
you
know
day
one
with
sub
modules
and
it
that
issue
is
there
whether
we
combine
you
know,
do
both
jason
and
seaport
or
not
so,
and
I
mean
and
then
there's
some
discussion
in
the
draft
and
there's
about
that
and
there's
there
have
been
discussions
about
that.
K
So
I
mean
personally,
I
thought
that
was
a
settled
issue,
because
it
it
has
been
there
for
years.
What
is
at
issue
here
for
me
is
how
to
do.
You
know
how
to
do
the
keyboard
inside
the
json
and
the
jason
inside
highlight
this
yeah
and
then
the
jason
said
the
snowboard
how
to
how
that
how
to
do
it,
syntactically
and
how
to
do
it
with
cedl
hank.
E
Yeah
hi
lawrence.
Yes,
I'm
I'm
a
little
bit
yeah,
sorry
to
say
that
I
think
we
should
some
to
do
some
divide
and
conquer
here.
I
don't
see
the
ujcs
and
uccs
converging
anytime
soon,
because
it's
not
a
central
problem.
It's
a
it's
a
it's
a
process,
procedural
problem
and
a
semantic
problem,
and-
and
I
really
want
to
have
it
done
like
seriously
and
then
another
pose
of
doing
that
to
doing
that
work,
but
I
would
like
to
cut
it
out
and
do
it
in
a
different
place.
E
To
be
honest,
so
that's
just
me
maybe,
but
if
we
are
starting
to
to
trying
to
solve
this
here
in
this
document,
this
will
take
more
than
a
year.
I
am
afraid
so
so
so
I'm
not
against
tackling
the
problem.
Actually,
I
actually
want
to
have
a
solution
that
makes
merges
the
rams
of
of
people
reading
and
working
with
something
json
an
everyday
basis,
but
in
the
end
what
they
really
want
is
to
have
something
useful
and
and
and
scalable
and
similar,
and
it
should
be
somehow
feeling
like
the
same
thing.
K
So
so
no
note
also
that
in
some
of
the
claims
like
the
manifests
claim
and
the
measurements
claim
that
allows
other
formats
that
are
pluggable,
so
you
can
do
co-switch
suit
and
and
a
switch.
So
you
can
put
like
an
xml
document
inside
a
any
token.
That's,
and-
and
we
have
to
do
that,
server.
E
As
a
value
that
is
agnostic
to
the
cwt
ram
at
the
very
least
or
it's
a
it's
a
co
suite
and
then
you
can,
you
can
understand
the
the
structure
because
you're
doing
the
same
encoding
but
but
I
think
you're
you're,
comparing
apples
and
origins.
Sorry.
A
Have
a
conversation
on
last
call
issues,
this
sort
of
feels
like
it's.
The
last
call
conversation.
Do
you
wanna
yeah,
move
to
the
next
segment.
K
Yeah
I
wanna
one
one
other
comment
here
is
I
mean
I
I
hope
everybody
can
see
how
I
got
to
where
I
got
to,
and
you
know,
if
we're
gonna,
try
and
trim
and
and
sidestep
this
issue,
maybe
we
figure
out
which,
what
what
do
we
do
and
do
we
give
up
on
the
maybe
we
give
up
on
the
on
the
json
part
I'd
rather
give
up
on
that
than
the
other
than
the
the
sub
modules
part,
and
then
I
also
would
really
like
to
hear
what
the
issues
are
that
are
so
difficult
here
at
least
write
an
email
and
get
and
give
me
some
idea
here
I
mean
I
know
of
a
few
issues,
but
you
know
hank
and
carson
have
both
spoke
about
that
these
these
issues
are
quite
large
and
I'm
not
sure
I
see
that
and
I
think
it
would
be
really
helpful
for
the
group
to
understand
what
those
issues
are.
A
You
thank
you
so
gary
you're
up
next
we're
gonna
review,
eat,
open
issues.
G
I
hope
everybody
can
hear
me
so
this
will
be
brief.
I
know
we've
been
discussing
a
little
while
and
this
will
not
include
if
this
is
not
include
the
previous
discussion
on
some
modules,
uccs
etc.
G
So,
let's
move
on
to
the
next
slide,
please,
okay,
as
per
ietf
one
one
one
I
had
submitted,
I
submitted
materials
that
it
to
as
part
of
that
meeting,
I
didn't
get
a
chance
to
present,
so
I
had
to
post
those
after
the
after
meeting,
but
I
at
that
time
I
said
I
would
be
classifying
issues
in
github
repo,
as
last
call
blocking
so
far.
I
have
not
found
I
only
we
have
only
one
issue
unresolved.
G
That's
currently
last
call
blocking,
and
I
don't
believe
that
that
should
be
a
that
should
prevent
us
from
going
to
last
call
now,
that's
leaving
aside
any
of
the
discussion,
that's
happening
on
the
chat
window
or
in
the
or
prior
in
the
prior
half
hour
of
discussions.
So
far,
let's
move
on
to
the
next
slide
thanks.
G
The
last
issue
is
a
rather
old
one,
as
you
can
see
from
the
number
it's
15..
It
is
so
broad
that
I'm
not
sure
I
can
close
it
in
good
faith.
At
the
same
time,
there's
been
no
activity
on
it.
It's
just
a
general
comment
on
should
must
consistency.
G
I
do
think
we
can
close
this
issue
mainly
because
I
think
it
will
cut
mainly
because
I
think
it's
just
too
it's
just
too
difficult
to
resolve,
and
I
expect
during
the
during
the
course
of
resolving
last
call
comments.
This
this
will
come
up
again
should
must
consistency,
and
so
I
I
and
by
the
way,
just
an
overall
comment.
G
I
view
last
call
as
the
first
step
towards
our
eduard's
long
process
to
rfc,
not
the
last
step
and
I'm
expecting
to
in
expecting
the
document
to
undergo
several
revisions
as
we
as
we
resolve.
Not
only
working
group
last
call
comments
but
ad
comments,
as
well
as
a
broader
review,
ayanna,
iesg,
etc.
So
so
I
think
some
some
some
people
may
be
in
the
impression
that
last
call
is
a
is
is
a
last
step.
G
G
G
I've
actually
submitted
a
formal
request
for
the
cwt
claims
review
for
an
expert
review
on
the
claims
that
have
been
identified
in
the
each
spec.
I
haven't
heard
any
response
on
that
yet
ella,
but
but
I
expect
that
that's
in
the
queue
for
cwt
claims.
That's
your
expert
review,
then
the
final
one
was
say:
the
sub
modules
related
to
it
related
to
target
environments.
G
Actually
I
don't
believe
we
should
resolve
that
either
prior
to
last
call,
because
I
would
like
the
I
would
like
to
see
what
the
rats
architecture
experts
when
they
do
actually
review
this
document,
as
part
of
the
last
call
actually
say
about
the
concept
of
submodules.
G
Okay,
yeah,
okay,
so
just
to
be
clear,
I
think
there
is
some
discussion
in
the
chat
window.
We've
already
been.
You
know.
At
least
I've
been
under
the
impression
that
the
github,
the
github
repo,
is
where
we
file
issues.
G
It
is
sometimes
a
little
difficult
for
me
personally
to
track
issues
on
the
mailing
list,
so
I
I'm
not
a
you
know,
I'm
not
saying
we
close
out
the
issues
now,
but
I
think
I
think
I
think
what
I
would
recommend
to
the
working
group
to
think
about
is
if
there
is
a
claim
that
that
that
needs
that
you
they
feel
needs
to
be
added
to
this
fact,
first
review
the
spec
to
see
if
an
existing
claim,
that's
already
described,
does
not
meet
the
yeast
case.
G
Second,
consider
whether
the
whether
whether
it
makes
more
sense
as
a
profile
and
each
does
have
the
concept
of
profiles,
so
so
there
are
so
so
the
you,
and
that
would
actually
mean
that
you
can
actually
bring
in
a
suitable
claim
set
for
for
your
particular
use
case
even
after
it
goes
to
rfc.
A
Thank
you.
So
we
do
have
some
time
to
discuss
readiness
for
last
call,
and
so
there
was
some
some
chat
on
the
list
of
people
expressing
opinions
that
they
think
it's
ready
from
the
perspective
of
the
group.
That's
here
today
we
get
get
a
sense
for
who
who
is
thinks
it's
ready
to
go.
F
All
right
and
again,
you
guys
hear
me,
okay.
I
know
I
glitched
for
a
second
there,
everybody
over
here,
okay.
F
Okay,
cool
yeah
and
thanks
gary
and
and
lawrence
for
your
comments.
I
appreciate
them
and
I'm
probably
not
going
to
say
what
you
think,
I'm
going
to
say,
but
I'm
going
to
say
that
see
a
couple
of
potential
ways
forward
that
I
would
like
to
hear.
The
working
group's
opinion
on
this
is
specifically
on
the
the
cheap
question
I
raised.
I
think
we
had
the
discussion
before
that
for
the
class
of
things.
We're
talking
about
a
profile
is
not
really
what
we're
talking
about
for
this
class
of
stuff.
F
There's
a
separate
things
that
we're
already
having
a
profile
for,
but
out
of
the
otherwise
there's
at
least
three
potential
ways
forward.
Just
summarizing
things
that
have
come
up
in
the
chat,
one
is
to
say:
well,
we
could
have
a
separate
document,
okay,
that
ex
that
adds
some
additional
general
non-profile
specific
things
to
to
eat,
and
you
really
have
to
have
the
eat
document
and
this
other
document
we
gotta
wait
for
before
you
can
actually
do
an
implementation
in
certain
contexts.
That
would
need
the
claims
that
are
in
that
one.
Okay.
F
Another
way
that
we
could
do
things
is
to
say
any
comments
here
is
done
as
part
of
last
call,
meaning
you
just
issued
the
last
call
on
the
current
version
and
you
treat
this
stuff,
in
which
case
we
might
have
to
do
a
second
round
of
review
and
stuff,
and
gary
kind
of
mentioned
this
one,
which
I
agree
with
your
comments.
F
Carrie
that
says
you
know
you
might
have
multiple
rounds
of
review
right
last
call
is
the
beginning,
not
the
end
right
plus
one
to
all
of
that,
and
so
that's
one
way
of
doing
it.
In
that
sense,
you
know
nothing's
really
last
call
blocking,
but
there
are
times
that
working
groups
do
multiple
do
last
call
multiple
times,
okay,
and
so
I
don't
like
having
to
do
it
multiple
times.
F
If
you
can
avoid
that,
and
so
I'm
trying
to
minimize
work,
but
that
is
a
possibility
and
then
the
third
one
lawrence
or
somebody
one
of
you
two
had
said:
okay,
it's
possible.
If
there
were
non-controversial
stuff
to
add
that
in
there
and
then
start
working,
your
last
call
my
preferences
for
that
one.
F
If
we
can
do
that-
and
that's
just
because
I
would
like
stuff
to
be
reviewed
all
at
the
same
time
rather
than
doing
multiple
rounds
of
reviews,
and
so
that's
why
my
preference
is
to
treat
it
as
if
you
can
do
it
dash
12,
add
in
the
four
little
sections
out
of
draft
perk
holes.
If
you
think
that
those
are
non-controversial
and
lawrence,
I
did
see
that
you
said
within
the
next
day
or
two.
You
do
an
evaluation.
F
That
would
be
fine
with
me
to
defer
the
decision
until
and
then
talk
about
it.
The
next
next
rats
meeting,
if
you've
had
a
chance
to
do
that
during
the
week.
So
that
would
be
lovely
but
either
any
of
those
three
possibilities,
I
would
say,
would
be
possible
ways
for,
and
I
would
not
object
to
any
of
those
just
my
preference
is
to
do
it
as
part
of
the
first
working
your
blast
console.
Thank
you.
E
So
thanks
dave,
so
first
of
all
any
decisions
here
should
maybe,
if
there's
only
a
few
days
of
more
input
to
make
a
decision.
I
think
that
is
fine,
of
course,
especially
in
the
course
of
the
itf
meeting
here
right
now.
Having
said
that,
I
do
not
see
a
easy
solution
to
resolving
anything
in
in
a
blob,
as
I
think
was
your
preference.
So
unfortunately,
I
have
to
say:
let's
get
the
cbo
based
stuff.
E
That
was
the
initial
cwt
space
out
now,
maybe
anchor
some
preliminary
sockets
in
the
document
to
enable
the
next
document
and
do
it
in
parallel.
That's
me
just
one
opinion.
I
I
see
the
point
of
of
resolving
this
all
at
once
makes
a
better
document.
I
I
really
see
that.
Unfortunately,
I
don't
think
this
is
will
be
done
until
the
end
of
next
year.
To
be
honest,.
G
Yes,
thank
you
yeah.
I
guess
one
general
comment
following
up
on
dave's
dave's,
we
can
go
through
at
least
on
the
tt
items
and
before
you
know,
hopefully
me
and
lawrence
can
turn
this
around
with
the
next
day
or
so,
and
we
can
and
we
can
even
put
out
you
know
a
version
12
before
the
friday
meeting.
I
believe
I
believe
the
submit
tool
should
be
open
again
today.
G
I
guess
going
back
on
what
hank
said,
though,
on
the
general
cddl
versus
versus
jot
representation
well
unsigned,
unsigned,
json
claim
representation
that
wants
to
discuss.
G
Would
it
be
possible
hank,
in
your
opinion,
to
actually
to
actually,
if
you
think,
it's
going
to
take
a
minimum
of
a
year
to
actually
potentially
take
e
to
rfc,
but
then
have
a
follow-up
document
that
builds
off
of
each
that?
Could
that
would
also
be
it's
it'd,
be
its
own
standards
track,
which
we
do
all
the
time
updates,
rfc
xxx,
for
instance,.
E
Exactly
yeah
yeah,
I
think
this
is
consecutive.
I
think
eid
is
our
our
basis
and
and
from
there
we
can.
We
can
build
a
lot
of
rather
cool
things
I
think
from
it,
and
and
and
I
think
we
should
not
stop
following
the
route
or
the
trail
that
lawrence
is
blazing
here,
but
but
I
think
we
should
should
cut
it
at
some
point,
because
we
are
really
waiting
for
this
and-
and
I
like
I
like
to
see
a
good
transformation.
E
L
L
Yeah
my
clarification
question
gary
is
you're
volunteering
to
to
rev
version
12
to
address
some
of
the
the
teep
suit
stuff,
but
to
hank's
comment
of
calling
out
the
cd
this
that
I
can't
speak.
Sorry,
would
you
be
able
to
address
that
also
with
the
version.
K
To
do
what
hank
is
asking
basically
turn
the
document
into
a
c
bar
only
document
remove
all
the
json
stuff
out
of
it.
I
think
that's
what
I
understand
that
that
seems
not
possible
by
friday
and.
K
E
Not
lower
my
hands,
I'm
apologize
and
then
yes,
the
the
the
lawrence.
That
is
not
the
thing
for
friday.
I
think
that
the
friday
ask
was
the
cheap
claims
that
the
dave.
A
Okay,
so
sounded
like
there
was
some
consensus
for
that
dave's
in
the
queue.
F
I
just
want
to
say
on
that
nesting
point
separately.
I
think
the
teep
use
cases
do
require
the
ability
to
do
nesting,
although
teep
is
only
using
seabor
independent
of
the
cheap
stuff.
My
preference
is
probably
for
the
same
reasons
as
florence
mentioned,
to
keep
the
json
stuff
in
the
existing
document.
F
I
think
there
are
use
cases
for
json,
and
so
I
would
rather
do
minimal
changes
and
try
to
get
the
document
out
sooner,
even
if
that
means
that
you
know
json
nesting
or
something
like
that
was
in
a
separate
document,
and
I
say
that
because
I
don't
think
anything
is
currently
blocked
on
it.
F
But
I
think
it's
an
important
use
case
and
I
don't
think
it's
worth
major
changes
to
the
document
that
might
be
destabilizing,
which
is
what
I
got
the
impression
from
lawrence
that
it
might
be
destabilizing,
and
so
we
could
pull
it
all
out
there.
But
if
it's
going
to
destabilize
the
document
or
whatever,
then
I'd
prefer
keeping
it
in
there.
That's
my
preference,
but
again
keep
us
blocked
on
having
nesting
in
a
seabor
which
it
already
supports.
In
fact,
the
new
way
of
doing
nesting
is
even
better.
Thank
you.
E
So
just
jumping
quickly
in
here
so
now
we
have
the
choice
between
delaying
it,
to
be
honest,
sorry
and
therefore
not
satisfying
t
or
satisfying
t
by
not
delaying
it.
So
so
I
this
is
a
conundrum,
so
I
I
I
I
would
not
understand
how
to
choose
between
these
options.
L
Well,
perhaps
issuing
on
the
rev
12
issuing
a
working
group.
Last
call
will
force
that
issue
to
accelerate.
K
K
And
and
we'll
do
a
json
document
later,
that'll
be
a
a
second
thing
that
when
we,
when
we
learn
how.
G
K
L
Okay,
but
lawrence
that
should
not
preclude
us
from
from
you
moving
forward
with
the
group
consensus
of
doing
the
update
and
then
starting
to.
F
K
Know
add
to
figure
out
what
the
claims
are,
that
the
dave
wants
and
add
them
if,
if
they're,
if
it's
straightforward,
I'll,
certainly
take
care
of
that
by
friday,
and
if
there
is
consensus
by
friday
that
you
know
to
go
to
last
call
and
move
forward
with
the
all
the
nesting
and
all
the
json
and
all
the
sea
war.
That's
fine!
K
But
I
what
I
think
I'm
hearing
from
from
hank
and
carson
is
that
the
all
the
nesting
and
all
the
seaboard
and
all
the
cdl
and
all
the
json
is
is
maybe
not
suitable
for
last
call.
So.
J
I
have
a
general
problem
with
standards
that
start
out
by
fragmenting
themselves
in
a
false
sense
of
trying
to
appease
certain
user
groups,
but
that's
unrelated
to
the
question
of:
can
we
get
the
semantics
of
of
all
these
these
things
working
together
right?
I
think
we
can
get
these
semantics
right.
It
might
take
a
little
bit
of
time.
J
I'm
just
not
sure
it
should
be
done
in
this
document,
because
it
actually
would
continue
on
the
development
of
cwt
and
jwt
beyond
what
the
scope
of
it
is.
Okay,
so.
L
In
in
the
interest
of
time
cabo,
I
hear
what
you're
saying,
but
I'm
I'm
trying
to
move
forward,
and
and
how
would
we
get
to
to
publish
if
you
will
so
gearing
lawrence?
If
you
can
rev
to
a
version,
12
announce
it
to
the
mail
list
and
then
for
the
participants.
L
We
can
certainly
put
a
a
call
of.
Are
we
ready
to
do
a
working
group?
L
Last
call
we've
already
clarified
so
dave
thanks
for
for
putting
in
your
expectation
of
what
should
be
on
the
eat
draft,
but
I
would
encourage
and
solicit
everybody
else
to
do
the
same
thing
of
if
there
are
things
missing
or
things
that
need
to
be
addressed
for
us
to
get
to
working
group
last
call
that
we
start
putting
them
both
on
the
mail
list,
but,
more
importantly,
as
the
authors
are
tracking
it
on
github
to
start
putting
them
and
documenting
them
on
github.
A
Okay,
so
should
we
move
on.
I
I
I
What
we
have
is
at
the
station
results
for
secure
interactions,
and
we
have
version
two
and
you
can
see
the
set
of
authors.
Who've
been
contributing,
as
well
as
getting
suggestions
from
other
people
on
the
call
here.
Next
slide.
I
The
big
change
that
occurred
from
last
draft
is
really
a
split
of
the
draft
into
two
parts,
and
this
was
requested
in
the
comments
of
itf
11..
The
comments
were:
let's
put
the
document
in
between
the
information
elements
that
include
the
attestation
results
and
then
into
end-to-end
implementation
options,
such
as
background
check
or
the
augmented
evidence.
So
we
now
have
a
document
which
really
focuses
on
those
two
different
areas.
I
Just
briefly,
the
drive
behind
this
draft
is
that
there's
many
kind
of
a
testing
environments
out
there
and
the
relying
party
can't
support
an
infinite
number
of
permutations
and
what
kind
of
claims
are
going
to
be
coming
in
about
a
verifier,
saying,
hey.
This
is
what
I
think
about
the
tester,
so
we
got
to
make
sure
that
we
have
some
commonality
in
the
kind
of
information
that's
coming
into
the
relying
party,
and
we
need
shared
definitions
next
slide.
I
I
The
simplification
of
the
draft
is
that
we
took
all
the
claims
that
we
had
previously
and
instead
of
having
boolean
like
either
the
executables
fail,
the
executables
are
approved.
Instead,
we
have
things
like
there's,
executables
and
there's
a
there's,
a
claim
about,
let's
say
executables:
do
we
have
the
right
binaries,
the
right,
runtime
files,
the
right
time,
scripts
loaded
and
so
getting
a
general
claim
about
executables
or
hardware
or
the
file
system
or
the
config?
I
This
is
the
kind
of
information
that
is
in
this
draft
coming
up
with
a
minimum
set
at
this
point
of
eight
things:
around
identity,
integrity
and
confidentiality
of
the
information
that
is
asserted
by
the
by
the
verifier
in
regards
to
the
attester,
and
so
that's
a
key
there
and
then
the
other
part
of
the
big
change
along
that
next
slide.
I
Is
that
we,
instead
of
having
boolean
now
have
a
unsigned,
signed
integer
and
that
sign
integer,
provides
information,
saying
that
there's
affirmation
about
the
claim
warning
about
the
claim
or
contradiction,
a
contra
indication
about
the
claim.
So
there's
standardized
results
about
what
was
found
out
about
a
particular
aspect.
For
example
the
executables.
We
could
have
a
green
or
firming
value
that
only
genuine's
genuine
files
and
executables
are
included,
whereas
if
we
don't
find
that
and
we
find
a
file
or
an
executable
that
has
been
loaded-
that
we
know
is
not
good.
I
I
So
the
the
key
here,
obviously,
is
that
we
have
tiers
of
values
that
simplifies
things
to
relying
party,
because
the
relying
party
can
either
code
against
the
specific
number
in
the
claim
or
against
ranges
in
the
claim,
if
they
just
want
to
say
I'll,
accept
any
claims
or
any
claims
that
are
currently
affirming.
I
will
go
ahead
and
deny
any
connecting
to
any
device
that
has
contra
indicated
claims.
I
And
we
have
looked
at
these
claims
against
multiple
types
of
hardware
technologies,
including
different
kinds
of
of
confidential
compute
hardware,
as
well
as
tpms
next
slide.
I
So
last
thing
about
the
part
one:
it's
important
to
remember
that,
just
because
you
say
that
something
is
affirmed
or
contraindicated
doesn't
mean
the
relying
party
has
to
accept
it.
This
is
just
the
normalization
of
what's
being
asserted
from
a
claim,
you
might
say.
Oh,
I
trust
a
lot
more.
A
confidential
compute
environment
such
as
sgx
or
trust
zone,
rather
than
a
tpm
for
an
equivalent
claim.
I
That
say
here:
the
is
the
code
build
and
it's
really
the
combination
of
freshness,
trustworthiness,
claims
and
identity,
which
are
what
would
be
combined
together
into
something
that
would
be
evaluated
at
the
relying
party
and
that's
the
second
part
of
the
draft.
Next
slide.
I
And
that
second
part
of
the
draft
matches
to
a
call
flow
in
the
architecture
draft
which
uses
the
times
and
the
rest
of
the
things
so
that
the
relying
party
and
effectively
the
verifier
b
at
the
far
end,
can
go
ahead
and
evaluate
the
information
bundle
to
make
a
decision
on
whether
to
start
a
secure
interaction
between
the
a
tester
and
the
relying
party
right
next
slide.
I
I
I
So
the
the
this
is
where
we
are
right
now,
questions
thoughts.
G
Yes,
thanks
eric
for
the
the
draft
and
the
the
explanation.
Sorry
I'm
having
trouble
getting
my
camera
on.
So
I
I've
read
through
the
trustworthiness
claims
section
a
few
times
and
one
of
the
things
that
I
don't
that
in
my
impression
reading
it
is
that,
although
the
claim
values
are
defined,
the
criteria
that
the
verifier
use
in
determining
those
claim
values
are
not,
and
therefore
interoperability
is
going
to
be
a
very
difficult
issue
like
I'll
give
a.
G
Let
me
see
if
I
can
give
a
concrete
example
like
take,
for
instance,
an
attestation
result
or
sorry
an
attestation
is
provided
in
the
form
of
a
token.
Maybe
that
says
the
firmware
running
on
the
device.
Is
that
version
x?
That's
and
that's
not
the
tip
one
verifier
may
actually
be.
It
may
actually
lower
the
trustworthiness
of
the
device
based
on
that,
because
it's
not
running
at
the
tip.
G
Another
verifier
may
know
what
is
at
the
tip
and
they
view
that
that
it
may
view
that
the
the
additional
changes
in
the
fir
in
the
later
version
firmware
are
not
sufficiently
consequential
to
affect
the
security
state
of
the
device
and
may
not
impact
the
trustworthiness
claim
accordingly.
G
I
Okay,
now
good
question:
we
certainly
have
had
discussions
in
the
past,
at
least
in
the
verifiers
I've
worked
with
on
this.
In
the
end,
the
verifiers
like
to
compete
based
on
how
good
they
can
do
something
some
verifiers
will
say
here
are
the
rules
of
which
I'm
going
to
process
a
conclusion.
Others
might
say:
I'm
not
going
to
actually
discuss
how
I
look
at
the
evidence
in
order
to
generate
the
conclusion.
I
It's
up
to
the
verifier
to
determine
what
level
of
exposure
they're
going
to
do
in
identifying
the
rules
for
processing
there's,
actually
a
good
reason
for
this.
A
lot
of
the
people
don't
want
to
show
what
their
issues
are
in
terms
of
what
they
see
as
vulnerabilities.
So
people
don't
start
to
design
to
their
attacks
to
pass
the
test.
So,
instead
of
saying
here
is
the
exact
equation
to
have
the
result.
Instead,
they're
saying
you
know,
this
is
what
I'm
willing
to
release.
This
is
what
I'm
not
willing
to
release
the
goal
to
meet.
I
This
standard
is
not
a
rule,
but
a
definition
of
a
particular
claim,
and
it's
up
to
the
relying
party
to
determine
whether
you
know
they
accept
the
assertions
that
are
made
at
the
standard
level
by
the
verifier
against
those
claims.
There's
a
bunch
of
other
things
that
can
go
along
in
that.
But
in
the
end
you
know
the
the
rules
for
calculation
are
not
always
formulaic,
especially
when
you
have
a
huge
amount
of
evidence
and
we
have
to
generalize
some
of
the
values
across
different
types
of
technologies.
I
A
So
we're
over
time
can
we
address
the
next
topic
in
two
minutes,
which
is
trusted
path.
I
All
right
trusted
path,
routing
we
have
the
same
authors
from
last
time.
It
really
is
an
instance
of
the
attestation
results.
Draft
can
go
to
the
next
slide.
I
I
This
just
talks
about
the
means
of
evaluating
the
information
coming
from
one
device
to
another,
and
there
was
a
question
on
the
mailing
list:
can
we
do
this
with
eat?
Can
we
do
this
with
yang
how's
this
going
to
be
encoded,
really
the
trustworthiness
path,
routing
and
the
trustworthy
path
rallying
draft
talks
about
how
to
parse
specific
fields
and
in
various
encodings
next
slide.
I
Okay,
so
we're
just
going
ahead
and
keep
on
defining
and
no
need
to
adopt
this
until
we
get
a
decision
on
the
attestation
results.
Okay,.
A
I
A
C
Good
morning
next
slide,
please
I'm
going
to
provide
an
overview.
I've
done
this
before,
but
it
seems
there's
confusion
on
the
draft.
C
C
Essentially,
this
is
to
provide
a
way
to
scale,
bringing
local
attestations
to
a
remote,
a
single,
remote
attestation,
and
so-
and
part
of
this
is
thinking
about
the
posture
assessment
use
case
and
what's
working,
what's
not
working
with
current
posture
assessment
techniques,
it
requires
a
lot
of
customization
on
the
part
of
every
single
organization
and
while
the
standards
are
there
and
they
work
that
has
been
a
barrier
you
know,
even
though
lots
of
vendors
have
implemented
it,
because
people
don't
have
the
expertise
to
deploy
or
have
a
person
responsible
for
that
level
of
detail.
C
Now.
What
we've
seen
with
trusted
boot
process
is
that
vendors,
a
number
of
them,
have
been
able
to
demonstrate
a
trusted
boot
process
that
relies
on
a
series
of
trusted
or
attestations,
working
out
or
resetting
a
process.
If
it
doesn't
work
out
and
then
you
know,
the
system
is
brought
up
as
as
being
trusted
and
it
even
can
provide
an
assurance
to
the
hardware.
C
That's
expected
on
a
system
now,
and
so
these
are
aligned
to
nist
sp,
800
193,
so
the
firmware
resiliency
specification
and
then
it's
further
instantiated
in
tcg's
reference
integrity,
measurements
documents
next
slide,
please
so
that
would
constitute
a
set
right
all
of
the
policies
or
measurements
and
and
you
might
break
it
down
in
different
ways.
You
might
have
multiple
sets
represent
the
document.
C
Having
this
guiding
way
to
take
a
set
of
what's
been
done
locally
and
report,
it
remotely
could
help
us
better
scale.
What
the
posture
assessment
looks
like
from
a
system
gathering
that
information
and
the
reason
is
that
you're
not
going
to
want
to
send
every
single
attestation
across
the
wire,
because
then
it
would
just
be
too
much
data,
but
we
have
logs
and
we
have
evidence
when
these
attestations
happen
locally.
C
So
the
idea
is
really
very
simple:
let's
group
them
up
provide
a
way
to
label
what
that
group
looks
like
and
then
be
able
to
send
it
to
a
remote
repository
whatever
that
is,
and
so
this
draft
sets
up
a
so
that
we
could
define
what
those
sets
look
like,
so
that
we
have
interoperability
across
the
wire,
and
we
understand
when
a
set
is
attested
locally.
What
does
that
mean
to
the
remote
entity?
C
And
it
you
know
it
obviously
uses
eat,
it
would
leverage
you
know,
assurance
of
what's
coming
from
that
host
and
how
that
was
provided,
but
would
be
essentially
just
grouping
those
sets
so
that
we
could
better
scale
posture
assessment
where
it's
possible
and
it
might
not
be
possible
to
do
attestations
for
every
bit
of
posture
assessment.
But
if
we
could
do
a
lot
more
via
this
technique,
that
puts
the
onus
on
the
vendor
to
create
the
set
of
what's
expected
and
then
have
remediation
capabilities.
Where
possible.
C
Then
this
is
going
to
help
all
of
those
end
entities
that
cannot
hire
somebody.
We
have
a
3.5
million
person
deficit
globally
and
there's
lots
of
organizations
like
ones
that
we
support
at
center
for
internet
security
at
the
state,
local
tribal
and
territorial
networks,
and
that's
just
an
example,
because
there's
lots
of
small
organizations
that
cannot
hire
resources
for
functions
like
this.
So
if
this
were
to
be
provided
by
the
vendor,
this
gets
us
closer
to
not
just
built-in
security
and
provided
built-in
security,
but
then
ongoing
assurance
to
that
expectation.
C
And
so
you
could
use
whatever
format
you
need
and
it
would
be
sent
to
a
repository
and
it
would
just
match
up
what
is
that
set
and
and
how
that
is
registered
next
slide.
Please.
F
C
Think
that
explains
it
well
enough.
If
there's
any
questions,
I'd
be
happy
to
take
them.
I
guess
at
the
next
session
yep
and
please
read
the
draft.
It's
short
and
simple.