►
From YouTube: IETF110-TEEP-20210310-1200
Description
TEEP meeting session at IETF110
2021/03/10 1200
https://datatracker.ietf.org/meeting/110/proceedings/
B
B
Okay,
I
think
it's
time,
hello.
Everyone
welcome
to
the
working
through
position
at
idf,
1
110.
So
do
we
have
a
note
taker
on
nancy.
A
We
need
at
least
one
note
taker.
The
cody
and
d
is
up
and
going.
We
can't
really
get
the
session
going
unless
we
have
one
one
volunteer.
B
So
no
till
applies
for
this
working
group
session
as
well
and
that's
the
agenda.
We
have
a
very
straightforward
agenda
for
this-
that
we
will
go
over
the
architecture
and
transport
protocol
for
first
ten
minutes.
Then
the
hackathon
report
and
the
rest
of
the
session
is
for
day
two
for
30
protocol
changes,
and
I
think
the
protocol
has
seen
it
really
coming
to
a
great
length
in
the
next
revision
and
seems
like
we
are
very
close.
B
Any
any
agenda
that
needs
to
be
discussed.
Are
you
guys,
okay
with
this
agenda?
Do
you
have
any
suggestions.
D
Dave
so
these
first
two
should
be
pretty
quick
I'll,
be
talking
about
the
draft
architecture.
14
next
slide.
D
All
right,
so,
just
as
a
recap
of
where
we
are,
we
went
through
a
working
group
last
call
at
ietf
109.
We
discussed
any
of
the
issues
raised
or
the
last
of
the
issues
raised.
I
should
say
because
we
discussed
them
at
most
of
them
at
previous
ietfs,
so
at
ietf
number
109,
I'm
getting
some
blinking
on
my
screen.
I
don't
know
if
other
people
are
from
heroes.
D
It's
blinking
on
and
off
weird
anyway
draft
14
posted
the
resolutions
from
the
ietf
109
meeting,
and
so
in
particular
the
three
things
that
we
discussed
at
ihf
109
that's
fixed
in
there
is.
We
had
a
discussion
about
how
you
indicate
that
you
are
that
you
no
longer
need
ata,
and
so
we
added
that,
on
request,
ta
conceptual
api
that
we
discussed
at
109..
D
There
was
a
paragraph
implicitly
talking
about
secure
domains
that
we
talked
about
removing
and
then
we
removed
that
and
then
finally,
there
was
some
discussion
about
applicability
text,
and
so,
if
you
remember
at
109,
we
had
a
sort
of
a
rush
session
because
we
only
met
for
an
hour
and
then
we
had
a
side
meeting
also,
and
so
some
of
these
were
discussed
in
a
side
meeting,
but
I'm
not
sure
that
any
of
those
were
contentious
but
feel
free
to
check.
D
But
I
think
most
of
the
people
that
cared
were
actually
at
that
side
meeting.
So
and
then
it's
been
on
the
list,
and
so
I
hope
we're
good
there.
There
was
a
open
pull
request.
I
think
it's
been
merged
now
as
trivial
editorial.
There
was
a
typo
and
in
particular
the
the
glossary
one.
Entry
in
the
glossary
was
out
of
order,
and
so
that
just
fixes
that-
and
so
my
belief
is
that
the
doc
is
ready
to
go
to
the
iesg,
whatever
the
shepherd
directs.
D
So
I
guess
my
question
is
to
the
chairs
is:
have
we
done
a
doc
shepard
review
yet
and
whether
we're
expecting
to
have
any
other
changes
come
in
from
doc,
shepard
review.
B
So
dave
I
just
reviewed
the
tip
between
the
previous
version
and
this
version.
I
I
would
like
to
do
a
one
complete
review
of.
B
D
Gotcha,
so
I
will
wait
to
post
draft
15
until
after
you've
done
the
review.
That
way.
If
you
find
anything,
then
I
will
put
that
in
a
draft
15
along
with
that
pull
request
2019,
but
since
that
one
is
just
ordering
it
doesn't
actually
change
the
text
or
then
fixing
a
typo
that
shouldn't
affect
your
doctor,
yep.
D
Okay!
Next,
I
don't
know
if
I
have
any
other
slides
on
this
one.
I
think
that
might
be
the
only
one.
D
All
right
so
now
we're
going
by
the
way,
just
the
last
thing
on
that
one,
as
I
think
a
cure
we'll
talk
about.
We
think
that
the
protocol
spec
is
now
stable
enough
that
we
don't
think
that
there
will
be
any
future
changes
needed
to
the
architecture
document,
because
now
that
we
have,
we
have
fairly
complete
ish
implementation
of
the
protocol.
We
think
we've
got
all
the
stuff
covered
in
the
architecture,
so
that
needs
to
be
the
architecture
and
everything
else
can
just
be
in
protocol,
as
any
changes
happen
all
right.
D
So
now
we're
going
to
move
on
to
the
transport,
which
is
the
layer
underneath
the
t
protocol,
how
you
bind
the
t
protocol
to
hdp
in
the
case
where,
where
the
agent
connects
to
the
tam,
so
here
the
timeline,
we
also
had
a
working
group
last
call
early
last
year,
which
had
some
reviews.
We
solicited
additional
reviews
after
that
that
then
we
discussed
that
ietf108
and
then
ivf
109.
D
We
had
the
last
issue
that
was
discussed,
which
had
to
do
with
that
adding
the
unrequest
ta
that
affected
all
the
documents,
and
so
the
changes
in
draft
10
here
is
we
added
the
unrequest
ta
for
consistency
with
both
the
other
documents
being
added
and
then
finally,
there
was
an
issue
that
I
will
talk
about
on
the
next
slide,
so
let's
just
go
on
to
the
next
slide,
so
this
is
already
in
draft
10.
go
ahead.
All
right,
so
here
is
the
issue.
D
The
architecture
document
explains
that
a
type
agent
may
need
to
talk
to
multiple
tabs
right.
One
example,
use
case
is
talked
about
in
the
architecture.
Document
is
where
the
ta
is
on
one
tam
and
the
personalization
data
needed
for
that
ta
is
on
a
different
ham.
Okay,
that's
one
of
many
cases
right
and
so
the
problem
was
the
transport
spec
had
language
shown
there
that
previously
implied
that
the
agent
only
had
one
tam
right,
because
it
says
when
it
you
know
periodically
you.
D
G
D
You
call
into
the
into
the
agent
from
the
broker
and
the
agent
either
returns
a
tam
uri
to
connect
to
or
passes
back
a
message,
intent
uri,
so
the
a
implied
that
well,
of
course,
that
only
means
one
time.
So
how
do
you
support
multiple
tams?
How
does
that
work?
D
So
that
was
the
issue
okay,
so
the
resolution
was
the
text
at
the
bottom
was
then
added,
which
explains
that
you
can
talk
to
multiple
tams
and
the
way
that
happens
is
that
the
broker
keeps
calling
it
request
policy
check
one
by
one
until
the
agent
says
nothing
to
do.
Okay,
so
each
call
and
passes
back
another
tam
uri
to
do
well,
the
intent
that
the
broker
will
then
call
a
request
policy
check
again,
so
it
iterates
through
these,
whether
it
does
those
in
series
or
whether
it
does
those
in
parallel
is
up
to
implementation.
D
The
point
is,
if
you
pass
back
one,
it
means
please
call
again,
so
that
was
the
resolution
and
that
same
change
was
made
in
the
in
the
protocol
document.
So
that
explains
that
the
previous
text
was
in
fact
correct.
It
just
needed
more
elaboration
to
explain
how
it
actually
worked,
and
so
that's
the
resolution
on
this
one.
D
I
believe
that's
it
for
this
document.
Unless
there's
any
questions
here,
just
confirm
that
is
yeah.
That's
the
last
slide,
so
yeah.
D
D
And
that
one
was
a
result
of
running
into
an
implementation
of
the
teat
protocol
when
trying
to
implement
multiple
tabs.
So.
D
B
E
Yes,
I'm
going
to
talk
about
hackathon
and
the
when
I
made
the
title
it's,
I
wrote
it
as
a
deep
hackathon,
but
it's
more
becoming
more
becoming
similar
to
typing
deep
in
suit
hackathon,
which
I
will
explain
later
in
the
slide.
E
Yes
and
next
please,
and
I
I
should
have
been
announcing
what
timing
we
will
get
together
at
together.
But,
yes,
it
was
in
japan,
time
from
10
am
to
3
pm
and
we
were
sitting
at
the
table
e,
a
comfortable
chair
and
yeah.
Okay
and
next
page.
Please.
E
And
this
is
the
objective
was
bombarding
all
the
pieces
inside
the
tip
protocol
draft
and
also
it's
we
are
implementing
on
top
of
the
over
http
draft,
so
go
through
all
the
cases
inside
the
draft
and
anything
it's
well.
We
just
went
was
trying
to
purify
the
documentation
and
spec
from
the
implementation
perspective,
and
implementation
was
from
two-time
one
from
time.
B
E
By
implementation
from
second,
it's
open
source
on
github
tam
on
tampos,
by
dave
in
his
github
from
microsoft
and
type
device,
is
it's
in
in
our
project.
We
call
it
deep
device,
but
it's
steep
client
wait:
it's
not
an
open
source,
but
we're
using
this
for
testing
the
draft
right
now
and
the
tip
agent
from
t
page
and
ta
from
microsoft
and
deep
library.
E
It's
it's
also
it's
implemented
by
second,
it's
more
like
a
helper
library
for
implementing
tip
agent
and
tip
broker,
and
it's
called
libsy
deep
and
that's
page
four
and
could
just
skip
the
page
pen.
E
Page
10
is
a
summary
I'm.
I
just
wanted
to
explain
the
summary
first
to
make
it
easier
to
understand
what
we
were
doing
and
after
yes,
we
after
the
hackathon,
we
I'm
not
sure
about
everybody,
but
we
pretty
much
feel
it's.
The
draft
of
the
tv
protocol
and
tip
over
http
protocol
is
pretty
much
reasonable
and
I'm
not
saying
it's
it's
perfect.
It's
not
I'm
not
saying
it's
optimal
or
best
or
but
it's
a
reasonable.
E
It
works.
Okay,
yes,
and-
and
it
doesn't
mean
it's
it's,
it's
fit
it's
okay
to
implementing
deep
and
it
will
work.
It's
we
don't
have
anything
else.
It's
perfectly
working.
We
still
need
to
work
on
it's
it's
right
here,
it's
until
from
itaf110
to
111
on
one
one,
one
11.,
probably
you
have
to
they
have
to
test
suit
manifest
in
the
implementation
and
also
we
only
have
tried
mostly
on
the
seaboard
implementation,
without
the
encryption
and
decryption
and
and
signature
verification.
E
E
E
The
reason
is
trying
to
set
use
the
same
bytes,
which
is
from
between
eight
to
16
or
64
bytes
as
the
same
and
the
eat
rats
eat
documentation,
so
I
have
to,
and
then
that
requires
the
implementation
changes
and
it
was,
it
worked.
Fine
didn't
have
any
much
problem,
and,
and
one
thing
we
we
couldn't
really
finish
it
in
the
hackathon-
was
creating
the
suit
manifest.
E
We
we
initially
was
using
pre-made
suit,
manifest,
which
is
uploaded
on
suit
github,
and
we
didn't
generate
it.
We
never
generated
by
ourselves,
so
we
were
trying
to
make
it
generating
the
suit
manifest
and
then
upload
it
to
the
time
server
and
then
using
it
from
time
to
client.
E
Yes,
that's
we
couldn't
finish
it,
but
it's
okay!
It's
we
got
it,
we
got
it.
We
it
was.
We
got
most
of
the
other
stuff
done
with
the
predi,
a
pre-created
suit
manifest,
and
the
next
was
unneeded.
Tc
list
was
added
at
I
df-109
and
we
never
finished
entire
procedure
from
downloading
pc.
E
That
has
a
trusted
component,
which
used
to
be
called
trusted,
application
and
install
it
and
run
it
and
delete
it
and
to
all
one
one
one
path
so,
and
for
that,
for
that
purpose,
a
needed
tc
list
was
added,
however,
yes,
and-
and
we
were
able
to
finally
verify
if
it's
working
or
or
implementation,
just
just
the
minor
thing
is
yeah.
I
needed
to
see
this
speak.
The
features
became
already
obsolete
in
the
latest
draft.
It's
it's.
E
E
And
yes,
and
the
last
thing
is
there's
this
all
the
steep
message
is
in
suit.
Manifests
too,
is
it's
written
in
c
board
and
every
entry.
It
should
verify
the
h
each
entry
in
the
c
board
entry.
However,
we
really
didn't
we
couldn't.
Yes,
it's
not
it's
not
easy
to
make
adding
all
the
checking
inside
but
well
yeah.
We
will
try
as
a
step
by
step
yes
and
next
page.
Please.
E
E
Yes,
this
is
a
some
of
the
activity
we
note
during
the
day
we
made
on
the
github
the
pull
request
and
adding
the
issues.
It's
it's
not
an
issue,
it's
more
like
a
asking
question
or
asking
a
comment:
github,
it's
only
the
way.
It's
called
this
issue.
So
that's
that's
listed
here.
So
first,
two
is
it's
not
really
big
big
changes.
E
To
make
the
implementation
easier,
we
have
a
cdl
example
of
the
sabor
expression
and
also
see
binary
expression,
representation
inside
the
tip
draft,
and
some
of
the
example
was
using
eight
bytes
and
some
of
them
some
of
the
id
component
id
was
using
15
byte
because
of
my
old
typo,
and
so
we
you
know
we
finally
can
use
the
size
which
is
reasonable
change
it
to
you
reasonable
and
a
little
bit
of
a
typo
fixing.
E
And
yes,
while
we
were
reading
the
the
documentation
implementing
the
on
during
the
hackathon.
Yes,
I
realized
that
the
word
was
in
the
deep
draft
was
t
it
was
ta,
signer
and
and
the
architecture
direct
was
tc
signer.
So
yes,
I
just
wrote
that
in
the
github
and
yes-
and
this
is
next-
one
is
going
to
be
talk
in
the
dave
sliders.
E
E
Dave
talk,
and
next
is
yes,
yeah
issue.
120
is
not
real
the
draft
or
any
protocol
issue.
It's
it's.
We
were
using
pre-generated
suit,
fire
suit
manifest
and
there
is
a
tool
yeah
so
to
manifest
generator,
but
we
didn't,
we
couldn't
come
up
with
how
did
make
a
generating
a
suit
manifest
for
deleting
so
that's
yeah.
We
wanted
to
have
a
example.
Then
we
could
put
it
in
whether
I'm
not
sure
what
it's
going
to
be.
E
It
should
be
in
the
deep
draft
or
suit
draft,
but
yes-
and
we
would
like
to
have
the
cddo
exp
expression
example
and
binary
presentation,
so
it
will
make
it
easier
for
the
people
who's
going
to
implement
this
from
this
draft.
And
yes-
and
this
is
next
era-
queer
request-
is-
this-
is
from
dave.
E
E
Yeah,
so
when
we
one
of
the
one
of
the
discussion
during
the
hackathon
was
I
never
write,
I
didn't
have
a
time
to
add
it
in
the
github
is
there's
a
sequence
number
and
a
suit
manifest
and
there's
a
version
number
of
the
trusted
component
inside
the
suit
manifest
and
how
to
handle
rollback,
and
we
didn't
get
to
the
conclusion.
So
if
we
get
to
have
a
little
bit
more
idea,
we
will,
I
will
put
it
in
the
github
and
on
another
and
the
next
one
is.
E
E
E
E
One
of
the
it's
you
usage
of
the
suit
manifest
binary
inside
the
tip
is
there's
a
t.
There's
a
tc
designer
who
is
developing
a
tc
tc,
which
is
include
application
or
the
personal
data
or
a
serial
number
or
license
license
key
and
and
that
will
be
encapsulated
in
the
suit
manifest
binary.
And
then
it
will
be
encapsulated
in
the
to
keep
message
and
and
and
that
will
be
hand
over
to
the
tam
server
tab
vendor.
E
It's
very
likely
to
have
some
of
the
pc
signer
is
independently
developing
the
pc
binary
and
handle
handing
over
to
the
tam
vendor,
which
is
something
like
app
store
or
or
time
server
hosted
by
security,
company
or
insurance
company
or
any
other
company,
and
they
would
like
to
host
the
binary
by
their
their
self.
Then
we
there's
there.
E
Then
we
need
to
override
or
specify
externally
the
uri
information
where
the
times
dc
binary
is
the
downward,
and
one
thing
one
of
the
idea
is
that
the
valid
use
cases
and
it's
it
was
the
104
is
the
question
asking
the
questions
one
or
four
and
105
is
how
to
describe
that
in
suit
manifest,
and
I
think
I
need
the
expert
from
suit
joining
today.
E
Should
we
should
we
should
we
ex?
We
add
your
eye
section,
override
section
externally
from
the
word
section
of
the
signed
by
tc
signer
or
if
we
should,
we
make
a
encapsulated
suit
in
I
forgot
envelope.
E
I
forgot
the
word
thing,
but
I'm
encapsulating
portion,
which
is
written
by
signed
by
tc
signer
and
then
adding
a
uri
information
with
override
and
encapsulating
again
with
the
time
vendor
we
didn't
yeah,
we
just
we
just
want
to
have
the
let's,
which,
which
way
is
this
prefer
way
with
the
suit,
and
we
would
like
to
have
the
relaxed
added
to
the
cdd
expression
and
binary
representation
in
the
draft
and
brandon.
Do
you
do
my
comment.
F
H
Think
that
all
of
the
questions
that
you
asked,
no
there's
one
in
addition
to
the
three
on
this
page,
so
I'll
start
with
the
one.
That's
not
on
the
page.
You
asked
about
rollback
specifically.
B
B
H
B
E
B
H
Is
that
using
a
more
sorry,
a
larger
sequence
number
shows
the
intent
to
install
an
older
payload,
and
it's
about
communicating
the
intent
accurately
so
that
that's
the
the
idea
there.
Okay.
E
Okay,
then
we
should
follow
yes,
so
then
we
should
put
use
the
sequence
number
for
the
display
list,
which
roll
back
or
whatever
it's
we
should
override
with
the
existing.
E
H
Yeah,
that's
right!
So
if
you
want
to
force
a
downgrade,
then
resigning
a
manifest
that's
identical,
except
for
having
its
version
or
it's
a
sequence.
Number
incremented
is
the
right.
H
B
E
Yes,
and
that
in
that
case,
is
it
it's
the
construct
construction
of
the
suit
manifest
binary?
Is
it?
Is
it
going
to
be
encapsulate
yeah,
yeah,
encapsulating
this,
the
existing
suit,
manifest
with
additional
uri
manifest
and
then
signing
signed
by
t
times
vendor.
H
Signed
by
the
tam,
the
tams
authority
and.
B
B
E
H
That's
correct:
you
do
also
have
the
option
of
embedding
one
manifest
inside
another
one,
and
particularly,
if
you
want
to
encrypt
a
manifest
there's,
some
discussion
about
encrypted
manifests
going
on
in
the
chat.
Then
this
becomes
relevant
because
embedding
it
in
the
cleanest
way
of
dealing
with
the
encrypted
manifest
is
to
take.
H
That
contains
nothing
but
the
encryption
information
and
potentially
an
overridden
uri
and
then
reference
a
manifest
that's
encrypted.
That
is
also
contained
in
the
in
the
external
metadata
of
that
first
manifest
yeah.
So
that's
an
option
as
well.
All.
E
Right.
Thank
you.
H
Then
the
last
one
generating
a
manifest
for
delete.
That's
a
hot
topic
and.
H
That
one
out
the
the
best
answer
I've
been
able
to
come
up
with
so
far
is
that
delete
is
probably
not
what
we
want,
because
it's
going.
B
H
Introduce
a
situation
where,
if
you
have
two
two
components
that
both
depend
on
a
tertiary
component
and
one
of
them
has
a
manifest
that
says,
delete
that
tertiary
component,
then
you
end
up
breaking
the
dependency
chain
of
another
tc.
So
you
probably.
B
B
B
H
Effectively
decrease
the
reference
count
of
the
of
the
component
that
you're
trying
to
delete,
and
if
it's
reference
count
hits
zero,
then
you
delete
it.
E
Yeah,
okay,
yeah.
Thank
you.
Yeah
either
is
not
easy
but
yeah.
Okay,
yes,
okay,
and
can
I
ask
the
additional
question
for
the
first
rollback
question?
Yes,
it's
a.
E
Handle
sequence
number
in
the
tip
agent
it
might
we
might,
it
might
have
the
two
two's
suit
manifest
binary.
One
from
one
is
for
one
for
tca
tca
is
updating
current
installed,
tc
a
inside
device
and
another
suit
manifest
menu
containing
tcb,
which
is
not
installed
already,
and
both
will
pro
and
the
suit
manifest.
It
says
to
handle
based
first
with
the
certain
sequence
number
before
handling
anything
inside
and
how
to
bind
how
to
is.
E
Do
we
need
to
care
the
which
sequence
the
sickest
number
should
be
binded,
to
which
tc
and
the
implementation
was
the
yes
something
additional
question
came
up.
E
H
H
Tree
and
they're
each
signed
by
different
authorities,
then
you
don't
want
to
use
the
top
level
sequence
number
as
the
sequence
number
for
all
of
them,
and.
H
That
this
is
such
an
important
consideration
is
because
that
would
effectively
give
the
the
top
level
authority
re
roll
back
authority
over
all
components
that
were
referenced
in
its
dependency
tree.
And
if
you
expand
that
in
a
in
a
a
system
that
allows
components
in
general
like
this,
then
that
could
be
expanded
even
further.
To
say
that
you
end
up
with
all
you
end
up
with
rollback
authority
over
any
component,
because
all
you
have
to
do
is
link
it
as
a
dependency
and
then
set
a
different
sequence.
Number.
E
So
and
yes,
then,
and
then
what
would
be
good
way
in
the
in
the
tip
agent
binding
between
the
different
tc
binary,
with
the
sequence
number
with
it,
because
the
component
id
is
inside
the
manifest
and
manifest
body
so
or
should
we
use?
E
C
E
Use
this
as
a
and
using
that
as
the
iso
okay,
yes,
okay,
let's
I
probably
for
the
next
hack
before
the
next
hackathon
is.
We
will
try
with
the
that
is
implementation,
yes,
okay,
yeah!
Thank
you
thank
you
and
I
think
that's
all
in
the
most
important
topics
in
the
slide.
Yes,.
B
That's
great
akira
thanks.
A
Yeah,
so
let
let's
take
a
pause
here
for
a
couple
minutes,
so
there's
some
questions
in
the
chat
with
respect
to
the
discussions
that
have
just
been
happening
with
respect
to
suit
between
akira
and
brendan.
But
hannes
also
raised
the
question
as
to
whether
these
discussion
topics.
A
Some
of
those
clarifications
and
descriptions
whether
they
belong
in
teep
or
suit,
or
both
so
hannes-
I
don't
know
or
dave-
I
don't
know
if
you
wanted
to
to
more
publicly
express
that
here,
we've
got
a
few
minutes.
D
D
Yeah,
so
the
issues
104
and
105
being
the
ones
that
I
think
were
on
that
last
slide
that
we're
just
talking
about,
I
think,
are
actually
questions
about.
D
You
know
how
do
I
use
the
suit
manifest,
and
so
those
are
ones
that,
in
the
actual
issues
I'd
commented
saying,
I
think
these
are
just
questions
for
suit,
not
about
teep,
and
so
I
don't
think
that
there's
anything
that
I
saw
yet
anyway
that
necessitated
a
change
in
the
teep
document
and
that's
why
the
discussion
with
brendan
as
long
as
brendan
says
it's
already
covered
or
whatever,
then
we
either
close
them
or
at
most
there
might
be
some
place
in
the
document.
D
We
can
add
a
deep
reference
into
a
particular
section
of
the
suit
manifest
spec.
If
there's
some
place,
that
would
be
appropriate,
but
I,
in
other
words
I'm
answering
your
questions
saying.
I
think
there
are
suit
topics,
but
I
think
there's
two
topics
that
my
understanding
is
brendan
has
answered
them
by
saying:
you're,
not
work
for
a
suit.
There
are
things
that
suit
has
already
done,
and
it's
just
making
sure
that
there's
understanding
and
links
into
the
correct
sections,
if
that's
appropriate
so.
D
Yeah
so
104
and
105
there
that's.
What
was
on
that
last
slide
that
we
were
talking
through
slide.
I
don't
know
11
or
whatever
and
akira's.
C
Dave
robin
here
just
just
for
the
for
the
notes
for
clarity.
So
do
you
think
that
these
those
clarifications
should
be
reflected
in
any
of
the
teap
documents.
D
I
am
open
to
others
opinion
on
that,
but
so
far
I'm
not
sure
that
I've
seen
anything
that
needs
a
change
to
the
teep
document.
D
But
you
know
akira
is
also
an
editor
in
the
tea
protocol
document.
If
akira
says,
hey,
there's
a
particular
place
in
the
protocol
document.
That
would
make
sense
to
have
a
deep
reference
link
to
a
specific
section
of
that.
That
would
be
fine,
but
I'm
not
aware
of
anything
right
now,
but
I
would
be
open
to
that.
If
somebody
else
generates
a
pull
request.
E
Great,
thank
you,
my
thought
is
it.
I
don't
think
it's
anything
related
in
in
the
tip
protocol
draft.
It's
just
initially
the
reason
I
opened
a
file.
The
issue
in
the
t
protocol
github
is,
I
thought
it
would
be
a
good
way
to
add
the
suit
manifest
example
in
the
exam
binary
representation,
cdo
example
section
in
the
teeth
draft.
That's
all
and
moving
this
closing
this
in
the
tip,
github
and
then
and
and
moving
to
the
suit
github
is,
is
absolutely
no
problem.
D
Yeah,
I
think
the
only
one
of
these
three
issues
here
that
we
that
there
might
be
able
to
be
a
deep
reference
is
the
bottom
one.
So,
for
example,
where,
in
the
query
response
right,
that's
when
you
have
the
list
of
unneeded
tas
and
then,
of
course,
the
actual
action
happens
in
the
update
message
inside
the
suit
manifest
and
then
so
in
the
field,
description
of
unneeded
tas
in
the
career
response
or
the
processing
rules.
D
For
that
that
it
might
be
possible
if
it's
not
in
there
already
to
have
a
deep
reference
into
the
suit,
manifest
spec
section
that
talks
about
the
delete
or
the
unlink
command,
whatever
it
gets
called.
So
so
that's
an
example
of
where
in
128
at
the
bottom,
we
might
have
a
deep
reference
there,
but
for
104
and
105.
I
can't
think
of
a
case
so.
A
I
Right
so
I
had
a
couple
of
questions
for
here
about
this
hackathon
presentation,
but
I
know
I
don't
know
if
it's
you
know
the
right
time
now
or
just
wanted
to
postpone
those.
Is
it
okay,.
I
Okay,
so
this
is
from
a
rats,
slash
implementer
angle,
and
so
the
questions
are
are
any
of
the
implementation
that
you
referenced
in
the
in
the
slides,
open
source
and
and
if
so,
would
it
be
possible
to
to
have
links
to
the
source
code?
Or
I
don't
know
if
it's
in
github
or
whatever
and
okay,
so
they're
all
open
source.
I
E
Do
you
mind
going
to
the
first
phase
four.
E
E
The
link
here,
the
one
only
it's
not
open
source-
is
the
or
type
device,
the
third
one,
but
first
one.
E
Fifth,
it's
there's
a
link
to
the
github.
I
Okay,
excellent,
so
I
go
and
see
this
and
does
does
any
of
these
implements
the
the
deep
evidence
and,
if
so,
which
one
I'm
asking,
because
I
would
like
to
provide
a
verifier
for
that
and
and
would
like
to
do
some
interrupt
as
well.
In
fact,
it'd
be
it'd,
be
super
nice
if
we
could
organize
something
together
at
next
sacrament
around
that.
E
First,
one
and
yeah
in
our
influence
we
haven't,
got
to
that
point.
Okay
is,
it
is,
does
it
have
it
in
your
implementation?.
D
Mine
includes
the
evidence
fields,
but
I
have
not
implemented
the
eat
stuff
yet,
and
so
it's
basically,
I
have
stubs,
that's
there
for
plugging
it
in
and
so
that's
why,
on
your
slide,
akira
you
mentioned
that
you
know
next
hackathon
or
whatever
we
want
to
play
around
with
implementing
and
integrating
the
rat
stuff,
and
so
that's
accurate
for
me
as
well.
D
B
Maybe
you
can
post
the
github
links
on
the
mailing
list
for.
F
F
D
Hana
said
that
you
had,
he
had
slides
on
his
hackathon
stuff,
and
so
I'm
wondering
if
the
chairs
would
want
to
allow
hanus
to
come
in
to
complete
the
hackathon
discussion
before
me.
Oh.
A
F
Yeah,
but
I
think
it's
also
fine
to
cover
this
during
the
suit
meeting.
If
there
is
time.
D
Because
I
would
like,
because
it
only
has
an
hour
and
he
passed
two
hours,
and
so
we
actually
have
far
more
time
in
this
meeting
than
the
suit
meeting.
I
say
as
a
suit
chair.
Oh.
F
Okay,
yeah.
A
Why
not
so
the
the
only
question
is
you
really
will,
okay,
so
hannes,
maybe
five
ten
minutes
at
the
most.
F
B
I
can
help
you
in
this
light,
so
I
think
hans
can
share
the
screen
and
present
the
slides
if
it's
okay
with
him.
D
D
Honest
posted
them,
you
gotta
scroll
up
to
four
fourteen.
Oh
four
ninja.
F
But
I
I
can
just
present
them
requested
the
presentation
rights.
F
F
Okay-
and
I
think
I
should
get
a
a
pop-up
that
says:
hey,
can
I
yes.
J
F
Maybe
you
can
show
the
slide
yes
now
I
know
it's
you.
B
B
F
Okay,
I
tried
to
hurry
up
yeah,
so
I
was
specifically
focusing
on
the
encryption
functionality,
because
that
was
one
topic
that
was
initially
in
odrb
because
of
this
personalization
data
that
was
encrypted
and
then
in
suit.
F
We
also
had
the
requirement
to
encrypt
firmware
images
themselves
and
the
spec
the
suit
spec
points
to
cause
end
and,
of
course,
the
deep
spec
points
to
do
for
that
matter,
and
but
we
don't,
we
don't
have
any
examples
in
there,
and
so
I
wanted
to
as
part
of
this
exercise
to
just
create
a
few
real
examples.
F
And
so
I
I
used
lawrence's
presentation,
qc
board.
All
the
person
did
all
the
sibo
implementations
a
little
bit
different,
so
it's
not
so
easy
to
interchange
them.
You
basically
have
to
do
a
rewrite,
and
also
for
the
crypto.
I've
used
the
bsa
crypto
api,
which
I
I
linked
in
the
slide
deck,
but
unfortunately
it
doesn't
implement
the
key
wrap
which
is
needed
by
the
cozy
spec.
F
So
I
had
to
also
fold
in
embed
dls,
so
there
was
maybe
more
code
than
I
had
hoped
and
the
my
and
I
wanted
to
integrate
it
ultimately
in
mcu
booth,
with
the
lipsu
lip
c
suit.
That
was
mentioned
earlier
as
an
implementation.
So
I
think
the
important
part.
F
What
I
learned
from
doing
this
besides
getting
examples
is,
is
that
I
believe
the
suit
manifest
specification
needs
some
extra
details
to
make
it
easier
for
developers
and
also
to
restrict
the
number
of
options,
because
we
have
paid
a
lot
of
attention
to
keep
the
manifest
size
very
small,
but
by
just
referencing
a
cozy
spec
for
this
functionality.
F
You
basically
blow
out
all
the
benefits
of
this
optimization
out
of
the
window,
because
the
cosy
spec
has
so
many
options.
It's
unbelievable
and
some
of
them,
in
my
opinion,
don't
make
a
lot
of
sense
for
our
use
cases
and
maybe
there's
in
the
future.
There's
other
kind
of
profiles
for
other
use
cases
that
we
haven't
envisioned.
F
F
What
it
does
is
it
create
a
content,
encryption
key,
a
random
content,
encryption
key
and
includes
this
content,
encryption
key
with
with
the
long-term
symmetric
key
that
is
available
and
and
then
the
spec,
the
suit
spec
uses
it
in
a
in
a
detached
mode
or
the
encrypted
firmware
is
not
included
in
the
cosi
in
the
in
the
cosy
structure.
F
So
it's
separate,
so
I
think
that's
also
one
aspect
and
yeah,
so
that
was
for
the
for
the
key,
rap
and,
and
the
example
is,
can
be
then
quite
sort
of
simple
or
small
and
then
the
other.
The
other
functionality
I
implemented,
which
is
a
little
bit
more
complicated.
But
it's
essentially
the
public
key
based
version
that-
and
there
are
also
many
options
in
the
cosy
spec
and
the
one
that
I
picked
after
looking
into
into
the
mcu
boot.
F
Was
I
used
the
elliptic
curve
tv
hellman
ephemeral,
static
mode
with
the
hkdf
which
also
used
the
aes.
B
F
And
and
so
in
in
essence,
the
entity
that
creates
the
firmware
image
again
in
a
detached
sort
of
as
a
standalone
then
creates
the
manifest
which
then,
where
the
this
party
then
creates
an
ephemeral
keypair,
and
it
includes
the
public
key
into
the
manifest
and
then
uses
them
akita.
The
hkdf
key
derivation
function
to
derive
the
key
that
is
used
to
encrypt
the
content.
Encryption
key
like
we
had
before,
and
that
is
the
that
is
then
used
to
encrypt
the
firmware
image
in
detached
mode.
F
So
it's
a
little
bit
convoluted,
but
but
I
think
with
the
this
is
the
description
with
the
added
description
and
I'm
going
to
prepare
br
on
how
that
text
would
look
like
for
the
meeting
for
the
student
meeting.
F
So
I
think
that
will
help
to
make
it
to
have
the
examples
in
there
and
have
the
text
in
there
so
that
the
implementers
get
those
two
modes
right
and
if
someone
wants
some
other
modes
of
course
feel
free
to
suggest
some
others
and
yeah.
I
would.
I
would
also
like
to
thank
russ
who
helped
me
with
some
of
the
with
the
key
rap
stuff,
and
then
I
had
a
chat
with
ken
about
his
lip
suit
and
and
brandon
on
the
cozy
stuff.
F
I
totally
forgot
again
that
we
use
the
e-dutch
mode
and
I
reached
out
to
the
mcu
boot
guys
about
their
capabilities
there,
because
ultimately,
I
wanted
to
in
in
this
case
I
wanted
to
add
the
suit
to
the
mcu
boot
to
have
sort
of
equivalent
functionality,
just
which
allowed
me
to
constrain
constrained
the
number
of
options
to
something
that
is
usable
also
in
the
mcu
boot
case.
A
Sounds
great
dave
you're
in
the
queue.
D
I
asked
since
honest
on
slide
four
you
mentioned
that
you
think
clarifications
are
needed
to
the
suit
manifest
document.
I
just
want
to
explicitly
ask:
are
there
anything
that
you
think
that
should
change
in
any
of
this
in
any
of
the
teep
documents?
Obviously,
this
use
case
is
important
because
we
talk
about
the
requirements
in
this
use
case
in
the
architecture
document
right
now,
but
is
there
anything
that
you
think
would
need
to
be
added
into
whether
it's
an
example
or
anything
else
in
the
teat
documents?
D
F
Yeah
so
previously
there
was
this
a
comment
about
adding
examples,
also
to
the
deep
document,
and
I
guess,
if
we
add
an
example,
sort
of
a
more
complete
example
with
the
suit
manifest
in
there.
I
think
it
makes
also
sense
to
maybe
include
one
that
also.
B
D
Okay,
got
it
all
right,
so
thank
you
because,
as
I'll
I
don't
remember
if
I
mentioned
this
in
the
next
presentation
or
not,
but
the
the
the
t
protocol
document
now
does
have
in
the
appendix
a
minimal
suit
manifest
in
the
example,
and
so
it
could
be
augmented
there.
So
all
right,
gotcha.
Thank
you.
D
A
Thanks
guys
and
hannes
I'll
upload
your
slides
to
the
teeth
materials
too,.
F
D
F
There's
one
comment
on
the
static
dp
helmet,
yeah
yeah.
I
saw
that
too
and
that's
why
I
was
confused
about
what
that
dls
presentation
really
did,
but
it
that
presentation.
If
I
really
understood
it
correctly,
was
more
concerned
about
specific
uses
of
the
cypher
suite
and
not
so
much
about
these
one-shot
messages,
because
there
is,
there
is
no
possibility
to
do
a
like
the
key
encryption
without
actually
having
one
party
a
one-shot
key
encryption
with
elliptic
tiffy
helmet
without
without
a
static
component
in
the
app
right.
F
D
So
I
think
yep
all
right
so
I'll
talk
about
the
changes
since
009.
This
is
the
actual
protocol
spec,
and
so
this
will
be
probably
the
rest
of
the
meeting
or
until
church
call
time.
So
all
right,
there
are
things
that
we
discussed
at
109,
and
so
a
bunch
of
the
changes
were
things
we
discussed
at
109..
So
here's
the
list
of
things
we
discussed
109
that
are
now
done
in
the
specs.
D
So
we
combined
the
install
and
delete
message
into
one
common
update
message,
so
you
can
do
both
installs
and
deletes
in
the
same
message,
even
in
the
same
suit
manifest
that
we
made
the
token
be
absent
when
it's
redundant.
So,
for
example,
if
you're
using
attestation-
and
you
are
getting
all
of
the
matching-
and
you
know
nonsense-
stuff
and
the
evidence-
then
you
don't
need
it
outside
the
evidence
in
the
response.
D
So
now
the
token
is
only
present
when
it's
not
already
redundant
with
something
else
the
cipher
suites
we
talked
about
are
now
both
of
them
are
mandatory
to
implement
on
the
tam
and
both
are
optional
on
the
agent
and
we
use
the
suit
component
identifier.
As
the
trusted
component
id,
so
all
those
things
are
things
that
we
resolve
at
109.
In
the
meeting
discussion,
people
can
go
back
to
the
minutes
and
recordings
and
stuff
there,
but
those
are
all
accomplished
as
we
discussed
them.
D
We
then
discussed
something
that
was
kind
of
open
going
into
109,
which
was
it's
been
a
cure
referred
to,
which
is
the
suit
manifest.
It's
now
used
to
delete
components,
and
so
that's
what
akira
was
mentioning
that
we
removed
the
ability
in
the
update
message
to
explicitly
specify
component
ids
to
delete,
because
that's
now
inside
the
suit
manifest.
So
that
was
also
done
in
this
draft.
So
next
slide.
D
All
right
and
then
some
things
that
we'll
talk
about
in
later
slides
here,
one
two
and
three
that
I'll
drill
down
into,
but
four
five
and
six
I'll
just
cover
here
so
akira
proposed
and
we
accepted
adding
maximum
sizes
to
various
integer
fields.
To
make
it
easier
for
constrained
implementations
to
know
how
big
of
a
of
a
buffer
to
use
or
to
to
have
for
say,
integer
fields
and
things
integer
fields,
and
even
you
know
token,
and
so
on-
have
a
maximum
size
there.
D
D
But
now
it's
explicit
that
we
now
have
a
place
to
do
that
and
we
filled
in
a
bunch
of
that
information
and
then
a
bunch
of
editorial
clarifications
that
are
worth
presenting
because
they're
all
editorial,
but
the
top
three
are
ones
that
we
need
to
discuss,
and
so
I
got
slides
on
those
three.
So,
let's
talk
about
talk
to
those
one
at
a
time
first,
so
next
slide.
D
Okay,
so
the
issue
number
49
was
you
know.
The
architecture
document
says
that
in
for
the
tpu's
cases
that
the
evidence
has
to
have
at
least
a
bunch
of
the
following
information
in
it,
or
at
least
capable
of
having
the
following
information
in
it.
It's
up
to
the
implementation,
whether
it
actually
has
a
specific
piece,
but
across
the
use
cases.
D
This
is
the
set
of
things
that
are
needed
for
the
union
of
them
or
the
they,
and
so
that's
the
list
on
the
left
side,
which
is
the
items
listed
in
the
teep
architecture
document,
which
of
course,
has
been
through
last
call.
So
we
already
have
consensus
on
the
leftmost
column,
the
right
most
column,
you
can
see
the
ones
that
mentioned
draft
ietf
rs
eat
are
the
ones
that
we
agreed
are
already
covered
in
the
existing
eats
eat
specification.
D
The
the
first
two
that
have
eat
in
them
are
kind
of
interesting,
because
there's
two
of
the
type
requirements
that
are
actually
in
the
same
plane
right.
The
chip
version
and
scheme
has
multiple
things
in
it.
That
I've
are
like
hyphen
separated
or
something
like
that,
so
that
one
needs
both
required
that
meet
both
requirements,
but
then
all
the
other
ones.
Besides,
the
three
that
say,
draft
itf
rats
eat
were
not
met
in
the
eat
document,
and
so
this
is
a
discussion
we
had
last
iatf.
D
I
think
in
like
rat's
discussion
where
hank
and
we
had
a
email
discussion
right
before
last
iatf
that
we
discussed
at
ietf,
but
I
don't
think
it
was
in
the
team
meetings.
That's
why
I'm
reporting
stuff
out
here
so
after
last
iatf
hank
then
went
and
wrote
a
document
that
actually
did
what
was
discussed
on
that
cross
rat.
D
Slash
e
sorry
grab,
slash
cheap
milling
list
discussion
and
that's
draft
burkhall's
rats
suit
claims,
which
was
also
presented
briefly
in
the
rats
working
group
yesterday,
and
so
the
claims
there
in
the
middle
are
the
ones
that
show
up
in
the
draft
berkeley
rats
suit
claims
in
those
sections
that
were
added
to
meet
the
teep
requirements
in
a
way
that
is
actually
not
team
specific.
D
So
if
you
look
in
the
teat
protocol
spec,
you
can
see
how
to
meet
the
requirements
in
the
tea
architecture
by
reference
to
the
two
rats
documents
and
so
in
rats.
Yesterday
there
was
a
discussion
about
whether
the
burke
hall's
document
should
be
combined
into
the
eat
document
or
what-
and
I
think
eat
is
on
the
agenda
for
rats
in
the
meeting
slot
later
today.
D
But
the
point
is
we
added
this
table
into
here
and
we'll
update
the
references
as
the
references
need
to
be
updated,
but
we
believe
the
list
of
claims
is
now
there.
All
requirements
now
appear
to
be
met
and,
of
course,
since
there's
a
normative
dependence,
well
there's
a
normative
dependency.
That's
actually
incorrect!
I
look
back
at
the
document
it's
informative.
D
Actually
it
could
go
either
way.
So
let
me
just
leave
that
open
right
now,
so
I
don't
know
if,
unless
there's
any
questions,
I
don't
think
there's
anything
else
here
to
talk
about
because
we'll
just
track.
The
the
issue
for
the
rats
document
is
the
draft.
D
Burp
does
not
actually
have
the
labels,
and
so
it's
actually
not
implemented
yet
because
you
can't
have
you
know,
what's
this:
what's
the
seaborn
numbers
to
use
to
for
those
claim
things
so
the
table
is
in
there,
but
you
can't
actually
implement
it
yet
and
we
would
like
to
be
able
to
get
to
that
before
next
ietf
and
so
to
answer
the
question
that
was
asked
early
in
this
meeting,
where
any
of
the
hackathon
implementations
doing
each
answer.
D
No-
and
this
is
one
of
the
reason
why
is
we
need
those
numbers
that
are
in
the
draft
bar
calls
one
before
you
can
actually
do
an
implementation
so
that
that's
why
it's
pushed
the
next
ipf?
All
right,
unless
there's
any
other
questions,
I
don't
know
if
there's
anything
in
the
chat,
no,
all
right.
Let's
go
to
the
next
slide,
then,
but
feel
free
to
jump
in
the
queue.
If
you
have
questions
about
rats,
interaction,
okay,
here's
the
example
oh
yeah.
This
is
I.
J
I
Sorry,
my
my
audio
at
the
critical
moment,
I'm
I'm
not
sure
you
said
whether
the
hardware
identifiers
claim
need
pre-registration
or
not.
D
That,
I
believe,
is
a
question
for
the
rats
working
group
rather
than
the
cheap
working
group,
and
so
I
think
we
will
use
whatever
rats
does.
D
F
D
Requirements
right
in
the
architecture
document
and
the
architecture
document,
you
can
read
it
as
not
having
any
requirement
in
that
respect,
and
so
that's
why
I'm
just
echoing
out
so
far
our
consensus
we've
not
had
any
consensus
that
there
is
any
requirement
there.
So
I
need
the
directions,
though,
right
thanks:
okay,
all
right
so
next
slide.
D
So
67
is
closely
related
still
related
to
rats
here.
This
one
was:
could
we
add
a
sample
eat
into
the
document,
because
we
talked
about
sample
messages
and
it
says
well,
it
carries.
But
of
course
it's,
the
content
is
elided.
D
So
can
we
fill
in
the
content
as
an
example
right-
and
this
is
the
appendix
for
examples,
so
we
did
that,
and
so
this
is
a
sample
eat
that
actually
appears
in
the
appendix
right
now,
and
you
can
see
the
tbd's
in
there,
which
is
how
they're
labeled
in
the
draft
perk
holes
document,
and
so
that's
why
you
can't
implement
it
yet
because
you
can't
implement
the
bottom
half
of
this,
and
so
this
is
a
complete.
This
is
a
made-up
example
that
doesn't
match
to
any
real
tees.
D
That's
why
you
can
see
the
chip
version
scheme
is
my
tee.
Just
you
can
fill
in
a
a
dummy
good
for
a
device
and
vendor
and
class
and
so
on.
So
this
is
not
a
realistic
one.
This
is
just
a
hypothetical
one,
with
a
with
a
made
up
te,
just
a
hat
show
how
the
claims
can
actually
fit
in
and
and
work
together.
So
if
we
after
implementation,
then
we
might
update
this
example.
D
We
could
maybe
have
a
real
one
if
we
wanted
to,
but
right
now
we
just
want
to
show
that
all
the
claims
are
met
and
how
it
fits
into
the
team
message.
So
that
was
issue
67,
which
is
resolved
other
than
filling
in
the
tbds
so
which
we
depend
on
rats.
For
and
again
all
those
tvs
are
the
ones
that
would
be
out
of
the
draft
burke
hall's
document.
Currently,
if
they
got
merged
into
eat,
that's
fine,
but
we
just
need
those
tbgs
and
so
in
the
rats
meeting.
D
All
right,
let's
use
any
questions
on
that
we
can
go
on
to
the
next
slide
all
right,
so
this
one
is
one
that
I
ran
into
and
I
I
proactively
merged
it,
but
I
do
not
claim
that
there
is
consensus.
D
Did
the
right
thing
that
I
have
support
for
this?
Otherwise
we
have
to
like
revert
it
or
do
something
else
which
is
okay,
because
this
is
still
open.
Okay,
so
the
issue
is
as
follows:
the
error
messages
have
an
integer
error
code
and
they
have
an
optional
text
message
right.
This
has
always
been
the
case
since
the
draft
zero
draft004
had
a
bunch
of
error
codes
and
had
an
eye
on
our
registry
for
the
error
codes.
D
Draft
of
five
makes
the
following
proposal:
okay,
new
error
codes.
I'm
just
going
to
read
this
because
this
is
the
important
part
here,
because
the
these
bullets
here
are
actually
quotes
out
of
the
actual
draft.
All
five
new
error
codes
should
be
added
sparingly,
not
for
every
implementation.
Error
error.
That's
the
intent
of
the
error
message
field!
That's
that
text
message
which
can
be
used
to
provide
details
meaningful
to
humans
right.
D
So
it's
saying,
don't
add
a
new
error
code
just
because
you
have
a
different
text
message
right
just
because
you
have
something
new
that
is
meant
for
a
human,
the
use
of
integers,
you
don't
add
new
integers
just
for
humans
right
new
error
code
should
be
only
added,
should
only
be
added
if
the
tam
is
expected
to
do
something
behaviorally
different
upon
receipt
of
the
error
message
rather
than
just
logging
the
event.
D
Hence
each
error
code
is
responsible
for
saying
what
the
behavioral
difference
is
expected
to
be
okay.
In
other
words,
the
proposal
is
use
integers,
if
you're
at,
if
you
actually
expect
them
to
show
up
in
a
switch
statement
on
the
tam
or
equivalent
right
or
jump
table
or
whatever
right
and
use
error
messages,
if
you
want
have
things
that
are
meant
to
be
different
for
humans,
so
you
can
overload
the
same
error
number
if
you
get
the
same
behavior
and
I
just
have
different
text
messages.
That's
fine
right!
D
You
don't
need
to
do
error
code
number
unless
you'd
have
a
different
entry
in
a
switch
or
a
jump
table
right
and
as
a
result,
each
error
code.
That
would
be
added
would
be
responsible
for
saying
an
example
of
what
the
behavioral
difference
is
expected
to
be.
I
got
an
example
on
the
next
slide,
so
so
that's
the
that's
the
new
text
that
appears
in
draft
0.5,
whether
people
like
it
or
not.
We
can
update
it
now.
The
result
of
this.
D
Okay,
that's
the
potentially
more
contentious
thing
that
I
want
to
call
out
says:
that's
why
it's
because
the
rule
proposed
is
that
in
order
to
add
one
that
you
got
to
say
what
the
behavioral
difference
would
be
and
therefore
that
would
be
more
like
an
rfc
required
rather
than
an
ionic
request.
Okay
and
so
as
a
result,
that
rule
also
resulted
in
reducing
the
number
of
error
codes,
because
a
couple
of
them
collapsed
because
the
behavior
would
have
been
approximately
the
same
or
would
be
the
same,
and
we
had
example
behavioral
differences.
D
So,
let's
look
at
the
next
slide,
so
that's
what
you
can
use
to
actually
evaluate
go
to
the
next
slide,
all
right,
so
this
is
trying
to
make
it
fit
on
one
slide,
so
I've
removed
redundant
words
by
putting
up
at
the
top
and
say
so
tim
receiving
this
error
might
right.
This
is
informative,
not
normative,
to
show
an
example,
because
the
actual
implementation
behavior
is
up
to
the
implementation,
but
to
motivate
why
two
things
are
different
right
then
there's
different
example:
behaviors.
You
can
look
at
and
says
well
yeah.
D
I
guess
it
is
a
pretty
different
behavior
than
the
other
ones
and
so
yeah
I
mean.
I
think
that
makes
sense
to
have
that
many
different
things,
because
that
many
possible
behaviors
and
so
here's
some
examples
right,
stop
trying
for
some
long
time.
Right,
for
example,
you
know
you
don't
support
a
common
version
or
something
like
that.
So
you
know
it
doesn't
matter
if
I'm
going
to
resend
unless
the
other
side
has
been
updated,
then
there's
no
point
we're
not
going
to
communicate.
That
would
be
example
of
permanent
error
retry
without
using
extensions.
D
If
you
find
that
there's
a
unsupported
extension
retry
using
a
different
version,
if
there's
a
mismatch
in
the
message
version
retry
using
a
different
crypto
algorithm,
if
the,
if
you
get
a
crypto
algorithm,
not
supported,
because
you
have
multiple
of
them
that
you
can
support,
you
just
try
it
with
a
different
one,
bad
certificate.
If
you
got
multiple
certificates,
you
can
try
a
different
certificate
certificate
expired.
D
Well,
you
might
kick
off
a
procedure
to
do
a
renewal
or
something
before
using
it
again
thinking
well,
okay,
maybe
your
times
aren't
quite
in
sync
and
he
thinks
it
expires.
You
know
five
minutes
before
me
and
oh
look
it's
getting
close
to
when
I
would
normally
renew
it.
I
don't
know
something
like
that.
D
So
temporary
error
might
be
something
like
out
of
memory,
and
so
I
might
want
to
retry
after
some
short
time,
because
just
because
he
hit
error
now
doesn't
mean
he's
going
to
hit
an
error
next
time
and
then
the
last
one
is
manifest.
Processing
failed.
So
something
was
bad
inside
a
particular
suit,
manifest
like
it
couldn't
do
some
command
or
trying
to
do
that
command,
hit
some
error
or
something
else,
but
that
might
not
prevent
me
from
trying
to
install
or
update
other
components
with
other
suit
manifests
right.
So
all
those
are
distinctly
different.
D
Behaviors
and
solos
make
perfect
sense
as
having
a
distinctly
different
error
code,
because
you
could
easily
imagine
an
implementation
that
has
a
switch
statement
or
jump
table
that
has
different
handlers
for
each
of
those
and
triggers
a
particular
action
in
code
in
the
tam.
Okay.
Now
maybe
there's
some
other
ones
you
can
think
of,
but
there
was
a
longer
set
in
draft
04
that
I
collapsed
into
exactly
this
list.
D
So
there's
a
couple
things
that
were
collapsed
into
permanent
error
and
a
couple
things
that
were
collapsed
into
temporary
error,
for
example,
but
if
there's
other
ones,
that
would
be
happy
to
add
them.
But
I
want
people
to
understand
this.
Is
the
proposed
rule
for
how
to
do
that
and
to
use
text
error
messages
for
things
that
are
only
differences
for
humans
or
for
logs?
And
so
that's
the
one
that
I
wanted
to
actually
verify.
D
We
have
we're
going
in
the
right
direction
in
the
document
right
now,
since
we
didn't
talk
about
this
before
it
was
just
in
a
github
issue,
so
I
will
pause
in
case.
Anybody
wants
to
jump
into
the
queue,
but
otherwise,
if
I
don't
see
my
jumping
into
q,
I
will
continue
all
right.
I
see
robin
wilton
jumping
in
the
queue.
C
Hi
dave,
yes
robin
and
I
have
to
say
I'm
from
isoc,
but
not
speaking,
for
ice
hock.
C
Yeah.
So
are
you
going
to
give
corresponding
examples
of
an
error
code
that
might
have
that
that
sorry,
an
error
code
that
does
not
justify
sufficiently
different
protocol
behavior
and
therefore
is
only
distinguishable
through
the
human
message.
In
other
words,
you
know
the
other
half.
D
I
was
not
okay,
but
if
you
want
one,
the
easiest
way
to
get
that,
maybe
one
of
the
other
t
protocol
editors
can
look
in
a
github
issue,
51
or
sorry
and
go
to
the
pull
request
and
look
at
the
pull
request
and
see
because
I
can't
remember
which
ones
were
deleted.
Like
I
said
the
easiest
ways,
I
think
there
was
at
least
two
that
were
combined
into
permanent
error
and
at
least
two
that
were
combined
in
a
temporary
error.
And
I
can't
remember
that
looking
back
at
the
github
pull
request.
C
D
D
D
One
case
is
where
there
was
a
memory
allocation
failure,
and
so
the
agent
fills
in
you
know.
Temporary
error
and
another
case
might
be
where
there's
some
component,
that
the
some
resource
other
than
memory.
Maybe
it's
a
disk
space
where
the
agent
needs
access
to
disk
space,
or
you
know,
secure
storage
or
something
like
that
and
can't
get
it
or
it's
not
currently
available.
So
there's
two
different
resources
that
it
needs
between
memory
and
storage
and
it
can't
get
one
or
the
other
and
both
of
those
resolve
to
temporary
error
right.
C
D
D
But
we
want
you
to
do
both
robin,
so
don't
stop
taking
notes.
Don't
stop
asking
questions
all
right
next
slide,
then,
unless
there's
anybody
else
all
right
now,
I'm
watching
the
cue
thing,
not
the
chat
thing.
Sorry
so
chairs
will
have
to
interrupt
me
if
there's
anything
in
chat
for
me.
So
all
right.
So
the
next
issue
and
this
one
now
we're
getting
into
ones
that
are
not
in
the
current
draft.
D
These
are
in
github,
but
not
any
text
that's
been
put
into
the
document
yet
so
this
is
one
that
we
ran
into
during
hackathon
implementation
and
trying
to
figure
out
what
to
do
about
it,
and
so
currently
I
have
implemented
what
the
draft
says,
which
is
not
great.
D
So
the
issue
comes
up
when
you
have
errors,
processing
the
query
request,
and
so,
if
I,
if
you
go,
if
you
think
about
the
things
we
just
talked
about
unsupported
message-
version,
unsupported
crypto,
algorithm
and
so
on.
So
let's
talk
about
unsupported
message:
version.
Okay.
This
is
kind
of
interesting
because
the
document
has
had
this
error
code
in
it
since
the
beginning,
so
you
think
about.
When
would
you
hit
this
error?
Okay?
D
Well,
you'd
hit
it
certainly
in
processing
a
query
request:
okay,
you
can
hit
it
in
processing,
an
update
message,
and
previously
the
document
says
that
you
can
only
ever
send
an
error
message
in
response
to
an
update
message.
Okay,
so
that
means
this
error
code
could
only
be
sent
in
if
you
hit
this
in
the
error
message.
D
Okay,
if
you
hit
this
in
the
update
message,
but
when
you
get
an
update
message,
you
get
an
update
message
after
sending
a
query
response,
how
do
you
send
a
query
response
by
processing
a
query
request?
How
do
you
process
the
courier
request?
Answer
you
can't
so
that
means
this
is
basically
an
error
code
that
there's
no
way
to
possibly
hit
a
normal
implementation
in
the
current
spec.
That's
the
issue!
D
Okay,
and
so
what
do
you
do
when
you
process,
when
you
hit
an
error
like
unsupported
message
in
the
query
request
what
the
document
says
right
now.
Is
you
drop
it?
You
do
nothing
so
there's
no
way
to
send
an
error
message.
There's
no
way
to
communicate
that
you
have
an
unsupported
message
version!
That's
the
issue:
that's
in
the
document
right
now.
So
the
question
is:
what
do
we
do
about
that?
Okay,
so
a
couple
of
options
we
could
do
number
one.
D
We
could
allow
an
error
to
be
sent
in
response
to
a
career
request
right.
That
would
be
my
preference
number
two.
We
could
do
what
the
draft
says
right
now,
which
is
to
silently
drop
the
query
request.
In
other
words,
the
tim
never
gets
any
feedback
whatsoever
that
the
that
there's
a
message
version
mismatch,
and
that
makes
it
really
hard
to
debug
things
and
so
for
us
as
hackathon
developers.
D
I
would
prefer
not
that
one,
which
is
what
the
graph
says
right
now
number
three
is
well.
We
could
copy
it
into
the
query
response.
It
says
you
send
the
query
response,
but
you'd
have
the
extra
error
fields
in
there.
We
could
do
that,
one.
That
just
seems
like
it's
extra
duplication
for
no
real
benefit,
and
so
that's
why
my
proposal
is
we
go
with
number
one,
which
is
we
change
the
spec
to
allow
the
existing
error
message.
D
That's
right!
The
existing
error
message
to
be
sent
in
response
to
a
curry
request
now.
One
thing
to
keep
in
mind,
though,
is
if
it
is
in
particular
the
unsupported
message
version
you
might
be
sending
an
older
error
message
version
to
the
tam
and
we
just
have
to
be
able
to
deal
with
that,
but
that,
I
think,
is
the
preferable
option
out
of
these
three
and
I
couldn't
think
of
a
fourth
option.
D
So
my
proposal
is
to
go
forward
with
option
one
in
the
next
version
of
the
document,
and
I
would
update
that
in
my
implementation,
which
would
be
very
easy
to
do,
but
I
am
open
to
feedback
if
people
think
that's
the
wrong
direction.
D
Pausing
in
case
anybody
wants
to
jump
into
the
queue
yeah,
certainly
from
other
hackathon
people.
Did
you
run
into
this,
and
what
do
you
do
with
your
implementation?
So
I
see
a
curious
inquiry.
D
D
Okay,
good
again,
my
preference
for
one
is
because
there's
far
less
spec
work
and
less
duplication
in
code
right
because
now
my
message,
composer
on
the
agent
side
and
message
parsers
on
the
tam
side,
only
to
look
for
error
codes
in
one
place
and
not
two
and
that's
why
one
is
simpler
to
implement.
D
D
All
right,
russ,
housely
center
review
about
cipher
suites,
and
so
the
top
half
of
the
slide
is
what's
in
the
document
right
now,
there's
two
cipher
suites:
you
can
call!
You
can
see
those
two
there.
Those
are
the
two
that
are
both
mandatory
to
implement
on
the
tam
and
you
can
pick
or
choose
on
the
agent
and
right
above
that
not
shown
here
is
the
direction
that
says
you
know.
Here's
the
table
or
and
an
algorithm
is
required.
D
That
has
an
hmac
and
he
says
I
think
future
cipher
suite
should
allow
mac
algorithms
other
than
h,
mac
such
as
gmax,
so
just
change
hmac
to
mac,
and
there
he's
not
talking
about
the
table.
He's
talking
about
that
text,
that's
right
above
the
table
that
says
the
algorithms
need
a
mac
algorithm,
and
so
I've
done
that
in
a
pull
request.
But
it's
not
in
the
document
to
just
make
that
change
that
says.
Future
ones
need
a
mac.
D
It
doesn't
have
to
specifically
say
that
the
future
ones
would
need
an
hmac
in
particular,
so
but
the
open
question
here
that
I
would
like
the
feedback
on
that.
It's
not
in
any
request
now
that
we
just
need
a
decision
on.
So
I
know
what
to
put
in
the
text.
D
K
So
we've
seen
in
other
working
groups
that
if
we
don't
say
what
the
rules
are
up
front,
then
the
iana
expert
has
to
decide
what
was
meant,
whereas
if
we
put
it
in
the
document
whether
we
can
have
integrity
without
confidentiality
or
not,
now
then
we're
then
the
iana
expert
can
enforce
the
working
group's
consensus
and
not
have
a
big
ios
head
scratch
moment.
D
So
since
I
don't
know
what
does
somebody
else
have
a
proposal
for
which
one
which
direction
would
be
the
answer,
so
whether
integrity
without
confidentiality
should
be
allowed
or
disallowed.
D
I
don't
know
it's
ming
on
here.
If
you
have
any,
I
guess
ming
isn't
on
here.
So
honest,
do
you
have
any
opinion.
B
Hey
dave,
I
have
a
comment.
I
I.
F
B
Lot
the
messages
being
exchanged
with
the
the
time
and
deep
agent
carry
a
lot
of
pai
data
like
the
device
identifier,
the
kind
of
trusted
applications
that
get
installed
and
it
has
a
big,
serious
privacy
impact
if
it's
sent
in
clear
text.
So
unless
there's
a
justification,
how
that
is
not
going
to
identify
a
specific
user's
device
or
it's
not
going
to
hamper
someone's
privacy
sure
we
can
code
with
integrity.
B
But
I
see
a
lot
of
sensitive
data
being
exchanged
and
I
I
don't
see
a
reason
why
we
should
degrade
someone's
privacy
by
not
allowing
confidentiality
at
this
time.
D
Yeah,
I
see
a
question
in
chat
from
jonathan
hamill,
which
is
a
reasonable
question
about
you
know
implying
I
don't
know
I
don't
have
a
preference
until
I
know
what
the
mech
is
used
for.
So
I'm
wondering
honest:
can
you
summarize
what
the
mac
is
used
for
for
that?
You
can
probably
do
it
more
succinctly
than
I
can.
F
Actually,
that's
not
true,
so
we
have
the.
F
We
have
in,
for
example,
with
so
it
depends
on
what
the
this
is
used
for
the
method.
D
Right
yeah
now
remember
this
is
the
question
is
not
about
whether
to
lost
something
without
a
mag.
The
question
is
whether
it
allows
something
without
encryption.
So
jonathan,
I'm
just
extrapolating
from
jonathan's
questions.
What's
the
mac
used
for,
let
me
rephrase,
can
you
summarize
what
the
cipher
suite
is
used
for
right?
This
is,
for
you
know,
encryption
or
it's
just
used
for
a
message.
Authentication.
I
just
want
if
you
can
give
us
that
answer.
Otherwise
I
can
try.
If
you
don't
want
to
do
so.
D
So
I
think,
there's
one
layer
that
is
used
to
keep
track
of
the
integrity
of
the
teep
message
and
so
separately
is
the
integrity
or
confidentiality
of
the
component
being
delivered
via
teep
right.
That
is
done
by
stuff.
That's
inside
the
suit
manifest.
Okay,
that's
not
what
this
one
is
about.
This
is
about
the
t
messages
themselves.
So
honest,
please
correct
me
if
I
say
something
wrong.
C
D
So
not
about
the
payload,
so
let's
pretend
that
you've
already
got
confidentiality
of
the
payload
okay.
This
is
about
whether
the
cheap
messages
themselves
have
integrity
which
they
do
or
the
teat
messages
themselves
have
confidentiality,
and
so
I
think
this
is
equivalent
to
saying:
can
the
t
messages
have
not
confidentiality
at
the
teep
message
layer?
You
still
have
confidentiality
at
the
payload
layer
and
in
theory
you
have
some
confidentiality
at
the
transport
layer,
although
that
confidentially
terminates
outside
the
tee.
D
So
it's
not
end
to
end
in
the
true
protocol
sense
and
so
the
met,
that's
heap
message
would
be
if
you
need
to
protect
the
confidentiality
of
say,
which
component
ids,
that
you
are
installing
and
uninstalling.
Would
that
be
confidential
information
and
in
some
use
cases
the
answer
is
absolutely
some
of
the
workloads
or
tas
that
you're
installing
might
be
personally
identifiable
information
right
if
you're,
installing
you
know
health
things
like
you
know,
blood
pressure
monitor
things
onto
a
device
or
whatever.
Then
that
can
be
confidentiality.
D
I
guess
the
question
is:
would
we
want
to
allow
t
messages
in
cases
where
the
components
being
installed
and
uninstalled
and
updated
that
the
I
that
the
categories
of
them
are
things
that
need
to
have
that
that
do
not
need
confidentiality
protection
and
it
would
be
fine
to
just
use
a
cypher
suite
for
the
t
messages
that
does
not
provide
confidentiality
of
the
t-petters?
K
D
That
is
a
great
point.
I
think
right
now
in
actually
some
who
can
speak
authoritatively
to
that
my
recollection
is
that
eat
is
a
json
web
token
or
cbor
web
token,
and
so
it
turns
the
same
answer
as
json
web
tokens
and
seaboard
web
tokens,
and
so
my
belief
is
yes,
I
think
they
can
use
cose
and
jose
for
the
jwts
and
cwts.
But
somebody
else
can
correct
me
if
I
said
that
wrong.
K
D
So
if
we
don't
know
any
better,
so
I
guess
here
I
don't
know
if
you
had
a
specific
preference.
Thank
you
ben
for
for
confirming
that
we
said
it
correctly.
So
since,
if
it's
true
that
it's
optional
and
eat,
then
it
might
make
sense
to
not
constrain
it
here.
D
To
say,
if
there's
some
use
case,
where
you
don't
care
about
confidentiality,
and
you
want
to
design
a
cipher
suite
for
that,
you
have
a
good
enough
reason
then,
giving
that
freedom
to
the
iona
expert
to
allow
it
might
be
okay
to
so
we
could
because
right
now
we
don't
constrain
it
and
we'd
be
explicit
about
us,
not
constraining
it
unless
there's
some
reason
to
say
nope,
sorry
in
a
confidentiality
only
right
now
and
that's
really
the
question.
A
Yeah,
so
I
I
didn't
realize
I
was
unmute,
so
speaking
from
the
rat's
perspective,
the
we
recall
that
there
is
a
draft
that
speaks
to
the
use
cases
in
which
no
confidentiality
is
needed.
It's
the!
U.
A
So
this
is
to
say,
I
think
the
intent
of
eat
is
that
you
would
use
and
and
that's
where
jim
shad
was
providing
the
feedback
with
the
understanding
that
eat
whether
you
were
using
the
cwts
or
the
jwts
that
you
would
be
using
confidentiality
in
those
tokens,
which
is
why
the
uccs
draft
was
presented.
D
Okay,
so
I
see
a
comment
from
brendan
that
I
agree
with,
and
so
I'm
going
to
channel
you
with
the
mic
here
brendan.
If
you
allow
integrity
without
confidentiality,
then
there's
a
security
consideration
in
doing
that
about.
D
You
know
talking
about
how
much
it
exposes
personal
information,
and
so
if
we
go
the
approach
that
says
we're
going
to
potentially
allow
this
in
the
future,
then
we
could
introduce
a
constraint
saying
any
registration
that
would
actually
propose
that
is
responsible,
for
you
know,
must
discuss
the
whole
pii
issue
and
what
fields
are
legal
to
be
expressed
in
that
t
in
the
teep
message
or
whatever,
for
example,
is
it
only
possible
when
you
have
eats
that?
D
Does
that
do
have
encryption
inside
them
that
type
of
stuff,
and
so
we
could
have
that
type
of
a
constraint
that
we
put
into
our
document?
That's
actually
requirements
for
those
proposing
an
integrity.company,
lg
cipher
suite.
I
don't
know
if
that
answers
your
your
point
brendan,
but
yeah.
I
agree
with
your
point
so.
D
Okay,
plus
one
thanks
brandon
for
confirming
all
right
so
and
I
guess
make
forward
progress.
Let
me
just
make
a
proposal
here
and
see
if
there's
objections
to
it,
I
guess
the
proposal
is
that
we'll
go
ahead
and
do
that
in
the
next
version
is
that
we
will
allow
potentially
allow
future
integrity
without
confidentiality.
D
Should
there
be
requests
for
it,
but
introduce
a
constr
a
requirement
for
anybody,
doing
that,
to
talk
about
the
security
considerations
and
how
it
protects
things
or
perhaps
disallows
the
use
in
certain
cases,
so
we'll
try
to
take
a
shot
at
proposing
some
text
like
that
for
folks
review.
So
all
right.
Unless
there's
any
objections,
then
I'll
take
that
as
a
direction
and
then
we
can
review
it
as
it
appears
in
the
next
document,
not
gonna
be
version.
So
all
right,
let's
move
on.
D
All
right
so
suit
manifest
examples.
There's
a
there's
been
an
open
issue
that
says:
can
we
add
a
suit
manifest
example?
I
think
we
had
a
simple
one
in
the
document.
This
is
what
we
were
talking
about
earlier
in
the
suit
discussion,
the
suit
the
relationship
discussion
from
academy.
D
So
the
real
question
is
whether
the
suit
manifest
examples
for
teep
should
be
in
the
protocol
spec
or
a
suit
manifest
spec,
and
so
this
is
not
the
first
time
this
has
been
on
the
agenda,
but
I
hope
it's
the
last
time
that
it's
on
the
agenda
for
an
ietf
movie,
so
just
a
recap
as
to
where
we're
at
right
now
the
suit
manifest
spec
has
six
other
examples
in
an
appendix
okay,
but
it's
close
to
being
done.
Okay,
that
we
don't
want
to
keep
the
suit
manifest
spec.
D
You
know
open
for
much
longer.
The
suit
meeting
is
coming
up.
I
think
tomorrow
right,
but
the
suit
reports
were
pulled
out
into
a
different
spec
and
the
suit
manifest
examples.
It's
useful
to
have
both
the
suit
manifest
examples
and
suit
report
examples.
D
So
here's
some
things
that
we
would
want
in
potential
examples.
Maybe
two
of
each
one
is
to
install
a
ta
that
needs
personalization
data
from
another
cam.
So
we
can
show
a
dependency.
It
would
put
two
with
two
tams
related
and
the
report,
an
example
might
be
partial.
Success
say
where
one
of
those
succeeded.
Another
one
failed.
D
Another
example
would
be
a
manifest
that
removes
or
unlinks
to
to
brennan's
point
removing
a
ta
and
its
dependency,
and
the
report
might
show
full
success
and
so
my
proposal
is
we
take
those
two
examples
with
those
two
success
and
failure,
cases
and
add
them
into
the
teak
protocol
spec
and
we
leave
them
out
of
suit
and
we
just
ask
suit
to
review
them.
D
So
that's
my
proposal,
any
objection
to
that
and
I'm
specifically
looking
at
people
like
brendan
and
hannes
and
russ,
and
if
I
hear
no
objections
we'll
do
that
in
the
next
version.
So
all
right
not
seeing
anybody
jumping
in
a
queue.
D
So
let's
go
ahead
and
move
on
yeah.
It
makes
sense
to
me.
Thank
you,
honest
all
right
now
we're
getting
into
a
section
for
a
couple
of
related
issues.
It's
about
use
of
tokens
in
teep.
There
are
interrelated
issues
around
freshness
and
state
matching
and
so
on.
So
we
talked
about
this
last
iatf
a
lot
in
the
side
meeting,
not
in
the
consensus-based
meeting.
So
this
is
my
report
back
out.
That
summarizes
some
of
the
side
meeting
discussion,
issues
in
the
spec
and
issues
and
implementation
all
rolled
into
one
section
here.
D
So
all
right
and
thank
you,
sir,
and
I
see
a
plus
one-
all
right
next
slide.
So
let's
get
into
this
couple
related
issues.
So
first,
let's
recap:
rats
relationship,
okay,
so
we
understand
the
context
of
some
of
these.
So
this
is
a
slide
that
we've
seen
before
in
both
keep
and
rats,
and
so
the
relationship
between
keeping
rats
is
that
the
t
agent
is
in
a
tester.
D
The
tam
is
a
relying
party
and
you
might
have
a
verifier
that
the
tam
uses
on
the
back
end,
and
so
the
evidence
appears
in
a
query
response
message
and
then
any
remediation
steps
appear
in
the
shoot
manifest,
which
is
in
an
update
message.
Okay,
so
everybody's
got
the
context
here,
let's
go
ahead
and
so
we're
talking
about
the
t
message
here,
which
is
that
the
horizontal
line
in
the
next
couple
slots
we're
talking
about
evidence
here
and
remediation
sets
in
update
message
all
right.
So
next
slide.
D
Okay,
so
in
rats
architecture,
rats
cares
about
freshness
and
replay
protection,
so
freshness
means
how
recent
were
the
values
generated.
How
recent
is
that
message
generated
replay
protection
is
to
replay
an
older
one,
even
if
it's
within
a
very
close
period,
okay
and
so
the
verifier
versus
the
tam.
The
tam
is
the
relying
parties,
the
verifier,
that
the
thing
that
might
be
separated
from
the
tam
used
on
the
back
end
cares
about
two
things
it
cares
about.
Was
the
evidence
recently
signed
by
the
attester
right?
D
That's
the
cheap
agent
was
the
evidence
recently
signed
by
the
tam
by
the
teep
agent,
not
an
older
replay
of
evidence
from
before
something
changed
like
before.
It
got
the
last
update
message,
even
if
it
was
only
five
seconds
ago,
it
might
have
been
before
the
last
update
message,
and
so
is
the
evidence
recently
signed.
The
second
one
is
the
claims
in
the
evidence,
have
some
values
in
them?
Are
the
values
in
the
claims
and
the
evidence?
D
D
The
relying
party
which
is
the
tam
the
tam
cares
about
was
the
attestation
result
recently
signed
by
the
verifier,
not
an
overreplay
right,
that's
outside
the
scope
of
the
team
protocol
itself.
Right
because
that's
that
vertical
line
and
are
any
values
of
claims,
recent,
not
obsolete
values
and
recent
results.
Now
some
of
the
claim
values
in
the
attestation
result
might
have
come
copied
or
derived
from
values
and
the
evidence,
and
so
that
why
it's
indirectly
dependent
on
the
the
what
the
verifier
cares
about,
and
so
how
recent
things
are
is
really
up
to
policy
right.
D
So
the
owner
or
the
configurer
of
the
verifier
and
the
tam
get
to
decide
what
recent
means.
Okay
and,
of
course,
the
details
of
how
it
passes
that
information
protocols
are
how
things
are
recent
right.
What
it
uses
to
make
that
determination
are
up
to
the
protocol.
Well,
there's
three
common
ways
and
we
have
a
protocol
where
rats
doesn't,
and
so
it's
up
to
us
to
decide
which
of
the
three
common
ways
we
want
to
allow.
So
next,
so
I'm
going
to
walk
through
the
three
common
ways
in
the
rats
architecture.
D
So
this
is
rat's
architecture
summary
for
cheap
folks,
because
anybody
designing
a
protocol
needs
to
have
a
way
of
accomplishing
those
and
we
have
a
protocol.
So
we
are
the
customer
here
of
rats,
so
all
right,
so
the
first
mechanism
we
can
use
and
by
the
way,
just
as
a
as
to
jump
to
a
conclusion,
we're
currently
using
method,
two
just
to
be
clear.
I'll,
do
three
methods
method
number,
but
the
question
is
whether
we
want
to
stick
with
that
or
open
it
up
for
a
lot
more
than
one
right.
D
That's
where
I'm
going
with
this
okay,
so
method
number
one
is
time
stamps,
and
so
we
could
allow
evidence
and
attestation
results
right,
not
cheap
messages,
but
evidence
manifestation
results
that
include
time
stamps.
Okay,
if
you
do
that
this
would
be
appropriate
for
cases
where
the
tam
and
the
heat
agent
have
synchronized
clocks
or
at
least
roughly
synchronized
clocks.
D
This
requires
that
the
teep
agent
have
a
trusted
source
of
time.
Okay,
that
source
of
time
might
be
a
trusted
clock
internally
or
on
demand
being
able
to
look
it
up
from
an
external
trusted.
Server
require
some
protocol.
That's
secured
to
be
able
to
acquire
that
time,
synchronization,
so,
it
might
be
say
an
implementation
of
ntp
seconds
out
of
a
tee
for
the
cheap
agent
whatever
it
is.
D
It
also
requires
having
claims
in
the
evidence
about
the
signer's
time.
Sync
mechanism
such
as
what's
your
time
sink
source,
and
is
that
something
the
verifier
is
going
to
claim
is-
is
correct
and
trusted,
but
it
doesn't
require
any
additional
messages
or
stated
attestation
time.
So
in
particular,
it
does
not
require
asking
the
ten
having
the
agent
asked
to
tam
for
a
nonce
or
a
challenge
for
the
for
the
attestation
for
the
evidence
right.
D
So
you
can
get
rid
of
an
extra
round
trip
here,
which
is
why
a
lot
of
things
you're
interested
in
doing
timestamp
stuff,
but
it's
only
applicable
to
cases
that
you
have
something
like
a
secure
clock
on
the
on
the
agent.
So
it's
not
for
everybody,
but
it
can
be
a
lot
more
efficient
for
cases.
We
already
have
this
for
some
reason.
So
that's
method,
number
one
is
time
stamps
so
next
slide.
D
Method.
Number
two
is
the
one
that
we're
using
now,
which
is
nonces,
are
the
ones
that
we
already
allow
right
now,
which
is
the
receiver
which
in
this
case
the
receiver
of
the
t
message
would
be
the
tam
right
requires
the
sender
being.
The
agent
has
to
include
announce
and
assigned
evidence,
and
so
the
agent
doesn't
have
to
have
any
time
sync.
He
doesn't
have
to
have
a
secure
clock
in
the
tee,
but
it
does
means
that
tam
has
to
keep
state
whenever
it
generates
a
nonce
or
a
token
right.
D
It
has
to
remember
that
state,
and
so,
if
you
have
a
very
large
number
of
ten
of
agents
per
tam,
it
can
become
a
scalability
issue
that
says
how
many
agents
can
you
support
simultaneously
doing
messages
messaging
changes
with,
because
you
have
to
keep
not
state
for
every
single
one
of
them,
at
least
in
the
classic
implementation
analysis?
Okay
and
the
tam
also
needs
a
clock
to
know
when
to
expire.
The
nonces,
although
for
most
times
that's,
not
really
a
big
deal
and
it
doesn't
have
to
be
synced
with
anybody.
D
It's
just
a
local
clock
right.
Tell
me
how
much
time
since
luke,
that's
fine,
so
that
part
for
teep
is
not
a
big
deal
and
then,
finally,
this
one
only
addresses
freshness
of
the
evidence,
so
how?
How
recently
was
it
signed?
It
was
signed
since
I
sent
you
the
nonce.
This
one
does
not
address
in
any
way
knowing
whether
the
values
in
the
claims
are
recent.
With
a
time
stamps,
you
could
include
a
time
stamp
inside
the
claim
itself.
D
You
can't
do
that
with
nonsense,
not
without
introducing
a
hybrid
which
uses
nonsense
and
time
stamps
together.
So
nonsense
alone
only
saw
freshness
of
the
evidence.
It
did
not
solve
the
ability
to
know
whether
the
claim
value
itself
was
there.
The
rats
architecture
does
talk
about
ways
to
deal
with
that.
In
the
non's
case
example,
you
could
include
how
much
if
you
have
a
non-synchronized
clock
that
is
secure
in
the
teat
agent.
D
You
could
include
time
delta
inside
the
evidence
and
that
can
be
used
in
a
secure
way
and
you
don't
have
to
compare
it
with
any
time
stamp,
but
just
time
sense,
and
if
you
can
trust
that,
but
that
requires
at
least
a
clock,
not
necessarily
a
synchronized
clock,
and
so
that
might
not
be
applicable.
So
this
is
a
is
a
partial
solution
with
balances.
This
is
what
we
do
now
next
slide.
The
third.
D
Method,
yeah
right,
that's
to
michael,
that's
exactly
what
I'm
getting
to
is,
yes,
so
hold
it
I'll
get
there
all
right.
The
third
method
is
epic,
handles,
potentially
we'll
call
these
epic
ids.
This
is
a
discussion
in
rats,
epic
psks.
These
are
unpredictable
values
that
the
agent
and
the
teep
both
get
periodically
from
potentially
a
third
party,
it's
unpredictable,
so
you
can't
so
that's
how
you
know
it's
recent,
because
you
couldn't
predict
it
in
advance.
D
They
both
get
it
from
a
trusted
source
and
it's
just
an
id
that
lasts
during
that
epic,
and
so
you
can
include
this
in
lieu
of
a
nonce,
and
so
you
can
do
comparison
that
says:
does
it
match
the
same?
One
that
I
have
so
this
is
much
more
scalable
than
a
nonce
in
the
sense
of
the
tam.
Only
has
you
know
say
two
of
these.
The
current
one
plus
the
previous
one
and
all
of
the
agents
are
using
the
same
value
during
the
same
period.
So
let's
say
your
epic
lasts.
D
D
Of
course
you
get
a
lot
less
resolution
in
how
recent
things
are,
because
you
can
only
say
if
something
is
recent
based
on
the
entire
epic,
and
so,
if
your
epic
id,
if
your
epic
period
was
say
24
hours,
then
you
can
only
make
a
determination
that
the
thing
was
sent
sometime
in
the
last
24
hours
right
so
yeah
you're
up
to
the
frequency
of
whatever
the
epic
id
distributor
is,
and
so
that's
the
only
disadvantage
here.
D
Is
you
lose
some
granularity,
but
what
you
gain
is
you
gain
the
a
lot
less
state
and
you
still
don't
have
an
extra
round
trip
to
require
the
knots,
and
so
the
point
of
these
is
that
all
three
of
these
are
that
no
single
one
of
these
is
strictly
better
than
the
others
right.
D
There's
always
some
metric,
in
which
one
of
the
other
methods
is
better
right,
and
so
what
that
means
is
that
if
we
make
a
choice,
we
have
to
choose
to
either
pick
one,
which
is
what
we
do
right
now
right
now
we
pick
method
two
or
we
have
to
say
we're
going
to
potentially
allow
more
than
one
choice
in
different
implementations
so
like
what
we
did
for
crypto
suites
right,
we
said
you
can
have
two
of
them
that
are
mandatory
to
implement
on
the
tam
and
the
agent
gets
to
pick
okay,
and
so
that's
really
the
question.
D
Is
no
okay,
I
stay
on
the
previous
one,
because
I
guess
that
this
is
a
different
issue.
So
let
me
just
ask
this:
how
okay
you
go
back
to
slide
16.,
so
the
question
is:
do
we
continue
to
stick
with
a
nonce,
only
approach,
okay,
which
does
have
the
extra
round
trip
and
makes
the
tam
have
to
require
a
bunch
of
state
and
have
scalability
potential
issues
in
some
use
cases,
or
do
we
want
to
be
more
flexible
and
say
that
our
protocol
is
capable
of
using
multiple
of
these?
D
In
which
case
we
might
make
a
decision
like
we
did
for
cypher
suites.
It
says
one
or
more
of
these
are
mandatory
on
the
tam
and
and-
and
you
know
the
agent
can
pick-
or
vice
versa
or
whatever
so
again
in
the
hackathons
we've
started
to
run
into
gosh.
D
It
sure
would
be
nice
if
the
tam
was
a
lot
less
stateful
than
it
is
now
and
you'll
see
that
in
comments
from
ming
and
me
and
folks,
where
the
nonce
approach,
by
the
way,
when
we
say
nons
and
t
but
also
applies
to
tokens
right.
So
that's
that's
the
issue
here
and
whether
it's
non,
if
attestation
is
used
or
token
of
attestation,
is
not
used
same
thing
all
right.
So
I
guess
my
personal
preference
as
an
implementer
is.
D
I
would
love
to
use,
maybe
method
number
three
as
allowed
and
of
course,
you'd
have
to
have
some
way
of
doing
capability.
Negotiation
like
you
do
for
cypher
suites,
to
say
how
you
make
sure
that
you're
picking
the
same
approach
but
gosh,
something
like
method
number
three
would
be
would
still
allow
use
with
constrained,
keep
agents
that
might
not
have
secure
clocks
but
still
allow
scalability.
D
And
so,
if
you
said,
if
you
were
to
allow
both
two
and
three
for
example,
then
the
tam
can
use
epic
handles
for
everybody.
That's
you
know
it
for
cases
that
you
don't
care
about
strict.
D
You
know
recency
requirements
more
more
strict
than
the
handle
distributor
uses
and
be
able
to
fall
back
to
nonsense,
or
something
like
that.
So
I
guess
I'm
I'm
wondering
if
we
want
to
open
things
up
more
than
we
are
right
now
to
make
implementations
better.
So
that's
my
question.
D
I
hope
I
hope
I
just
answered
your
question
michael
about
where
I
was
going
with
this
is
to
should
we
change
the
peak
protocol
to
support
a
method
other
than
two,
even
if
we
retain
also
keeping
method
number
two
is
allowed,
so
I'm
especially
interested
in
hearing
from
other
implementers
as
to
what
they
think,
because
you
know
in
the
in
the
cipher
suite
analogy
right.
We
tried
to
keep
the
agent
simple
and
putting
the
complexity
on
the
tam
side.
D
By
saying
the
agent
gets
to
pick
whichever
one
is
the
best
for
it,
and
the
tam
had
to
do
with
the
complexity
of
dealing
with
multiple
choices
so
and
thomas
said
it
could
make
it
a
verifier
problem
we're
up
in
tams.
So
let
me
respond
to
thomas.
If
we
go
back
to
that,
first
diagram:
the
terror
about
the
that
had
the
the
relationship
between
the
the
picture.
D
It
actually
applies
to
to
both
make
it
a
verifier
problem
rather
than
the
tams
for
the
evidence.
You
are
right,
thomas
for
the
attestation
results.
The
tan
still
has
scalability
issues
there
on
the
attestation
results.
So
you're
right,
you
could
do
something
like
make
it
the
verifiers
issue
for
scaling
the
tester
for
skilling
the
evidence
and
use
a
different
approach
in
the
attestation
results.
You
could
do
something
like
that,
but
there's
also.
D
The
same
server
or
even
the
same
influencer
implementation,
and
so
it
doesn't
really
solve
the
problem.
Thomas
of
scalability
issues
right
where
handles
and
timestamps
both
solve
scalability
issues
at
the
expense
of
of
you
know,
requiring
either
synchronized
clocks
or
less
granularity
isobusan
asks
and
can
work
as
a
handle,
distributor,
absolutely
and
again,
where
I'm
going
to
try
to
stop
using
the
word
handle
because
the
t
the
rat's
working
group
said
we're
not
gonna
use
the
word
handle
they're,
gonna,
rename
it
so
I'm
gonna
use
epic
id.
D
I
don't
know
what
the
rats
is
gonna
use,
but
that
was
one
of
like
four
terms
that
were
thrown
out
there
and
since
here
I
say
epic
handles
I'll
call
it
epic
id
just
for
people,
understand
yeah,
probably
epic
identifier,
thanks
michael
so
contam
work
is
a
handle
id
distributor.
Absolutely
so
all
of
their
roles
in
the
rats
architecture
could
be
combined
with
other
roles.
They're
they're,
conceptually
separate
the
handle,
the
the
epic
id
distributor
could
be
the
same
as
the
tam.
It
could
be
the
same
as
the
verifier.
D
It
could
be
a
separate
entity
just
like
your
time,
sync
source
right.
You're,
if
you're
using
ntp
sec,
your
ntp
server
could
be
the
same
as
your
tam
or
could
be
the
same
as
your
verifier.
You
know
combined
in
theories,
but
it
says
conceptually
separate
implementation,
even
if
it's,
even
if
it's
combined
into
the
same
server
your
service.
D
Okay,
any
comments
preferences
here,
because
this
one
affects
a
lot
of
other
stuff
as
to
whether
we
allow
more
than
just
nonsense
and
again
when
we
say
nonsense,
not
slash
token
in
the
teeps,
but
in
the
spec
a
token
is
a
nonce
not
just
for
just
for
the
non-attestation
case,
but
all
the
same
constraints
of
life,
and
these
three
approaches
could
be
used
without
attestations.
Three
approaches
here
could
be
used
if,
in
lieu
of
tokens,
we
could
use
epic
ids
in
lieu
of
tokens
in
in
the
team
messages
in
theory.
D
So
so
not
seeing
anybody
jump
into
queue.
It
sounds
like
nobody
has
a
strong
opinion
at
this
point,
so
yeah
the
dance
was
added
in
the
tea
protocol
to
support
the
riots
case
right.
D
I
have
an
opinion
because
I
would
love
to
get
to
a
point
to
not
have
to
do
tokens
in
the
first
place
for
the
main
use
cases
that
I
care
about
so
khano
says
I
think
we
should
use
whatever
rats
does
well.
Rats
is
not
going
to
make
this
choice
and
the
reason
for
that
is
rats
is
not
charted
through
a
protocol,
and
this
is
a
protocol
choice.
The
reps
architecture
has
to
support
multiple
protocols.
D
D
So
they're
not
going
to
solve
this
sephora
they're
not
going
to
answer
this
for
us
all
right,
so
daniel
asks,
which
is
the
one
that
I
prefer
right
now
from
talking
to
the
people
at
so
I'm
now
going
to
put
on
a
microsoft
hat,
not
as
a
document
editor
hat
because
you're
asking
about
which
one
I
prefer
as
a
documentary.
I
prefer
that
one
of
the
implementations
prefer
and
if
different
implementations
prefer
different
ones,
then
I
prefer
supporting
multiple
of
them.
Okay.
D
Now,
if
you
ask
me
as
an
implementer
or
somebody
representing
an
implementer
which
one
I
prefer,
I
think
when
I
chatted
with
people
that
own
various
microsoft
services
they
kind
of
like
the
id
since
they
had
not
implemented
the
rat
stuff.
Yet
the
feedback
was
the
method.
Number
three
is
actually
quite
attractive.
D
They
said
for
cases
related
to
teep,
and
the
reason
for
that
is,
it
does
not
have
any
strict
requirements
on
having
secure
clocks
and
it
has
the
least
state
requirement,
given
the
lack
of
a
secure
clock
requirements.
So
number
one
requires
a
secure
clock.
Number
two
require
has
a
state
requirement.
This
one
has
neither
and
so
method
number
three,
the
epic
ids
they
said
was
the
most
attractive,
given
that
they
have
not
implemented
it
yet,
and
so
that's
not
a
decision
that
was
a
that
one
looks
pretty
cool.
D
We
might
consider
doing
that
one.
So
I
see
seren
says
the
same
thing.
I
prefer
the
epic,
so
so
I'd
say
between
two
epics
sorry
between
two
implementers
that,
like
the
epic
handle
approach
that
that
might
be
a
consensus
to
at
least
allow
epic
ids,
whether
we
switch
to
that
only
I
guess
is
a
different
question,
but
at
least
to
allow
it
okay,
all
right.
D
So
I
guess
we
can
continue
discussion
on
the
list,
but
this
one
does
affect
a
lot
of
other
stuff,
and
so
I
see
we
got
like
nine
minutes
left,
but
I
think
if
we
could
get
a
direction
on
this
one,
this
would
make
a
lot
of
other
stuff
be
more
straightforward,
because
otherwise
leaving
this
one
open,
it
will
leave
a
bunch
of
other
open
issues
open.
D
D
Yes,
correct
that
brennan
is
correct,
so
the
I'm
just
going
to
echo
that
at
the
mic
here,
one
of
the
issues,
so
the
epic
ids
is
not
necessarily
better
than
the
other
ones
in
all
metrics
one
was
how
how
much
granularity
you
get
in
terms
of
recency,
because
you
know
your
policy
is
limited
by
how
frequently
the
epic
ids
are
distributed,
but
the
other
one
is
called
out
in
the
rats
architecture
document
right
now
that
brennan
does
point
out
here,
which
is
there's
an
attack
that
if
you
can
cause
the
epic
ids
to
be
delayed
in
the
network.
D
Okay,
so
in
other
words,
if
I
can
somehow
say
dos
the
epic
id
distributor
such
that
the
epic
ids
get
distributed
to
the
agent
and
the
tam
that
you
that
they
can't
be
the
new
ones
can't
be
distributed
for
24
hours.
D
Then
both
the
tam
and
the
agent
continue
to
use
the
one
that's
24
hours
old,
and
so
I
can
increase
that
replay
window
for
the
for
as
much
as
I
can
delay,
okay,
and
so
that's
the
delay
attack
that
it's
susceptible
to,
and
so,
but
that
requires
me
basically
delaying
it.
On
both
sides,
because
otherwise
you
can
detect
the
attack
and
and
mitigate
it,
but
as
long
as
you
can
delay
it
say
by
dosing
at
the
epic
id
distributor,
then
you
can
open
that
window
to
the
attackers
you
know
wins.
D
So
so
that's
the
downside
here.
That's
why
saying?
Well,
let's
just
switch
and
only
support
epic
ids,
some
use
cases
might
say.
I
don't
want
that
and
if
we
want
teep
to
be
used
in
all
use
cases,
then
maybe
one
might
consider
supporting
you
know
two
or
even
all
three
of
these
methods
in
t,
but
that's
more
protocol
complexity.
D
So
that's
the
trade-off,
yeah,
so
right
so
method,
number
three
is
not
the
best
one
from
a
security
perspective,
because
you
lose
some
security
protections
and
granularity
that
you're
getting
out
of
the
other
two
but
you're
again,
it's
all
trade-offs
right,
there's,
no
single
one
size
fits
all
and
that's
why
this
one's
a
tough
choice.
So
that's
why?
If
it's
me
as
a
spec
writer,
I
might
be
inclined
to
I'll.
Have
the
spec
support
multiple
methods
for
different
use
cases,
and
let
one
side
pick
one
so
that
you
can
keep
supporting
constrained
nodes.
A
J
D
All
right
so
we'll
keep
this
one
open,
but
you'll
see
that
one
will
affect
the
next
couple
of
issues
too,
and
so,
let's
see
what
else
we
can
at
least
get
out
there
to
be
part
of
that
same
discussion,
so
go
on
the
next
slide.
D
D
There,
when
the
attestation
bit
is
set,
so
the
query
request
comes
in
there's
an
attestation
bit
that
says:
hey.
Can
you
please
include
evidence
in
the
in
the
query
response?
Okay,
there's
also
a
challenge
field.
This
is
optional.
That's
in
the
query
request,
okay,
and
so,
since
it's
listed
as
optional,
you
can
see
the
text
says
when
a
challenge
is
provided
and
the
challenge
the
challenge
and
the
request
must
be
copied
into
the
nonce
claim
found
in
the
eat.
Okay,
so
that
leaves
open.
D
So
is
it
legal
or
illegal
to
send
a
query
request
which
has
attestation
bit
on
and
the
challenge
field?
Absent?
Okay?
Is
that
legal
or
illegal?
That's
the
open
question
here,
and
so
the
first
question
well
does
teep
require
the
nonce
approach
or
is
any
of
those
approaches?
Okay.
Well,
that
was
the
question.
This
issue
that
I
think
akira
filed
and
this
one
any
is
okay.
The
intent
of
the
text
in
the
document
right
now
is
that
the
attestation
bit
was
allowed
to
be
set
with
the
challenge
absent.
D
Okay,
that
was
the
intent,
we're
writing
that
text.
Okay,
now,
whether
that's
the
right
thing
or
not,
that
was
the
intent.
So
but
then
the
question
is:
how
do
you,
how
do
you
negotiate,
which
freshness
approach
to
use
I'm
getting
the
blinking
back
again
now?
So
all
right,
so
the
evidence
already
carries
the
approach
specific
claims.
So
if
you
use
nonsense
or
time
stamps
or
maybe.
D
You
can
tell
that
by
looking
in
the
evidence,
but
you
can't
tell
what's
what's
what's
supported
in
the
message,
and
so
what
we
were
just
talking
about
it
should
be
forced.
This
is
the
relationship
of
the
previous
issue
right.
Should
we
force
the
use
of
a
single
approach?
Should
we
force
the
agent
to
support
all?
No,
probably
not,
should
we
add
a
field
into
the
query
request
like
we
did
for
supported,
cipher
suites
right.
D
This
is
if
we
support
multiple
of
them,
that's
bolded,
because
that's
the
one,
that's
my
personal
preference
or
we
can
overload
the
challenge
field
and
make
the
challenge
field
mandatory
by
putting
the
stuff
in
there
and
then
the
challenge
field
would
become
mandatory,
but
I
don't
like
overloading
fields.
That's
why
I
don't
like
that
one.
So
so,
if
we
support
multiple
ways
of
doing
it,
then
my
preference
is
that
the
challenge
field
would
be
optional.
D
For
example,
if
you
have
the
timestamp
approach
or
the
epic
id
approach,
then
you
would
not
necessarily
need
the
challenge
present,
and
that
would
be
a
case
where
attestation
be
set
and
challenge
absent.
Okay,
and
so
this
one's
very
closely.
The
previous
one,
that
if
we
go
with
one
of
those,
then
I
think
that
the
clarification
is
likely
to
be
challenge.
It
can
be
absent,
and
that
was
the
original
intent,
even
though
we
required
nonsense
before
so
all
right
carry
on.
D
J
D
Great
use
of
a
token
versus
a
challenge,
and
so
this
one
there
was
a
response,
I
think
already
on
the
list
or
maybe
in
the
chat
here,
and
so
you
can
see.
We
have
a
token
field
and
we
have
a
challenge
field
now,
at
the
time
that
this
was
written,
the
the
token
and
the
challenge
are
both
exactly
the
same
syntax.
D
I
think
that
has
now
been
fixed,
because
I
think
the
challenge
has
now
increased
to
512
bytes
in
order
to
work
with
that
sgx
thing
that
akira
mentioned
in
the
hackathon
report,
some
point
both
both
of
them
are
beasters,
and
so
the
intent
was
the
token
is
present.
If
and
only
if,
the
attestation,
that
is
clear
and
the
challenge
is
allowed,
but
not
required
at
the
attachment
to
set.
D
So
you
could
never
have
token
and
challenge
be
present
at
the
same
time
so
given
they
could
not
be
present
at
the
same
time,
they
currently
have
separate
label
values,
and
should
we
combine
them
into
one
label,
and
I
think
there
was
a
response
from
someone
in
the
list.
I
don't
remember
who
maybe
ben,
who
said
better
to
keep
them
as
separate
because
they're
semantically
different,
and
so
I
think
that
is
the
proposed
resolution
to
127,
which
is
to
just
clarify
just
leave
them
as
separate
things
and
make
sure
that
it
is
clarified.
D
So
unless
anybody
has
objections
to
that,
we'll
leave
them
as
separate
things,
even
even
if
they
have
the
same
syntax,
which
they
currently
don't.
So
that
one
should
be
easy.
I
guess
we
can
go
to
the
next
slide.
Maybe
we
can
get
one
more
in
two
minutes.
So
all
right
last
one
is
related
to
that
question
about
you,
know,
epic
ids,
and
what
the
challenge
is
required.
D
So
this
one
has
been
open
forever
and
I'm
coming
back
to
it
now,
because
we're
now
getting
to
the
tailing
of
things,
and
so
I
want
to
kick
this
into
that
same
discussion.
We
take
the
list
so
I'll,
just
tee
it
off
right
now
and
ask
people
to
comment
in
their
in
the
list.
Discussion
of
the
other
one
of
the
epic
id
related
one
unsolicited
query
response:
okay!
Well,
if
you're
using
attestation
with
time
stamps
or
epic
ids,
then
you
don't
need
any
per
request.
D
Token
or
nots
right,
you're,
actually
not
you're,
not
saying
you're,
not
keeping
any
state,
because
that
was
the
point
of
keeping
making
sure
there's
no
state
in
the
town.
In
order
to
generate
the
stuff,
you
don't
need
to
get
a
challenge.
D
There's
actually
no
reason
to
get
an
extra
round
trip,
because
there's
no
state
to
match
right,
you're
trying
to
not
have
state
right,
and
so
the
proposed
optimization,
is
that
if
a
query
request
contains
no
token
or
challenge,
then
the
agent
may
cash.
The
information
that
career
request
and
send
any
unsolicited
query
responses
in
the
future
to
that
same
tam
uri,
whenever
it's
handling
a
request,
ca
or
unrequest
ta
api
call
from
the
broker,
but
anytime,
you
know
periodically.
D
D
So
if
we
go
that
approach,
that
is
my
proposal
here
and
we're
out
of
time
now.
So,
if
you
object
to
that,
you
have
to
take
it
to
the
list,
but
that
I
would
like
comments
on
the
list
is
that
proposed,
optimization,
which
I
think
works
fine
and
gives
the
best
behavior.
So
there
you
go.
That's
what
I
would
like
to
do
in
an
implementation.
A
Yep
yep,
so
I
think
we're
we're
out
of
time
dave.
You
only
had
one
left,
so
my
suggestion,
since
we
are
out
of
time,
is
to
put
these
last
two,
the
previous
one
and
this
one
on
the
list
yeah,
and
we
should
be
able
to
close
them
down
sure
all
right,
all
right,
good
progress.
Thank
you.
Everyone
and
we'll
continue
the
discussion,
especially
on
on
the
different
methods
for
keeping
freshness
on
the
list
as
well.