►
From YouTube: IETF113-RATS-20220322-0900
Description
RATS meeting session at IETF113
2022/03/22 0900
https://datatracker.ietf.org/meeting/113/proceedings/
G
A
B
C
Okay,
well
we're
gonna
get
started
so
welcome
to
rats
working
group
session
one
and
we're
gonna
we're
gonna
go
through
a
few
of
the
chair,
slides
to
be
to
get
started.
So
just
a
reminder.
The
in
terms
of
the
no
note
well
information
pilot.
I
have
policies
on
on
ip,
so
this
is
a
reminder
that
the
init
that
the
ietf
policies
are
in
effect
for
various
topics
such
as
patents,
code
of
conduct.
C
C
There's
some
meeting
tips
for
for
meeting
today,
if
you're,
an
in-person
participant,
make
sure
you
sign
in
the
session
using
the
media.
Echo
data
tracker
also
use
mediaco
to
join
the
mic
too,
keep
audio
and
video
off,
if
not
using
on-site
version
and
for
those
in
the
room.
Please
keep
your
mask
on
for
those
who
are
would
like
you
to
do
that.
Remote
participants
make
sure
that
your
audio
and
video
are
off
unless
you're,
sharing
or
presenting
during
a
session
and
use
of
the
headset
is
strongly
recommended.
C
A
A
So,
as
you
can
see,
and
if
you
flip
to
the
next
slide,
we
have
a
very
packed
agenda
for
today.
Hopefully
you
guys
have
seen
this
because
I
don't
know
that
we
have
a
lot
of
time,
we're
already
one
minute
over
in
our
our
time
slot
to
bash
it.
So
I'm
going
to
do
a
call
once
twice
no
changes,
let's
go
ahead
and
get
started
too
late.
A
H
A
C
A
I
We
are
just
about
at
a
pass
at
the
isg.
There
are
two
discusses
which
I
believe
are
minor
and
might
also
be
closed.
At
this
point,
we
think
we've
answered
all
the
comments
that
are
there,
so
we
need
one
more
vote
in
order
to
close
the
document.
Changes
that
have
occurred
during
the
isg
review
include
adding
a
appendix
describing
ima
doing
some
reference
changes
and
doing
some
xpath
syntax
tweaks.
I
I
We've
been
doing
this
mostly
because,
as
we
close
out,
chara
we
should
be
able
to
after
char
is
done
with
the
iesg
to
go
ahead
and
write
a
social
and
socialize
a
security
considerations
document
and
then
go
to
working
group
last
call.
It
really
is
not
a
big
document.
It
should
not
be
a
controversial
one,
but
since
we
have
a
dependency
on
chara,
we
are
sort
of
completing
that
work.
I
It's
broken
into
two
parts.
The
first
part
is
the
information
element,
definitions
for
attestation,
results
that
are
generated
by
verifier
to
support
interactions,
secure
interactions
between
a
tester
and
relying
party,
and
so
the
first
part
is
really
about
claims
effectively
claims
that
are
generated
for
secure
interaction,
support
between
two
devices.
I
Now,
there's
been
a
number
of
changes
since
itf
112
first
thing
is
working
group
adoption
and
thanks
everybody
for
chiming
in
and
providing
comments.
It
was
a
good
set
of
discussions
on
that.
We've
done
a
bit
of
text,
clarifications
on
the
values
of
specific
trustworthiness,
claims
and
trustworthiness.
Claims
are
types
of
attestation
results
again
that
are
generated
for
the
purpose
of
understanding
the
trustworthiness
of
one
device
for
another.
There's
also
been
mailing
list:
comparisons
with
the
eat,
security
level
and
mailing
list
comparisons
of
the
eat.
I
Software
results
we'll
have
one
slide
on
the
software
results,
but
again
we're
just
doing
a
quick
update.
Also,
we've
been
aligning
the
trusted
path.
Routing
document
we
have
a
new
author
there
because
of
the
the
additions
from
meling
ching
from
china
mobile.
So
we
are
continuing
to
percolate
that
draft,
but
we're
not
requesting
working
group
adoption
until
we
really
get
some
market
uptake.
I
There
are
at
least
some
people
that
are
testing
the
service
out,
but
there's
no
point
in
standardizing
it
until
we
have
some
more
general
adoption
to
make
sure
people
are
going
to
go
and
stay
with
the
same
type
of
deployment.
Next
slide
now
quick
highlight
on
trust,
reminisce
claims
and
trust
rhythmist
claims.
I
I
Other
thing
that
I'm
going
to
pull
out
and
we're
not
going
to
read
the
text
here.
There
are
a
number
of
design
principles
around
the
ar
and
in
this
case
the
ar
for
trustworthiness
claims,
and
these
are
important
as
well
for
when
you're
designing
attestation
results,
and
these
have
been
in
the
draft
for
about
a
year
or
so.
I
Making
sure
that
these
trustworthiness
claim
rules
are
hit,
makes
things
a
lot
easier
for
the
implementer
of
the
creation
of
the
attestation
results
and
their
digestion
by
a
policy
language
sitting
in
the
relying
party
policy
on
the
foreign
device
on
the
right
from
the
last
slide.
All
right
and
last
slide.
I
This
is
a
table
that
has
undergone
some
discussion
on
the
mailing
list
over
the
last
few
weeks,
and
that
is
the
comparison
of
the
intent
and
design
of
some
of
the
trustworthiness
claims
for
executables
and
file
system
and
some
of
the
claims
over
in
the
east
side
with
software
results,
which
I
think
might
be
getting
renamed
and
while
we
dive
into
it,
I
wanted
to
highlight
that
there
are
certain
things
that
we
want
to
make
sure
that
we
handle
when
we
look
at
the
various
specific
objects
that
we're
handling.
For
example.
I
These
things
are,
what
is
the
target,
that's
being
evaluated,
what
are
the
number
of
includable
states
and
how
understandable
are
they
and
how
complex
is
the
language
for
then
having
a
policy
on
the
target
device?
What
is
the
purpose
of
the
of
the
of
the
claim?
What
are
the
different
encodings
and
serialization?
I
That
is
needed,
so
I
don't
think
we
have
time
to
dive
into
this,
but
I
want
to
keep
this
in
the
back
pocket
to
understand
that
there
really
should
be
some
commonality
of
the
claim
designs,
as
we
try
to
figure
out
what
needs
to
be
encoded
for
passing
across
the
network,
particularly
when
we're
talking
about
writing
some
policy
language
on
the
relying
party
for
interpreting.
What's
going
to
be
coming
from
the
attestation
results
and
please
chime
in
on
the
mailing
list.
I
I
A
I
J
Yeah
correct
so
this
is
roman
jumping
in
since
I
I
got
invoked
yeah
eric
is
exactly
right.
I'm
in
contact
with
kind
of
rob
to
please
ask
him
to
to
re,
rob
rob
wilton
to
revisit
his
discuss,
because
I
believe
the
edits
that
the
team
put
out.
Thank
you.
Eric
do
address
the
do
address
the
feedback
and
the
ballot
turnover
will
happen
on
wednesday
at
the
at
the
plenary.
So
we're
all
pushing
to
get
things
cleared
as
fast
as
possible.
H
Hi,
I'm
hank,
I
have
been
have
been
told
by
the
list
to
present
my
name,
I'm
hank,
and
this
is
about
the
architecture,
so
michael
richardson,
most
mostly
did
all
of
this
content.
So
this
is
a
report
because
we
are
in
in
a
good
state.
The
tiny
little
letters
on
the
left
side
are
hiding
who's
contributing
in
the
last
half
year
and
longer
helping
us
getting
this
document
done.
H
There
are
some
little
star
asterisks
at
some
of
the
names.
These
are
the
editors
of
the
documents,
so
we
have
now
no
remaining
issues
185
in
total,
the
tuesday's
meetings
are
and
hiatus
at
the
moment,
and
we
have
addressed
literally
all
of
the
pull
requests
except
the
ones
after
my
editorial
cutoff.
So
we
will
not
touch
any
content
of
the
document
until
there
will
be
a
next
action
that
might
be,
I
don't
know
actually
so
next
slide,
which
is
what
is
happening
next,
that's
the
conclusion.
H
So
we
have
a
diff,
you
can
look
at
it.
We
added
a
few
things
at
the
end,
we
upgraded
the
references
and
our
state
is
a
very
limbo
state
of
being
submitted
to
isg,
which
can
mean
everything
I
assume
it's
not
dead,
and
so
I
don't
know
what's
happening
next
now,
so
we
will
not
edit
anything
at
that
document
at
the
moment
until
we
know
what
the
further
steps
are.
So
that
is
my
question
to
the
room.
What
are
we
doing
now.
A
H
J
K
J
J
Give
me
the
rest
of
the
week
and
I'm
sorry
the
rest
of
the
week
after
ietf
week,
and
I
should
have
it
because
I
think
that
my
early
review
dropped
all
the
comments
I
would
have
and
they
they
largely
appear
resolved.
I
just
need
to
double
check
and
then
we
can
go
to
ietf
less
call
and
trigger
their
direct
reviews.
So
the
action
is
with
me.
H
J
J
H
H
I'm
shocked
interesting.
That's
the
next
item.
Okay,
so
we
have.
We
have
a
daa
document
in
an
adopted
state
that
has
happened
due
to
the
split
from
the
interaction.
A
reference
interaction
model
document
daa
by
itself
seems
to
be
its
own
thing.
That
has
is
worth
worth
discussing
having
its
own
issue
tracking,
and
I
think
that's
fine.
So
now
we
recently
convinced
the
failure
to
be
a
co-editor
of
this,
and
now
we
have
a
few
next
steps
to
be
done.
So
I
don't
know
how
familiar
with
da.
H
So
then
you
can't
really
distinguish
one
a
tester
from
another,
so
that's
done
by
having
a
third
party,
it's
a
daa
issuer
and
that
might
be
very
similar
to
a
rat's,
endorser
and,
and
that
has
to
be
fleshed
out.
So
there
has
been
some
comments
on
the
list
and
some
comments
on
the
on
the
document
itself
that
we
have
a
strong
relationship
here.
We
haven't
addressed
those
yet
so
that
is
the
next
step.
H
One
next
step,
then
we
have
a
trusted
computing
group
concept
called
the
privacy
ca
privacy
would
also
be
literally
in
support
of
being
a
dia
issuer.
So
we
haven't
been
talking
about
that
in
the
text
right
now,
but
it's,
I
guess,
the
same
function
so
that
has
to
be
again
elaborated
on,
and
then
we
have
the
dice
concept,
the
composer
identifiers
from
tcg.
That's
using,
not
hardware,
root
of
trust,
about
the
existence
of
a
certificate
and
if
the
certificate
creation
chain
has
been
is
there.
H
So
if
you
with
an
existence
of
a
rule
of
trust
certificate
exists,
so
then,
then
you
can
can
imply
that
all
the
other
certificates
were
fine.
So
there's
a
the
trust
consumption
of
the
dust
chain
in
the
dice
concept
and
that
again
would
have
to
be
addressed
and
correlated
to
the
daa
issuer
flow.
That's
been
done
so
I
think
that's
been
done
outside
of
tc
of
our
atf
in
the
tcg.
But
again
the
document
doesn't
talk
about
that.
So
these
are
the
three
items.
H
H
That
would
really
benefit
from
this,
because
you
don't
really
know
that
that
exact
thing
was
wrong,
but
maybe
the
concept
of
your
whole
swamp
might
be
wrong,
and
so
so
that's
the
attestation,
our
scope,
that
we
are
targeting
here
for,
and
so
that
is
our
next
steps,
but
I
have
to
admit
that
we
haven't
prioritized
that
work
at
the
moment.
So
that's
just
a
status
report.
Any
questions
on
that.
L
H
H
L
H
N
That's
precisely,
this
is
the
envelope.
That's
precisely
to
understand
this,
because
this
is
new
to
me
and
I
wanted
to
so.
The
goal
is
about,
as
you
said,
to
not
necessarily
distinguish
among
many
similar
things
that
you
don't
care
or
is
about
because
looking
at
the
private
cca,
the
first
impression
you
get
is
that
what
you
want
is
to
protect
privacy
of
the
of
the
attester
for
whatever
the
reason
yeah.
Whatever.
H
If
I'm
talking
about,
I
want
to
say
some
cell
phone-
and
you
know
all
of
these-
are
kind
of
identical
and
we're
not
talking
about
the
sim
card
thing,
the
individual
part
but
the
rest
of
the
composite
device.
And
now
you
can
do
a
group
attestation
for
all
the
cell
phones
at
the
same
brand
for
scope.
Let's
say
it's
an
enterprise
yeah.
H
N
H
With
the
devices
nothing
to
do
with
privacy
in
the
on
the
other
hand,
exactly
the
devices
do
not
lose
their
individuality,
they
get
issued,
something
they
can
say,
but
I'm
of
this
group
that's
basically
the
role
of
the
issuer
and
that's
why
it
might
also
be
an
endorser,
because
endorser
is
very
similar
to
that.
So
there's
a
bit
of
some
discussion
how
to
generalize
it,
for
example,
for
it
yeah.
C
L
To
move
on,
that's
fine!
I
just
wanted
to
respond
to
thomas
d.a.a.
My
understanding
is
a
general
cryptographic
concept.
It's
not
bound
to
tpms,
for
example,
fido
supports
the
da
protocol
in
some
ways
and
there
are
a
lot
of
flavors
of
daa,
and
so
there's
a
it's
a
big
rich
space
and
it's
not
associated
with
tpm's
solely.
H
A
H
Sure
we
do
that
so
next
slide,
please
it's
an
action
model,
it's
cool,
so
yeah,
that's
where
we
split
the
dar
stuff
off
and
we've
already
heard
eric
talk
about
the
background
check
model
about
subscriptions
and
challenge
response.
So
the
yang
module
is
about
challenge
response.
The
subscription
model
is
about
apparently
something
else
again,
and
then
we
have
the
time-based
new
directional
models.
These
are
general
interaction
models,
how
you
convey
evidence
and,
to
some
extent,
always
could
apply
to
attestation
results
because
they
inherit
the
freshness
characteristics.
H
So
now
the
challenge,
the
chara,
the
challenge,
request,
response
attestation
and
the
subscription
and
the
time-based
ones
are
there,
but
in
the
architecture
of
rats
we
have
defined
the
background
check,
interaction
model,
which
is
a
composition
of
interactions
and
the
passport
model,
which
is
again
a
composition
of
interactions.
So
these
haven't
been
covered
by
the
interaction
models
id
yet.
H
But
there
is
a
a
project:
linux
foundation,
project
out
there,
that's
called
a
c2pa,
it's
a
coalition
of
content,
provenance
and
authenticity,
and-
and
they
want
to
implement
all
this,
so
they
switched
already
to
sieber
and
cddi,
and
they
really
they
really
wanted
to
have.
We
need
a
document
to
refer
to
these
specific
implementations,
specific
interaction,
combinations
here
for
the
models.
H
So
that's
why
we
pull
that
in
to
the
mercury
at
the
moment
and
eric,
for
example,
also
highlighted
the
ar
augmented
model,
which
is
again
a
combination
of
the
backpack
round,
check
model
and
the
passport
model.
So
so
that's
also
something
we
could
consider
to
put
in
here.
We
don't
know
where
the
demarcation
line
is,
but
I
think
we
won't
go
anything
beyond
that.
So,
but
that
is
what's
happening
right
now.
H
H
A
B
O
H
Oh
yeah
uccs,
so
uccs
by
name
hasn't
changed
but,
as
lawrence
is
probably
well
aware,
be
included
now
in
the
appendix
of
the
uss
id
a
option
to
accommodate
both
json
cbor
as
a
feature
with
cddi.
So
there
are
two
features
in
c
sorry:
it's
two
capabilities
of
the
cddi
expressiveness.
One
of
them
is
called
feature
and
another
one
is
called
a
generic.
H
So
by
selecting
a
feature
which
is
apparently
sieber
or
json,
you
can
now
switch
to
alternate
generics
that
would
allow
you
to
use
the
json
prelude
or
the
sibo
prelude
and
therefore
it
would
not
create
any
conflicts
with
any
c
detail.
Definition
whatsoever.
When
you
do
a
json
and
sibo
compliant
cdl
is
back
so
lawrence
took
note
of
that
and-
and
he
already
wanted
to
encompass
it
actually
does
incorporate
it
in
the
each
spec,
because
it
also
has
a
target
of
addressing
jason
and
sibo.
So
we
haven't
changed
the
name.
H
H
So
what
we're
doing
here
is
we're
introducing
the
concept
and
we
always
bundle
it
with
at
least
the
very
first
application
scenario
and
that's
rats.
So
I
think
it's
still
very
fine
to
have
this
in
reds,
because
we
can't
release
the
concept
into
the
wild
by
saying
and
then
you
have
to
do
a
threat
model,
and
this
is
just
how
you
do
it,
because
then
people
will
just
do
it
that
way
and
don't
have
to
write
down
their
security
implication
about
why
you're
doing
this
and
how
this
is
done.
H
H
They
have
to
serve
a
purpose
like
eat,
and
then
you
have
the
threat
model
and
the
security
consideration
about
that.
That's
what's
happening
in
this
id.
So
that's
why
it's
not
in
a
cwt
space.
That's
why
it
is
in
the
red
space,
but
in
general
to
be
honest,
the
core
of
it
can
apply
to
any
kind
of
cwt.
I
hope
that
makes
sense
to
you.
If
not
maybe
look
at
the
draft.
A
bigger
discussion
on
the
list.
A
H
L
L
So
here's
a
kind
of
a
status
of
the
the
blue
arrows
of
things
that
have
changed
in
the
dash
12
draft.
So
that's
where
work
was
done
and,
as
you
can
see,
most
of
everything
is
green,
which
means
it's
ready
for
last
call.
So
the
two
areas
that
are
still
need
some
work
just
in
terms
of
the
individual
claims
are,
you
know
measurements
and
results
basically
stuff
related
to
attestation
results
ar
next
slide.
L
The
hardware
version
claim
was
improved
and
then
the
ayanna
section
was
was
filled
in
to
some
degree.
The
main
purpose
of
the
the
dash
12
draft
was
actually
to
get
things
published
for
early
allocation,
which
that's
I'm
not
going
to
talk
about
that
today.
I
think
that's
just
administrative
at
this
point
next
slide.
L
L
L
That's
an
interesting
thing.
I
mean
the.
I
think
the
cddl
tool
is
a
little
bit
shaky
on
on
the
the
jason
parley.
So
I've
had
some
trouble
with
that
and
so
there's
there's
some
work.
That'll
that'll
be
in
the
dash
13
draft.
The
you
know
finishing
that
off
that
jc
generic
actually
is
making
the
cdl
a
lot
simpler.
So
it's
actually
helpful.
L
I
mean,
I
think
it's
we're
on
the
edge
here
in
terms
of
the
use
of
cvdl,
but
I
think
it's
a
good
direction
and
then
that
rearranging
the
sections
to
to
group
the
claims
better.
I
think
that's
a
good
one
that
that's
that's
basically
straightforward
work
next
next
slide,
so
here's
topics
that
I
think
we
need
consensus
on
still
so
there's
some
issue
about
the
relationship
between
eat
and
uccs
and
geary's.
Going
to
talk
about
that.
I
think
the
real
core
here
is:
is
there
a
normative
reference
or
not?
L
L
A
J
What
did
you
announce
the
the
really
great
news,
if
folks
weren't,
watching
the
mailing
list,
that
the
early
allocation
for
eats
are
now
approved
through
the
through
kind
of
the
the
normal
kind
of
processes?
So
at
this
point,
what
we
are
waiting
for
is
ayanna
to
just
perform
their
batch
administrative
action
to
get
those
claims
posted.
R
Q
Go
yep:
it's
it's
guy
for
darko!
Speaking
on
behalf
of
the
remote
integrity,
verification
draft!
Next,
please,
I
think
we're
doing
pretty
well
just
as
a
reminder.
The
objective
here
is
to
standardize
the
way
that
you
could
you
that
you
can
use
tpm
based
devices
to
do
remote
attestation,
that
is,
to
assess
the
the
the
integrity
of
the
software
and
of
the
device
that
you're
you're
trying
to
validate.
Q
Next,
please,
I
think
the
status
is
that
the
discuss
comments
I
think,
have
been
resolved.
There
are
a
couple
of
other
none,
as
I
understand
non-blocking
comments
which
require
resolution,
but
I
don't
think
those
are
hard
and
I
think
I
can
probably
get
them
done
even
perhaps
today
or
tomorrow
and
from
there.
I
think,
we're
on
to
the
rfc
editor.
As
I
understand
it,
next.
Q
A
A
A
A
A
Call
for
interest
to
see
if
there
was
interest
by
the
participants
in
this
working
group
if
they
wanted
to
extend
the
charter
and
if
they
liked
the
proposed
text,
and
so
there
was
a
lot
of
discussion
that
went
on
in
the
mail
list,
and
so
we
wanted
to
do
the
pulse
again
here.
I'm
trying
to
talk
as
much
well
while
ned
brings
up
the
text
to
see
if
there
were
any
other
remaining
issues,
vis-a-vis
the
revised
text
for
us
to
recharter
the
group.
A
J
A
A
S
S
B
U
A
C
H
H
I'm
okay
with
that
there
is
enough
text
in
the
charter.
That
says
sure
that
will
work,
and
I
don't
think
we
need
to
new
protocols
there.
I
just
want
to
say
that
protocols
that
can
convey
evidence
from
an
attester
to
a
verifier
could
in
theory,
also
be
used
for
that,
so
they
are
not.
They
are
not
literally
invented
for
that,
as
said
by
the
charter,
but
they
invented
for
the
other
thing.
So
this
is
like
a
weird
loophole:
how
you
could
invent
new
protocols
for
the
other
thing
you
know.
H
Okay-
and
I
also
understand
that
yes,
I
just
want
to
say
that
that,
for
example,
2da
is
a
protocol
for
a
test
of
the
verifier,
and
if
that
is
getting
standardized,
it's
a
protocol
and
then
you
can
apply
to
the
other
thing.
So
the
asymmetry
in
the
text
does
not
really
matter,
because
if
you
did
the
one
thing
you
can
do
it
for
the
other
thing
it
becomes
symmetric,
so
the
asymmetric
text
in
the
charter
does
not
serve
a
purpose.
G
Hi,
so
for
the
first
item
and
sorry,
I
didn't
get
this
to
the
list.
What's
the
gating
function
for
a
document
on
extensions
and
the
reason
I'm
asking
is
because
you'll
have
cases
where
you
have
to
register
things
into
registries
and
some
might
require,
might
require
a
document.
You
know
into
cozy
and.
G
V
V
You
know
alternate
protocols,
even
if
there's
already
a
standard,
one
that
exists
and
just
being
more
explicit
in
the
charter,
I
think,
would
be
useful
to
say
really.
The
burden
is
on
somebody
proposing
a
protocol
to
say
why
would
you
not
be
able
to
use
an
existing
one
right,
and
so
I'm
just
suggesting
some
wording
that
does
not
preclude
necessarily
new
protocols
but
at
least
raises
the
burden
of
of
of
proof
for
those
proposing
it
to
say.
V
H
So
yeah
hi
this
is
hank
dave.
Do
you
think
that
would
put
me
in
any
position
to
again
argue
why
tuda
has
a
valid
point?
If
so,
I
would
not
like
to
do
that,
but
if
you
think
it's
obvious
that
tudor
is
a
standalone
thing,
because
it
does
things
differently,
I'm
I'm
not.
I
don't
have
a
problem
with
it
and
just
just
as
an
individual,
because
I
don't
like
more
work.
V
I
guess
my
point
is
that
there's
a
couple
of
different
legs
in
the
architecture
document
like
a
protocol
between
a
a
tester
and
a
relying
party,
and
then
there
are
protocols
between,
say
a
verifier
and
one
of
the
other
two
and
protocols
between
the
attester
and
their
lying
party
might
be
pre-existing
that
you're,
adding
attestation
to,
and
so
the
goal
is
to,
whenever
possible,
put
attestation
into
existing
protocols
and
do
authentication
right
now.
But
your
legs
that
go
off
to
you
know
an
endorser
or
a
a
reference
value
provider
or
a
verifier.
V
You
know,
maybe
you
need
new
ones
that
might
be
using.
You
know
http
or
something
else
as
a
transport
and
those
might
be
okay,
but
trying
to
reuse,
say
a
test
you're
lying
party
protocols
for
the
horizontal
leg
and
the
diagrams.
I
think
it
should
be
a
strong
bias
there
and
so,
but
you
could
be
layering
things
on
top,
and
so
I
don't
have
a
specific
answer
to
your
question.
H
V
Well,
for
example,
in
the
in
the
passport
model,
it's
conveying
attestation
results
right
in
the
background
check,
it's
containing
evidence
and,
in
the
background
check,
of
course,
neither
of
the
it's
just
using
it
as
a
transport
right.
It's
it's
putting
evidence
over
the
top
of
whatever
that
protocol
is
not
that
the
relying
party
knows
that
it's
evidence
right,
it's
just
an
opaque
blob,
but
it
has
to
pass
off
to
verify.
I'm
on
your
background.
Yet
yeah.
H
M
M
P
P
Hi,
this
is
hannes.
What
I
hear
is-
and
I
haven't
followed
that
discussion
is
previously-
is
you
guys
want
to
restrict
what
is
being
standardized?
On
the
other
hand,
everyone
who
has
a
specific
favorite
protocol
wants
to
make
sure
that
the
dex
covers
what
they
are
have
in
mind,
which
is
kind
of
odd.
You
essentially
want
to
like
it
feels
like.
P
A
A
A
A
L
I'll
only
one
comment
yeah,
this
is
lawrence.
Most
of
my
comments
were
around
whether
or
not
eat
was
going
to
be
discouraged
as
an
attestation
results
protocol,
because
there
was
seemed
a
lot
of
consensus
around
that,
and
I
was
hoping
for
a
little
bit
of
an
adjustment
in
the
wording
to
be
clear
that
we're
not
excluding
eat
as
attestation
results
and
that
we're
we
have
an
expansive
or
basically,
we
have
an
expansive
view
of
attestation
results,
not
a
narrow
one.
So
so
that
was,
that
was
my
main
concern.
A
H
Yeah,
I
think
that's
what
this
is
saying.
I
think
there's
also
another
distortion
item
under
exactly
that.
The
next
session,
if
I'm
not
mistaken
about
the
attestation,
result
scope
and
such
so
that
would
tie
into
that
correct,
yes,
yeah,
so
so
I
will
postpone
that
that
that
content
discussion
and
then
we
can
bring
it
up
in
the
next
session.
H
A
A
Yeah,
well
I
mean
we're
gonna
have
to
confirm
things
on
the
mail
list
anyway.
So
please
I'm
strongly
requesting
that
you
guys
read
through
the
proposed
text.
I
will
do
another
call
for
support
for
the
rechartering
of
this
text
and
we'll
go
from
there
on
the
mail
list.
Okay,
reasonable,
okay!
Next
up,
I
believe
we're
going
through
milestones.
J
Hi,
yes,
I
want
to
just
kind
of
continue
on
with
the
discussion
that
you're
narrating
about.
What's
in
the
milestones,
I
will
say
I
have,
I
saw
there
were
some
pending
milestones.
I
approved
some
of
them.
I
did
not
release
kind
of
some
of
them,
so
that's
why
you
may
notice
that
things
are
in
a
halfway
state
based
on
the
edits,
we're
making,
and
I
think
it's
it's
all
informed
by
this
charter
conversation.
My
meta.
J
Would
be
as
we're
thinking
about
milestones
is
first,
of
course,
we'll
need
milestones
for
the
recharger
activity,
but
I
would
really
caution
the
working
group
to
make
sure
that
we're
pipelining
the
work
correctly,
that
we
actually
in
fact
have
enough
energy
to
kick
off
and
start
everything.
You
know
I
I
don't
want
to
say
at
the
same
time,
but
you
know
we
can
finish
kind
of
all
the
work
and
we're
not
in
a
situation
where
we
fan
out.
We
start
a
lot
of
things
and
we
lumber
we
lumber
slowly
toward
completion.
A
C
Yeah
so
in
most
cases
we
had
work
progress
without
updating
the
milestones,
so
the
recent
flurry
of
activity
is
essentially
to
go
back
and
provide
milestones
that
reflect
the
the
actual
status
of
the
various
drafts,
and
so
several
of
those
that
are
currently
in
every
direct
review
are
fit
into
that
bucket.
And
then
there
were
a
couple
of
milestones
that
were
submitted
that
were
in
anticipation
of
the
change
to
the
working
group
charter.
L
W
L
Okay,
I
don't
have
30
minutes
of
slides
or
30
minutes
of
talking
to
do
myself.
That's
for
sure,
mostly,
I
wanted
to
have
some
good
discussion
about
attestation.
Results
and
kind
of
some
of
the
framing
around
attestation
results.
What
we're
trying
to
achieve
here.
So
I
just
have
a
few
slides
to
kind
of
introduce
some
things
and
then
I
just
like
facilitate
some
discussion
to
try
to
back
and
forth.
It
seemed
like
it
was
a
little.
L
So
one
of
the
things
I
really
a
point
that
seems
really
important
to
me
is
that
attestation
results
are
for
a
full
range
of
security
strengths,
so
that
ranges
from
a
piece
of
hardware
that
is
designed.
It's
not
a
tpm.
It's
designed
just
to
provide
authenticated
a
tested
device
identity,
maybe
all
the
way
to
the
rp,
so
no
measurements,
no
software,
so
the
no
tpm.
So
I
think
that's
that's
a
use
case
and
I
think
we
want
to
be
accommodating
that
use
case
in
both
evidence
and
results.
L
Another
use
case
is
simple:
uncertified
software.
So
attestation,
like
is
built
into
an
android
app
like
a
fido
implementation
inside
an
android
app.
So
it's
all
software,
there's
no
tpm,
there's
no,
not
much
really
going
on
to
measure.
It
can't
really
measure
itself
so,
but
it
is
a
form
of
attestation
right.
We
see,
we
see,
implementations
like
that.
You
know
fido
so
and
then
there's
everything
between
which
is
kind
of
where
we're
spending
a
lot
of
our
time.
L
So
system
architectures,
so
I
think
we
need
to
think
about
attestation
results
for
a
full
set
of
system,
architectures
so
again,
purpose-built
hardware
that
just
does
attestation
there's
no
software
in
it
at
all.
It's
not
and
it's
not
a
tpm
again
app-based,
so
the
attestation
is
implemented
in
java
or
swift
or
python,
or
something
like
that.
L
L
H
L
L
H
Let's
know
so,
if
evidence
becomes
stay
at
the
station
results
become
stale,
there
come
somehow
a
ghostly
entangles
right.
You
don't
know,
apparently,
because
the
the
the
technology
around
that
you
know
that
the
nationalization
result
is
stale
depends
on
the
somehow,
knowing
that
the
evidence
becomes
stable.
Now
evidence
not
known
to
you
and
mostly
so
that
that's
in
general,
the
the
challenge
of
rats
so
now
you're
saying
that
everything
that
produces
evidence
can
relate
to
attestation
results.
H
And
now
what
I
would
like
to
highlight
is
that
the
testing
environments
in
the
testers
create
evidence,
that's
a
first
and
then
the
testing
environments
can't
just
be
signing
fools.
I
think
that's
obvious
right,
yeah
yeah!
So
so,
but
if
you
say
everything
can
be
in
a
testing
environment
by
saying
everything
is
in
a
tester,
it
can
be
a
signing
fool.
I
think
that's
a
contradiction.
L
A
L
I'm
when
I
say
go
back
to
if
you
go
back
a
slide,
please
when
I
say
system
architectures
and
security
levels,
I
didn't
say
that
these
were
signing
fools
or
attesting
fools.
I
just
said
you
can
implement
them
in
all
these
different
ways.
It's
this
is
just
implementation
and
you
know
sorting
out
who's
the
fool
and
who's,
not
the
full.
L
That's
really
the
job
of
the
verifier
right,
and
so
some
and
I
mean
you
could
be
a
verifying
fool
too,
but
but
assuming
we
don't
have
verifying
pools,
it's
the
job
of
the
verifier
to
say
what
it
is
and-
and
they
may
say
like
okay,
this
this
attestation
came
from
a
python.
You
know
on
a
something
or
other,
and
I
it's
not
very
good,
and
then
you
can
use
it
if
you
want,
but
it's
not
very
good,
and
so
that's
that's
what
I'd
say
all
right.
Okay,
thank
you.
Hank
says
thumbs
up.
I
One
yeah
adding
one
thing
to
the
discussion
that
relates
to
the
previous
discussion:
it's
important
to
remember
that
you
can
sign
stuff
and
be
sending
it
to
or
lying
party
the
physical
device
and
that's
okay.
Dave
taylor
really
did
a
good
job
of
educating
the
our
forza
people
that
the
relying
party
also
has
a
verifier
in
most
cases
because
it
has
to
interpret
the
evidence
as
well
on
the
passport
model
is
something
that
was
evaluated
before
so
just
because
something
sent
to
our
lying
party
does
not
make
it
at
the
station
results.
I
P
Hi
this
honest,
I
think
both
eric
and
hank
responded
to
the
slide
in
a
way
that
was
completely
unrelated
to
what's
on
the
slide
so
which
is
which
with
great
points.
But
but
if,
in
my
discussions,
which
are
unrelated
to
rats
with
the
various
people,
there's
always
an
attempt
to
make
a
judgment
about
the
security
of
a
system
that
they
are
describing
and,
interestingly,
it
shows
up
actually
very
nicely
in
these
and
these
different
categories.
P
And
there
is
often
for
many
people
like
there's
an
assumption
on
what
they
consider
the
threshold
to
be
what
the
minimum
buy
is.
And,
of
course
there
are
some
preferences
and
biases
that
go
along
with
it.
And
I
think
I
hear
you
learn
saying
that
you
have
these
different
models
but
you're
not
trying
to
make
a
judgment
of
whether
that's
good
or
not.
P
Right
and-
and
I
think
that's
probably
the
right
way-
sort
of
like
leave
that
policy
decision
out
there
and
let
someone
decide
but
be
aware
that
there
is
obviously
a
spectrum
and
those
deploying
the
solution
need
to
make
a
decision
about
what
they
consider
useful
and
what
which
one
not
and
it
it.
I
think
it
also
then
boils
down
to
in
in
context
of
rad,
not
just
about
like
judging
the
overall
results,
but
actually
individual
values
within
inside
of
a
claim
as
well.
P
So,
for
example,
you
take
a
a
security
level
claim
sort
of
a
lifestyle
life
cycle
state
claim.
So
typically,
if
you
have
some
hardware
id
in
there,
there's
a
life
cycle
state
associated
with
it,
but
if
it's
in
certain
states
any
information
for
example,
if
it's
in
a
debug
state
you
can,
you
can
have
a
perfectly
secure
solution,
but
you
can
then
switch
it
into
a
debug
state,
different
forms
of
debug
state.
P
We
put
the
bar
on
like
I
personally,
I'm
not
too
happy
about
level
this.
That
level
two
part,
and
I
have
a
different
perspective
on
level
one
of
course,
but
I'm
sure
everyone
in
the
room
is
different,
so
I
don't
know
how
you
best
want
to
convey
that
so
that
people
in
in
future,
discussions
who
are
not
part
of
the
group
or
iedf
in
general
will
then
not
stumble
over
the
same
issue.
L
Yeah
I'd
like
to
respond
to
a
couple
of
things
there:
okay
and
then
the
next
thing,
the
q.
So
I
spent
a
lot
of
years
started
out
as
a
software
guy
and
then
I
got
a
job
doing
some
hardware
and
it
really
opened
my
eyes
about
like
what's
what's
going
on
in
terms
of
hardware,
I
mean
to
me,
hardware
was
just
a
cpu.
L
You
just
ran
stuff
on
then
I
started
understanding
what's
really
going
in
the
hardware
and
how
variable
it
is
and
how
you
attack
hardware
and
all
sorts
of
stuff
like
that,
then
I
spent
a
couple
years:
designing
certification
levels
for
fido
and
that
really
deepened
my
knowledge.
You
know
understanding
common
criteria
and
how
people,
you
know,
actually
evaluate
hardware
security,
so
I
mean
so
you
know
15
years
ago
I
would
have
been
like.
I
don't
really
understand
this
hardware
stuff
and
it's
just
like
it's.
We
just
need
to
do
a
good
job.
L
Now
I
see
security
as
very
as
a
huge
sliding
scale
from
a
whole
bunch
of
over
a
whole
range,
and
my
main
point
here.
The
thing
I'm
really
after
is
that
we
can't
narrow
in
on
one
security
level
in
rats.
We
should
not
do
that
all
the
protocols
I
mean.
If
you
want
to
design
a
specific
protocol
for
a
thing,
then
it
then
that's
fine,
design
it
and
call
it
out,
as
this
is
just
for
this
security
level
or
just
it's
not
a
universal
solution,
but
rats
should
be
designing
for
universal
security.
L
A
M
A
You're
never
going
to
be
able
to
please
everybody,
yes
and
every
design.
So
I
think
as
a
goal.
That's
laudable
right,
but
I
think
some
of
the
work
that
you've
seen
have
been
very
specific
to
some
hardware
platforms
or
architectures,
and
we
made
sure
that
you
know
I'm
speaking
to
the
child,
one
which
is
more
tpm
specific.
As
an
example,
that's
fine.
L
I
mean
I
I
don't
I
I
know
it's
hard.
I
don't
think
we
should
just
give
up,
because
we
can't
you
know
on
the
get-go
I
mean
I
think
eat
is
doing
okay
at
this
full
range,
so
I
think
there's
some
possibility
there
and
I
just
went
up
and
we're
recognizing
char
as
tpm
specific
the
question
the
real
question
for
me
is:
is
where
does
ar-4si
fit
in
this?
Is
it
universal
yeah
for
all
the
levels
or
is
it
narrow
to
a
specific
one?
I
want.
H
H
So
so
you
should
let
someone
that
decided.
That's
good
or
bad.
That's
what
you
said
right.
That's
a
verifier!
That's
a
policy
on
there
right,
so
it's
defined
who
and
what
and
when
will
decide
this
in
the
architecture.
I
think
that's
very
important
to
sound,
because
when
you
said
it
was
like
some
miracle
occurs,
but
no
the
architecture
really
decides
this
and
the
very
fair
decisions,
and
that's
why
this
is
defined
through
attaching
results,
and
I
think
this
is
to
be
discussed
right
here
right
now,
so
yeah.
P
This
is
honest
again,
so
the
architecture
is
a
very
abstract
thing.
Of
course,
in
the
end,
it's
people
need
to
decide.
That's
what
I'm
trying
to
get
to
like
people
need
to
make
some
decisions
on
what
they
find
acceptable
and
what's
not
okay,
but
those
are
the
people
later
who
deploy.
The
technology
is
different
from
us
here.
P
A
P
A
P
P
L
H
H
H
A
H
And
that
it-
and
that
is
the
better-
the
miracle
occurs
that
that
hana
said
because
some
people
define
something
we
don't
express,
how
but
it's
enforced
by
a
single
role
in
the
architecture
that
is
very,
very
defined
and
not
ambiguous
and
not
abstract,
and
that
is
a
verifier
and
if
you
are
contesting
that
that,
I
think
has
to
be
very
spelled
out,
because
the
architecture
is
done
at
the
moment.
If
you
didn't
agree
with
this
in
the
last
five
years,
that
is
a
little
bit
curious.
So.
L
Here's
my
example:
I'm
clearing
a
I'm,
a
bank
clearing
a
100,
000
transaction.
I
want
it
to
be
done
with
something:
that's
common
criteria:
certified
I'm
a
bank
clearing
a
50
cent
transaction.
I
really
don't
care
if
it's
an
android
app.
So
as
the
relying
party,
the
bank
in
this
case
is
deciding
something
about
security
level
and
they're
deciding
it
in
the
context
of
the
transaction.
L
So
the
verifier,
I
don't
see
the
verifier
as
doing
things
like
deciding
whether
a
transaction
is
good
because
we
don't
want
the
verifier
involved
in
the
transaction
amounts
or
who
the
people
are
or
what
country
they're
in
or
anything
like
that.
The
verifier
is
about
verifying
the
the
hardware
and
the
software
and
the
device,
it's
not
about
application
specific
stuff.
L
So
I
think
we
will
have
verifiers
that
are
just
about
sorting
out
android
apps
one
android
app
from
another,
and
we
will
have
verifiers
that
are
about
sorting
out
secure
elements
one
from
another.
We
will
have
verifiers
that
can
sort
out
android
apps
from
that.
So
the
verifier
has
a
role,
a
big
role,
a
super
important
role,
a
critical
role,
but
so
does
the
relying
party.
L
A
L
K
K
Now
that
to
me
looks
like
two
separate
roles,
one
relying
party
and
one
verifier,
but
I
have
finally
got
it
through
my
head
that
this
is
in
fact
three
entities.
You
have
two
verifiers
and
a
relying
party,
so
what
you
have
is
a
verifier
who
says
yes,
this
result
is
trustworthy,
a
separate
verifier
that
says
yes.
Indeed,
this
is
the
version
of
firmware
that
it
should
be
running.
And
finally,
you
have
the
relying
party
that
says:
okay,
both
of
these
guys
said
it's
okay.
So
now
I
believe
you
mm-hmm
yeah
good
sounds
good.
K
I
I
want
to
violently
agree
with
brendan
and
and
lawrence
we've
had
this
discussion.
Please
listen
and
I'm
saying
this
respectfully,
because
dave
thaler
did
educate
us
before
during
the
architecture
that
the
verifier
is
embedded
in
the
relying
party.
It's
a
actually
not
something
pretty
about
the
architecture,
but
you
have
to
talk
about
attestation
results
as
coming
to
our
lying
party,
even
if
they're
co-resident
it
is
not
at
the
station
results
just
because
it's
sent
over
to
the
same
physical
device.
It's
the
relying
party.
N
N
We
ended
up
talking
about
something
I
mean
the
different
usages
of
the
of
the
identities
and
the
quality
of
the
attributes
and
the
sources
of
these
attributes
etc,
and
people
ended
up
with
the
concept
of
a
level
of
assurance.
That
is
what
you
want
to
verify,
depending
on
the
transaction,
whether
we
are
talking
about
one
hundred
thousand
dollars,
or
we
are
talking
about
two
cents,
just
a
suggestion.
P
Yeah
similar
to
lawrence
and-
and
I
think
eric
also
repeated
that
as
well
as
brendan,
I
think
we,
despite
the
initial
differences,
I
think
we
actually
talked
about
the
same
stuff
and
have
the
same
view.
I've
witnessed
the
same
debates
in
fido
with
regards
to
these
sort
of
like
multi-stage
decision
making
processes.
P
And
that's
and
maybe
maybe
it
is
but
but
maybe
that's
what
the
area
where
the
disconnect
is
and
there's
the
idealization
that
there's
one
single
body
to
verify
somewhere
totally
separate
from
the
others
that
making
the
decision
and
then
there's
the
relying
party
who
just
eats
whatever
it's
getting
being
served.
And
what
I
hear
is
it's
actually
more
nuanced
than
that.
A
R
L
R
H
A
L
I
mean
I
I
would
say
when,
for
me
relying
poly
po
relying
party
policy
takes
into
account
the
application
the
domain
specific
stuff
like
is
this.
Am
I
letting
this
thing
on
the
network?
What's
the
transaction
map
is,
am
I
verifying
a
fingerprint
or
something
like
that?
The
the
verifier
policy
is
all
about
device,
integrity
and
device
trustworthiness.
So
that's
where
I
mean
that's
where
how
I
pull
them
apart,
you
know,
one
is
one,
is
application
specific
and
one
is
really
the
the
domain
of
verifying
the
device.
L
So
this
is,
I
wanted
to
make
this
comment.
I
mean
I
think
I
mean
at
least
the
way
I've
been
thinking
about.
The
interaction
between
the
verifier
and
the
relying
party
is,
it's
mostly
a
sort
of
a
back-end,
b2b
kind
of
interaction,
and
I
think
maybe
some
of
you
don't
have
have
some
other
ideas
about
that,
but
if
it
is
basically
or
at
least
in
the
in
the
I
think
the
b2b
use
case
is
a
big
one.
L
It's
one
that
needs
to
be
addressed
that
we
need
to
really
be
cognizant
of.
So
in
that
case
I
would
say
my
understanding
is,
you
know.
Json
plus
tls
is
what
everybody
does
for
b2b.
So
in
terms
of
that
interaction,
we
should
just
go
with
that
and
let
the
the
the
it
guys
have
been
doing
that
stuff
for
a
long
time
just
handle
that
that
kind
of
thing.
L
So
we
don't
don't
need
to
worry
too
much
about
the
security
of
that
and
but
I'm
not
I'm
not
trying
to
say
we
have
to
write
a
standard
for
this
or
go
into
a
lot
of
detail.
I
just
want
to
be,
I
think
you
know.
In
fact,
I
guess
what
I'm
saying
we
probably
shouldn't
write
a
standard
for
too
much
of
this
next
slide.
L
Okay,
I
don't
think
we're
going
to
have
much
time
to
get
into
identity
here.
I
don't
think,
but
I
think
there's
some
some
discussion.
I
don't
think
we
have
enough
time
to
complete
this,
but
I'll
say
a
few
things
here,
I'm
starting
my
my
my
understanding
of
device
and
identity.
I
don't
think
we
have
a
definition
of
it.
L
What
was
in
the
original
eat
draft
eight
zero
zero,
as
adopted
by
this
working
group
that
eat
draft
there
was
no
verifier
in
there
all
the
claims
went
to
the
relying
party
that
was
the
conception
and
that
was
adopted
by
this
working
group
in
that
form.
Before
the
separation
was
really
set
there,
so.
L
P
What,
if
you
replace
it
by
identifier,
then
you
see
that
there
are
different
communities
or
different
industries
have
different
ways
to
identify
things
they
care
about.
The
cellular
industry
has
other
identifiers
that
they
care
about
on
that's
on
a
device
that
has
a
sim
card
versus
someone
who
has
an
enterprise
equipment,
and
so
that's
why
it
has
been
impossible
so
far
to
come
up
with
a
fixed
number
or
small
set
of
identifier
types
to
have
a
good
way
to
identify
these
different
components
that
people
care
about.
P
L
L
L
H
H
We
provide
an
extensive
list
of
identifiers
to
identify
the
testing
environment,
explaining
it
to
the
verifier,
because
it's
a
reference
integrity
manifest
it's
like
the
endorsement
and
stuff
and
the
reference
values,
and
you
have
to
understand
what
a
testing
environment
is
actually
supposed
to
give
you
evidence
evidence
about
which
target
environment
that's
very
important
for
the
appraiser
process,
because
if
something
else
is
doing
that
it
might
be
the
wrong
source.
So,
as
a
verifier,
you
have
to
understand
which
thing
in
the
thing
is
giving
you
the
assertions.
M
H
It
so
that
that's
what
column
is
effectively
all
about.
That's
why
the
extensible
list
of
methods
how
to
identify
a
a
testing
environment
and
like
a
multiple
of
them
in
an
attached.
I
think
that
actually
is
the
identifier
thing
from
so.
So
that's
that's.
The
first
thing
I
want
to
say,
and
also
I
want
to
hijack
this
time
to
come
back
to
the
multiple
verifier
thing.
H
L
C
L
Back
there,
but
I
think
there
should
be
some
discussion
back
and
forth
between
you
know
on
on
identity.
In
particularly,
I
mean
you
know,
if
you
can't
use
ueid
for
your
your
identification
use
case,
then
let's
talk
about
why
and
what's
wrong
with
it
that
the
specific
comments
on
that
I
would.
I
would
really
appreciate
that.
Okay.
P
L
P
L
L
L
Oh
okay,
so
I'm
probably
running
out
of
time.
So
there
is
text
in
a
pull
request
that
I
mentioned
on
the
mailing
list.
I'm
now
calling
them
sort
of
verified
forwarded
claims,
rather
than
pass
through
to
clarify
that
you
can
take
a
claim
that
came
from
the
attester
forward.
It
to
the
the
verifier
can
take
the
claim
that
came
from
the
attester
and
forward
it
to
the
relying
party.
But
that
is
subject
to
the
policy
of
the
verifier
and
the
relying
party
needs
to
know
what
that
policy
is.
L
L
L
So
this
maybe
is
still
kind
of
a
question
of
what
what
verifier
does
what
and
how
you'd
think
about
it.
But
I
mean
it's
to
me:
there's
some
some
verifiers
verifiers
are
about
not
about
are
not
application,
specific
they're
about
the
device,
some
verifiers
say
the
devices
are
good
or
bad
and
very
in
a
very
simple
way.
You
know
thumbs
up
thumbs
down.
L
So
you
know
they
could
be
very
complicated
things
that
they
don't
want
to
know
to
know
that
they
have
the
job
of
verifying
all
the
details
about
the
devices.
So
what
they
want
is
the
rats
verifier
to
provide
them
a
lot
of
validated
information
about
the
device,
but
not
transaction
specific
information
about
the
device.
So
I
I
see
the
range
here
of
in
antistation
results
is
from
very
simple.
L
L
A
L
L
L
L
No,
so
so,
maybe
maybe
maybe
we
could
have
a
little
more
discussion
about
what
happens.
I
mean
to
me.
The
big
conceptual
thing
here
is
that
it's
emerging
is
that
a
verifier
when,
in
the
rats
context,
its
job
is
to
to
do
things
that
have
to
do
with
device
integrity,
authenticity,
measurements
characteristics
about
the
device,
because
rats
is
an
attestation,
is
about
the
device.
L
So
a
rat's
verifier
is
about
the
device
it
doesn't.
The
relying
party
implements
their
policy
and
that's
when
they
bring
into
the
the
application
specific
thing
like
what
you,
what
are
you
trying
to
do?
What's
the
device
trying
to
do
play
content,
you
know,
give
you
a
measurement
that
you're
going
to
look
at
clear,
a
financial
transactions.
So
that's
the
relying
party
policy,
so
that's
really
where
I
pull
apart.
U
Yeah
on
the
subject
of
pass
through
claims-
I
you
know,
I'm
speaking
selfishly
as
a
neat
editor,
and
I
really
don't
want
to
see
us
getting
bogged
down
in
how
a
verifier
would
actually
interpret
a
claim
that
that
is
presented
as
evidence
before
it.
It
can
be
sent
as
a
as
an
attestation
in
the
document
I
think
lawrence's.
I
actually
covered
it
pretty
well
on
that
last
slide.
U
There's
just
two
there's
a
there's,
a
large
gamut
of
what
would
be
required,
particularly
multi-stage
verifiers,
for
for
how
a
verifier
would
interpret
evidence
against
an
appraisal
policy
before
relaying
it
as
a
pass-through
claim.
The
other
thing,
too,
is
when
we,
when
this
discussion
started
in
the
working
group.
I
looked
at
the
rib
document,
which
I
figured
was
the
working
group.
U
H
So
this
is
hank,
so
what
I
heard
is
are
two
items
here.
That
would
be
basically
addressing
the
overall
thing
you
can.
You
could
argue
that
the
verifier
has
a
policy
that
allows
to
take
evidence,
values
and
their
claim
semantics
and
put
them
into
attestation
results,
but
the
relaying
party
should
be
very
well
aware
that
this
policy
exists
and
it
was
applied,
and
then
the
second
thing
I
heard
was
it's:
it's.
It's
actually
totally
fine
with
the
architecture
to
have
multiple
verifier
roles.
H
One
of
them
is
co-residing
on
the
relying
party,
so
it
can
actually
receive
evidence
without
any
confusion
and
had
a
further
ado
and
do
the
appraisal
process
of
evidence
on
the
underlying
parting
entity
and
then
pass
it
through
the
relying
party
role.
That's
co-existing
on
the
relying
party.
I
think
that
is
more
clear,
because
now,
with
this
solution,
the
entity
that
is
the
relying
party
could
also
consume
reference
values
and
endorsements
which
a
relying
party
cannot,
and
so
I
think,
the
idea
that
I
think
hannes
was
again
going
to
that.
H
We
can
have
fire
nuances
on
whether
multi-verifier
things
happens
is
the
better
solution.
Because
then
evidence
can
be
passed
on,
that's
unambiguous
and
and
and
at
the
end
the
relying
party
makes
sense
of
it
and
it's
entity
that
it
is
so
so
I
think
significant,
smaller,
leading
towards
the
multiple
verifier
thing,
except
instead
of
the
policy
that
is
re-kind
of
purposing
the
values
without
and
then
you
have
to
understand
it
and
might
not
be
clear,
but
that's
just
me
for
now.
This
is
a
discussion.
So,
let's,
let's
do
this
discussion?
Okay,.
A
I
V
Yep
dave
taylor.
I
just
want
to
say
first
of
all
that
I
really
liked
lawrence's
description
of
a
bunch
of
the
topics
there.
So
thank
you
lawrence,
for
example,
the
pass-through
slide.
I
really
like
that
way
of
framing
stuff
so
nicely
done.
I
guess
my
question
is:
is
the
term
passed
through
in
any
document
I
couldn't
find
it
neither
eat
or
or
ar
4si
or
anything,
it's
a
useful
word
to
use,
because
I
think
that's
the
term
that
I'd
like
to
update
the
teak
protocol
spec
to
be
or
keep
architecture.