►
From YouTube: RATs WG Virtual Interim Meeting, 2019-10-08
Description
RATs WG Virtual Interim Meeting, 2019-10-08
A
For
good
together,
so
in
the
interest
of
time
Eric
of
your
okay,
we
should
keep
the
agenda
and
this
and
we
can
pick
to
the
discussion
and
then
for
those
who
are
taking
the
etherpad
knows
Eric.
You
can
come
back
and
when
we
have
at
the
last
minute
five
minutes
if
they're
fortunate
swinging
spoon.
Okay,
so
let's
go
timing.
B
B
C
B
B
A
Good
now
great
thanks
yeah.
So
basically
we
we
need
to
shift
all
of
the
calls
for
adoptions,
and
our
hope
was
that
we
could
do
the
call
for
adoption,
the
architecture,
the
gang
and
the
interaction
models.
But
if
Kathleen
says
we
should
put
a
placeholder
for
the
last
five
minutes
to
see
if
we're
ready
to
do
that.
B
D
D
D
D
Going
back
to
the
notes,
I,
don't
find
a
lot
of
concrete
actions
that
I
can
put
into
play
of
a
lot
of.
We
had
a
lot
of
conversation
about
different
kind
of
levels
of
assurance
between
different
things
and
that
that's
I
found
that
very
difficult
in
the
end
to
get
into
the
use
cases,
because
they
weren't
specific
to
specific
things,
and
it
wasn't
clear,
wasn't
clearly
new
new
cases.
I
need
you
to
include
so
I
still
a
work
in
progress,
I
think
there's
some
more
pieces.
D
D
Think
terms
like
this
root
of
trust,
for
update
and
root
of
trust
for
verification
and
stuff
I
think
that's
compounding
the
the
situation
and
I
suggest
avoiding
it.
If
you
can
so
I
know
it's
hard
to
get
people
who
are
even
in
a
particular
area
to
change
terminology
or
non
sensing
anyone's,
but
I
think
this
is
going
to
bite
us
later
on
when
it
goes
to
wider
I
get
for
you,
goodness
I'm
going
to
get
questions
you're
like
what
and
there's
like.
Well,
no,
it's
not
a
tough
name
for
yourself.
You
know
it's!
D
D
Don't
I,
don't
really
want
to
keep
it
there.
That's
not
my
goal
and
the
major
work
is
aside
from
a
lot
of
little
tweaks
a
lot
a
little
bit,
including,
for
instance,
PCT
references
now
that
the
these
documents
and
such
as
other
things
that
people
have
suggested
but
I've
gone
down
it
through
is,
as
I
said
in
March,
is
put
it
put
a
template
in
so
the
major
edit
I
made
to
it
since
marchers
added
the
attestation
type
path
for
a
background,
check
and
I've
gone
through
pretty
much.
D
Every
use
case
that
we
had,
except
for
some
of
the
sub
sub
cases
and
I,
put
that
in
put
that
in
as
exact
as
I
can
I
think
that
you
will
disagree
in
some
cases
about
things
and
I.
Think
that's
good
and
there's
some
places
I
couldn't
make
a
decision
as
to
printing
truck
there's
the
test
patient.
I
portunity.
D
D
Well,
isn't
this
the
same
as
this
and
observe
that
actually
they
differ
by
attestation
type,
and
so
that's
one
of
the
reasons
I
didn't
want
to
deduplicate
things
too
soon
because
I'm
sure
there's
other
things
that
other
attributes
of
these
cases
that
are
probably
going
to
show
up
and
we're
going
to
say.
Oh,
yes,
that's
two
new
spaces
because
it
differs
in
how
you
do
things
and
I
hope.
That's
the
useful
thing
and
I
hope
this
is
really
what
I
was
going
for
beginning
so.
E
I
just
want
to
make
an
observation
here:
the
safe
they
wear,
I
think
out
of
the
use
cases.
I
think
there
might
be
two
different
categories
of
use
cases
here
and
some
of
the
use
cases
are
really
generic
and
don't
try
to
specify
the
solution,
and
so
like
five
point.
Four
and
probably
many
of
the
ones
that
are
black
right
now
are
probably
in
that
category,
because
I
think
the
passport
versus
a
background
check
is
often
a
property
of
a
solution
to
a
use
case,
and
so
the
other
category
is
some
of
the
use.
E
Cases
in
here
really
are
specific.
You
know
solutions,
and
so
you
know
Android
keystore
and
what
they're
things
pointed
to
in
the
air
in
the
use
case
document
are
specific
solutions.
Any
specific
solution
will
either
be
background,
check
or
passport
or
high-grade
or
whatever,
and
so
I
think
it
is
natural.
E
The
fact
that
you
have
some
that
are
black
or
TBT
and
some
that
are
not
it
has
to
do
with
whether
it
specifies
a
solution
so,
for
example,
in
the
ml
confidential
ml
model,
which
is
just
the
the
black
one
that
I'm
staring
at
right
now,
five
point:
four:
there's
going
to
be
passport
solutions
and
there's
going
to
be
background,
check
solutions
and
the
general
use
case
is
at
goseck.
Yes,.
D
Well
enough
and
I
think
that's
something
that
that
we
either
need
to
go
and
find
the
people
that
are
doing
tasting
or
confidential
machine
learning
models,
or
we
need
to
agree
that.
Well,
we
might
just
not
be
able
to
solve
that
problem
because
it
we
might
not
include
something
that
someone
needs
or
something
like
this
or
they're,
going
to
have
a
custom
extension
or
I.
Don't
know
whatever
something
like
that
is
going
to
happen.
We.
B
E
I
wonder
if
we
could
not
have
like
use
cases
and
I
don't
know,
uses
or
something
so
even
the
5.3
TP
working
group
use
case
right
in
the
slides
that
I
presented
the
concentric
meeting.
It
was
clear
that
there
was
a
use
case,
which
was
you
know.
How
do
I
integrate
attestation
through
mediation
and
then
there
was
a
specific
proposal
on
a
solution
where
we
said
this
is
the
one
that
probably
makes
the
most
sense
forty
right,
and
so
that
was
a
particular
type
particular
way
to
use
it
with
open
tres
protocol.
E
F
This
is
Laurence
bumble.
It
I
agreed
with
everything.
Dave
said
in
his
first
set
of
comments.
It
doesn't
seem
that
critical
to
me
to
sort
them
into
background
versus
passport
seems
like
that.
Could
for
a
given
sort
of
use
case
that
it
could
vary
based
on
business
model
or
something
like
that,
so
I
mean
I.
Would
this
doesn't
seem
like
a
critical
sorting
criteria
to
me?
It
seems
like
we
should
be
accommodating
both
in
most
of
our
work,
both
right.
G
Now
the
third
point-
and
this
is
our
voice-
I-
think
passport
and
background-checked
are
probably
my
favorite
part
of
this
use
case
because
I'm
looking
at
the
interaction
models
between
network
elements
and
the
interaction
models,
are
very
much
determined
based
on
the
protocols
that
are
choosing
how
to
extract
the
information.
So
I'm,
really
a
fan
of
this
breakdown.
E
Where
I
was
going
to
say
that
I
think
one
of
the
main
values
of
background
check
versus
passport
in
this
type
of
taxonomy
is
I.
Think
whether
it's
background,
check
or
passport
helps
to
make
it
easy
to
understand
why
some
people
are
looking
at
trying
to
standardize
evidence
and
other
people
are
looking
at
trying
to
standardize
the
attestation
result.
F
D
F
It's
just
so,
it
just
seems
like
we
want
to
be
flexible
and
accommodating
both
models.
Sort
of
all
the
time
and
most
of
our
standards
I
mean
a
lot
of
our
standards
that
kitty
it's
around
the
definition
of
the
of
the
token
and
the
token
this
should
be
neutral
to
you
know
the
claims
that
eat
all
that
should
be
neutral
to,
though,
to
whether
its
background
or
pathway
that.
B
F
Vision
here
also
is
for
eats
is
that
they
get
stuffed
into
all
sorts
of
other
protocols
into
extensions
and
TLS
into
HTTP
headers
into
HTTP
bodies.
So
the
whole
use
case
could
just
be.
It
could
be
driven
by
how
how
the
eats
are
getting
stuffed
into
smoke
and
protocol
and
totally
out
of
under
proper
control.
So.
D
B
B
You
don't
need
to
vest
in
a
whole
new
set
of
language,
like
you
do
with
the
architecture
document,
so
I
think
this
could
actually
make
a
better,
more
reachable
architecture
document
to
have
higher
deployment
and
more
people
adopting
it.
I
think
would
get
a
better
adoption
right
with
that
kind
of
structure.
So.
H
H
B
Really
appreciate
so
which
choices
michael
has
made
in
this
like
I,
don't
want
people
to
have
to
learn
an
entire
new
language
set
to
adopt
this.
You
know,
I
know
that's
common
with
some
protocols,
but
I
don't
think
it's
necessary.
This
should
be
pretty
simple
right.
You
use,
eats
and
lots
of
different
ways
and
you
validate
them,
and
you
know
you
move
on
your
merry
way.
B
You
make
this
something
that
we
can
use
as
a
standard
and
it
could
be
integrated
everywhere
so
that
we
don't
have
companies
coming
up
with
their
own
solutions,
which
they
already
have
and
are
continuing
to
do
right.
So
time
is
important.
I
think
we
could
get
something
like
this
document
out
faster
and
we're
done
and
I
think
we'd
have
less
arguments
over
it.
So.
E
E
J
B
Just
dropped
a
bomb
right,
so
I'd
love
to
hear
other
other
thoughts
or
if
people
haven't
read
the
use
case
document
that
they
read
it
and
think
about
it
in
this
way
and
they
think
towards
adoption
part
of
the
Charis
workshop
that
we
did
a
few
months
back.
We
looked
at
what
protocols
were
adopted
and
what
we're
not
there's
a
clear
industry
demand
for
this,
and
that
was
one
of
the
main
factors.
But
the
understandability
is
another
one.
I.
D
D
A
D
B
A
C
A
A
Okay,
so
let's
go
ahead
time
Kathleen.
We
absolutely
need
to
continue
this
discussion
and
it
flowed
into
New
York,
a
textured
raft
so
but
I'd
like
to
give
Hank
time
to
provide
his
view
on
the
architecture
and
content
and
update
to
that
draft
so
that
we
can
continue.
This
discussion
is
okay,
no
sections.
A
H
H
H
We
only
have
two
major
types
that
are
architectural
constituents
now
that
our
roles
and
principles
and
the
messages
between
them
principals
are
basically
the
bucket
you
can
put
rolls
in
and
those
communicate
with
each
other.
So
this
is
more
than
the
background
check
and
the
passport
model
allows
for
literally
every
kind
of
combination
and
message
exchange,
including
proxying.
H
A
lot
of
stuff
Lee
laying
at
betting
in
parallel
and
yada
yada,
so
also
enables
us
to
avoid
specification
texts
about
roots
of
trust
and
trust
anchors,
because
we
just
introduced
a
very
important
I
think
concept
that
is
separating
the
internals
of
the
attested
Road
there's
something
in
there
that
that's
great
they
each
for
example,
and
something
that
is
attested,
for
example,
coordinates.
There's
always
a
simple
go
to
example,
that
has
geographic
coordinate
in
them,
and
that
is
the
attested
computational
environment.
These
are
separate
and
nothing
more.
H
H
People
now
contributed
to
this
model
over
the
last
year
and
it
is
resulted
in
the
simplification
of
terminology,
like
a
lot,
are
down
to
four
roles
and
five
message:
sites
and
consulting
with
Michael
and
the
use
cases
parsing
them
a
lot
of
times
and
putting
them
through
all
the
solution.
Traders,
including
I,
hope,
Fido
and
eat,
which
is
sometimes
a
little
bit
hard
to
get
feedback
from
this
mess
to
all
of
them.
H
Basically,
the
four
roles
and
five
messages
so
that
map
steep,
apparently
they've
got
it
and,
and
he
was
able
to
method
it
apparently
maps
to
Fido
and
s
Lorenz
objects
to
this,
and
it
is
mapping
the
complete
space
of
TC
ttpm
base
attestation
and
te
based
added
station
evidence.
So
that's
nice,
therefore
BF
over
there's
a
case
of
Pyo
see
here,
so
it
should
be
able
to
map
eat
the
open
trust
start
from
or
God
wasn't
true.
That
might
be
cheap
version,
one
at
some
point.
J
Here
this
is
Gary
here,
I,
don't
believe
it
does.
Man
to
fight
I
cited
the
example
yesterday,
yeah
Android
safety
net
attestation,
whereas
he
tested
and
the
attest,
get
a
tested,
computing
environment
and
the
attest
are
one
of
the
same.
So
it's
not
I
mean
it's
not
sure.
If
that's
the
goal
of
this
document,
then
we
need
to
make
sure
that
it
does
that
we
need
to
make
sure
that
doc,
if
we
see
turreted
terminology
that's
been
defined,
is
actually
consistent,
of
course,
definitely
to
be
the
goal
to
try
on
a
document
either.
H
Retin
safety
net
I
put
a
bail
to
the
list,
so
safety
net
itself
says
it
is
not
an
agitation
so
that
that's
kind
of
contradiction,
I
was
not
able
to
resolve.
It
just
says
it's
a
claim
set
and
please
use
keystore
to
make
this
agitation
it
really
in
the
description
of
safety
net.
So
I
was
a
little
bit.
I
didn't
know
how
to
deal
with
that.
So
I
need
more
import
about
that
and
we,
as
a
group
most
certainly
need
to
understand
this
better.
H
But
at
the
moment
the
session
seems
to
be
the
claim
said
and
attestation
seems
to
be
based
on
the
keystore
element
of
this.
That
is
my
my
high
ten,
my
high
overview
and
and
most
certainly
proposals
of
texts.
The
only
way
to
remediate
this
because
I
don't
know
how
to
phrase
it
better,
and
so,
if
it's
a
disparity
and
if
separate
on
a
fire
system
permission
lever
is
not
enough,
then
I
don't
know
what
is
enough.
Well,
if
lose
all
the
others.
It's.
J
A
matter
of
clarifying
the
scope
of
the
document
right
because
I
view
safety
net
as
yeah
a
little
bit
a
little
bit
more
sophisticated
form
itself.
Attestation
and
even
Fido-
has
the
concept
of
self
attestation,
which
is
basically
self
signing
a
lot
of
you
know,
and
a
lot
of
security
experts
I've
heard
find
that
absolutely
worthless
from
a
from
a
person
security
perspective,
but
it's
there
so
I
think.
If
we're
doing
that's
what
I'm
saying?
Are
we
going
to
cover
cases
that
that,
maybe
you
do
not
add
sufficient
security
value?
J
H
C
This
isn't
the
question
that
was
asked
is:
does
the
architecture
cover
the
scenario
where
the
attested
environment
is
the
same
as
the
attesting
environment
and
it
does
because
we
have
the
ability
to
distinguish
the
two?
We
can
always
say
that
that
in
some
implementations,
those
two
environments
are
combined
one
in
the.
D
Yeah
it
does
not.
This
is
not
one
architecture
to
rule
everything
to
become
the
same
case.
This
is
a
set
of
tools
to
put
together
that
are
used
to
solve
specific,
well,
actually
use
cases
in
in
the
different
communities.
So
not
every
component
of
the
architecture
necessarily
is
used
by
everybody.
Yes,.
H
Indeed,
it
is
a
composability
here
you
can
leave
out
roads,
you
can
even
collapse.
The
testing
and
a
test
environment.
If
you
really
need
to
the
architecture,
does
not
spread
that
out.
It's
a
separate,
but
we
can
highlight
if
you
don't
separate
them,
you
have
the
security
issue,
but
still
you
have
to
have
this
level
of
assurance.
You
have
to
do
to
highlight
that
at
some
point.
So,
if
you're
highlighting
here
it's
okay,
it's
on
as
hard
as
you
get
it's
kind
of
fishy.
H
According
to
all
the
inputs
that
is
imperil
to
Kathleen's
latest
a
suggestion
or
proposal
is
that
we
move
all
the
terms
up
to
provide
a
better
overview
and
then
immediately
start
to
relate
all
the
terms
to
make
a
better
relationship
between
all
these
terms.
That
is
basically
what
the
use
cases
are,
I
think,
as
least
as
I
think
Michael
would
agree
with
this.
H
Please
please
just
drop
in
a
know
if
there's
enough
room,
so
we
try
to
abstract
the
use
cases
and
the
roads
there,
and
therefore
we
have
a
very
limited
set
of
terms
now,
which
are
nine
and
you
can
combine
them.
In
any
case
you
want,
you
can
leave
a
lot
of
them
out
in
your
workflow
solution
and
you
come
let's
the
testing
and
it
has
been
stuffed
with
this,
not
spare
doubt
but
certainly
possible.
With
the
exception
again,
you
have
to
highlight
that
you're
not
being
separate.
H
If
you
do
this,
otherwise
it
is
not
valid
evidence
and
you
cannot
put
trust
within
this
properties
on
it
again.
This
is
a
complement,
those
diagrams,
because
this
should
go
up
in
the
architecture
to
reduce
the
learning
curve
that
we
are
encountering
today.
There's
another
discussion
about
standard
and
formation
de
that
does
not
have
to
be
here.
I
think
we
can
skip
it
for
the
sake
of
time.
H
I
just
wanted
to
highlight
the
architecture
does
not
have
to
be
standard
like
if
it
is
possible
to
formulate
requirements
on
the
solutions
that
are
like
an
attacker
must
be
able
to
create
a
sensation,
evidence
an
identity.
She
never
has
certain
qualities.
For
example,
there
testing
in
a
tested
environment
are
not
separate.
There
is
a
very
important
qualities
of
the
evidence
that
is
very
important
to
the
post
processes.
If
you
don't
know
that
you
cannot
trust
that
and
put
no
trust.
Listen
to
this.
If
you
do
express
that,
for
example,
this
it
claims
you're
golden.
H
If
you
do
not,
it
is
impossible
to
still
distinguish
evidence
that
is
trustworthy
from
one
that
has
that
might
have
so
to
speak.
Security
issues,
as
I
heard
from
theory,
but
that's
ok,
and
that
is
the
only
prescription-
is
that
the
architecture
should
do
ever
and
nothing
more
and
as
I
heard,
we
have
to
go
back
to
the
AG,
probably
to
let
that
be
confirmed
because
I
don't
really
know
how
a
BCP
1400
terminology
in
an
informational
doctrine
works
actually
and
I
have
not
met
yet
one
individual.
H
H
It
would
make
a
lot
of
sense,
but
then
they
would
not
be
use
cases
anymore,
but
scenario,
descriptions
like
use
care
usage
scenarios.
Use
cases
are
intended
to
be
not
using
the
terminology
of
the
actual
solution,
because
they
are
only
a
story.
Then
you
map
them
to
the
unifying
part.
That
is
the
architecture.
So,
if
you're
going
with
user
scenarios
here,
you
can
use
the
terminology
already,
but
I
think
that's
not
the
definition
of
use
case
anymore.
But
that's
only
me.
We
are
camping.
This
with
us.
I,
don't
know
right.
C
B
So
this
is
Kathleen.
I
am
just
going
to
disagree
with
Hank
that
we
need
to
have
a
completely
new
defined
set
of
terminology
that
is
confusing
and
hard
to
reach,
and
that
makes
it
an
architecture.
So
I
don't
agree
with
that.
I
think
you
can
define
an
architecture
and
allow
it
to
be
reachable,
and
you
know
I'm,
just
picturing
it
going
off
if
Dave,
Baylor
and
I
both
have
had
trouble
reading
the
document
a
lot
of
other
people
will
we.
H
Don't
know
let
me
highlight
it
is
not
finished
yet
of
the
composition,
for
example,
that
Dave
is
proposing
are
not
in
there,
yet
we
pull
them
all
out
to
boil
it
down
to
a
nucleus
that
we
can
start
again
with.
So
it
is
probably
not
matching
all
the
use
cases
at
the
moment,
because
we
pulled
it
out
to
give
you
the
pure
essence
that
was
refined
from
these
cases.
Mapping
them
back
to
them
is,
of
course,
an
important
task
of
the
architecture,
so
I
don't
know
where
to
start.
H
If
you
want
to
do
that,
you
case
document
I'm
not
really
convinced,
because
they
are
basically
evolving
to
user
scenarios
and
they
use
the
architecture
itself.
Most
certainly
need
better
mapping
to
use
cases.
So
maybe
both
documents
merge
and
that
I
think
is
what
Micah
was
highlighting.
What
I
like
indicating?
Please
again,
stop
me
if
I'm
saying
something
wrong
here:
Michael
and
and
readability
of
something
that
is
actually
complicated
and
not
simple,
is
a.
C
H
But
there
was
no
chance
to
do
directed
as
I
think
so
maybe
we
keep
that
as
a
extra
proposal
going
on
and
see
how
this
works,
and
if
there
is
enough
agreement
we
can
mold
the
use
cases
and
derive
terminology
from
them
and
do
the
architecture
there.
That
is
I
think
that
the
end
result
would
look
quite
similar,
but
it's
a
different
approach.
I
agree
with
that.
Well,.
H
E
If
you'd
like
me
to
do
that,
yes,
because
I
have
to
because
none
of
the
documents
other
than
the
text
that
Michael
mentioned,
that
he
added
in
that
he
does
not
did
not
expect
to
be
in
these
case.
I
do
want
to
write
some
text
about
background
check
and
passport,
especially
as
it
relates
to
teeth
and
I.
Guess.
Michael
has
a
little
bit
of
that.
But
yet
did
short
answer
is
yes,
because
I
was
hoping
to
write
some
text
anyway.
Okay,.
H
Yeah,
something
look
at
is
always
better
I
think,
and
so
you
can
compare
it.
Moving
on
interaction
model
in
this
case
is
progressing.
We
adapted,
maybe
I,
don't
know
if
level
valid.
This
is
now
the
architecture
terminology
it's.
We
are
not
through
the
whole
document
yet,
but
the
major
chunk
of
it
is
now
aligned
and
we
have
running
code
for
the
interaction
model,
which
is
basically
a
co-op
seaboard,
CDA
based
implementation
that
is
viable
to
be
integrated
in
forever
and
can
run
out
of
the
box.
H
It
is
there
and
you
can
test
it
all
the
time.
It's
literally
using
the
architecture,
terminology
and
the
interaction
model
described
in
the
apparently
interaction
model,
draft
its
BC
3.
So
everybody
is
the
desert
who
use
it
and
if
you
do
not
have
any
requirements
in
hardware,
we
provide
a
simulators
and
emulators
to
a
network
aversion
to
test
this
life
on
any
books.
You
have
there's
a
interesting
benefit
to
this,
because
you
have
a
hands-on
feeling
how
this
works.
H
B
F
H
Interaction
models
are
the
edges
between
brawls,
where
messages
are
effectively
relayed.
So
it
comes
into
this
picture
as
a
message,
and
the
interaction
model
is
basically
highlighting
how
these
messages
are
queried.
They
may
be
even
pushed
if
you
use
time-based
or
other
approaches,
which
is
the
next
slide,
because
there
will
be
more
than
one
model
we
realized.
We
are
starting
with
the
challenges
one
month,
one,
it's
a
often
probably
most
used
model,
but
it's
rather
underspecified
because
there
is
never
a
reference.
H
Martin
document
you
can
point
to
like
we
are
doing
it
this
way,
so
we
just
build
it
here.
There
are
flavors
of
this
like
the
direct
anomalous
education
at
a
station.
There
is
also
the
ephemeral
key
dice
at
the
station
approach
and
there
is
a
unidirectional
time
based
approach
that
are
not
covered
in
the
interaction
model
document.
Yet
so,
with
respect
to
Phi
go
you
can
choose
any
into
XE
ones.
That
can
be
a
challenge
response.
H
C
H
Exactly
that's
my
delisting
advanced.
We
were
only
annoyed
that
there
was
no
challenge
response
reference
at
the
action
model,
but
now
we
realize
that
a
lot
of
flavors
here
that
are
not
all
covered
in
the
use
case
document,
yet
that
are
also
used
today
in
production,
and
we
cannot
just
leave
them
out
and
sell
them
mostly
metal,
not
Metro,
geography
and.
J
Hey
this
is
Gary
here
my
name,
ain't
jack,
but
I
mean
this
is
I.
Think
yeah
I,
like
reading
the
interaction
model,
its
informative,
I,
understand
it,
but
this
is
actually
an
example,
in
my
opinion,
of
where
we
get
into
trouble
when
we
try
to
actually
be
prescriptive
on
terminology
assertion,
as
its
defined
here
is
not
the
same
as
an
assertion
defined
in
the
fight
of
context,
because
assertion
and
a
certain
can
only
do
to
be
generated
a
route
almost
always
after
a
user
verification
operation
has
been
performed
because.
H
J
F
J
Not
going
to
resolve
it
and
that's
why
it
shouldn't
even
be
a
we
shouldn't
even
talk
about
normative,
a
normative
terminology.
We
should
just
say
this
is
in
this
context:
that's
it
anyway,
and
otherwise
we're
what
you're
getting
right
into
these
right
into
issues
what's
being
defined
as
an
assertion
in
the
context
of
interaction
is
very
it
became.
This
document
is
very
different
than
what
Claudia
Potter
defines
an
assertion
and
the
call,
even
though
the
call
flows
could
actually
become
very
similar.
D
F
H
D
F
H
H
F
H
And
the
gossiping
and
then
using
that,
if
it
diverges
from
a
interaction
model
you
can
find
we
need
a
contributor
that
really
spells
that
out.
Just
saying
it
is
defined
somewhere
else
is
enough.
Creating
a
conversion
point
here.
It
just
creates
separate
solutions
that
are
not
interoperable
anymore,
so
the
conversion
point
has
to
be
retained.
H
Otherwise
people
basically
abandon
the
advantage
of
having
interoperability.
That's
everything
basically
I'm,
saying
yeah.
We
can
have
separate
solution
that
works
on
their
own
domain.
That
is
okay
and
we
can
hope
for
adoption,
or
we
can
include
existing
solution.
That's
basically
the
idea
of
the
interaction
model
draft
and
which
is
which
is
a
longer
arm
of
the
architecture
actually
moving
on
the
yang
module
will
only
be
a
status
update,
so
there
have
been
two
reviews,
which
is
very
nice,
but
not
enough.
H
So
I
think
the
Lord
in
the
lower
limit
was
like
three
reviews
and
I
think
until
the
next
ITF
meeting
with
another
review
that
should
be
possible.
What
I
can
report
is
that
there
is
a
mother,
actually
multiple
prototyping
efforts
in
production
environments
already
and
they
are
progressing
fast.
There
also
will
be
more
complicated.
H
Role
compositions
than
pests
for
a
background
check,
but
they
will
always
somehow
be
related
to
those
that
is
true,
but
calling
them
just
hybrid
would
not
be
enough
and
I'm
reluctant
to
go
into
composite
device
definition,
because
that's
kind
of
easy.
My
only
question
is:
does
a
use
case
document
cover
than
aka?
Does
the
architecture
document
cover
them,
because
those
two
will
converge?
H
That
is
much
the
plan
originally
also
and
I'm,
not
sure
if
it's
valid
or
useful
beneficial
to
introduce
the
idea
that
I
the
tester
is
a
composite
device
and
that
there
are
multiple
things
that
they
can
be
attested
to
by
a
multi.
Let's
call
them
principles
again,
because
that's
why
that's
architectures
flexible
that
could
attest
for
some
of
these
sub
components
and
composite
devices,
I'm,
not
sure
if
that's
relevant
to
the
architecture,
probably
it
would
be
over
engineering
may,
but
the
notion
was
raised
so
I'm
raising
it.
It
was
the
only
thing.
H
I
was
not
sure
about,
because
it's
so
that's
an
item
otherwise,
and
yang
module
needs
more
text.
We
are
aware
of
that.
Also
reviews
show
us.
Yes,
they
can
be
more
direct
and
it
will
be
provided
by
other
contributors
than
me
and
it
is
in
the
queue.
So
this
will
be
done
until
the
next
meeting
also
and
then
yang.
While
you
will
have
a
relatively
stable
state
that
is
according
to
already
adopted
terminology,
I'm,
sorry
to
say
this,
but
the
role
terminology,
for
example,
as
a
nucleus.
E
H
E
On
the
on
your
last
question,
this
is
Dacia
where
I
think
the
working
group
did
have
previous
discussion.
I'm
thinking
it
was
last
face-to-face
meeting
about
different
types
of
compositions
of
Claim
says
whether
there
was
nesting
or
changing
or
whatever
and
I.
Think
for
that
discussion,
which
of
course
may
be-
and
you
know
the
eat
document
or
whatever
I
think
that
does
have
some
does
weren't
some
architectural
discussion
to
motivate.
Why
that's
interesting
so,
in
other
words,
is
there
benefit
to
introduce
the
concept
of
I?
E
Don't
know
composite
devices
is
the
right
word,
but
I
think
there
is
a
benefit
to
increasing
whatever
is
necessary
to
understand
the
use
case
for
having
more
complex
arrangements
of
whether
it's
eats
or
claim
sets
or
whatever
term
that
you
want
to
use
I
think
there
is
some
impact
on
the
architecture
document
to
motivate
that
I
have
to
think
about
what
the
right
way
to
describe
that
is,
but
I
do
think
that
there
is
that
there
is
a
benefit
to
introduce
something
there
and
I
have
to
think
about
that
all
right.
This
is
I.
There's.
G
A
couple
things
that
I
think
would
give
it
examples
of
that
and
they
were
hit
on
the
use
case
document.
We
have
multiple
TPM,
equivalent
ships
and
our
platforms,
and
how
do
you
get
in
a
unit
I'd
set
of
claims
from
different
ships
pushed
out,
and
these
are
mostly
TPM
two
types
rather
than
EEP
types,
a
passport
attestation,
as
well
as
key
provisioning,
and
especially
for
virtual
and
physical?
How
do
you
handle
the
assembly
of
virtual
and
physical
attestation
going
off
device?
G
F
Well,
I
was
going
to
ask
kind
of
how
how
we
see
this
yang
document
relating
to
the
eat
document
I
mean
my
my
understanding
is
yang
is
basically
documenting.
The
claims
that
exists
today
in
TPM
chips
that
can't
really
be
changed
and
eat
is
defining
a
different
way
of
doing
claims
and
there
I
almost
seems
like
a
bit
of
ships
in
the
night,
not
really
sure
how
to
relate
them.
J
H
F
H
F
F
C
B
For
that
discussion,
if
we're
going
to
take
it
to
the
list,
if
Dave
or
some
representative
from
the
teep
working
group
might
be
able
to
time
in
since
we
do
have
te
vendors
working
in
that
forum,
who
have
agreed
to
split
out
attestation
to
reps,
do
they
plan
to
use
this
or
not
right?
So
those
would
be
really
good
questions
to
understand
so
having
some
interaction
from
the
T
working
group
might
be
good
on
those
questions
right.
C
C
C
I
think
that
would
be
a
case
where
we
would
want
the
rats
working
group
would
want
to
look
at
them
and
say:
does
it
make
sense
to
have
different
drafts
that
are
that
are
defining
the
same
semantics
but
are
differ
in
terms
of
their
data
model?
You
know,
maybe
we
can
work
to
the
two
to
simplify,
so
that
the
we're
not
we're,
not
you
know,
defining
the
same
thing
differently
in
multiple
as
cases
that
was
looking.
That
was
one
of
the
concerns
that
we
had
going
into
the
discussion
at
the
last
face-to-face.
C
C
C
H
H
G
B
F
G
What
thing
we
can
do
I
mean
the
idea.
Even
the
claim
set.
Six.
The
yang
model
has
a
lot
of
other
stuff
for
RPC
elements
and
elements
going
back
and
forth.
So
even
if
it's
fixed,
there
is
quite
a
number
of
yang
models
that
could
be
exposing
the
same
information
from
different
vendors
just
nailing
down.
That
is
a
reasonable
amount
of
work
and
useful
in
of
itself,
even
with
the
fixed
elements
out
of
that
TPM,
the
interaction
model
supported
by
the
router
can
be
very
different.
G
F
Like
all
so
in
the
in
the
like
Android
attestation
world,
we
don't
specify
any
of
that
stuff
and
don't
care
about
that
stuff,
because
it's
all
application
specific
I'll
run
in
HTTP
transactions
and
headers.
And
you
know
it's
like
your
banking
app
is
got
an
interaction
model
in
your
your
United
Airlines
app
as
an
interaction
model,
and
all
of
that
stuff
is
just
we
don't
care
about.
Any
of
that.
All
we
just
care
about
is
defining
the
the
claim
format
and
let
letting
those
apps
those
Android
apps
interact.
However,
I
want
all
over
the
place.
F
J
F
I
think
maybe
there's
a
maybe
there's
a
vision
here.
I
can't
really
speak
for
it
myself
because
I'm
not
that,
but
you
know
TPMS
are
limited
in
what
they
can
do
now.
Maybe
we
move
to
something,
but
that's
a
lot
more
powerful
than
TPMS
in
terms
of
ability
to
express
claims,
and
that's
where
we
would
want
to
look
at
have
the
claims
that
are
in
TPMS
today
relate
to
how
the
claims
are
being
defined
for
eat
that
we
would
be
mine.
F
My
interest
in
all
of
this,
the
the
sort
of
RPC
back
and
forth
the
interaction
model
that
seemed
like
that
should
be
factored
out
and
that's
kind
of
a
than
it
is
that's
a
conveyance
protocol
for
claims
or
for
tokens
for
TPMS
for
routers,
that's
kind
of
a
specific
thing,
and
maybe
it's
just
making
us
it
may
be.
These
are
ships
in
the
night,
except
for
trying
to
understand
how
the
claims
can
be
similar.
So
there's
a
transition
plan
from
TPM
based
claims
to
eat,
based
claims,
I.
G
See
what
you're
saying
there
certainly
is
a
need
now
for
the
vendors
who
want
to
talk
to
and
from
TPMS
to
have
a
transport
model
mapped,
which
is
why
they
get
what
the
egg
metal
came
from.
I
mean
the
yang
model
started
in
in
the
vendor
community
for
routers,
and
we
want
to
have
a
common
one
across
the
routers.
That's
why
I
came
to
this
group
I
think
that
others
might
also
want
that.
It
seems
pretty
straightforward
honestly.
F
C
In
theory,
based
claim
is
supposed
to
be
a
dependent
of
a
root
of
trust
and
nothing
that
prevents
a
TPM
or
some
other
some
other
component.
That
would
assert
itself
as
a
root
of
trust,
to
implement
any
claim.
I
think
that
the
reality
is
that,
because
there
is
such
a
large
installed
base
of
a
particular
type
of
root
of
trust
that
changing
an
installed
base
has
you
know,
challenges
you
can't
just
change.
H
Only
that
it
requires
this
signature
to
be
able
to
apply
to
the
claim
set
yeah,
because
this
is
the
trustworthy
function
on
the
system.
There's
something
no
no
signing
foulon
out
here.
Maybe
maybe
it
is
because
we
are
allowing
a
testing,
a
tested
environment
to
collapse,
but
still
there
should
be
indicated
as
a
level
of
assurance,
and
if
we
do
so,
it
has
to
highlight
that
not
every
Harvard
system
can
sign
arbitrary
data
that
some
evidence
is
bound
through
the
functions
that
they
are
deployed
with
today
and
in
the
NAND
year
world.
H
B
Okay,
so
I
have
I,
guess
two
questions,
then
one
is
from
the
tape
working
group.
We
have
hardware
vendors
working
together
there
with
their
starting
point,
is
the
open
trust
protocol.
They
have
handed
off
the
attestation
piece
for
us
within
that
a
call
knowing
that
hardware
would
have
to
be
updated.
Is
this
something
they're
planning
on.
E
E
Right,
the
only
thing
that
you
need
to
well
to
be
clear,
the
only
thing
that
you
need
the
hardware
to
be
updated
for
is
if
the
hardware
provides
some
of
the
information
that
goes
in
the
evidence.
Okay,
now
the
thing
that
they're
relying
party
consumes
right,
which
is
the
Tam
and
the
t
p--
case,
the
thing
that
the
relying
party
consumes.
Is
the
attestation
result?
What
goes
the
attestation
result?
E
They
have
no
impact
whatsoever
outside
what
the
hardware
says
says
in
the
evidence,
may
have
no
direct
and
may
or
may
not
have
any
direct
impact
on
the
literal
content
of
the
attestation
results.
Right.
That
depends
on
what
you
define
the
attestation
results
contain:
that's
what
the
Tam
actually
consumes.
Okay,.
B
Okay,
so
then
as
possible,
and
then
the
other
use
case
on
well,
I
guess:
there's
lots
of
excuses,
so
then
the
other
piece
where
you're
talking
about
systems
and
where
interoperability
might
be
important.
One
thing
that
I
personally
think
is
very
important
is
the
supply
chain,
where
you
have
software
modules
able
to
provide
an
attestation
on.
H
F
B
It's
it's
too
difficult
and
there's
there's
ways
to
do
it
depending
on
the
operating
system,
and
it's
got
to
be
managed
separately
right,
so
creating
something
that
can
be
managed
within
a
normal
IT
management
system.
For
the
enterprise
like
if
this
was
added
into
some
type
of
configuration
management
system
as
an
expected
piece
and
not
like
some
special
security
service,
then
we'll
be
doing
the
enterprise
as
a
favor
in
terms
of
being
able
to
provide
a
level
of
assurance
for
systems
that
they
know
what
they
expect
to
see
in
a
consistent
way.
Yeah.
F
C
C
C
B
I
H
B
H
I'm
not
sure
if
we
can
have
adoption
of
eat
as
indoors
as
a
sole
endorsement
document.
Again
it's
evidence
and
not
that
actually
but
but
you
can
use
it
for
the
format
you
can
use
for
that
I'm,
a
green
with
that.
There
has
to
be
a
lot
of
other
existing
things
for
like
20
years
to
to
be
taken
into
account
and
just
cutting
that
off
hard,
the
not
ease
adoption
it
will
be
probably
short
of
actualizing.
H
C
F
C
F
So
I've
sorted
out
the
the
open
issues
into
kind
of
three
categories:
there's
those
those
that
are
claims,
so
these
are
claims
that
are
not
defined
in
the
eat
document.
Some
of
them
are
easy
to
add.
Like
boots.
Eat
is
probably
easy
to
add.
Some
of
them
are
gonna
to
me
are
going
to
be
like
months
and
months
of
work
like
software
inventory,
software
inventory
see
really
important
to
me,
particularly
for
Erick's
use
cases
and
a
lot
of
things.
People
are
expecting
out
of
attestation.
F
So
what
I'm
kind
of
hoping
is
that
the
the
claims
are
the
clients
comput.
The
issues
that
are
listed
here
are
when
we
finish
all
these
issues.
We
finished
eat.
That's
not
what
I'm
trying
to
try
to
have
it
set
up
for
sewed.
So
if
there's
a
claim
that
you
want-
and
you
don't
see
it
listed
in
the
ate
document
or
in
the
issues
here,
please
say
something
in
you
know:
file
an
issue
or
something
like
that,
and
you
know
maybe
there's
some
some
claims
in
the
yang
document
that
are
not
represented
here.
F
That
would
be
that
would
be
cool
to
have
them
here.
Then
the
other
ones
are
issues
that
are
I've
marked
ready
to
close.
I
I
don't
know
what
we
have
in
terms
of
closure
policy
on
these
things.
A
lot
of
them
are
ready
to
close
because
of
the
assumption
that
they
were
going
to
go
in
the
architecture
document
that
seems
a
little
open-ended
today,
so
I'm,
probably
not
going
to
go
close
them.
F
For
that
reason,
and
then
the
other
ones,
the
that
don't
have
a
label
on
them,
are
issues
that
need
some
does
nominate
and
some
work.
Some
editing
I
have
not
sorted
them
out,
as
as
to
like
text,
editing
versus
engineering
design.
Some
of
them
are
just
text
editing.
Some
of
them
are
engineering
design.
F
So
I'm
going
to
point
out
the
Yui
ID
one
here.
Should
you
a
you
EITS
be
larger
than
128
fifths,
I'm
going
to
kind
of
racing
through
here.
There's
some
comments
back
and
forth.
I
have
a
pull
request
on
this.
Now,
with
some
analysis
of
it's
done,
the
birthday
attack
and
stuff
so
trying
to
get
that
to
drive
that
to
closure.
F
Anyway,
so
generally,
that's
the
you
know
where
I'm
trying
to
where
I'm
trying
to
go
with
the
issues
trying
to
balance
my
time
working
on
these
issues
and
keeping
them
organized
and
I'm
commenting
on
architecture
in
use
cases
but
I'm
trying
to
make
this
set
of
issues.
Be
you
know
once
we
once
we
cause
all
these
issues,
then
the
heat
documents
on
I'm
sure
there's
some
new
issues.
The.
C
Patent
is
is
for
focal
is
called.
Action
is
review
the
set
of
issues.
If
you
have
issues
you
want
to
add,
please
contribute
them
and
comment
on
the
on
the
on
the
ones
that
are
there
and,
at
some
point
it
makes
sense
for
the
for
the
working
group
to
consider
each
claim
and
approve
or
not
approve.
The
claims
that
are
there
is
that
yeah.
F
Yeah
yeah
and
particularly
I,
mean
I.
Think
the
biggest
one
of
the
biggest
actions
is
enough.
You
think
about
the
claims
that
are
necessary
for
use
cases
and
I'm
doing
this.
Do
it
but
think
about
the
claims
that
are
necessary
for
use
cases
and
see
if
those
claims
are
missing
in
in
a
document
or
in
the
issues
list.
So
we
kind
of
have
a
scope
of
how
many
claims
are
going
to
define
all
that.
Okay.
C
H
Yeah
this
is
Hank.
I
would
like
to
have
a
more
concise
proposal,
how
to
use
the
use
case
document
as
an
architecture
or
how
to
merge
them,
because
I
not
sure
this
mover
and
Christine's
proposal
is
some
little
bit
between
the
lines,
I
think
so
Kathleen.
Maybe
if
you
would
be
so
kind
and
propose
the
way
forward
that
you
are
envisioning
is
an
explicit
extension
to
your
first
email.
That
would
be
I,
think
something
the
list
can
reach
and
parse
better.
Would
that
be
okay,.