►
From YouTube: IETF113-RATS-20220323-1200
Description
RATS meeting session at IETF113
2022/03/23 1200
https://datatracker.ietf.org/meeting/113/proceedings/
B
Hopefully,
just
a
little
bit
too
fun
of
an
evening
as
opposed
to
more
people
down.
E
A
A
A
A
G
A
Awesome
yeah:
we
we
got
a
big
room
today
so
with
that,
let's
just
go
ahead
and
get
started
because
people
will
just
start
struggling
in.
I
Okay,
so
in
case
you
weren't
aware
this
is
session,
number
two
for
rats
and
we're
going
to
just
go
through
some
of
the
slides,
so
there's
the
notewell
information.
Everybody
should
be
familiar
with
that.
I
And
then
there's
you
know,
pointers
to
the
various
information
and
materials
for
the
meeting
that
are
also
in
the
chair,
slides
and
we
should
be
familiar
with
the
code
of
conduct,
so
we're
going
to
move
along
it
to
the
agenda,
which
is
here
so
so
our
our
first
topic
is
going
to
be
uccs
and
ujcs
for
eat
and
jerry
is
going
to
be
presenting
that
so.
A
Well,
we,
let's
make
sure
so
this
is
the
agenda
bash.
So
hopefully,
let's
just
do
a
quick
check.
Everybody
by
now
should
have
looked
at
the
agenda.
You're,
okay,
going
once
going
twice
so
with
that
we
can
move
forward
and
and
head
to
the
first
topic
so
so
giddy
in
the
interest
of
time.
Did
you
want
to
run
this
slide
since
you
haven't?
I.
A
Giddy,
do
you
have
a
preference?
Ned
is
ready
to
run
the
slides.
E
Yeah
he
can
run
the
slides.
I
can't
take
notes
today
because
I'm
presenting
so
I
hope
you.
A
Yeah
so
thomas
has
graciously
volunteered
would
prefer
to
have
a
a
second
one
or
or
multiple.
So
if
those
ned
are
hanging
out.
A
E
Thanks
so
there
is
so
justin
by
the
way,
even
though
I'm
presenting
this
is
on
behalf
of
the
eats
editors
myself,
jeremy
lawrence.
So
as
most
people
know,
there
are
two
standards
track
working
group
documents
for
attestation,
tokens
and
rats.
One
is
geet
and
the
other
is
the
uccs
specification
which
hank
went
over
from
the
status
yesterday.
That
stands
for
unsigned
seaboard
claim
set,
and
our
goal,
particularly
as
we're
trying
to
drive,
beats
towards
completion,
is
to
establish
a
relationship
between
these
documents.
E
And
as
hank
went
over
yesterday,
there's
an
assumption,
even
though
the
document
is
titled
uccs
that
unsigned
json
claimsets
are
also
also
should
be
supported.
So
just
for
the
purposes
of
this
presentation,
when
I
use
uccs
it
covers
both
unsigned
c-more
and
unselling
json.
E
So
a
couple
of
premises
here
first
is
uccs
is
scope
data
station?
It's
not
a
generic
method
to
send
unsigned
cwt
claims
arbitrarily
the
use.
The
current
uccs
draft
makes
it
very
clear
about
this
limitation
and
I'm
not
going
to
read
that
read
that
text.
I
think
everybody
can
see
that,
but
I
think,
moreover,
this
is
a
working
group
document
and
therefore
is
actually
scoped
according
to
the
current
rats
charter.
E
So
that's
one
premise:
the
second
premise:
if
we
go
to
the
next
slide.
E
Uccs
does
not
always
require
a
mutually
authenticated,
secure
transport.
Now
the
front
matter
of
uccs
document
does
state
the
benefits
of
a
mutually
secure
channel,
but
but
but
this
is
actually
more
of
a
security
consideration,
but
but
in
the
opinion
of
the
editors
it
should
not
be
a
normative
requirement.
E
E
So
I
give
an
example
there
where
uccs
may
be
acceptable
in
a
one-way,
authenticated
tls
session
as
an
example
and
obviously
in
the
web
today,
to
one
way
authenticated
tls
is
is
is
quite
common.
E
So
eat
is
the
rat
standards
track
for
conveying
a
standard
track
method
for
conveying
attestation
methods,
evidence
and
as
per
this
occur
as
for
the
as
per
the
current
and
what
has
been
documented
and
has
been
there
for
yes,
probably
a
year,
maybe
even
more,
each
can
take
three
forms,
one
as
a
as
a
cwt
jwt
or
as
the
uccs.
E
E
Eat
is
silent
on
normative
requirements
for
underlying
transport,
as
I
mentioned,
but
there
are,
there
is
a
security
consideration
section.
This
is
you
know,
heat
is
general
purpose,
not
a
not
all
heat
transports
can
it
can
be
guaranteed
to
be
through
a
mutually
authenticated,
secure
tunnel.
I've
worked,
you
know,
I'm
working
personally
on
bluetooth,
implementations,
for
instance,
and
that
would
be
a
prime
example
where
mutual
mutual
authentication
is
not.
It
is
not
always
feasible,
at
least
not
in
the
way
that
you
expect
with
the
ttos
or
dtls
connection.
E
The
other
thing,
too,
that
the
editors
will
concede
is
that
the
e
document
itself
can't
pro
will
probably
not
do
justice
to
all
the
security
sector.
Considerations
around
transport
of
unsigned
claim
sets,
and
not
even
just
transport,
but
when
it
actually
makes
sense
to
use
on
to
use
on
clients,
unsigned
claim
sets
and
when
it
doesn't,
and
it's
our
opinion
as
the
editors
that
that
actually
would
be
better
covered
in
a
different
in
a
different,
dedicated
draft.
K
K
K
There
is
actually
a
sentence
in
the
uccs
document
right
now
that
only
mentions
evidence
and
that's
why
I
bring
it
up
because
if
there
exists
any
use
cases
for
eat
in
for
attestation
results
where
uccs
might
make
sense,
then
we
might
want
a
word
smith
to
that
one
sentence
and
that's
in
the
uccs
document
right
now,
but
I
don't
know
if
there's
any
use
cases
for
uccs
with
attestation
results.
Yeah.
E
Relationships
between
a
verifier
and
a
relying
party
once
again,
it's
kind
of
dependent
on
what
the
I
want.
The
security
considerations
are
in
that
in
that
kind
of
setup
it
could
be
that
what
we're
considering
mutual
mutual
authentication
could
be
handled
if
something
different
from
the
transport
layer,
for
instance,
one-way
tls,
I
mentioned,
plus
maybe
an.
E
K
Okay,
so
yeah,
if
we
think
there
could
be
some
case,
there's
just
one
sentence
in
the
introduction
which
says
that
it
discusses
conditions
for
its.
You
know:
ucs,
proper
use
in
the
scope
of
rats
and
the
conveyance
of
evidence
from
a
tester
to
a
verifier,
and
we
might
want
to
amend
that
as
to
make
it
either
have
two
examples
or
just
make
that
be,
for
example,
to
not
overly
constrain
it,
because
I
think
all
the
rest
of
uc's
test
would
apply
if
there's
actually
a
use
case.
So.
E
E
E
Thank
you,
okay,
so
let's
go
to
the
let's
go:
let's
go
to
the
next
slide.
Here
you
mean
the
one
after
oh
yeah,
you
know
pretty
pretty
sorry,
I
think
you're
less.
Could
you
go
back
for
one
slide?
Let
me
see
if
I
covered
this
yeah.
No,
we
we
covered
this
here.
Okay,
let's
go
to
the
next
one.
Let's
get
to
delete
okay,
so
here's
the
editor's
recommendation.
E
The
e
document
can
provide
the
cdl
description
for
unsigned
claim
sets
covering
for
both
cwt
and
jwt.
The
document
will
incorporate
the
request.
Diana
for
the
seaboard,
json
tag
to
identify
unsigned
claim
sets
and
the
current
uccs
document
would
refocus
on
only
security
considerations
for
unsigned
claims
and
it
could
be
informational
track
and,
and
it
could
even
you
know,
could
also
cover
some
of
the
scenarios
that
dave
was
just
now
mentioning,
which
is
with
your
respect,
to
not
just
attestation
evidence
but
at
station
results.
E
So
why
this
change
we,
the
eat
document,
requires
it
only
requires
a
stable,
cdl
description
of
uccs
and
we're
confident
that
it
exists
today.
Thank
you,
hank
and,
and
the
other
utc
uccs
editors
for
working
through
that.
E
The
security
considerations
for
uccs,
though,
are,
I
think,
we're,
in
my
opinion,
we're
only
just
beginning,
and
you
know
the
editors
also
feel
that
too
it
may
not
close
very
quickly
and
the
other
thing
too
is
we
don't
want
to
see
any
implementers
who
actually
require
the
uccs
option
today
to
get
held
up,
we
do
believe
eat
can
go
to
rfc
with
the
reference
to
the
uccsid
and
its
security
considerations,
and-
and
that's
that
would
be
assuming
that
the
working
group
acts
on
the
recommendations
of
the
previous
slide
and
uccs
document
can
then
start
to
actually
look
more
comprehensively
at
all
the
and
all
the
transfer
security
considerations.
E
You
know
I
mentioned
where
one
way
off
the
sufficient.
That's
at
the
transport
layer.
I
mentioned
an
example
where,
where
the
auth
and
the
other
direction
could
be
happening
at
the
application
layer
just
now,
my
response
today
rule
role
of
the
root
of
trust
in
security
transport,
which
is
really
one
of
the
major
considerations
in
actually
in
actually
coming
up
with
the
ucts
concept
in
the
first
place.
E
A
Yeah
we
are
at
time,
but
let's
take
two
minutes
for
questions.
H
Hi
gary,
I
just
had
a
quick
question
about
the
the
security
considerations
of
uccs
in
each
is
that
normative
or
informative?
What's
the
nature
of
that,
my
concern
is
yeah.
Sorry,
if
it's
it
would.
E
Yeah
good
document
in
this
round
sure
it
would
be
informative.
He
mainly
because,
like
mainly
because
I
think
it's
a
it's
an
involving
it's
an
evolving
use
case,
we
really
don't
know
we
really
don't
have
a
full
grasp
of
the
of
all
the
different
geese
usage
scenarios
of
utcs.
You
know
dave
just
mentioned
out
of
station
results
where
I
do
think
uccs
that
it
can
play
a
role
but
yeah
it
would
be
security
considerations.
I
always
view
in
the
context
of
heat.
I
would
view
as
informative.
E
Reason
is
that
eat
itself,
since
it's
based
on
cdbt
is
what
is
what
I
sometimes
refer
to
as
a
self-defending
payload.
So
a
deployer
could
actually,
it
could
actually
have
no
dependencies
on
the
transport
layer
at
all.
They
could
they
could
encrypt
it,
they
could,
they
could
sign
it
and
it
could
be,
it
could
go
over.
Multiple
transport
layers
of
varying
security
is
varying
security
levels
and
security
insurances,
I
should
say,
and
still
be
still
be
as
secure
as
the
application
calls
for.
A
B
All
right,
thank
you,
so
just
a
couple
of
clarifying
questions
just
and
I
was
taking
notes
at
the
same
time,
so
it
might
be
just
that
I
missed
something.
So
I
apologize.
If
that's
the
case,
so
you
mentioned
the
e
authors
wanting
to
fold
this
into
the
eat
draft.
B
I
would
be
against
that
just
in
the
cons,
the
the
amount
of
time
taken
and
then
I
guess,
we'd
also
need
to
understand,
since
it
references
this
what's
going
to
be
the
hold
up
for
this
document
to
complete
for
eat
and
personally,
I'd
just
like
to
see
eat,
make
some
quick
progress
and
and
get
through
final
publication
soon.
E
Yeah
well,
well,
I'm
not
saying,
I
didn't
say
fold
the
entire
uccs
document
into
eat.
I
just
said
I
I
just
said
the
cddl
description.
I
think
utcs
continues
as
a
separate
working
group
document.
That
is
the
hold
up
right
there
you
we
don't.
We
think
we
have.
We
think
we
can
actually
complete
the
cdl
description
for
this.
I
don't
know
really.
I.
E
You
know
how
that
would
how
that
would
take
shape
on
the
uccs
document
and
there
is
a
normative
dependency
in
the
document,
so
I
didn't
put
that
in
there
as
an
alternative,
because
I
I
mean,
because
the
editors
feel
that
the
the
editors
have
agreed,
that
this
is
actually.
This
is
actually
the
least
painful
path,
but
you
know
the
other
alternative
is
to
eliminate
all
the
normative
dependencies
on
uccs.
E
But
I
think
that's
that's
going
to
be
not
fun
either
for
for
implementers,
because
because,
because
any
implementer
comes
to
each
document
they
may
do
and
they
may
they
may
first
ask
okay
well
what?
If
I
don't
want
to
sign
this,
then
assign
this
token,
then
you
get
into
uglier
situations
where
an
implementer
might
actually
implement
things
that
have
killed
us
in
the
past
on
tls
security
such
as
null
ciphers,
which
I.
A
J
J
If,
if
we
want
to
go
forward
with
that,
but
the
more
fundamental
problem
is
that
that
cwt
actually
was
meant
to
be
a
general
purpose
specification,
and
I
see
a
certain
tendency
of
this
working
group
to
pull
this
stuff
in
and
essentially
claim
cwt
and
and
kind
of
merge,
eat
and
cwt.
And
there
are
some
good
reasons
to
do
that.
But
there
are
also
some
good
reasons
not
to
do
that
in
the
extent
that
that
pulling
over
the
cdl
into
the
the
document,
what
would
provide?
E
M
M
Just
to
reinforce
what
carson
said
is
that
the
uccs
is
for
cwt
and
we
have
an
application
scenario.
That
is
why
we're
doing
the
first
uccs
core
id
in
rats
and
that's
the
usage
and
threat
model
and
the
security
consideration
of
rats,
because
a
uccs
may
and
must
never
come
without
the
prescription,
how
to
use
it,
because
it
is
dangerous
to
use
it
without
one,
and
I
think
therefore
it
has
to
have
context
and
just
by
chance.
M
E
Yeah
you
see
once
again
it
is
scoped
at
a
station.
You
should
the
the
editors
that
they
wanted.
The
general
purpose
method
for
for
conveying
unsigned
seaboard
claims
probably
should
have
taken
this
to
taking
this
to
other
to
another
working
group.
Maybe
the
ace
working
group
or.
A
I
just
want
to
reiterate:
we've
had
these
discussions,
we
had
the
discussion
with
with
jim
shot.
Let's
just
move
on
okay,
and
then
we
can
have
the
discussion
kathleen
as
chair
posed
a
question
of
how
we
can
help
eat,
accelerate
moving
forward,
which
means
tightening
its
scope.
So
with
that,
let
me
just
park
it
because
we
are
well
over
time
and
we
can
come
back
to
it
if
we
have
time
at
the
open
mic.
A
Otherwise
we
will
raise
it
again
in
the
mail
list,
so
next
gidi
you
are
on
for
at
the
station
for
cloud.
E
I
think
yes,
so
I
thought
I'd
get
ahead
of
this
issue
here.
You
know,
particularly
since
we're
trying
to
wrap
up
heat.
A
white
paper
came
out
from
the
friday
alliance
on
on.
Essentially
what
is
cloud
synchronization
of
private
keys.
These
are
private
keys
related
to
authentication
credentials.
This
is
actually.
E
This
is
actually
discussed
last
summer
during
the
apple
worldwide
developer
conference
there.
There
are
valid
reasons
for
this
private
key
synchronization
can
allow
for
for
ease
of
user
adoption
and
ease
of
end
user
management
credentials,
particularly
when
credentials
have
to
move
from
one
device
to
another
which
could
be
you
know,
not
just
device
migration
or
upgrade.
It
could
also
be
lost
devices
as
well.
What
we
call
device
recovery,
sometimes
in
the
photo
context.
E
So
the
yeah
okay-
just
I
knew
this
drawing
wouldn't
come
out
very
well,
but
I'll.
Just
kind
of
talk
to
it.
Fido
defines
the
authenticator
restricted
operating
environment,
which
ideally
would
have
a
some
sort
of
some
sort
of
trusted
environment
to
increase,
encompass
all
the
critical
security,
sensitive
authenticator
operations.
Those
would
be,
for
instance,
by
not
just
sign
a
protection
of
private
keys
and
signing
operations,
but
associated
signing
operations,
but
also
biometric
match
and
the
attester.
The
attester
could
very
well
be
incorporated
to
the
aroe.
E
So,
as
for
the
current
rats
architecture,
which,
as
was
discussed
yesterday,
we
really
don't
want
to
really
don't
want
to
change
significantly.
This
point.
There
are
some
underlying
assumptions
that
one
of
them
is
that
the
testing
environment
is
conventionally
isolated
from
the
target
environment
in
which
you
can
in
which
it
can
collect
evidence
about
the
second.
E
E
Now
we
have
a
situation
where
implementers
are
actively
extracting
keys,
although
not
necessarily
out
of
station
keys.
Let's
move
on.
E
So,
as
I
mentioned,
the
phytoauthenticator
may
not
have
the
separation
between
a
tester
and
a
target.
In
fact,
photo
authenticators
could
even
be
downloadable
applications
and
we
have
seen
some
implementers
actually
pursue
that
route.
So
the
question
I
have
to
working
with
should
attestation
evidence
specifically
address
whether
whether
private
key
material
is
extractable
and
a
sub
question
would
be.
Should
this
evidence
be
accompanied
by
evidence
that
attestation
keys
are
not
extractable
and
the
lack
of
such
evidence
could
also
be
used
by
an
rt
lack
of
a
lack
of
explicit
evidence.
E
That
is,
is
still
a
valid
data
point
to
any
appraisal
policy.
So
that's
the
explicit
evidence.
You
can
also
take
the
route
of
what
I
call
implicit
evidence,
which
would
be
if
the
rp
determines
whether
the
authenticator
allows
extrapolates
radical
keys
by
some
other
means
such
as
such
as
an
endorsement.
E
You
know
it
also
carries
digital
letters
about
letters
of
assurance,
dloas
that
might
actually
be
sufficient
for
an
rp
to
make
a
termination
or
a
verifier.
If
you
want,
if
you
want
to
keep
keep
the
two
separate
and
by
the
way
in
fido
parlance,
we
don't
we
are
we.
We
always
assume
that
the
verifier
is
integrated
in
the
rp.
E
We
could
leave
the
issue
to
any
profile
for
phytocompliant
authenticators
and
then
we
can
define
relevant
evidentiary
claims
and
profile,
or
we
could
do
nothing
and
let
the
rp
figure
out
the
appraisal
process
via
some
sort
of
implicit
evidence
or
some
other
means,
and
that's
it.
I
don't
believe
I
have
any
slide
on
this,
so
I
just
decided
to
raise
this
topic.
E
If
I
don't
see
any
interest,
we
won't
perceive
the
first
bullet
and
we
we
will
probably
we
probably
leave
any
any
potential
solution
to
the
lat
latter.
Two
okay,
I'm
done.
M
M
So
if
my,
I
want
to
say
root
of
trust.
Okay,
if
my
testing
environment
has
this
capability
of
the
key
material
being
changed,
and
that's
very
clear,
alongside
with
every
endorsement
that
the
verifier
can
do
that,
that
is
fine.
But
how
do
I
guarantee
that
there
is
an
endorsement?
How
do
I
not
guarantee
the
safe
assertion
of
my
testing?
Environment
is
hey,
my
keys
are
not
exchangeable
and
they,
in
fact,
are
so
without
a
good
understanding
of
the
security
considerations.
M
How
to
make
endorsements
here
really
really
trustworthy
and
working
should
be,
is
the
core
of
the
problem.
I
think
it's
not
actually
the
problem
to
change
the
key
it
makes
it.
The
problem
is
that
you
must
always
be
aware
that
this
can
happen
when
you
talk
to
something
that
has
that
capability
right.
So
that's
my
comment
here
so
not
entirely
adverse,
but
it
looks
like
very
dangerous.
Terran
to
me.
E
K
E
D
Oh
there
there
you
are
okay,
I
just
think
there's
a
really
big
difference
between
fido
authentication,
keys
and
attestation
keys,
so
export
of
attestation
keys
is
a
really
big
deal
and
it
is
relevant
to
this
group.
Phyto
authentication
keys.
If
that's
all
that's
being
happened
with
fido,
then
that's
that's
a
fido
thing
and
fido
should
take
care
of
that.
So
that
would
probably
be
a
a
two
or
a
three
on
your
list.
There
thanks
son.
A
G
Tony
natalin
so
gary,
I
would
rather
see
us
do
nothing
in
this
particular
space
and
let
fido
or
whoever
wants
to
create
the
profile
since
they're
the
you
know,
they're
they're
the
experts
in
this
particular
case.
I
don't
think
it
makes
sense
for
this
group
to
do
anything
with
that.
With
that
profile,.
G
A
N
Good
good
cool,
okay,
let's
start
with
the
goal
of
this
document,
so
the
scenario
is
we
have
one
or
more
authorized
supply
chain
actors
in
the
form
of
oems
odms,
independent
software,
vendors,
silicon
providers
etc.
That
need
to
come
together
and
describe
an
attester
to
a
verifier
so
that,
when
evidence
from
the
attester
is
passed
on
to
the
verifier,
the
verifier
can
use
what
it
learned
about
the
tester
from
the
supply
chain
to
evaluate
the
evidence
according
to
its
appraisal
policy.
N
And
this
should
you
know,
lower
the
barrier
to
entry
in
the
supply
chain,
actors,
space
which
is
currently
highly
fragmented
and
eventually
bring
us
to
a
better
place.
Obviously
we
think
this
is
a
very
important
work
that
has
not
been
tackled
in
comprehensive
way
and
quorum
is
an
attempt
to
deal
with
this
and
the
new
proposed
charter.
Tax
includes
scope
for
this
work
to
be
taken
in
by
the
group,
but
for
the
time
being,
since
we
still
live
under
yield
charter,
the
draft
meekly
weights
at
the
periphery
of
of
the
working
group.
N
Okay,
so
to
clarify
what
is
the
scope
of
concise
rims?
Here
we
are
looking
at
the
endorsement
and
reference
values
arrows
that
go
into
the
verifier,
so
we
are
not
concerned
at
all
with
conveyance
of
appraisal
policies
here
and
besides
quorum
defines
the
payloads,
not
the
the
the
the
underlying
transport.
So
surely
we
want
this
to
be
compatible
with
rest
apis,
which
is
obviously
a
very
natural
target
for
for
transporting
according
payloads,
and
therefore
we're
making
sure
that
the
right
media
types
are
in
place
from
the
onset.
N
But,
apart
from
providing
this
kind
of
glue,
we're
not
interested
in
promoting
one
transport
or
or
another
effectively
quorum
is
transport
agnostic
yeah.
N
I
think
I'm
done
with
this
next,
please,
okay,
so
a
quick
refresher
on
the
design
principles
for
those
who
don't
know
or
have
forgotten,
so
we
described
in
a
tester
in
terms
of
triples,
which
are
simple
stereotype
sentences
with
subject
verb
and
object
which
allow
us
to
say
things
like
you
know:
target
environment,
t
as
reference
value
x
or
a
testing
environment,
a
as
verification,
k,
y
or
targeted
testing,
slash
a
testing
environment.
N
T
prime,
a
prime
has
endorsed
value
z
and,
since
the
set
of
triple
z
is
extensible,
we
can
potentially
say
many
more
things.
For
example,
if
you
wanted
to
express
relationships
between
sabates
or
in
a
composite
devices,
we
could
do
that
by
just
by
minting
a
new
triple
which
provides
the
the
needed
semantics.
N
This
whole
thing
gets
then
serialized
in
sibor,
and
I
think
that's
where
the
concise
in
quorum
comes
from,
and
then
we
can
sign
them
with
cosi
and
therefore
the
triples
can
become
in
fact
quadruples
by
adding
the
cosy
signer.
As
the
subject
of
the
statement
that
is
encoded
in
the
triple
okay.
Next,
please
so
status
recap
where
we
are
so
the
information
model
has
been
done
in
tcg,
specifically
in
the
dice
working
group,
and
it's
in
a
document
called
dice
endorsement
architecture.
N
E
N
N
Basically
there's
a
bunch
of
cdl
describing
the
serialization
details
and
a
number
of
examples
in
sybor,
diagnostic
mutation
and
and
and
with
that
all
the
automatic
assembly
and
test
infrastructure
hooked
into
a
bunch
of
you
know
github
actions
so
that
we
we
make
sure
that
any
change
we
introduce
is
correct
and
we
have
also
built
a
fairly
complete
software
implementation,
which
tries
very
hard
to
stay
as
close
to
track
as
close
as
possible.
N
The
bleeding
edge
in
the
cdl
above,
which
includes
corim
comeds,
which
are
sort
of
the
core
building
block.
That's
where
the
triples
are
stored
and
cost
width
2,
and
this
is
all
library
code
in
golang
and
handy
cli,
build
built
on
top
of
it.
That
is
really
usable.
N
So
the
questions.
Clearly,
we
cannot
call
for
adoption
now
because
the
charter
text
that
contains
the
scope
extension
that
allows
core
m
to
be
a
ras
work
item
is
not
yet
in
so
I
think
the
question
we
can
ask
the
group
is
whether
once
the
new
charter
is
in
place,
would
core
be
considered
for
adoption
yeah.
I
think
that's
that's
the
fair
question
that
you
can
ask
now.
N
K
Hey
taylor,
hey
thomas,
so
I
think
that
this
is
a
good
document
and
if
the
charter
effort
goes
through,
then
I
think
this
would
be
absolutely
appropriate
to
be
done
in
rats.
So
I
think
this
is
good
work.
I
think
my
only
other
comment
or
question.
I
think
the
value
of
this
is
for
the.
If
you
don't
mind,
can
you
go
back
to
the
little
diagram
that
showed
the
which
lines
and
stuff
you
know
what
I'm
talking
about
yeah
this
one?
K
I
think
the
primary
value
for
this
one
is
in
specifying
the
reference
values,
because
there's
a
format
for
that
that
doesn't
cleanly
fit
into
any
other
document
that
we
have
right,
because
you
need
your
verbs
right.
You
may
need
to
have
sets
of
values.
You
know
your
reference
values
may
have
the
the
following
claim.
It
needs
to
have
any
of
the
following
values,
and
so
it's
not
a
singleton.
K
It's
a
set
right
so
that
that's
what
I
think
value
of
coderem
is
there's
with
relation
to
the
left
line,
though
I
don't
think
there's
a
strong
case
for
that,
although
reference
values
could
be
bundled
with
endorsements
and
have
both
lines
coming
from
the
same
body
when
the
two
top
roles
are
the
same
entity
right
when
your
endorser
is
also
a
reference
all
your
provider,
you
can
do
both,
but
I'm
not
sure
that
korean
has
a
strong
case
for
endorsements,
as
opposed
to
one
place
in
the
document.
K
That
says,
reference,
values
for
evidence
and
endorsements,
and
I
completely
agree
with
that
right,
because
your
endorsements
have
claims
your
evidence,
have
claims
and
they're
compared
to
an
appraisal
policy
to
say
to
the
endorsements
and
the
evidence
to
those
claims
together
match.
You
know
the
following
reference
values.
K
I
think
if
you
did
that,
I
would
consider
that
to
be
reference
values
in
the
in
the
current
format,
with
some
additional
endorsement
stuff
showed
in
there
too,
and
so
I
might
try
to
scope
the
work
to
say,
keep
endorsements
out
of
it
and
just
concentrate
on
the
reference
value
provider
line
which
of
course
could
be
combined
with
an
entity
or
whatever.
I
think,
there's
a
stronger
case
for
that.
So.
N
Okay,
cool
on
on
your
question
on
your
point:
where
would
you
put
say,
for
example,
I
need
to
interface
with
the
certification
body
right.
So
it's
not!
You
know
it's
not
a
supply
chain.
K
If
there
are
information
needed
in
the
appraisal
policy
that
cannot
be
expressed
in
the
same
sorts
of
things
that
eat
uses,
and
I
phrase
it
that
way
because
it
may
not
be
the
only
format
if
you
have
a
proprietary
one
right,
but
if
it's
not
isomorphic
to
eat,
then
I
would
put
that
in
the
reference
values
line
and
say:
okay,
you
just
have
different
verbs
there
sure,
but
I
would
still
call
that
the
reference
values
lying
to
answer
your
question:
okay,
it's
just
how
you,
how
how
you
define
the
lines,
and
so
I
I'm
defining
the
line
that
way,
maybe
differently
than
how
you
define
the
lines
yeah.
K
Okay,
now
the
the
the
the
architecture
document
is
is
it
is
generically
phrased
enough
to
punt
this
question
down
the
road
and
I
think
that's
perfectly
fine
right.
It
says
once
we
recharter,
then
the
discussions
like
this
start
to
become
in
scope,
but
my
main
feedback
is
yes.
I
think
it
would
be
appropriate
for
the
working
group
to
work
on
this
and
continue
this
discussion
so.
M
Yeah
so
to
let's
start
with
dave's
point
first,
because
that's
fresh
in
my
mind,
I
think
endorsements
can
live
without
reference
value
provider
statements.
So
yes,
this
could
be.
There
could
be
a
courier,
that's
just
about
endorsers.
M
I
think
reference
values
always
refer
to
someone
who
was
authoritative
to
tell
them,
and
that's
that's
kind
of
similar
to
how
you
would
describe
an
endorser,
because
the
reference
where
you
have
to
come
from
the
authority
that
creates
reference
about
a
component
of
your
layered
device
and
dice
and
then
yeah.
You
have
to
point
to
at
that
at
least
so.
The
identity
part
of
the
endorser
has
to
go
somewhere
into
reference
value
reference,
integrity,
measurements
because
otherwise
you
don't
know
which
testing
environment
is
supposed
to
tell
you
and
evidence
about
which
target
environment.
M
This
relationship
is
very
important
and
sometimes
it
gets
a
bit
lost
along
the
lines,
so
I
think
yes
endorsements,
but
could
stand
by
themselves.
Reference
values
knee
pointers
to
endorsers,
so
that's
a
very
minimum
where
this
overlap
happens,
and
I
think
the
co-room
can
be
designed.
Maybe
there's
some
tweaks
here
that
we
can
do
that.
We
can
accommodate
for
the
rvp
and
the
indoors
are
being
very
separate
and
both
of
them.
Then
I
can
be
combined
by
verifier,
so
so
I
think
that
that
might
be
a
a
checklist
to
have
to
do
with
the
cddl.
M
So
I
think
it's
that
is
accomplishable
so,
but
thank
you
for
the
comment.
I
think
we
have
to
take
into
account
that
the
red
box
there
green
boxes
at
endorser
and
rvp's
are
very
separate,
but
still
the
rvp's
are
about
things
than
the
adores.
I
will
talk
about,
so
there
is
some
relationship
there
and
another
thing
I
want
to
say,
because
thomas
is
so
modest
about
this
there's
already
a
corresponding
profile
of
corum,
which
is
the
psa
endorsement
token,
so
that
is
going
hand
in
hand.
M
D
This
is
lawrence
first,
I
just
want
you
to
know
that
roman
has
more
books
than
you.
D
Okay,
all
right
all
right,
so
so
the
reference
values
have
to
correlate
to
measurements
in
evidence.
Otherwise
you
don't
know
what
to
do
with
them
right,
yep.
So
there's
got
to
be
something
going
on
in
evidence
that
some
format
you
know,
however,
the
measurements
are
tran
transmitted
that
you
can
correlate
them
to
the
right
reference
values.
Now
my
understanding
so
there's
an
implication
there
for
eat.
Basically
what
I'm
thinking
is-
and
I,
but
I
think
this
is
being
handled-
and
I
wanna
I
just
wanted
to
surface
the
topic.
D
D
D
J
A
Okay,
I
think
the
queue
is
closed
to
your
question.
Thomas,
you
are
correct
and
roman
also,
as
our
a.d
mentioned.
As
a
process
reminder,
we
cannot
adopt
the
document.
A
A
I
keep
forgetting
we're
hybrid.
Have
you
read
the
korean
draft.
A
So
what
I'd
like
to
see
thomas
is
get
some
feedback
to
make
sure
that
there
is
interest
and
some
have
read
the
draft
and
agree
it.
I
mean
I'll
pick
on
dave.
It
looks
like
he
has
read
the
draft
from
a
processes
after
we
charter,
we
we
want
to
get
some
level
of
feedback
on
whether
the
draft
is
ready
to
be
adopted.
A
So
if
I
don't
have
volunteers
well,
actually
I
should
say
if
we
don't
have
enough
people
that
have
read
the
draft,
then
I'll
ask
for
volunteers
to
provide
feedback
just
to
the
level
and
then
do
the
call
for
adoption.
But
this
is
all.
N
A
That's
why
I
should
have
clarified
that
okay,
so
so,
for
those
who
have
read
the
draft
to
the
authors,
did
you
do
a
new
revision?
I
don't
recall
in.
M
A
A
M
Interested
in
having
read
it
might
might
be
different
things
and
also
yeah,
I'm
sorry.
This
is
not.
This
is
a
fact
right
so
and
we
had
15
or
17
votes
to
being
interested
on
the
email
list
during
christmas
already,
so
I
would
like
to
have
them
into
account.
If
we
talk
about
people
interested
in
having
this
work
yeah,
they
may
not
be
in
this
room
here,
even
virtually
right
now,
I'm
just
just
highlighting
there
was
17
15
votes
about.
A
A
If
there
are
no
others,
the
chairs
actually
have
a
question
any
anything.
Anyone
wants
to
raise
gidi
you're
on
the
cube.
E
Yes,
I
want
to
get
back
to
my
presentation.
I
want
a.
I
want
to
clear
a
clear
guidance
from
the
group
on
resolving
the
circular
dependency
between
uccs
and
eat.
Now,
remember
you.
E
A
We
are
concerned
about
the
progress
and
maturity
and
the
question
that
we
wanted
to
put
forward
to
the
eat.
Authors
is
your
expected
timeline
if
you
notice
the
milestones
that
we
updated,
we
noted
I
think
it
was
in
112.
We
noted
using
guidance
by
you
as
the
authors
that
the
draft
should
be
ready
for
working
group
last
call
in
april.
E
No,
I
think
the
second
one
actually,
the
first
one.
No,
I
don't
believe
so.
We
think
we
can.
Actually.
We
can
actually
resolve
that.
The
second
one
I
think
the
the
feedback
was
that
we
can
actually
that
at
least
the
one
that
I
provided
was
that
it
would
be
it
looks
like
the
consensus
is
that
would
be
better
handled
in
a
profile.
E
I
think
the
attestation
results
is.
Is
the
annotation
results?
Discussion
doesn't
belong
in
there,
it
doesn't.
It
would
not
derail
the
eat
document
and
if
certain
people
feel
that
they
are,
I
think
we
should
take
it
to
working
group
consensus
rather
than
having
having
individuals
with
their
own
opinions
in
the
real
progress
and
stuff.
I
I
do
think,
though,
this
uccs
dependency
needs
to
be
resolved.
I'm
asking
the
chairs
once
again
a
recommendation
as
to
how
they
would
like
to
see
it
resolved.
I
E
M
Okay,
two
items:
first
of
all,
we
can
give
a
written
statement
of
consensus
of
the
editors
after
we've
synced
after
this
itf
meeting,
and
I'm
pretty
sure
that's
easy.
I
don't
know
where
is
this
coming
from?
The
second
item
is
you
do
not
have
a
circus
dependency
dependence
of
uccs,
you
can
just
you
eat
just
to
eat
and
the
uccs
part
can
be
applied
to
any
cwt
and
we
give
you
even
guidance
how
to
do
it
with
each.
So
I
think
you
don't
have
any
dependence
at
all.
Just
don't
mention
it.
M
I
think
this
is
a
decoupled
problem.
That's
how
it
is
designed.
That's
why
we
are
not
holding
anything
up,
because
we
made
the
smart
decoupling
of
the
problem.
You
can
just
create
each
specification
and
then
say
and
uccs
applies
to
it
in
your
ccs
there's.
There's
no
recursive
thing.
That's
a
imaginary
problem.
E
K
And
I'm
gonna
repeat
a
comment
that
I
made
in
chat
a
while
back
when
the
during
the
presentation,
but
I
think
it's
consistent
with
what
kathleen
and
nancy
had
commented
at
the
time
and
similar
to,
but
not
the
same
as
what
hank
just
did.
Okay,
my
opinion
is
that
the
best
way
forward
would
be
to
remove
all
the
normative
content
about
uccs
out
of
eat
and
change
it
to
be
an
informative
one.
And
yes,
I
know
that's
work
right
because
that
would
entail
moving
some
stuff.
K
That's
in
the
eat,
spec
into
the
uccs
doc.
I
see
lawrence
nodding,
so
I'm
hoping
that
means
yeah.
You
understand
what
I'm
saying
is.
I
think
that
that
is
actually
doable,
okay
and
that
that
is
actually
the
fastest
path
to
getting
eat.
Rfc.
Okay,
so
that's
what
I
would
argue,
as
the
alternative
is
to
say,
take
the
normative
content
move
it
into
the
uccs
document.
Leave
informative
content.
That
says
you
know
there
might
be
future
work
on
doing
such
and
such
or
you
know
whatever.
It
is,
that's
an
informative
reference.
K
I
think
that's
perfectly
fine!
That's
the
only
difference
between
what
hank
said
and
I
said
is.
I
would
leave
it
as
an
informative
reference,
because
you
can
informatively
reference
work
in
progress
right
and
so
uccs
would
become
work
in
progress
as
far
as
the
as
an
rfc
pops
out
is
concerned
right
because
it
won't
affect
the
rfc
editor
by
then
right,
so
it'll
be
listed
as
a
net
informative
reference.
I
think
that's
the
way
that
I
would
go.
I
think
that's
the
fastest
past
rfc,
so.
D
So
the
problem
is
the
cddl
that
seems
that
has
to
be
a
normative
reference,
so
you
can.
I
I
mean
I
know
how
to
make
a
soft
preference
or
or
an
informative
reference,
but
I
need
the
cddl
from
for
scwt
in
eat
to
make
the
cddl
and
eat
complete.
That
seems
like
a
hard
reference
to
me,
and
that
was
why
we
proposed
bringing
that
cddl
into
eat.
D
M
M
A
Okay,
guys
we
ned
has
the
chair
and
I'll.
Just
echo
dave's
comment
that
he
says
you
can
keep
the
ccdl
and
eat
and
not
make
the
main
ccdl
depend
on
uccs.
A
Well
so
before
we
close,
ned
wants
to
do
a
poll
just
so
that
we
can
give
the
eat
authors
guidance.
I
Okay,
so
raise
your
hand
if
you,
if
you
agree
to
the
motion
of
moving
normative
information,
that's
currently
in
the
each
spec
and
and
changing
it
to
be
informative.
I
E
E
You
that's
that
that
that's
good
we'll
I'll
document,
my
understanding
and
post
it
to
the
mailing
list.
Okay,
okay,.