►
From YouTube: IETF104-TEEP-20190326-0900
Description
TEEP meeting session at IETF104
2019/03/26 0900
https://datatracker.ietf.org/meeting/104/proceedings/
D
B
B
Procedural
note:
well
I'm
not
going
to
read
it
to
you.
Hopefully
it's
Tuesday
morning,
you
should
know
this.
By
now.
We
follow
the
IETF
policies
and
procedures.
I
want
to
get
to
to
the
meat
of
the
discussion
here.
So
let's
go
through
the
agenda
and
we're
just
going
to
go
through
the
logistics
with
the
chairs.
We're
going
to
have
David
wheeler
come
up
and
give
us
an
update
on
the
architecture.
B
For
those
of
you
who
are
new
here,
we've
been
tracking
work
in
the
drafts
through
github,
so
we've
posted
the
link
for
where
the
issues
are,
but
David
and
named
will
be
going
through
those.
After
that,
we
had
a
way.
It
should
really
be.
David
Thaler
had
a
successful
hackathon
so
with
a
couple
of
other
participants,
Hannes
being
one
of
them
and
a
couple
of
folks
from
Japan,
so
he'll
be
providing
a
report
after
that,
we're
not
going
to
do
since
there.
We
have
not
revved
the
OT
RPE
draft
I.
B
B
B
B
B
E
B
A
B
G
G
So
we're
gonna
go
through
the
document,
changes
that
we
made
we're
gonna,
follow
it
through
the
github
issues.
So
hopefully
that
will
allow
you
to
more
easily
kind
of
go
back
and
see
some
of
the
things
that
we've
done
and
then
there
are
several
issues
that
are
still
open
or
between
the
author's
in
discussion
and
so
we're
bringing
in
some
detailed
discussion
here
and-
and
hopefully
you
can
help
us
resolve
some
of
those.
G
Those
issues
maybe
see
things
from
from
a
slightly
different
perspective,
so
we'll
go
through
several
of
the
issues
in
much
more
detail
than
others
for
for
ones
that
are
shorter,
we
think
maybe
resolve
those
and-
and
the
text
is,
is
in
the
the
draft,
if
you
think,
there's
still
a
problem.
We'd
love
for
you
to
just
open
an
issue
on
github
and
and
we'll
that's
the
way
that
we're
tracking
it
and
that's
the
way
that
we're
resolving
it.
G
So
any
questions
or
things
that
you
have
even
on
issues
that
we've
closed
we'd
still
invite
you
to
to
open
up
a
new
issue
and
say:
hey
I,
don't
don't
think
this
is
quite
right
or
or
there's
something
else
that
needs
to
be
addressed.
Okay
next
issue,
so
so
here's
the
the
status
I'm
not
going
to
go
through
a
lot
of
these
in
detail.
These
are
the
things
that
we've
closed
on
github
and
and
they're.
G
Basically
around
some
terminology,
discussions
around
device,
user
device,
owner
distribution
of
the
TAS,
multiple
te
es,
some
some
diagrams,
multiple
Tam's
and
and
some
information
about
the
attestation.
We
haven't
closed
the
attestation.
Yet
we
still
think
that
there's
more
work
to
do
we'll
talk
about
that
in
detail,
so
the
the
items
that
are
still
open
we've
got
four
items
that
we
think
are
ready
to
close
we're
going
to
talk
about
those
today.
Hopefully
we
can
get
agreement
that
three
eight
thirteen
and
fourteen
we
can
close
the
others
we
think
are
still
open.
G
Some
of
them
are
issues
that
we
got
to
talk
through
the
security
domains
is
one
that's
at
the
top
of
the
list.
Will
have
some
detailed
discussion
this
morning
about
that
others
are
are
more
just
you
know
we
got
to
get
around
to
making
the
changes
in
the
document
like
trust,
anchor,
fingerprint
and
and
some
of
the
key
stuff.
That's
gonna
change
a
little
bit.
We
just
haven't
gotten
around
to
that
yet
so,
but
those
are
the
issues
that
are
open.
G
Okay,
next
slide.
Okay,
so
what
I
want
to
do
is
kind
of
talk
through
these,
the
issues
that
we've
closed
or
are
ready
to
close,
and
this
first
one
is
the
trusted
app
distribution.
We
we've
had
a
lot
of
discussion
about
this
in
in
the
current
spec.
We
didn't
really
talk
enough
about
this
issue
of
well.
How
do
I
get
apps
down
on
to
the
platform?
And
what
does
that
look
like
in
the
document?
You
can
see
that
there's
really
three
parts
to
to
an
application.
G
There's
the
application
itself,
what
we,
what
runs
in
the
rich
OS,
the
rich
execution,
environment,
REE!
That's
that
little
blue
box
and
that's
kind
of
the
app
that
we
normally
think
about
right.
It's
the
app
that
the
user
would
interact
with
the
TA.
Is
the
trusted
app?
That's
the
thing
that
runs
inside
the
te
e,
so
it's
typically
smaller,
usually
than
the
app
itself,
but
it's
running
in
a
different
environment,
and
then
the
Greenpeace
is
the
metadata.
G
That's
personalization
information,
maybe
passwords
keys,
URLs
things,
some
of
those
things
might
be
private
or
very
specific
to
that
device
or
that
user.
So
the
concept
in
the
architecture
draft
is
that
that
might
be
encrypted
and
it
might
be
encrypted
with
a
device
unique
key
so
that
it
becomes
private
and
that
data
should
be
consumed
by
the
TA.
So
there's
there's
technically
you
know
five
different
ways.
We
could
package
these
three
elements
right
if
we
take
all
the
different
combinations.
G
What
we've
shown
here
is
the
three
cases
that
we
think
make
the
most
sense.
So
the
first
is
that
you
package
them
all
together.
So
that
means
that
the
Tam
that's
delivering.
This
would
have
to
have
the
ability
to
encrypt
the
metadata
with
the
device
unique
key
package
that
all
together
in
one
package
and
send
it
down
to
the
device
case
to
is
the
app
and
the
TA
are
bundled
together
and
the
metadata
comes
maybe
at
a
separate
time
or
in
a
separate
message.
The
third
cases,
all
three
of
them
are
different.
G
Now
the
other
two
cases
would
be
where
the
app
and
the
metadata
are
bundled
or
the
TA
and
the
metadata
are
bundled
now,
there's
a
couple
reasons
why
we
don't
think
those
are
as
useful
so
and
part
of
this
has
to
do
with
the
way
that
we
believe
the
applications
and
the
TAS
are
going
to
be
built
right.
Typically,
you
have
an
application
and
it's
for
wide
distribution.
It's
not
bloat
for
a
specific
device
and
the
same
with
the
TA.
So
but
the
metadata
is
device
specific.
It
may
have
some
common
elements.
G
Some
common
configuration
elements,
however,
there's
going
to
be
device,
specific
information
in
that,
and
it's
going
to
be
encrypted
with
the
device
specific
key.
So
we
don't
believe
we
believe,
that's
really
a
separate
step
that
the
team
has
to
make.
So
it
wouldn't
really
make
sense
to
bundle
the
app
and
the
metadata
and
then
leave
the
TA
out,
because
it's
also
a
a
wide
distribution.
If
you're
going
to
bundle
the
metadata
and
the
app
together,
you
might
as
well
throw
the
TA
in
there
as
well.
G
So
then
you're
back
at
case
one
but
the
TA
and
the
metadata.
You
can
make
some
arguments
that
maybe
that
makes
sense,
but
again,
if
you're
bundling
a
broad-based
application,
together
with
the
metadata
just
throw
the
the
client
app
in
there
and
and
you're
back
at
case
one
again,
so
we
think
these
three
cases
are
the
ones
that
make
the
most
sense.
If
you,
if
you
disagree,
you
know
love
to
have
a
comment
now,
if
you
think
about
it
later,
and
you
think
that
there's
some
reason
why
we
would
include
other
packaging.
G
Please
put
a
comment
on
the
github.
One
of
the
primary
issues
that
we're
working
out-
and
it
has
impacts
to
the
protocol
flow-
is
how
you
get
that
device
specific
key
to
the
TAM
so
that
the
TAM
can
encrypt
the
metadata
or
the
service
provider
can
encrypt
the
metadata,
and
this
has
impacts
how
many
back-and-forth
trips
that
we
have
to
make.
G
What
key
is
it
and
so
forth,
and
we're
going
to
talk
some
more
about
that
as
we
talk
about
some
of
the
flows
and
things
like
that,
but
in
in
the
current
spec
we
have
this
idea
that
there's
going
to
be
an
AI
K
and
that's
tied
to
a
security
domain.
We
have
some
more
discussion
about
the
so
I'll
kind
of
leave
that
here
we'll
get
back
to
it
later.
G
One
of
the
other
things
that
were
open
was
open
in
the
last
meeting
was
how
do
you
handle
multiple
t,
E's
versus
a
single
te?
Is
it
too
complex
and
so
I
put
this
diagram
together?
It's
it's
in
in
the
document,
so
you
can
see
that
there's
two
teeth
brokers
and
they're
each
talking
to
their
own
te
e.
So
in
the
case
where
you
have
multiple
T
E's,
a
teat
broker
will
be
sort
of
that
agent
on
the
rich
side.
That
will
manage
the
interactions
with
that
te
e
and
that's
platform-specific
right.
G
So
in
essence,
you
could
have
a
an
OS
that
combines
those
two
teat
brokers
into
one
and
and
talks
to
both
of
them.
But
the
idea
is
that
the
local
app
is
gonna
know
what
teat
broker
it
needs
to
talk
to
to
get
to
the
te
of
interest.
This
is
no
different
than
finding
the
right
USB
driver,
or
you
know
some
other
device
on
the
platform
and
the
OS
will
provide
mechanisms
to
the
obvious
Capo's
and
provide
the
right
pointer.
In
the
simplest
case,
you
have
a
one
te
and
one
take
broker.
G
G
How
does
this
work
with
with
the
TAM
the
the
client
app
has,
has
an
application.
It
might
have
multiple
TAS
that
it
wants
to
install.
Does
it
have
to
go
to
different
tabs
to
get
those
TAS
and
that
sort
of
makes
sense
at
one
level?
But
you
know,
let's
kind
of
take
a
step
back.
We
added
some
text
in
in
the
architecture
document
to
kind
of
explain
this
right,
so
the
TAM
is
really
a
an
access
point
for
service
providers
into
devices.
G
So
when
the
service
provider
wants
to
put
out
an
application
right,
they
create
an
app
they
create
their
TA.
They
have
some
way
of
generating
personalization
data.
Now
they
want
to
reach
devices
out
in
the
market.
Different
devices
are
gonna,
be
going
to
support
different
Tam's.
So
if
you're,
you
know
wanting
to
get
large
public
distribution
of
your
app
you're
gonna
push
your
application
NTAs
out
to
multiple
attempts.
Maybe
Verizon
has
a
tan.
Maybe
t-mobile
has
tan,
maybe
there's
an
Apple
Store
Tam
and
a
Samsung
Tam
and
a
Google
Play
Store
to
him
right.
G
So
you'll
push
your
app
and
all
the
TAS
that
your
app
needs
will
get
pushed
to
the
dam.
So
in
a
normal
case,
when
a
client
goes
to
install
that
they
only
need
to
go
to
one
Tam
because
as
the
service
provider,
you
want
your
application
to
get
out
there.
You're
gonna
enable
the
TAS
to
to
install
or
you're
going
to
enable
the
cams
to
install
all
those
TAS.
G
Now
there
may
be
a
case
where,
for
some
licensing
reason
or
something
like
that,
maybe
there's
a
inherent
dependency
where
a
TA
is
only
supplied
by
some
some
specific
Tam
and
it's
not
widely
accessible
to
handle.
That
case,
we
said
you
know
we're
not
going
to
handle
that
in
the
general
protocol
it
can
be
handled
in
a
couple
of
ways.
One
way
is
that
the
teat
broker
could
use
the
manifest
to
identify
what
Tam
to
go
to
that.
That's
how
normally
the
teat
broker
and
the
TPA
Jan
are
gonna
work.
Another
possibility.
G
The
last
bullet
on
the
slide
is
that
you
go
to
one
Tam
and
the
Tim
gets
the
request
for
all
the
TAS
when
it
doesn't
have
one
of
those
TAS.
It
does
its
own
processing
to
go
out
and
grab
that
from
another
ta
and
and
provide
it
down.
So
so
then,
the
teat
broker
is
still
only
going
to
single
to
him
and
that's
the
concept
that
that
we
have
there
any
questions
on
that.
Any
disagreements.
E
Clarifying
question
this
is
TAFE
they
were.
This
is
talking
about
I'm.
Looking
at
the
bolded
point,
I
claim
that
manifest
file
can
contain
all
the
tans
you
may
use
give
the
TAS
normally
just
one
and
you're
talking
about
the
client
app
manifest
file
and
back
on
the
trust
of
that
distribution
slide.
We
had
case
one
case
two
in
case
three.
He
trying
to
figure
out,
where
is
the
client
at
manifest
file?
Is
that
part
of
the
client
app?
In
other
words,
is
this
slide
focusing
on
case
three
only
know
what
that's
that's.
My
clarifying
question.
G
G
So
so
the
concept
is
that
the
client
app
is
going
to
hold
the
manifest
that
was
generated
by
the
service
provider,
who
created
the
the
application
and,
and
that
will
include
other
Tam's,
that
the
service
provider
has
pushed
the
the
app
out
to
so
those
Tam's.
That
list
of
Tam's,
then,
is
what
the
device
looks
at.
It
looks
like
it's
trust
anchor
list
says
what
which
Tam's
do.
I
trust,
and
obviously
there
should
be
some
interaction
there.
There
should
be
some
intersection.
G
D
H
Okay,
thank
you
hi
everybody,
so
I
think
the
this
strawberry
pointer
for
this
one
was
the
how
popular
the
one
cloud
lab
MIT
pen
down
the
multiple
third-party
trust,
apps,
just
apps,
and
it
just
this-
was
a
wonder
decision
point
well
felt
that
it's
a
very,
not
a
common,
that
one
client
app
depends
on
many
third-party
TS.
Most
of
the
time
common
cases
clone
app
from
service
provider
develop
to
tear
themselves
for
that
catch.
H
They
can
you
see
case
one
Ida
ponder
the
case,
one
or
two
or
three,
and
did
the
difficult
part
is
if,
for
the
cases
through
right
as
a
David
Fowler
nation
at
the
Christmas
tree,
where
cloud
apps
that
normally
have
a
store.
And
yes,
if
a
some
apps,
a
gaming,
app
user
authentication
ta
use
a
payment
here
from
different
vendors.
Then,
when
now
we,
when
we
choose,
is
for
this
civil
provider
came
up
from
civil
provider
to
acquire
the
SAP
onerous
from
certified,
TS
and
upload
to
the
time
our
it's
a
choice.
H
Is
it
maybe
one
maybe
much
with
temps,
but
that
more
fulfil
over
says
is
sense
right,
but
that
temp,
because
we
said
to
single
time-
and
it
means
if
he
one
cloud
app-
depends
on
three
TS-
why
its
own
develop
to
our
sorcerer
farmer.
Third
party,
it
pushes
named
still
need
a
supply,
all
three
ta
to
the
time
that
SP
choose
as
I
was
assumed.
This
is
achievable
right.
That's
a
this
choice
met.
This
is
a
contrast
to
the
alternative
approach.
H
You
mentioned
that
a
manifest
file
can
have
three
tiers
there
and
for
ETA
is
indicated
time
it
can
go
to
get
the
in
sport,
so
in
this
case,
tip
whoa
tip
a
broker
well
to
the
orchestration.
It
would
talk
with
respected
time
to
get
that
yeah
in
a
class
site
versus
server-side
that
this
a
primer
time
would
go
to
the
next
time
to
get
it
here.
I
think
that's
a
decision
point
and
which
choose
to
use
the
first
one.
We
assume
the
common
catch.
The
SP
owns
the
TM
was
time.
I
E
Here,
it's
always
trusted
application
all
of
these
slots.
Yet
so,
if
I
understand
the
answer
when
it
says,
because
the
the
relationship
between
the
term
manifest-
and
the
trim
package
in
there
slide
was
kind
of
my
clarifying
question
where
it's
their
relationship
and
as
I
understand
the
answer,
if
you
go
back
to
slides
I'm
going
to
try
to
summarize
what
I
think
I
heard
is
the
answer
to
my
question.
E
I
think
what
I
heard
is
to
says
my
original
question
was:
is
this
talking
about
when
it
goes
and
gets
what
the
client
app
installer
does
and
I
think
the
answer
was
no.
This
is
what
the
bundle
composer
does,
whoever
creates
the
bundle,
and
so
in
case
one
the
tan
was
creating
the
bundle
and
case
one
and
I
think
Ming,
and
you
were
trying
to
ascribe
that
the
way
that
the
tan
creates
the
bundle
is
that
may
go
and
fetch
all
the
TAS
compose
the
bundle
and
then
send
the
bundle
down.
E
Okay,
so
the
fact
that
there's
a
manifest
they
okay.
Now
you
can
go
back
to
the
slide
that
David
was
on
so
when
it
says
that
it
can
contain
or
whatever.
This
is
what
the
team
is
doing
to
construct
the
bundle
and
not
what
the
consumer
of
the
bundle
does
right.
That
was
that's
I,
think
what
you're
saying
is
the
answer
to
my
question.
E
E
J
H
K
Yeah
was
just
one
smaller
issue,
but
we
used
to
don't
manifest
in
two
different
places.
One
is
sort
of
the
manifest
for
in
describing
the
trusted
application
and
and
potentially
where
to
get
it,
and
so
on.
The
other.
Manifest
is
sort
of
more
from
the
app
development
context,
but
we
also
have
a
manifest,
so
that
may
be
a
little
confusing.
E
G
So
the
service
provider
creates
an
application
with
one
or
more
TAS
and
creates
a
manifest
that
says:
here's
all
the
Tam's
that
I
push
my
my
application
out
to
and
here's
all
the
TAS
that
are
needed
with
this.
So
so
it
provides
everything
that
the
team
needs
to
go,
get
and
install
those
pieces,
so
the
service
provider
creates
that
that
gets
pushed
out.
G
Now
we
haven't
really
talked
about
exactly
where
that
manifest
is.
We've
talked
about
that
it's
part
of
the
client
app
and
the
client
app.
If
it
was,
you
know,
pulled
down
from
a
spore
and
then
it
would
interact
with
the
teat
broker
and
say
here's
my
manifest
I
need
you
to
install
the
rest
of
this.
There
there's
this
concept
with
that.
We've
also
talked
about
where
there's
an
installer
and
somehow
that
installer
gets
the
manifest
we
don't.
We
haven't
really
talked
about
that
t0
time.
Where
do
you
get
that
manifest?
L
E
Yeah,
what
that
was.
My
question
is:
if
we
only
talk
about
case
three,
and
your
answer
was
no,
in
fact,
if
you
don't
have
to
fetch
it
at
all,
it's
bundled
in
there.
This
is
something
the
bundle
composer
does
when
putting
it
in
there
and
then
yes,
the
manifest
doesn't
have
to
include
separate
location
to
go
and
fetch
it
from
what's
already
part
of
the
bundle
correct.
K
H
Yeah,
it
has
not
been
well
well,
especially
hard
for
the
manifest
I
think
it
is
now
we
talk
about
installer,
so
how's
that
we're
seeing
what
they're
seeing
installer
I
was
a
requirements.
There
I
think
we
let
a
student
working
on
and
with
having
high
level
have
will
have
a
manifest
file.
That
can
tell
you
see
information,
okay,.
G
Okay,
so
I
think
we're
ready
for
the
next
slide.
That's
okay,
okay!
So
one
of
the
the
open
items
was:
is
there
only
one
ta
in
an
application
or
can
I
get
into
a
situation
where
one
ta
depends
on
another
ta
and
then
how
complex
do
we
allow
this?
How
deep
is
that
dependency
can
I
get
into
circular
dependencies?
What
happens
when
I
have
different
client
applications
that
are
dependent
on
different
versions
of
the
same
ta
at
the
enth
level
of
dependency?
G
I
think
that
there's
a
my
perspective
is
that
I
think
we
should
find
some
way
of
simplifying
the
dependency
so
that
we
can
provide
some
simple
dependencies
or-
or
we
offload
this
in
in
some
other
way.
I,
don't
think
that
I
know
from
the
Intel
SGX
perspective.
If
you
require
only
a
single
ta,
it's
going
to
really
limit
the
capabilities
of
teeth,
to
interact
with
the
sgx
environment.
G
I'll
give
you
an
example.
So
let's
say
I
have
a
an
application
that
wants
to
do
authentication,
so
it
has
a
TA
that
does
authentication
and
that
ta
needs
an
identity
key.
So
then
it
depends
on
another
ta
that
provides
a
key
store,
a
secure,
key
store.
So
now,
I
have
a
direct
dependency
for
my
client
app,
the
authentication
ta
and
the
authentication
ta
depends
on
a
key
store
ta.
So
that's
a
that's
a
simple
dependency
that
happens
quite
a
bit
in
in
some
environments.
So.
L
H
You
ok,
so
I,
don't
know
how
to
turn
on
that.
Video
I
gave
you
to
not
see
me
right
yeah
then
it
had
to
tomorrow,
Rita,
okay,
I'll
just
speak
right,
so
I
think
in
the
mattresses
that
follow
up
to
the
question,
lessening
up
in
the
speak
like
a
microphone
right,
the
simple
case,
a
one
app
can't
depend
on
much
with
TS
and
then
manifest
file
like
with
target
or
later
mind
if
I
look
at
least
all
TS
and
install
them
in
sequence,
but
I
think
that
hears
it
depends
on
more
about
the
order.
H
I'll
show
you
start
here
first
before
ta
to
if
a
kind
of
app
make
it
that
in
right
order
is
simple
case
they
already
recovered
today
and
here
to
talk
about
a
more
the
deep
dependency
TT
way.
One
depend
tier
two
tier
two
different
tier
through
and
saw
that
must
be
inner.
That
order
are
strictly
carried
out
cut
out
otherwise
right.
H
So
if
a
client
happen
knows
that
order,
then
they
can
put
a
magnifier
I
use
that
all
today
it
is
it's
a
kind
of
implicitly
supported,
but
I
think
he
will
talk
about
a
more
complex
case
that
way
I'm
thinking
the
weather.
We
can't
avoid
those
complex
case
where
cloud
app
cannot
know
the
order
is
self
and
it
has
related
he
FA
Garza
when
he
runs.
Oh
I
need
another.
Yet
the
TA
include
that
dependents
itself.
H
E
So
I'm
in
queue
here
this
is
Dave
Taylor
and
here
I'm,
actually
speaking
as
a
suit
working
group
chair
just
to
be
cleared,
neither
as
an
individual
participant
nor
as
a
tea
/
huge
here,
so
I
was
chatting
with
Brendan
Moran
yesterday
as
a
chair
of
the
both
heap
and
suit
working
groups,
right
we'd
like
them
to
be
aligned
and
compatible.
So
I
was
chatting
with
Brendan.
He
Brennan
is
the
author
of
the
suit
manifest
document
and
asked
him
his
opinion
of
this
issue
and
I.
E
Don't
think
Brendan's
in
the
room
right
now
is
that's
why
I
as
chair
I
will
relay
what
feedback
if
he
isn't
the
room?
Please
come
to
the
mic.
Otherwise,
I'll
summarize
what
he
said.
The
suit
working
group
is
defining
a
manifest
format:
that's
capable
of
expressing
dependencies
and
gusting
ordering.if
installs,
and
all
that
kind
of
thing
like
that.
Okay,
now
the
suit
working
group
is
also
scoped
to
focus
on
optimizing
for
firmware
right
and
so
Brendan's
thought
was.
E
He
would
put
into
his
document
to
say
this
focus
is
on
optimizing
for
firmware,
although
this
suit
manifest
format
might
be
usable
in
larger
contexts,
and
if
so,
if
he
does
that,
then
he
said
that
it
would
be
fine
for
t2,
simply
punched,
the
despont
the
work
into
saying
as
long
as
this
suit
manifest
can
deal
with
deal
with
it
and
the
bundle
contains
the
suit
manifest.
Then
you
don't
have
to
solve
it
in
this
particular
working
group,
and
so
that's
basically
the
summary
from
from
Brendan,
okay.
B
L
E
That
the
manifest
format,
the
new
one
right,
is
already
generic
and
could
be
used
for
just
about
anything,
even
though
it
wasn't
designed
for
it.
So
he
said
you
know
in
theory,
you
could
use
it
for
passing.
You
know
videos
and
dependencies
on
codecs
and
stuff,
not
that
anybody
would
ever
want
to
do
that.
But
the
point
is
the
manifest
format
he
believes
is
flexible
enough
to
be
used
for
wider
purposes,
and
he
saw
no
reason
that
it
couldn't
be
used
to
solve
this
T
problem,
even
though
that's
not
what
he
was
focusing
on.
B
E
K
K
G
E
M
L
E
With
that
yeah
Brendan's
opinion
was
that
there
wasn't
anything
that
wasn't
already
addressed.
But
I
agree
with
your
point
that
that
should
come
as
a
suit
working
group
request,
and
then
they
should
look
at
they.
The
authors
should
look
at
it
and
say:
okay.
Yes,
we
believe
these.
Your
currents
are
met,
yeah,
okay,.
B
B
He
never
left
the
queue
so
so
main
feel
free
to
interject,
but
as
the
tea
chair,
I'm
gonna
ask
the
suit
chairs.
That's
why
I'm
looking
at
both
of
you
so
is
there
a
formal?
Do
we
need
to
formalize
it
by
me
having
to
say
to
the
suit
working
group
track
or
github,
especially
number
13,
or
can
you
guys
just
relay
that?
Okay,
what
do.
E
H
It
means
I
agree
that
I
think
we
should
just
first
I
want
to
leverage
what
should
my
tea
face.
You
can't
do
and
also
send
out
requirements
they
whether
to
really
meet
our
need.
It
says,
and
maybe
you
have
contact
you
have
most-
that
will
state
now
and
I
think
we
should
review
and
a
look
at
leverage
fragile,
so.
E
If
there
are
people
in
this
room
that
have
an
opinion
on
what
the
requirements
are,
you
are
welcome
to
come
to
the
suit
working
group
meeting
it's
in
the
morning
slot
tomorrow
and
Brendan's
friend
is
presenting
this
particular
draft,
and
if
you
have
comments
on
it,
this
would
be
a
good
place
to
move
that
discussion
so
that
we
don't
continue
that
depart
Scotian
in
the
deep
working
group.
Okay,.
E
I
N
N
G
I
that
that's
a
good
clarification,
so
I
think
our
first
step
is
to
define
requirements
for
what
the
manifest
needs.
I'll
pass,
that
to
the
suit
working
group,
so
that
they
can
verify
that
the
manifests
can
do
that.
I.
Think
then
we
have
the
next
step,
which
is
to
say
how
do
we
create
the
manifest?
What
information
goes
into
it
and
how
it
gets
processed.
B
E
B
B
G
Okay,
so
attestation,
we
added
quite
a
bit
of
text
around
attestation
to
the
current
architecture,
draft
I'm,
not
proposing
that
we
close
this
at
this
time.
There's
I
still
think
there's
some
work
to
do
so
want
to
walk
through
what
we
did
in
in
the
draft.
We
we
define
what
we
believe
attestation
is
the
assumptions
around
that
and
how
we
need
to
support
both
proprietary
and
standard
attestation
signatures,
because
there's
tes
out
there
that
are
available
today
that
have
proprietary
type,
a
test
stations.
G
So
we
need
to
pull
those
in
and
then
there's
a
proposed
format
for
attestation
that
that
we
put
into
the
the
draft
I'm
not
sure
that
that's
100%
there
yet
and
we're
hoping
that
we
can
align
with
the
rats
and
and
eat
work.
That's
going
on,
so
that's
likely
to
change
quite
a
bit,
but
it
starts
the
discussion.
So,
let's
go
on
to
the
next
slide
and
I'll
talk
more
about
the
attestation
pieces.
G
So
an
attestation
is
is
a
process
right.
It's
both
a
protocol
and
data
where
one
entity
presents
a
series
of
claims
to
another.
So
the
the
presenter
of
the
claims
is
the
ax
tester
and
the
person
that
receives
the
claims
and
and
verifies
them
or
checks
them
as
the
verifier
and
and
there
needs
to
be
sufficient
proof
that
the
verifier
is
satisfied,
that
those
claims
are
true
or
enough
information
so
that
the
verifier
can
reject
the
claims.
G
So
there's
different,
verifiers
and
and
verifiers
have
different
standards
as
to
what
they
require
to
to
make
that
proof,
and
in
our
case
right,
the
verifier
is
the
TAM.
The
tam
needs
to
make
sure
that
the
te
e
is
is
trustworthy,
so
the
tape
asset
test
stations
are
going
to
be
based
on
asymmetric,
key
pairs
that
are
under
control
of
the
TE
e
and
and
then
we
need
to
define
a
create,
a
well-defined
claim
set
that
allows
us
to
carry
the
claims
for
t
to
the
Tam
so
again,
the
primary
purpose
in
orange
shirt.
G
O
G
Okay,
next
slide,
so
in
in
t
the
attestation
is
going
to
be
used
for
multiple
things
right,
it's
going
to
prove
the
identity
of
the
device.
That's
gonna,
be
part
of
the
attestation
or
prove
the
identity
of
the
ta,
so
that
so
that
Tam
or
service
provider
could
authorize
the
use
of
keys,
but
that's
an
example,
prove
the
identity
of
the
device
or
TA
so
that
you
can
prevent
masquerading
type
attacks
on
a
service
provider.
G
It
can
be
used
for
ta
ta
to
prove
identity
there
to
prevent
unauthorized
interactions
between
TAS.
It
can
be
used
to
prevent
unauthorized
devices
from
installing
a
TA
into
a
tea
that
the
Tam
or
the
service
provider
doesn't
doesn't
approve.
Of.
These
are
are
just
some
of
the
things
that
they're
examples.
I
think
that
they
were
were
helpful
to
think
through.
B
B
So
this
is
effectively
a
use
case
that
has
been
I'll
say
somewhat
under
discussion
in
the
rats
working
group.
So
I
think
there
will
be
interdependencies
that
again,
you
know
I
encourage
all
of
those
who
are
interested,
but
who
are
also
working
on
this
to
participate
in
the
rats,
because
I
would
hate
to
see
this
be
very
specific
when
there's
overlap,
I
totally.
G
B
P
Comment
so
it
seems
like
we're
down
in
the
bunch
of
details
and
I,
wouldn't
be
surprised
if
you
find
that
we
want
to
be
able
to
make
out
the
stations
without
providing
a
unique
identity
down.
The
road
I
mean
if
I
want
to
run
a
key
store
to
provide
for
other
applications
to
run.
Why
do
I
need
to
let
whoever
is
providing
that
and
be
able
to
track
my
unique
identity
that
ties
back
to
me
and
so
as
a
PR.
P
G
G
P
B
E
I
J
B
G
G
Okay,
so
one
of
the
things
that
we
call
out
in
the
spec
is
that
the
cryptographic
properties
that
we
get
out
of
the
attestation
are
only
part
of
what
verifier
needs
to
comprehend
when
they're
approving
an
attestation
or
approving
the
claims
or
accepting
them
as
true
there's
a
wide
variety
of
assumptions
that
are
included
in
the
attestation
in
illicitly
things
like.
How
was
the
attestation
key
installed
in
the
platform?
What
were
the
manufacturers.
G
Processes
and
procedures
in
doing
that,
how
is
a
key
identified
as
compromised?
What
are
the
steps
for
a
compromise?
How
does
a
verifier
know
whether
a
keys
been
compromised?
All
of
these
things
are
processes
and
things
that
happen
outside
of
the
attestation
itself
and
the
verifier
needs
to
be
comfortable
with
those
kinds
of
assumptions
that
are
built
into
the
device
and
the
key
and
the
attestation.
So
I
go
read
the
text.
E
The
question
based
on
the
discussion,
we're
having
so
far
with
the
relationship
with
rats,
is:
should
the
architecture
document
focus
on
the
use
case
and
the
requirements,
but
not
the
details
of
specifying
it
and
leave
that
to
rats.
If
so,
then,
this
particular
slide
might
be
something
that
moves
out
of
the
architecture
spec,
if
that's
the
case,
but
certainly
the
cases
like
who
is
the
verifier,
who
is
the
relying
party
are
all
use
case,
things
that
are
perfectly
appropriate
to
keep
in
there
like
in
the
previous
slide.
So,
okay.
G
G
So
in
order
to
move
things
forward
and
to
provide
some
something
to
throw
rocks
at
I,
put
together
an
attestation
structure
in
the
end
we
want
to
align
with
eats
and
rats,
and-
and
hopefully
we
can
do
that
quickly,
but
from
the
the
concepts
that
we
have
in
teep,
an
attestation
structure
has
to
have
some
sort
of
header
that
gives
us
what
type
of
attestation
this
is.
Is
this
a
proprietary
attestation,
or
is
this
one
of
the
standard
forms?
It's
one
of
the
standard
forms
were
a
type
of
signature
and
probably
some
version
information.
G
G
B
G
So,
let's,
let's
go
to
the
next
slide,
so
one
of
the
things
that
I
am
trying
to
do
and
thinking
through
is
taking
something
like
an
S
Jack's
attestation,
which
is
on
on
the
left
and
I've
highlighted
the
elements
in
in
red
there
in
that
red
box
that
identify
what
are
the
elements
of
an
S
Jack's
attestation?
How
do
they
then
map
into
something,
maybe
a
little
bit
more
general
and
one
of
the
things
I
think
is
important
to
note.
G
The
reason
why
I
put
this
slide
in
here
is
when
we
look
at
the
s
Jack's
a
test
station.
There's
there's
really
only
two
hierarchies
of
things
that
we
have.
So
we
have
a
CPU
SVN,
secure
version
number
that
tells
us
what
version
of
micro
code
is
running.
Basically
the
te
e,
and
then
you
have
te
or
more
aptly
ta
identifying
information
which
includes
the
hash
of
the
TA
code,
the
hash
of
the
key
that
signed
the
TA
code
and
then
a
product
ID
of
the
TA,
and
then
a
security
version
number
for
the
TA.
G
So
the
important
thing
I
think
that
I
wanted
to
communicate
to
the
working
group
and
others
to
think
about
is
there's
often
situations
where
you
update
an
application
but
you're
not
doing
a
security
update.
So
if
you're
on
version,
if
the
latest
version
is
3.1
and
you're
on
3.0
or
2.9,
maybe
it
doesn't
matter
from
a
security
perspective.
It's
the
security
version
number
that's
more
important.
When
there's
a
release
that
says
there
is
a
security,
vulnerability
or
security
problem.
G
This
is
the
latest
security
version.
Those
are
the
things
that
are
most
important
and
so
in
in
the
STX,
where
we've
separated
those
out
now
there
is
usually
some
sort
of
tracking
right,
so
you
have
version
numbers
of
the
actual
code
and
then
at
some
particular
point
you
update
the
security
version
number
because
one
of
the
updates
included
security
code.
Then
you
have
new
features,
minor
bug,
fixes
and
then
another
security
version.
So
that
should
be
important
for
us
to
to
correlate
in
our
identifiers
for
TAS
as
well.
G
H
You
can
still
see
me
right.
Okay,
this
is
right,
so
sick
domain.
As
a
commonly
taken
sensor,
we
say
why
we
need
a
secret
domain
idiot.
Is
it
artificial?
We
can
overhead
for
much
of
that.
One.
The
currently
ot
IP
protocol,
as
that
as
a
first
step
to
create
secret
domains
and
a
managed
to
get
domain,
and
then
TS
are
installed
on
a
secret
domain,
and
traditionally
it
was
inherent
or
formula
pretties
that
a
current
of
current
activity
does
have
that.
So
this
hospitals
coming
past
I
think
I
need
to
go
over
the
background.
H
What
proposal
now
says
first
proposal
was
last
time
said
to
allow
just
implicit
secret
domain,
and
it's
not
always
need
to
be
explicit.
Currently
it
was,
it
is
explicit,
we're
making
implicit.
Then
it
means
one
secret
domain
can
be
created
silently
when
a
TAC
in
stock,
so
that
we
could
go
to
install
here
directly.
We're
not
going
to
install
secret
domain
was.
There
was
also
ocean
here,
say
with
the
catcher
completely
eliminated
a
secret
domain.
H
Soft
in
tip
right
its
opportunity
decide
whether
they
have
that
layer,
but
it's
only
with
dealing
with
trust
applications
only
ta,
so
two
questions
coming
in
where
they
secrete
domain
was
needed
and
then
for
security,
where
we
have
a
instituted,
a
service
provider,
anonymous
access
certainty,
and
for
that
is
a
security
concern
of
privacy
concern.
We
introduced
that
and
this
two
are
related
I
think
we
can
go
to
next
slide.
I
think.
H
H
So
it's
a
sacred
to
me
previously
so
used
to
it's
a
as
a
security
pondering
and
secret
pondering.
So
you
just
ever
provide
the
world
honest,
a
secret
domain
and
it
has
group
RTS
on
the
secret
domain.
So
if
you
have
a
multiple
with
whether
we
could
glue
for
them
say
they,
you
secure
the
mayor's
way
as
a
layer
for
trust
boundary
for
that,
but
ahead.
Sorry,
you
found
here
I
think
in
this
slide.
I
would
say
we
wouldn't
need
to
matter
circuit
domain
as
that's
a
delay.
H
It's
become
primary
entity
right
first,
the
classes
city.
Then
in
this
back.
So
that's
that
that's
anime
wanna
make
us
our
second
eraser.
Well,
because
secured
domain
and
a
civil
provider,
we
added
this
anonymous,
annotation,
ki,
AI,
kak,
so
use
of
a
secret
domain.
As
a
discussion
on
my
next
one
was
so
what?
If
we?
What?
H
If
do
not
say
why
we
need
a
I
came
but
I
expected
to
that
air
KS,
you
create
wing,
you
quite
secured
domain
and
you
create
a
key
enough
device,
a
new
key
pair
that
public
he
sent
back
to
the
time
and
a
like
a
for
to
service
provider.
So
service
provider
can
use
that
a
key
to
encrypt
any
metadata
and
a
parental
early
that
include
personalization,
theta
secrets
on
to
a
trust
application
into
device.
So
we
choose
not
to
use.
H
G
So
maybe
I'll
just
summarize
this
real
quick
yeah
go
to
the
the
next
one.
So
the
discussion
that
that
we've
had
as
authors
on
what
was
trying
to
understand
what
the
security
domain
what
was
for-
and
you
know
it
boiled
down-
we
we
have
different
discussions
about
well,
it
helps
with
management.
You
can
quickly
delete
TAS.
G
And
then,
if
you
wanted
to
group
TAS
together,
you
could
do
that
with
some
optional
elements
or
or
we
make
it
optional
altogether
and
and
that
has
implications
to
what
key
is
used
or
may
remove
the
concept
altogether.
So
so
that's
sort
of
where
we
were
and
we
haven't
really
been
able
to
decide
as
authors,
we've
we've
had
a
lot
of
discussion
around
it
so
and
and
what
we've
come
to
it
at
this
point
was.
G
K
Mean
this,
this
is
honest
I'm
at
the
minimum.
We
have
to
outline
clearly
what
what
the
features
are,
and
you
think
you
bring
up
a
new
point
on
the
anonymous
at
the
station
key,
namely
the
interaction
with
the
service
provider
which
actually
isn't
documented
the
earth
I'm.
What
I,
when
I,
look
through
this
and
try
to
reverse-engineer
the
properties
from
from
the
orthia
be
protocol?
K
There
was
also
another
component,
which
was
because
the
this
AAK
AAK
was
provided
to
the
client
application
for
an
interaction
between
a
client
application
and
the
te
which
I
didn't
see
a
need
for
either.
You
didn't
mention
that,
but
instead
you
mentioned
a
new
one,
namely
this
sort
of
key
provisioning,
all
the
way
to
the
service
provider
which
we
with
which
we
don't
have
in
sort
of
like
the
they're.
Currently,
the
protocol
runs
between
the
de
and
in
potentially
broker
wire
broker.
Do
the
fam
and
not
all
the
way
to
the
back
end
fried.
K
B
H
Okay,
so
this
also
I
say
this
tech
matter.
They
carved
mean
so
the
AI
case,
where
whether
when
I
said
needed,
we
could
talk
about
today
to
use
of
case
of
yak
is
used
right
once
he
used
to
encrypt
a
person
on
this
data
and
the
key
upon
herself
right
so
just
to
kinda
suggest
that
one
you
get
a
encryption
for
the
partner
itself,
it's
and
happens
by
can
be
by
ISP
right
is
each
other.
H
You
crept
in
it,
give
it
to
the
top
right
and
you
respond
whether
letting
it
action
part
right
but
leave
it
out
of
there
say
never
the
whittler
mention
this
one.
So
why
not
a
single
a
I
can
do.
We
need
a
warrior
press
P
and
we
argument
is
over
fair
I
could
actually.
This
is
not
a
really
strong
I
need
a
for
that
one
again,
so
it
is
really
incredible.
Data
and
central
demise,
one
key
from
device,
should
be
sufficient
for
the
equation.
H
Purpose
combination,
ality
all
right,
so
whether
which
SP
odd
times
center,
that
is,
is
already
in
a
protocol.
So
for
that
purpose
separate
that
I
can't
press
peace
not
need
it.
Next
come
down
set
whether
then,
whether
this
aik
a
separately
keys
needed
at
all
right.
A
second
can
are
so
that's
it
good
to
second
point,
because
that
accused
today
give
it
back
to
the
TD
con
app
decline,
happens
and
richer
clapping
in
a
rich
reward.
It
can
curry
what
he
is.
H
Are
you
stalling
unit
device
without
contacting
time,
because
there
now
it's
a
local
and
you
know
offline
mode,
offline
mode,
you
don't
have
the
net
will
connect
up
with
time,
but
you
know
what
T
is
available,
but
how
do
you
trust
that
response
from
te
and
for
that
case,
it'll
return
response
that
response
can
be
verified
by
public
key
of
this
at
local
attestation.
Key
for
that
purpose
then
rich
documents
that
whether
this
also
required
required
this
arguments,
I
think
I
believe
and
never
Thaler
coming
gear.
You
mention
say
this
ordered
the
Vice
IDs
right.
H
H
She
shouldn't
be
accessible
and
exposed
to
any
client
apps
that
can
love
to
talk
with
T,
so
a
we
can
imagine
that
some
want
distributed
can
tap
in
a
forum
and
use
download
that
and
into
many
devices,
then
that
clan
app
collect
devices
certificates
for
authorized
it
occurs,
so
is
that
a
privacy
concern
not
so
if
we
consider
there
a
privacy
concern
there,
we're
better
want
to.
We
want.
He
responds
to
control
that
instead,
he'll
rely
on
the
ritualized
to
do
that
job,
because
I
would
put
a
bird
on
ritual
s.
We
don't
know.
G
G
The
appropriate
cryptographic
operation
to
to
use
for
a
personalization
data
and
and
I
gave
a
bunch
of
details
in
the
notes
and
the
slides,
comparing
what
I
have
to
do
to
encrypt
personalization
data
from
the
service
provider
to
the
te
e
using
the
tes
public
key
and
there's
quite
a
bit
of
things
that
have
to
be
done
to
create
confidentiality,
integrity
and
proof
of
source
and
and
improve
the
delivery.
It's
much
much
easier
with
the
symmetric
key,
and
if
we
have
a
symmetric
key,
we
don't
have
any
privacy
concerns,
because
it's
it's
it's
generated
automatically.
G
So
I
really
think
that
we
need
to
breathe.
In
my
opinion,
I
think
we
need
to
dispose
of
the
AI
K
for
personalization
protection
and
use
a
symmetric
key,
and
then
all
of
this
then
goes
away
and
then
I
think
we
end
up
in
the
case
where
the
security
domain
becomes
either
optional
or
it
becomes
removed.
And
that's
my
opinion.
K
E
H
Okay,
so
so
now
this
was
today.
So
we
look
that's
a
separate
aik
that
looks
not
that
necessary
right,
necessary,
so
T
key
wow,
it's
a
tacky
public
key.
He
has
that
certificate.
Public
key
can
be
used
for
that
to
clear
a
p.m.
today,
personalisation
theta,
incredible
to
use
a
separate
public
key
or
not
in
your
cup
that
uses
Semitic
you,
whatever
the
point
I,
do
we
already
assuming
this
a
random
secret
symmetric
data
in
Quebec
is
used,
but
that
is
wrapped
by
the
public
key
right,
transporter
key
as
the
transporter
key
to
the
device.
H
H
H
We
just
talked
of
tea
and
the
tea
vendors.
The
plantations.
Every
niche
is
hard
to
link
to
that
I
had
to
support
secret
domain.
You
know
how
to
support
TS
within
their
current
a
structure
or
they
major
change
and
then
for
T
perspective.
As
a
would
argue,
we
do
not
have
a
compelling
requirement
of
fail.
We
have
the
introduced
circuit
domain
for
this.
That
was
more
for
traditional
reasons
in
a
way.
K
The
sense
you
are
like
I
like
the
idea
to
explore
the
use
of
symmetric
keys
instead
of
this
aik
I
I,
think
that's
something
we
should
look
into
specifically.
If
the
service
provider
creates
this
metadata
and
and
encrypted
it
most
likely
will
also
encrypt
the
TA.
Binary
is
super
symmetric
key,
so
maybe
maybe
there's
some
reuse
effect
there
and
also
having
I'm
sort
of
the
security
domain
concept,
implicit
or
completely
optional,
but
then
allow
us
to
reduce
our
round
trip
for
a
creation
which
otherwise
would
always
be
there.
K
If
you
create
a
new
security
domain,
which
I
suspect
that
in
many
cases
you
would
you
wouldn't
want
this
isolation.
Concepts
would
be
there
anyway,
regardless
of
on
the
on
the
secure
web
site
between
the
T
different
TAS,
and
they
would
have
to
define
by
the
our
by
design
interfaces
to
to
talk
to
each
other
anyway.
So
I
I,
don't
think
we
are
losing
much
but
I
believe
that's
a
starting
point
for
some
more
detailed
investigation.
So.
G
H
That's
okay,
I
think
yeah!
That's
one
way
they
could
do
that
as
a
default
behavior
made
today
is
explicit.
Right.
Sp
may
was
much
more
secure
domain
right
so
now
say
for
one
second
to
me.
What
if
they
want
to
do,
they
can
use
a
public
key
asset
kind
of
identifying
identifying
as
trigger
of
this
different
SD.
E
M
B
A
B
K
They've
made
the
new
sort
of
proposal
which
is
not
captured
into
so.
For
me,
it
would
be
implicit
and
then
an
extension
could
make
this
optimization
happen
so
by
additionally
creating
this
security
domain.
But
here
it
also
then
says
using
the
default
table.
Provisioning,
a
public
key
and
and
the
proposal
that
they
mentioned
earlier
was:
let's
explore
how
we
would
actually
use
a
symmetric
key
for
the
aik
to
protect
the
data
that
is
then
encrypted
like
the
metadata
and
also
the
the
DEA
binary
I.
H
You
should
I
would
a
more
profit
to
a
more
be
cautious
aside.
Yes,
I
know
it's
it
may.
If
you
don't
have
a
way
to
allow
and
you
have
a
make
a
preset
have
that
separate
key
for
that
possibility,
and
then
it
cannot
break
some
existing
Atty
right
away
right.
At
least
they
can
have
a
forward-looking
pass
for
the
past.
That
has
my
thinking.
H
E
What
I
was
going
to
comment
on
is
I.
Think
some
of
the
arguments
around
you
know,
aik
or
whatever,
in
the
discussion
of
having
some
security
association
that
goes
between
the
service
provider
and
the
t'ee
to
which
the
TAM
is
not
privy
to
those
keys.
It's
kind
of
an
interesting
discussion
and
the
for
at
least
the
use
cases
that
I
have
is
the
case
where
the
ta,
not
the
TE,
but
the
ta
would
want
to
have
its
own
key
pair
like
the
ta,
wants
to
do
and
attest
to
some
other.
E
You
know
TA
and
a
different
device
and
so
on,
and
so
you
have
one
key
pair
for
the
TE
itself
for
the
device
and
one
for
the
ta
and
I
didn't
see
a
reason
or
a
need
to
have
an
additional
one
for
the
SD.
That's
kind
of
neither
of
those
two
could
solve
any
use
case.
I
can
think
of
I
can
solve
by
using
one
key
or
the
other
key.
E
So
you
might
imagine
the
TA
key
is
used
to
generate
a
symmetric
key
between
the
service
writer
and
the
TA
that
other
TAS
don't
have
even
other
TAS
inside
this
Hakeem
security
domain.
If
there
were
any
okay
and
so
I
can
figure
out
how
to
solve
all
those
with
these
two
other
keys
and
that's
why
I
think
I
would
be
fine
if
there
was
no
security
domain
in
the
document.
E
K
And
honnest
I
think
a
force
would
be
okay
for
me
as
well,
because
we
in
any
case,
have
to
describe
on
what
the
keys
the
symmetric
keys
that
we
as
stablishing
to
protect
that
information
with
whom
they
relate
with
what
the
key
naming
is
and
in
some
sense,
even
though
the
name
security
domain
doesn't
show
up
anymore.
We
will
have
some
text
there,
so
it
would
be
I
think
more
or
less
confusing
substitute
than
there,
because
the
security
domain
concept
has
been
extremely
confusing
in
order
discussions,
yeah.
E
I
think
it's
fine
if
there's
example,
text
that
says:
okay
yeah,
like
in
an
SG
x
context,
you
have
no
OS
and
here's
what
it
means
and,
like
your
your
slide
on
s,
checks
attestation,
you
might
say
by
way
of
example,
if
this
was
s
GX,
it
might
look
like
the
following.
Are
this
only
one
level
by
the
way,
if
you're,
in
a
trust
zone,
contact
you're
running
up
to
even
here's
an
example
or
something.
E
B
H
Okay,
so
to
comment
on
last,
a
symmetric
key
part.
We
thought
a
part
of
that
too.
You
know
one
point:
it's
just
I
get
a
car
vacation
from
David
n
hannahs
that
what
do
you
mean
there?
It
when
you
use
a
separate
asymmetrically,
it
can
be
permanent
if
you
symmetric
keys
are
more
like
one
time
what
time
station
key
right.
We
use
data
encryption,
but
if
you
maintain
that
permanent,
but
now
you
have
a
key
you
now
per
TA
or
per
device
now
a
time
I
spin
need
to
recall
that
of
all
devices.
H
Permanent
record.
Remember,
symmetric,
key
I
think
that
it
posed
some
security
challenge.
But,
oh
you
steady!
You
have
a
a
Iko
Uwais
I
can't!
Rather
you
don't
have
a
mani
like
Anna
David,
a
gopher
one,
one
keeper
TF,
but
that
only
that
ta
could
decrypt
data,
and
that
was
that.
Actually,
that
was
the
motivation
of
a
ocularly.
Yesterday,
warper
ta,
we
have
one
per
group.
Yes
right!
H
That
means
one
person
that
yes
can
receive
data
only
sent
to
them
all
other
tears
cannot
decrypt
data
right
so
that,
where
the
purpose
where
different
tears
can
get
the
key
only
rap
to
them
transported
so
that
transport
key
is
used
so
and
only
public
is
given
to
the
SP
on
tank
instead
of
symmetric
key.
So
sir,
and
the
symmetric
key
is
to
steal
its
data
in
Quebec
is
already
always
generated
in
a
data
exchange
and
when
the
encryption
symmetric
key
is
used
to
encrypt
but
symmetric.
B
Did
I
did
here
and
I
think
we're
just
circling
back
so
I
want
to
close
on
this
particular
issue.
So
I
want
to
make
sure
what
I
heard
from
Hannes
and
from
Dave
is
an
individual
contributor
they're
fine
with
the
recommendation
and
the
use
of
symmetric
keys,
so
I
just
want
to
get
a
sense
from
the
room.
Are
there
any
objections
to
go
with?
The
recommendation
is
listed,
going
once
going
twice
anybody
awake
okay!
So
let's
just
resolve
the
issue
for
the
recommendation
so
that
we
can
close
it
and
move
on
okay.
B
G
Okay,
so
the
trust
anchor
there's
been
some
some
minor
confusion,
I
think
back
and
forth
about
how
do
we
do
management
of
the
trust
anchors,
how
our
trust
anchors
installed
and-
and
some
of
us
feel
you
know
that
that
might
be
better
in
a
separate
document.
We
really
need
to
to
focus
on
just
the
requirements
of
how
trust
anchors
are
used
and
what
their
properties
and
requirements
are
in
inside
teeth.
I,
don't
think
we
need
to
go
through
all
of
the
manufacturing
of
of
trust
anchors
and
the
provisioning
it's
much
more
important
to
do
that.
G
G
B
G
Need
to
give
him
time
and
the
local
te
signing
first.
So
there
was
a
proposal
about
making
the
TE
connect
sort
of
go
away.
My
person
there's
this
concept,
I
think
Dave's
going
to
talk
about
this
a
bit
in
in
the
hackathon
as
well.
Where
there's
a
no
request
to
talk
to
the
Tam
and
then
the
Tam
says.
Please
tell
me
your
device
status,
and
then
we
tell
the
device
status.
Okay,
I'm,
sorry,
so
so
the
one
point
that
I
want
to
make
is
Minh
lots
of
discussion
back
and
forth.
G
But
my
comments
here
is
the
the
the
objection
was
that
if
you
send
your
signed
attestation
to
a
Tam,
then
you
might
be
revealing
identity
information
through
your
key.
The
discussion
here
is
that
no
you
don't
have
to
do
that.
You
can
make
some
some
decisions
locally
in
teep,
based
upon
your
manifest
and
the
Tam
key
to
make
sure
that
that's
within
your
trust,
anchor
so
I
think
we
can
resolve
that
I'm
for
saying
you
know
install
ta.
It
is
the
message
I
think
what
we'll
have
some
more
discussion
on
that
yeah.
A
E
J
G
G
Will
clean
that
up
in
in
some
of
the
flows
in
the
future
session
in
the
future
drops
of
the
document,
but
basically
there's
some
piece
of
code
that
talks
to
the
Tam
that
could
be.
You
know
a
service.
It
could
be
something
that's
part
of
the
OS
itself.
It
could
be
a
library
that
you
link
into
your
application,
but
in
essence
it's
something
that
the
client
app
talks
to.
So
the
client
app
could
integrate
that
and
talk
directly
to
the
Tam,
but
it's
all
just
a
software
decomposition
issue
next
slide.
B
E
These
are
the
participants,
the
two
folks
they're
from
a
ist,
and
they
had
an
implementation
that
they
had
done
ahead
of
time
of
a
part
of
it.
They
didn't
actually
bring
the
boards
with
them,
and
so
we
had
a
bunch
of
discussions
about
what
they
found
and
the
implementation,
but
we
couldn't
actually
do
interoperability
testing
for
reasons
I'll
explain
in
just
a
minute:
go
ahead.
Next:
okay,
gee!
The
formatting
is
weird
on
this
display.
That's
okay,.
E
E
Okay,
so
last
IETF
we
tried
to
implement
I
should
say:
I
tried
to
implement
ot
RP
starting
over
SGX,
had
the
port
open
source,
jose
implementation,
and
this
is
where
we
kind
of
designed
between
Ming
and
I,
what
went
into
the
OT
RP
/
ACP
spec,
which
hadn't
been
written
at
that
point,
and
so,
based
on
the
discussion
that
we
kind
of
agreed
to
you
and
start
implementing
there.
That's
we
present
it
to
the
working
group
last
IETF,
and
so
this
I
TF
working
on
updating
that,
and
so
that's
what
you'll
see.
E
So
that
draft
is
basically
the
output
from
hackathon
103.
So
now
you
can
go
on
to
say
what
we
did
this
time.
So
we
all
by
the
before
you
go
on
the
last
point
there,
this
ot
RSP
spec
or
no
place
that
talked
about
exactly
how
you
do
periodic
checks
or
policy.
This
means
a
service
provider
or
if
somebody
has
policy
that
needs
to
be
pushed
down
to
the
device
may
be
updated.
Personalization
data,
maybe
a
new
version
of
a
TA,
and
so
the
client
is
running
perfectly
happy.
But
how
does
the
administrator?
You
know?
E
The
service
provider,
whatever
it
is,
push
down
an
update
to
that,
and
so
that's
the
policy
checks
that
the
client
would
have
to
somehow
connect
back
to
say,
I'm
happy
going
along
just
fine
anything
new
for
me
and
it
says
yes,
I
have
new
stuff
for
you,
and
so
we
had
a
discussion
about
that
between
Ming
and
I
last
IETF,
and
so
we
designed
it
but
did
not
implement
it.
Then
now
you
can
go
on
well.
B
E
The
github
issue
number
two:
it's
a
github
right.
We
have
issues
filed
on
documents,
ok,
and
so
are
the
three
documents
right.
This
is
the
issue
that
has
filed
against
the
OT
RP
protocol
document,
for
it's
part
of
it
once
issued
number
to
be
is
addressed.
That
means
that
both
documents
will
correctly
cover
their
tender
pieces
of
it.
So
yes,
it's
just
since
the
OT
RP
protocol
has
not
been
updated
and
or
to
find
a
proposal.
You
have
to
look
at
the
github
issue.
E
E
So
I
mentioned,
there's
two
different
implementations
represented
across
the
two
implementations
that
were
present.
I
was
working
on
both
SGX
and
trustzone,
and
the
folks
from
a
ist
we're
working
on
both
trust
zone
and
risk.
5,
ok,
so
notice,
everybody
at
the
entire
table,
including
Hannes,
was
using
trust
zone
for
something
we
were
all
trust
on
people,
but
some
of
us
were
also
SGX
people,
and
some
of
us
were
also
risk
by
people
so
between
us.
We
could
have
discussions
that
says
how
does
this
apply
to
this
type
of
te?
E
Last
time
we
designed
it
but
didn't
implement
it.
Okay,
now
it's
implemented,
at
least
in
my
other
three
implementations,
its
implemented
mine,
okay.
So
what
we
compress
is
we
learned
between
those
of
us
at
the
table?
We
had
a
number
of
discussions.
We
filed
five
new
draft,
eight
issues
on
the
OT
RP
spec,
and
we
added
comments
on
three
existing
issues
based
on
the
discussions
and
proposals
that
we
had
here
and
so
I'm
going
to
walk
through
those
depending
on
how
much
time
we
have
does
I
want
to
make
sure
we
have
time.
E
Okay,
great,
so
we
have
time
alright.
This
is
a
summary
that
I
presented
at
the
hackathon
I'm,
going
to
actually
go
through
these
in
subsequent
slides.
Do
only
have
time,
so
we
can
skip
the
bottom
half
of
this,
because
it's
all
on
subsequent
slides,
okay,
these
are
snapshots
of
the
actual
github
issue.
Some
of
these
are
pretty
trivial,
and
so,
if
I
wanted
to
skip
these,
we
can
first
observation
that
we
had
was
in
the
OT
our
P
protocol
spec
right.
So
now
we
kind
of
skipped
the
OT
IP
protocol
discussion.
This
is
it
okay.
E
In
the
OT,
our
P
protocol
spec
in
the
device
state
response,
it
has
this
in
the
middle
of
the
message
you
can
see,
it's
reporting
this
list
of
security
domains
which
might
become
moot
according
to
previous
recommendation
and
so
I
think
we
should
go
on
to
the
next
slide.
Okay,
the
next
one
is
in
that
same
message
that
get
device
state
response
right.
This
is
te
e
information
and
I
know
you
can't
necessarily
read
the
text,
but
this
is
so
that
I
can
read
it
and
to
explain
it
right.
E
It
has
a
search
field
and
a
CA
search
field
and
the
search
field
contains
a
head,
basically,
the
the
the
certificate,
that's
the
leaf
certificate
in
the
chain.
Okay,
so
this
is
like
the
te
e
certificate
that
chains
up
to
a
CA
and
the
CA
search
field
is
an
array
that
has
a
risk
of
the
certificates
that
are
everything
above
the
leaf
back
up
to
the
root.
Okay,
saying
that
the
entire
search
chain
is
split
into
two
fields:
there's
the
leaf
in
one
field
and
the
rest
of
the
chain
in
the
other
field.
E
Okay,
when
doing
a
note,
ERP
implementation,
okay,
you
have
to
use
JSON
web
signatures
and
the
jasa
ws
suspect
has
this
x5c
field
that
you
have
to
implement,
and
it's
actually
mentioned
in
the
ARP
spec
itself.
The
way
that
x5c
is
encoded
is
you
have
your
entire
search
chain
in
one
JSON
array,
so
that
means
as
currently
specified.
You
have
to
have
two
pieces
of
code
to
encode
and
decode.
You
know
hit
construct
and
to
parse
search
chains
and
the
rkp
part.
E
You
have
to
split
the
search
chain
or
two
pieces
and
then
code
one
in
one
one
in
one
field
and
the
rest
of
another
one
and
the
x5c
field,
you
have
to
combine
them.
That
means
you
have
to
have
to
return
to
see
different
pieces
of
code,
and
so
the
issue
here
is:
why
are
they
separate
fields
instead
of
doing
it
the
same
way
as
x5c,
which
you
already
have
to
implement
in
your
OTP
code
and
just
put
them
all
in
one
array?
That's
what
this
issue
is
tracking.
E
E
Okay,
there's
a
field
in
the
device
state
report
that
has
the
te
name:
okay
and
it's
under
specified
what
that
is,
so
we
kind
of
compared
notes.
What
did
you
implement?
What
did
you
implement
for
this
field?
The
document
has
an
example
which
has
the
literal
value
primary
space
te
e
in
the
example.
So
it
wasn't
clear
to
us
so
we'd
implemented
different
ways
of
to
say.
E
That's
card
coded
on
sending
it
because
they
couldn't
figure
it
out
and
in
my
code,
I
had
filled
in
Intel,
SGX
and
op
dash
T
for
the
two
cases,
and
both
of
those
might
be
wrong
right.
If
it's
an
arbitrary
string
that
the
TE
gets
to
fill
in
okay,
the
only
case
that
ot
RP
talks
about
it
is
when
you
have
multiple
te
es,
it
tells
you
which
one
to
hand
off
to
you
and
that's
not
sufficient
answer
the
question.
E
So
it's
an
under,
we
all
agreed
that
it
was
under
specified
and
trying
to
figure
out
what
to
do
with
this
in
our
implementation,
and
you
can
see
the
bottom
question
is,
or
should
the
field
be
deleted?
Okay,
which
gets
into
a
little
bit
of
overlap
with
when
we
talk
about
the
attestation?
That
part
which
is
I,
think
the
last
of
these
issues
so
I
want
to
go
on
because
they
shouldn't
be
deleted,
is
a
potentially
valid
answer.
E
What's
the
version
of
opti
that
I'm
running
or
it's
a
version
of
reveal
trippy
agent
or
none
of
the
above,
and
we
couldn't
tell,
and
so
similarly
question
is:
should
this
field
be
deleted
which
I'll
get
to
you,
which
is
one
possible
resolution,
and
so
it's
actually
unclear
what
to
do
here.
So
we
found
an
issue:
don't
have
a
proposal
other
than
maybe
it
should
be
deleted.
Let's
go
on.
This
is
the
last
one.
E
Okay,
there's
already
the
issue
that
David
talked
about,
which
is
the
filing
of
the
how
to
handle
attestation
in
the
architecture
document.
Okay,
the
archer
P
spec
is
the
protocol
spec,
which
also
needs
to
match.
There
wasn't
previously
an
issue
filed
against
the
protocol,
spec
to
say
you
need
to
talk
cover
attestation
or
whatever
it
means
in
the
protocol
spec.
So
we
filed
this
to
say
and
you
can
see
this
is
related
to
architecture
issue
right.
So
it's
basically
the
same
issue.
E
That's
a
lot
like
an
attestation
right,
it's
sending
the
claims
and
the
proof
right
to
the
side.
Okay,
and
so
the
question
that
came
up
is
is
great
device.
State
response
is
that
duplicating?
Is
it
actually
an
attestation
piece,
in
which
case
there's
it
would
be
an
overlap,
will
say
what
rats
might
want
to
be
talking
about,
and
does
it
actually
still
belong
in
the
OT
IP
spec?
Or
should
this
just
reference
an
attestation
protocol,
this
defined
elsewhere?
That's
the
overall
question,
and
if
that
was
the
case,
then
they
get.
E
If
you
go
down
that
branch
of
the
discussion
and
the
get
device
state
message
would
either
be
absent.
If
there
was
a
different
message
in
a
different
protocol-
or
it
would
be
an
encapsulator
for
some
message
in
that
case,
those
other
fields
I
mentioned,
they
would
go
away
because
they
would
be
inside
this.
Other
attestation
message
right
now.
Things
like
name
and
version
are
outside
these
certificates,
but
in
many
of
the
attestation
mechanisms
they
would
be
claims
inside
the
certificate
right.
E
So
instead
of
saying
my
te
name
is
whatever,
in
parallel
to
me,
sending
the
certificate,
it
would
be
a
certificate
extension
inside
the
certificate
where
it's
signed
as
part
of
a
certificate.
That's
attested,
that's
just
another
way
to
encode
the
same
information
and
another
way
that
the
name
and
version
fields
might
be
able
to
be
deleted.
E
When
look
at
say
how
the
trusted
computing
group
defines
their
search
chains,
that
mechanism
would
be
consistent,
saying
no,
the
name
and
the
version
they
would
just
be
fields
that
certificate
exchange
ins
inside
the
certs,
not
as
parallel
fields,
there's
multiple
reasons
why
the
name
and
version
might
actually
be
deletable.
Okay,
all
right,
I
think
that's
the
end
of
the
hackathon
report.
Any
questions
on
the
OT
IP
protocol
before
I
go
into
transport
stuff.
H
Ahead
missing
me
here:
I
just
want
a
little
bit
and
color
grading
first,
one
good
good
of
Finance.
Thank
you
at
this
a
first
two
editorial,
then
the
a
part
of
the
team
name
and
a
version.
Just
a
motivation.
There
was
a
TA
P
protocol,
t
name
and
aversions
are
kind
of
a
yes
kind
of
claims.
Colorful
attributes
about
the
environment
that
should
be
part
of
attestation.
H
So
idea
is
that
when
you
send
T
name
and
a
version
number,
it's
a
party
itself,
not
the
icing
at
a
time
can't
default
policy
says
I
will
give
it
trusted
application
only
for
those
T's
I
allow
our
trust
right
so
that
we're
teen
named
reversion.
But
now
the
comment
on
say
that
a
product
where's
chooses
of
that
teen
named
revolution,
Atlanta
like
that,
what
do
you
rest
right?
H
We
didn't
require
team
name
and
a
version
part
of
T's
certificates
off
so
you're
saying
whether
that
was
when
you
should
teach
certificate
is
that's
all
part
of
an
information
there
or
you
know
other
part
of
that.
I
think
that's
a
good
question!
First,
it
currently,
it
is
say
when
T
generates,
that
request
devices
stating
information
which
he
include
all
the
information
there.
That's
how
the
harmony
information
sent
over
sometimes
at
some
time
we'll
make
that
decision,
whether
it's
a
continue.
So
that
is
a
this
to
meanness.
That's
hard,
yep.
E
E
Okay,
all
right
as
a
reminder,
if
you're
new
to
this
discussion,
if
you
missed
the
discussion
last
time,
you
can't
remember
what
we
talked
about:
here's
the
summary
there's
a
division
of
labor
in
the
specs
between
the
RTR
P
protocol.
In
this
document.
Okay,
there
is
not
an
intent
that
this
stuff
should
go
into
the
OT
RP
spec.
Why
is
that?
Well,
as
the
that,
though,
GRP
spec
covers
the
communication
between
the
agent
and
the
Tam,
which
is
things
that
go
from
inside
the
TE
write.
E
The
transport
is
outside
the
TE,
your
that
which
the
the
architecture
document
calls
the
broker
right,
and
so
the
or
RP
spec
is
something
that
the
that
the
agent
can
claim.
Compliance
to
this
Beck
is
one
that
the
broker
could
claim
compliance
to
okay,
so
there's
a
division
of
labor
between
different
components
and
what
they
comply
to
that's
supposed
to
be
a
clean,
layering.
Okay,
alright.
E
Yes,
so
in
the
architecture
document
the
terminology
there,
there
was
one
part
that
was
a
little
bit
confusing
and
so
I
had
a
different
term.
When
I
wrote
this
document
here
and
you
can
see
in
quotes
there,
I
used
this
term
cam
broker
and
I
wanted
to
throw
that
out
there,
because
I'm
wondering
should
the
architecture
document
have
this
term
it
currently
doesn't,
and
the
distinction
here
is:
there's
actually
two
different
ways
to
implement
to
town.
E
Okay,
one
way
to
implement
it
ham
is
you
write
a
Tim
service,
the
wage
you've
always
written
at
ham
service?
The
other
way
to
write
a
tam
is
to
use
a
t,
ee,
okay,
you're
using
say
SGX
inside
the
tam,
and
so
you
have
the
part
of
the
tam
that
does
ot
RP
that's
running
inside
trust,
application
in
the
tam
service
and
you
have
the
park,
that's
outside.
E
That's
implementing,
you
know
HTV
or
ever
okay,
and
so
in
that
case
you
have
these
two
pieces
and
which
you'll
see
in
a
later
slide,
which
actually
showed
up
at
HF
103.
But
it
had
these
terms
on
it.
You
said
HTTP
server
and
TAM,
and
so
I've
changed
that
to
say
the
park.
That's
the
HTTP
server
implements
this
spec
and
I
need
a
name
for
that,
and
so
I
called
that
Tam
broker,
which
is
the
tam
side
of
the
transport
okay,
and
so,
if
you're,
using
a
te
e.
This
would
be
the
part.
E
E
When
it
says
te,
it
always
uses
te
to
mean
the
te
on
the
device.
Okay,
whereas
the
tam
could
have
a
trusted
execution
environment
too.
So
that
term
was
a
little
bit
confusing,
because
when
you
have
one
of
the
Tam
there
is
a
te
up
here.
But
when
the
document
says
to
you
never
talks
about
that
one,
it
means
the
other
one
down
here
and
the
device.
But.
G
E
You
my
message
flow
and
you
can
see
what
the
labels
are
and
how
to
match
that,
but
again
I'm
trying
to
write
this
document
in
a
way.
That's
agnostic
is
whether
you
have
a
te
and
the
Tam
or
not
meaning
it
should
cover
both
cases.
Right
right,
I
could,
and
certainly
in
my
implementation,
it
does
I
think.
E
G
B
P
Mark
yeah,
but
aren't
we
musta
concerned
about
the
protocol
and
sure
you
might
be
reusing
some
more
TP
thing
over
there
or
it
might
be
quantum
computer
or
whatever?
But
from
the
perspective
of
what
we're
describing
it's
a
service
called
a
tanum
micro
services,
quantum
computer
load
balancers.
Why
do
we
care
I
mean
if
you
want
to
write
this
but
separate
spec,
says
here's
an
informational
document
of
how
I
built
my
town?
That's
fine
with
me,
but
confusing
this
stuff
saying
all
those
TT's
and
which
one
I
meant
talking
about.
I.
Think
that
just.
E
Making
it
more
confusing,
I
think
it's
necessary
to
talk
about,
at
least
in
the
security
consideration
section,
because
I
claim
that
if
you
have
a
town
that
does
not
have
a
t'ee,
then
you
have
much
more
security
risks
than
one
that
does,
and
so
it
has.
It
does
affect
the
spirit
consideration
section,
certainly.
P
P
E
E
Okay,
yep,
you
can
skip
that
I
already
said:
yeah
the
policy
stuff.
We
didn't
implement
that
yet
this
was
the
slide
that
I
showed
before
this
is
last
IETF
slide.
Okay,
so
I
label
it
at
103
changes
from
oh,
oh
201
in
between
last
IETF-
and
this
is
the
HTTP.
This
working
group
has
this
document:
that's
updating,
BCP
56,
which
is
building
protocols
with
HDPE.
So
it's
intended
for
the
rest
of
ITF.
Anybody
that
wants
to
use
HTTP
is
a
transport.
E
It
should
be
paying
attention
to
be
CP,
56
and
they're,
updating
it
and
that's
an
active
discussion
there
and,
in
fact,
I
think
it
was
only
like
a
10
minute
discussion
on
the
agenda
for
this
week,
which
means
they're
almost
done
with
it,
and
so
what
happened?
Is
that
I
asked
the
authors
of
that
Mark
Nottingham
to
do
a
review
of
this
document
to
say:
hey
how
we
do
it
right
and
he
came
back
and
said:
you're
doing
it
almost
right
with
one
change.
He
said.
E
First
of
all,
the
document
said
to
you:
it
says
to
use
a
specific
media
type,
and
so
he
changed
it
to
say.
Ot
rp+
JSON
a
set
of
application,
slash
JSON
the
slide
that
I
showed
last
IETF
from
hackathon.
We
were
just
using
application,
slash
JSON,
it
says,
use
a
specific
media
type
as
a
recommendation
when
he
does
his
review.
He
said
the
only
thing
that
I
see
that
should
be
done
differently
is
instead
of
using
a
get
in
the
first
message.
So
if
you
go
back
a
slide,
you
see.
E
The
very
first
message
is
a
get
at
the
top
there.
Okay
go
back!
Thank
you.
He
said
you
should
be
using
as
your
link
post
instead
of
a
of
a
get
and
then
you're
consistent,
and
we
said
done
so.
That
was
the
main
technical
difference,
but
he
ran
oon.
Oh
one!
Now
you
can
go
on
the
same
slide
now
updated.
You
can
see
at
the
top.
It
says
post
instead
of
get
and
instead
of
JSON,
it
says:
Oh
share,
p,
+
json,
that's
the
slide.
Okay!
E
Now
the
other
thing
that
you'll
see
is
in
the
top
right:
okay,
HTTP
server
parenthesis
broker.
Whatever
is
the
thing
that's
this
vertical
line
here
is
what
this
spec
does,
and
the
vertical
line
to
the
far
right
is
what
the
OT
RP
spec
does.
Okay,
so
there's
an
actor
here,
there's
a
thing:
that's
responding,
HTTP
and
doing
the
encapsulation
and
adding
the
headers,
and
so
on
and
I
need
a
name
for
that
piece
which
is
not
a
generic
HTTP
server.
E
It's
the
thing
that
sits
on
top
of
these
to
be
protocol
and
as
the
right
headers
and
stuff,
and
so
I
needed
a
name
for
that,
anyway.
Okay,
so,
to
respond
to
Erik,
I
need
to
have
some
name
for
this,
which
is
different
from
HTTP
server.
If
you
went
back
to
my
103
slide
and
said
HTTP
server
and
that
was
kind
of
confusing
cuz
I'm,
not
talking
about
the
HP
protocol
implementation,
so
I
invented
the
term
and
I
happen
to
use
HP
broker
for
symmetry
I'm,
not
wedded
to
that.
E
If
you
got
a
better
suggestion,
but
I
wouldn't
have
some
term
we
can
agree
on,
but
I'm
going
to
go
along
with
whatever
they're
working
for
tells
me
I.
Think
that's
my
last
slide
is
that
right
there,
that
that
was
my
I
picked,
a
name
out
of
the
air
and
I
picked
that
one
for
symmetry,
because
I'm
not
slide.
You
can
see
on
the
left.
Its
ot
RP
agent
and
agent
broker
are
those
two
lines
on
the
left
and
so
on.
There
right,
I
had
Tam
and
Tam
broker
just
for
symmetry.
E
Okay,
the
architecture
document
right
now
has
og
RP
agent.
An
agent
broker
and
Tam
I
need
two
terms
over
here,
just
for
symmetry
and
so
I
picked
am
and
Tam
broker
again
I'm,
not
wedded
to
that.
If
they're
working
group
wants
something
else,
that's
fine
with
me.
So
my
last
question
is
on
the
last
slide,
which
I
will
ask
the
chair
since
I'm
not
acting
as
chair.