►
From YouTube: IETF105-RATS-20190724-1550
Description
RATS meeting session at IETF105
2019/07/24 1550
https://datatracker.ietf.org/meeting/105/proceedings/
A
B
C
D
C
E
E
D
E
B
All
right,
so
we
have
we're
beating
our
work
on
the
on
use
case
document.
That's
not
going
to
be.
We
made
a
decision
or
a
virtual
interim
that
we
would
not
publish
the
as
an
RFC,
but
it
should
be
available
for
for
publicly
for
for
review.
We
did
call
for
an
adoption
on
the
e
draft
and
that
adoption
was
accepted.
We
have
a
call
for
adoption
for
the
token
vine
draft,
the
interaction
model,
draft
yang
module
draft
and
the
to
to
draft.
B
D
D
B
D
B
B
H
H
I
We
go
no,
it
works.
You
should
turn
it
off
the
end
of
the
session
so
that
people
at
home
don't
hear
what
you
say
to
the
chairs
quietly
hi
I'm,
Michael
Richardson,
we'll
be
talking
about
the
use
case
documents
a
day,
or
rather
you
will
be
talking
about
the
use
case
document
today.
I
really
hope
says:
oh
three,
that's
excuse
me
and
that's
correct.
I
anticipated
posting
in
you
and
yesterday,
but
my
little
more
aspirational
than
active.
I
What
are
we
doing
today?
How
we
got
here,
where
are
we
going?
Can
I
raise
it?
Show
hands
of
those
who
were
at
the
intro
interim,
so
I
would
say
20%
of
the
rooms
that
look
about
right.
So
for
a
lot
of
you,
this
will
be
new
and
I.
Think
that's
okay
and
we
got
where
are
we
going?
Where
are
we?
Where
is
it
going?
I
I
would
like
to
spend
the
most
the
bulk
of
the
time,
the
discussion
we
have
only
one
microphone,
that's
okay,
I
guess,
and
then,
after
the
sort
of
after
discussion,
I'd
like
to
share
what
I
actually
in
my
vision,
is
how
it's
going
to
mutate
into
what
it
will
look
like.
Okay,
if
we
get
there
so
there's
an
initial
zero,
zero
zero
one,
zero
three
posts
district
of
the
ritual
interim
I.
Imagine
posting
in
Oh
for
yesterday.
Actually
there
wasn't
enough
material
that
I
fairly
felt
it
was
worth
the
integer
and
it's
as
tired.
Okay.
I
So,
as
we'd
agree,
the
intention
is.
This
is
not
published
as
an
RFC,
partly
because
the
iesg
doesn't
really
feel
that
we
should
publish
requirements
and
use
case
documents
on
their
own.
If
this
working
group
really
really
thinks
that
the
content
is
valuable,
then
I
would
urge
you
to
put
it
in
as
an
appendix
to
some
other
document.
That's
going
to
be
it
published
anyway,
I'm
not
looking
from
our
author
credits,
so
I
don't
care.
I
The
goal
is
to
focus
us
on
what's
important
and
what's
not
I'm
well
in
continuing
so
the
document
so
far
there
are
13
use
cases
listed,
I,
hope,
they're
in
better
order
than
they
were
at
the
last
meeting.
There's
approximately
four
categories:
device
capabilities,
our
firmware
state
claims
cryptographic
key
claims,
so
the
distinguished
is
ima
devices,
a
foo,
I'm
running
firmware,
blah
blah
blah
and
the
cryptographic
keys.
Things
are
more
like
this
key
has
been
stored
in
a
particular
type
of
container
or
TPM,
or
something
and
that's
why
you
can
trust
it
or
not.
I
Geographic
is
in
location.
Where
are
things
where
it
things
connectivity,
which
is
a
little
bit
like
geographic
in
a
more
abstract
sense.
I'm,
you
know
connected
to
something,
or
whatever
includes
a
survey,
have
identified
technology
users,
so
this
list
could
increase
trust.
The
computer
group
computing
group
has
said
they
wanted
to
use
this
phyto
says
they
wanted
use
this
and
Android
key
start
has
been
expressed
as
being
a
thing
and
I
know
we
have
people
from
there,
though
I
can't
quite
figure
out
yet
how
that's
going
to
work.
I
Carl
Wallace
contributed
three
big
examples
of
existing
attestation
claims
down
to
the
asn.1
decode
in
this
kind
of
stuff.
I
found
it
fascinating.
I
have
as
many
questions
as
answers
about
what
I
saw
in
there
and
I.
Don't
know
whether
or
not
it's
useful
in
this
for
us
to
do
this
kind
of
thing
at
this
level
it
may
be
that
at
a
smaller
level
of
abstraction,
it's
useful
to
see
what
people
have
done,
or
maybe
we
just
need
more
text
to
less
hex
dump
to
really
say
something
interesting.
Yes,
roman.
I
I
I
D
K
Just
a
thank
you
for
these
you've
got
your
skates
drafted.
It's
already
covered
a
lot
awful
night
nation's
technology
and
the
industry
I
just
the
one
who
at
one
point
that
are
maybe
one
years
ago
we
have
education,
use
case
draft
about
the
technology
network
network
organization
technology.
Oh
yes,
all
right,
so
I'm
wondering
with
our
consider.
It
can
also
be
a
part
of
this
document,
so
if
we
can
consider
it
so.
I
It's
a
network
virtualization.
Obviously,
if
we
I
haven't
read
the
document
right,
the
instant
I
think
the
answer
is
that
we
need
to
post
the
relevant
pieces
to
the
mailing
list
and
abstract
what
is
the
use
case?
That's
occurring
and
a
lot
of
a
lot
of
people
thing
and
I
want
to
attest
over
the
network
as
to
a
particular
aspect
of
the
device
and
say
so:
that's
a
device
attestation
use
case,
and
so
the
question
is:
is
there
something
unique
about
the
particular
environment
there?
So
in
some
cases
people
said?
Oh,
yes,
there's!
I
I
I
am
interested
in
feedback
as
to
the
utility.
The
examples
I
think
that
maybe
less
detail
about
the
examples
would
be.
It
was
probably
warranted.
I
kind
of
just
Karl
and
he's
not
here
this
week
send
me
a
pull
request,
so
it
was
really
easy
to
just
suck
it
all
in
without
thinking
and
I
went
wow.
There's
a
lot
of
really
interesting
stuff
here.
I.
I
Don't
really
think
that
that
it
we
all
of
it,
belongs,
but
I
actually
think
that
it's
kind
of
useful
for
people
to
see
prior
art
and
what
happened
and
what
kind
of
things
were
there,
but
I
think
we
need
more
explanation
of
some
things
or
maybe
just
references
to
where
these
things
are
defined.
So
I
think
that
would
be
very
welcome.
Yeah.
K
I
Yeah,
so
so
please
we
can
discuss
more
so
so
my
intention
is
to
do
a
little
bit
and
then
have
I
was
whole
slide
for
open
mic.
So
yes
in
general,
I
would
like
people
to
express
the
use
case
and
say
I.
Think
I
have
a
use
case
as
you've
just
said,
and
then
you
know
said:
okay,
that's
great,
please,
let's
figure
out
how
it
fits
into
the
rest
of
the
thing.
Where
is
it
going
so
first
point
is
we
want
to
add
new
use
cases?
I
There's
been
one
pointed
post
to
the
mailing
list:
I
think
it
was
Monday
or
Sunday
by
dr.
Ian
Oliver,
maybe
you're
here,
I,
don't
know
about
three
new
terms,
at
least
with
supply
chain,
dynamic
systems
and
data.
There
was
some
discussion
of
it,
so
whether
some
of
this
belonged
or
not
and
I
think
that's
all
appropriate.
My
goal
is
to
accept
the
text.
Okay,
make
sure
to
take
clarifying
questions
about
the
text.
Do
you
mean
it
refers
to
when
the
oranges
are
in
the
container
or
when
the
oranges
are
in
the
store?
Okay,
whatever?
I
If
it's
a
photo
just
and
clarify
that,
so
that
we
have
some
agreement
as
to
what
is
the
case
that's
being
described,
and
then
I
want
to
argue
about,
is
this
different
from
something
else?
So
do
you
see
the
two-step
process
here?
Remember
we
have
that
meeting
where
people
ask
for
clarification,
questions
only
and
clearly
people
weren't
clear
on
what
clarifications
were
all
right,
so
so
I
really
do
want
that
step
on
the
mailing
list
to
do
that
because,
before
you
start
disagreeing
with
it,
you
probably
have
made
some
assumptions
about.
I
What's
going
on
that
may
be
or
may
not
be
true,
and
so
the
idea
is
we
really
like
to
get
a
unified
view
of
it.
So
that's
the
blue
things
Jessica
Fitzgerald
McKay,
who
I
saw
in
the
back
somewhere
there
has
suggested
a
different
set
of
dimensions
and
I
tried
hard
to
understand
at
10
o'clock
on
Monday
night.
What
that
really
meant
and
I
actually
I
failed
to
understand
the
the
list.
So
I
did
not
could
challenge
you
yet,
but
but
on
it,
but
I
hope.
I
Maybe
I
got
three
dimensions
out
of
what
you
wrote
and
I
think.
That's
a
useful
comment
and
I
think
that
we
should
categorize
the
uses
cases
on
a
number
of
different
ways,
but
ultimately
this
is
not
about
making
an
ontology
of
use
cases.
Okay
and
if
you
know
about
the
Platypus
who
I
believe
is
a
mammal
that
has
a
beacon,
lays
eggs
and
therefore
is
warm-blooded,
but
you
know
lays
eggs.
The
question
is
what
category
confused
biologists
first
centuries
right
is,
to
wit
what
kind
and
that's
not
our
goal.
I
My
goal
is
not
to
figure
out
whether
this
use
case
belongs
in
category
a
or
category
B,
but
to
understand
that
use
case
and
whether
we
have
to
solve
it.
Okay,
so
a
platypus
exists.
If
it
needs
an
ecosystem
to
live
in,
we
need
to
provide
it
and
we
don't
need
to
worry
about
which
part
of
the
zoo
we
put
it
in
okay,
if
it
gets
its
own
place,
great,
okay
and
open-mike,
come
tell
me
the
things
that
you
fail
to
find
how
many
people
have
read
the
documents
since
the
I
know.
I
Dave
has,
of
course,
yeah.
It's
done
and
just
leave
your
hand
up.
Okay,
so
not
that
many,
so
that
that's
not
so
good,
because
I'm
hoping
you'll
come
and
argue
and
discuss
with
with
whether
the
13
items
we
have
are
useful
or
not,
and
we
can
see
what
was
going
on
and
do
you
have
new
ones
so
Frank
has
given
us
one
new
one:
does
someone
else
have
things
that
they
don't
feel
that
have
been
represented
by
them?
Yes,
sir?
How
much
time
do
I
have?
Oh.
L
L
I
And
I
can
only
do
that
if
I
mean
I
can
look
through
the
list
of
extra
documents,
but
of
course
they
showed
up
on
Friday
right.
So
I
can't
have
that
happen.
So
we
are
having
a
side
meeting
tomorrow
morning
at
8:30
in
the
corral
room,
and
the
goal
is
to
put
the
use
case
document
on
the
screen.
Anyone
have
a
VGA
cable
because
I
need
one
and
to
actually
stuff
them
in
at
that
point,
so
that
we
can
actually
argue
over
the
text
right
there.
I
That's
the
goal
of
the
side
meeting
is
to
actually
bring
that
forward.
So
if
all
we
do
is
go
through
the
documents,
as
you
just
mentioned,
and
and
in
pull
the
right
pieces
out
or
if
you're
the
expert
on
that
document,
you
can
say
you
want
paragraph
six
through
nine
of
this
thing
will
condense
it
down
to
one
paragraph.
That
would
be
a
really
useful
thing
to
get
together
to
do.
Okay.
So
that's
what
the
goal
is
to
make
that
and
Rev
the
document
and
you
know,
go
on.
Okay,
all.
I
Right
well
so
what
I
have
envisioned
for
the
use
case
document
is
a
series
of
pieces
like
this.
That
doesn't
look
like
this
right
now,
so
there'll
be
a
series
of
thing,
it's
the
name
of
the
used
case
who
is
going
to
use
it?
Okay?
What
is
the
goal
of
this
if
there's
a
list
of
12:12
protocols
or
standards
or
something
that
can
you
that
will
use
this
or
make
use
of
this
thing
great?
Who
is
attesting
okay?
What
is
the
device
or
the
the
TPM
or
the
root
of
trust,
or
something
like
this?
I
That
is
making
a
statement?
Who
is
the
relying
party
who's
going
to
verify
the
statement
or
cares
about
what
it
says
and
the
use
case?
What
is
the
description?
Okay
and
then,
if
you
look
at
the
eat
document,
for
instance,
there's
a
whole
long
list
of
claims
that
it
offers
right
a
palette
of
things
that
you
may
say
about
it,
and
so
the
intention
is
in
the
use
case.
What
are
the
claims
that
you're
going
to
be
making
use
of,
and
so
in
order
for
this
to
be
useful?
This
is
two
things.
I
First
of
all,
it
motivates
why
that
claim
exists
in
the
eat
document.
Okay
and
that's
the
whole
points,
the
use
cases
and
secondly,
it
could
say
something:
I
need
to
attest
to
the
shape
of
the
microphone,
and
we
do
not
have
a
claim
that
attests
to
that.
So
that
would
mean
that
there's
a
gap
right,
and
so
we
only
have
13
use
cases.
So
imagine
we
have
20
at
the
end
of
the
day
and
then
we
argue
about
them
and
we
end
it
with
17.
I
Okay,
that's
not
that
many
to
go
through
and
say
things
and
then
we,
the
question
is
well:
do
we
have
things
in
the
eat
document
that
don't
need,
aren't
needed
or
or
are
missing
and
I
think
that's.
The
whole
purpose
of
a
use
case
document
is
to
explain
to
us
why?
Where
are
you
doing
certain
things
that
makes
sense.
I
I
There
you
go
so
says:
that's
the
the
Vasa
T,
so
certainly
that's
the
case.
There's
a
use
case
for
computational
systems.
That's
motivated
by
well
blockchain
systems
where
apparently,
they
would
like
to
have
some
kind
of
attestation
that
the
hardware
they're
running
is
real
hardware
and
is
no
powerful
than
a
certain
thing
and
has
not
virtualized
and
other
stuff
like
that.
But
one
of
the
key
points
is
that
all
of
the
members
are
testing
and
all
the
members
are
relying
because
it's
a
peer-to-peer.
I
N
O
So
here's
a
general
comments
and
general
comments
on
the
oh
one
draft
that
was
published
about
a
month
ago.
Some
this
was
the
first
major
revision
to
it
since
it
was
draft
about
a
year
ago.
One
of
the
major
shifts
in
this
version
was
that
an
8
is
considered
to
be
either
a
CW,
T
or
a
JWT.
It
can
be
either
and
the
whole
document
Orient's
around
that.
So
that
was
a
there.
O
O
So
doing
that
now
the
document
inherits
a
lot
from
those
documents
and
I
think
this
is
a
good
thing.
Simplifies
things
less
text
to
write.
There
may
be
some
leftover
stuff
in
the
the
draft
from
before
what
it
wasn't,
but
we
can
clean
clean
that
up
anyway.
So
inheriting
it
inherits
things
like
claim,
optionality,
it
inherits
the
verification
process
and
it
inherits
the
Ayana
process
and
I
think
these
are
things
we've
had
some
discussions
about,
but
if
you
really
look
at
what
weirdest
is
I
think
where
it's
landing
and
and
I'm
happy
about
this.
O
Another
thing
that
this
document
does,
as
this
version
does,
is
defines
the
claims
in
some
text
plus
CD
DL,
and
then
the
CD
DL
is
used
to
basically
mechanically
or
procedurally
derive
that
JSON
or
the
C
War
for
the
actual
serialization.
So
tomorrow
we
have
some
discussion
about
data
model
versus
information
model
and
how
all
that
fits
together,
so
I'm
not
going
to
go
into
that
today.
I'm
just
saying
that
this
is
how
the
o1
draft
is
set
up.
O
I
think
it's
nice
to
be
able
to
have
that,
based
on
the
CD,
DL
and
sort
of
describe
the
each
claim
without
going
into
any
details
of
the
Jason
or
C
port
representation
or
some
other
representation
and
that's
kind
of
becomes.
The
core
of
the
definition
of
the
claim
is
that
that
text
plus
CD
DL,
so
the
CD
CD
DL,
is
being
used.
Normatively
here,
I'm,
not
sure
that
that's
been
done
before
I
mean
in
every
everything.
I've
seen
doesn't
use
it
normatively.
O
O
D
P
Mike
Jones
I
think
we're
already
aligned
on
this,
but
I'm
at
Microsoft
I'll
state
for
the
record
that
when
we
developed
the
claims
in
the
job
and
the
COTS
backs
yep,
we
made
it
explicitly
use
case
driven.
We
wanted
to
look
for
clays
that
we
believed
there
were
existing
use
cases
that
would
use
them
immediately
and
if
so
we
put
them
in
and
otherwise
we
provided
registries
where
people
could
add
them
later
and
I.
Think
that's
that's
worked
out.
Well,
okay,.
R
O
O
So
the
the
the
first
issue
here
was
about
claims
optionality,
so
this
is
got
a
laser
here.
I
think
not
a
very
good
one,
but
so
this
was
the
current
text.
Then
I
went
and
read
the
text
in
CWT
and
JWT
I'm.
Just
throwing
button
there
and
said:
oh,
that
text
looks
real.
That
text
looks
really
good,
so
let's
just
use
that.
O
Q
D
I
Mike
actually
I
believe
that
the
text
should
say
profiles
must
override
this
because
I
think
the
whole
point
of
the
profile
is
to
say
which
ones
they
actually
want
to
use
right.
So
if
they
don't
do
that,
then
they're
not
a
profile
or
not
useful
as
a
profile
right
so
I
think
that's
actually
thing
so
your
document,
it
should
say
tomorrow
they
are
all
optional.
Of
course
right.
But
someone
who
writes
it
whatever
is
gonna
a
profile
is,
it
needs
to
say
what
they're
using
and
if
they.
I
O
O
Okay,
good,
okay,
now
or
something
kind
of
different,
so
UE
IDs
are
an
identifier
kind
of
like
a
serial
number,
but
not
really
a
serial
number.
They
they
identify
individual
instances
of
something.
If
you
have
a
million
phones
and
there's
a
million
different
UE
IDs,
so
you
ideas
may
have
something
made
up
a
new
concept,
a
new
idea,
new,
a
new
name
for
something
you
yeji's
did
not
exist.
Prior
to
the
a
draft.
There
are
two
types
of
uue
IDs.
O
One
is
based
on
kind
of
a
something
very
well
can't
be
based
on
the
I
Triple
E
identifier,
which
is
often
a
mac
address.
So
it
can
be
based
on
that.
So
that
seems
all
pretty
straightforward,
but
there
were
a
number
of
comments
and
questions
about
UE
IDs
as
random
numbers.
So
the
idea
is,
you
can
have
you
Eid
that
it
a
random
number
at
least
120
128
bits
should
be
cryptographic
quality
and
if
you
generate
your
Yui
IDs
that
way,
there
will
be
enough
collision
resistance
that
it
will
work
just
fine.
O
So
there
were
the
two
issues
were
raised.
One
was
is
128
bits
enough
and
then
the
other
is
is
a
statement
about
cryptographic,
quality
enough,
I
guess.
The
third
issue
here
also
from
Tom
F
was:
are
you
know?
Are
they
good
in
other,
so
another
version
of?
Are
they
good
enough?
So
I've
done
some
math
here
on
the
128
bits.
Hopefully
my
math
is
right,
but
it
seemed
like
enough
bits
and
then
cryptographic
quality
saying
it
must
be
a
cryptographic
quality
number.
That's
the
text
for
it
right.
There.
S
All
right,
Stuart
Cherisher
from
Apple
I'm,
not
sure
whether
128
bits
is
or
it's
not
enough,
but
your
reasoning
there
I
think,
is
flawed.
Using
the
assumptions
you've
got
there.
The
probability
of
my
phone
conflicting
is
one
in
freedom
per
trillion.
You
do
that
a
trillion
trillion
times
the
probability
of
two
devices
conflicting
is
guaranteed
and
if
you've
not
heard
of
the
birthday
problem,
look
it
up
on
Wikipedia.
It
will
explain
the
correct
way
to
do
this
analysis.
Okay,.
T
Thomas
Thomas
was
easy.
Consulting
I
can
give
you
the
formula
a
spreadsheet
which,
given
your
maximum
population
size
and
you
expect
a
population
size.
What
is
the
probability
of
collision?
This
is
a
known
thing
and
I
put
in
a
nut.
It's
in
a
number
of
my
graphs,
especially
looking
at
number
my
graphs
and
I.
T
O
Found
it
I
looked
at
the
UUID
and
I
explicitly
did
not
like
the
UI
deeds.
It
seemed
like
the
constructs
were
really
complicated,
were
overly
complicated
and
they
predated
the
idea
of
doing
it
with
just
a
cryptographic
quality
random
number.
Sometimes
you
ideas
are
ephemeral,
sometimes
they're,
not
so
I
found
it
easier
to
just
to
go
this
direct
this
way.
So.
U
I
think
you'll
find
the
established,
math
and
ecosystems
around
you.
You
IDs
will
give
you
exactly
what
you're
looking
for
with
less
work
with
less
definition
in
your
document
and
will
do
everything
you
need
to
do
your
you,
IDs
are
well
studied
and
widely
deployed
pretty
much
everywhere.
So
it's
something
we're
thinking
about
mm-hmm.
G
V
D
E
W
D
D
W
W
W
O
All
right
so
some
characteristics
of
signing
keys,
there's
some
text
in
the
document
that
says
the
eat
is
always
signed
by
the
attestation
key
material
provisioned
by
the
manufacturer,
so
some
suggests
removing
this
to
allow
for
ephemeral,
keys.
Some
suggest
strengthening
key
protection
requirements,
requirements
around
the
signing
keys
as
far
as
I
can
see,
CWT,
EJ
and
and
GWT
do
not
make
any
comments
about
signing
keys,
I
mean
I,
guess
kaze
does
say:
generally
you
should
protect
your
signing
keys.
O
My
sense
of
this
is
that
most
of
the
characteristics
of
signing
keys
belong
in
profile
documents
and
that
we
want
to
be
pretty
similar
to
the
way
JWT
and
see
GWT
work
in
the
eight
draft.
So
that
probably
means
removing
this
text
and
generally
going
to
the
making
sure
that
we're
lined
up
around
that
comments.
Please.
Q
Hi,
this
is
Hank
might
not
be
a
big
surprise,
but
some
suggest
strengthening
heat
protection
requirements
since
interest
to
me,
because
we
are
legislation,
trust
Britain,
there's
a
little
bit
yeah.
So
if
it's
just
my
rich
system
committee,
rated
from
a
home
directory,
that's
something
that's
entirely.
If
it's
a
shielded
secret
that
has
some
restriction
on
it
to
access
it,
that
you
have
to,
for
example,
Shah
Integra.
Q
And
say
life
is
good
because
an
attestation
Troughton
it's
highly
important
to
convey
the
this
information,
or
at
least
a
way
to
get
this
information,
because
if
the
eat
itself
tells
you
I
was
signed
by
a
super
QoS,
well
a
secure,
a
key
that
doesn't
enrich
the
information
at
all.
It
can't
just
be
like.
So
maybe
maybe
there
has
to
be
a
game
that
shows
there's
a
reference
to
some
song.
I,
don't
know
ta
that
confirms
this
in.
O
Q
W
Gary,
mine
didn't
Qualcomm,
sorry
I
get
it
by
myself,
but
I'm.
Actually
the
opinion
that
the
Senate
said
that
the
Senate
is
okay
and
I
actually
file
a
sheet
on
the
ephemeral
he's
based
on
the
based
entropy
from
arm.
But
that
wasn't
my
personal
feeling.
Is
it
a
femoral
keys?
It
should
not
be
used
for
signing
that
Westbay
themselves
are
attested,
and
now
you
get
into
a.
D
W
Okay,
yeah
how
you
tries
to
keep
into
your
now.
You
have
to
have
tested
that
you
know
I'm
smelling
so
for
each
I.
Think
if
you
at
the
top
of
the
top
of
the
token
should
have,
it,
should
have
some
level
of
assurances
associated
with
its
key
material.
That's
done
by
having
a
key
material
vision
record,
but.
O
I
mean
the
question
to
me:
still
is
what
goes
in
the
draft
versus
what
goes
elsewhere
and
I'm
still
kind
of
looking
for
the
consensus
there,
and
it
seems
seems
to
me
still
that
the
key
material,
the
strength
of
key
material
should
not
be
in
the
draft.
Just
like
it's,
not
in
the
CWT
drafter,
the
JWT
RFC's.
F
So
I
disagree
with
the
previous
speaker,
I'm.
Sorry,
mr.
Dave
and
I
agree
with
the
proposal
to
move
the
tip
profile
documents.
I
submitted
a
number
of
different
use
cases
or
references
to
use
cases
that
Michael
put
into
the
use
cases
document
and
a
number
of
those
would
require
your
proposal
because
they
do
not
rely
on
some
menu
provision
by
the
manufacturer.
F
X
Adam,
whatever
critical
technologies,
I'm
agreeing
with
what
you're
saying
here,
it
should
be
not
in
the
eat
draft
to
make
it
more
general.
X
X
X
W
F
Hey,
there
are
many
different
use
cases
of
eats
like
whether
the
eat
goes
to
the
verifier
or
whether
the
each
is
part
of
the
SS
station
so
or
whatever
another
different
use
gives
you
different
ways
to
compose
it
right,
if
you
say
it's
key
material
that
is
trusted
by
the
receiver.
That's
a
perfect
thing.
Just
talk
about
the
security
considerations
and
manufacture
is
one
common
example.
That's
a
great
example
right,
but
there
are
cases
were
there
other
examples
that
still
use
key
material
trusted
by
the
receiver,
where.
D
F
W
O
Okay,
a
verification
process,
I
think
there's
two
uses
of
the
term
verification
and
verifying
that
are
in
rats,
there's
in
the
CWT
JWT
case
and
that's
mostly
and
there's
very
explicit
text
in
both
CWT
and
GWT.
That's
primarily
around
verifying
the
signatures
on
the
cosy
and
Jose,
then
there's
the
end
and
rats
verification,
mostly
Illumina,
so
so
I
think
eat
just
inherits
from
JWT
and
CWT.
So
I,
don't
think,
there's
any
need
for
any
that
text
in
the
eat
document
I
thought
about
it.
O
Q
Q
O
W
W
The
slide
it's
it's,
not
a
perfect
reflection
of.
Why
I
did
that
I
think
it's
more
along
the
lines
of
reflecting
off
of
reflecting
on
both
verification
guidance.
That
would
be
that
that
would
improve
the
readability
of
document
would
be
kind
of
necessary
for
an
independent
readers,
putting
that
in
all
in
one
section,
so
they
can
get
straight
to
it.
W
And
how
claims
are
claims
are
interpreted
by
verifies
that
the
week
will
be
questioned
if
we're
audit
review,
as
we
try
to
take
this
into
a
standard
and
it
was
I
would
like
to
get
ahead
of
it.
I
don't
think
it's
it.
We
could
put
that
underneath
under
the
individual
discussions
under.
Did
you
acclaims,
but.
O
It
before
closing
out
this
OC
this
so
CWT
and
JWT
a
don't,
say
anything
about
appraising,
checking
or
validating
the
value
of
the
claims
themselves.
They
just
disguise
the
signature
check
and
the
overall,
and
that
was
that's
and
and
to
me
that
that's
where
each
land
and
the
the
validation
of
the
claims
is
the
larger
and-
and
you
know
another
turtle,
yeah
I
think
we.
W
Y
Tony
yeah
Tony,
Hadley
I
noticed
he
didn't,
have
a
notion
of
a
presentation
or
a
presenter
right
of
the
claim
itself.
So
there
is
the
issuer
of
the
claim
and
then
there
may
be
a
presenter
of
the
claim
which
may
not
be
the
same
thing.
So
you
know
the
device
or
whatever
may
actually
have
a
claim
right
and
a
signature
on
it,
but
they
may
also
something
else
may
actually
wrap
those
up
into
another.
You
know,
since
you.
Y
P
Like
John's
Microsoft
I
was
going
to
give
an
example.
I
inhabit
your
office.
I
was
going
to
give
an
example
of
that
very
distinction
in
a
recent
job,
I've
seen,
which
is
the
security
event.
Token
specification
makes
a
distinction
between
issuer
and
presenter
for
exactly
the
reasons
that
Tony
talks
about,
and
at
least
us
we're
describing
that
linguistic
distinction,
which
is
a
semantic
distinction,
is
worth
maintaining
and
can.
P
O
Y
Y
D
R
C
O
O
You
know
I've
kind
of
described
the
entity
in
some
words
I'm,
not
that
happy
with
the
current
text.
Basically,
I'm
seeking
suggestions
and
advice
find
my
way
to
do
a
little
better
job
of
describing
now.
One
other
comment
I
do
have
about
that
is.
I
did
look
around
a
little
bit
to
see
who
else
uses
the
term
entity
x1
2,
5
2
defines
it
as
something
very
broad.
O
M
Comments
please
yeah
Robin
Wilton,
just
to
mention
there's
a
guy
in
Australia
called
Raja,
claw,
CLA,
okay,
who
defines
entity
as
part
of
a
taxonomy
of
identity,
anima,
T,
and
so
on.
It
not
say
that
should
change
the
definitions
you
have
here,
which
I
think
is
compatible,
but
it's
interesting
to
look
at
how
in
his
taxonomy,
if
it's
in
a
whole
lot
of
other
things
that
you
might
will
find.
Okay,.
F
Y
B
X
W
On
the
mailing
list,
I
don't
think
we
need
to
put
any
additional
guidance
in
this
document
on
the
use
of
Cawdor
jawed
registries,
but
registering
these
claims
registering
these
claims
or
any
cancer
profiles.
I
just
wanted
to
make
sure
that's
the
case
that
we
can
close
any
related
issues
in
the
day.
If
you
can
find
the
github
okay
I've
got
that
I've
got
a
copy
that
making
the
cutoff
of
a
grating
on
this.
If.
O
D
D
I'll
get
there
okay,
so
we
wanted
to
cover
the
milestone
since
we're
gonna
be
updating
them
so
on
tomorrow.
We're
gonna
be
talking
about
or
we
have
presentations
for,
updates
on
a
couple
of
the
drafts,
but
there
are
still
a
few
that
aren't
on
the
docket.
So
I
wanted
to
pulse,
because
there
was
some
discussion
that
perhaps,
on
the
token
bind
that
that
we
wouldn't
move
forward.
But
I
wanted
to
confirm
that
with
the
group.
D
Okay,
so
if
you
have
objections,
let
me
know,
but
I,
don't
think
it's
something
since
we
haven't
adopted
it,
it's
not
anything
that
we
need
to
take
to
the
list.
The
second
one
is
to
does
so:
I'm,
okay,
so
you're
not
presenting
on
to
dad
but
I'm.
Presuming
that
you
still
want
to
move
that
forward.
Yes,
we.
D
Q
D
You
you're
learning
yes
or
no
you're
learning.
Okay,
so
with
that
tomorrow
we
have
a
full
agenda,
so
I
encourage
everybody
to
review
the
the
new
updated
drafts
that
we're
going
to
be
discussing
tomorrow
tomorrow
we
are
going
to
allow
some
time
to
discuss
where
and
how
we
want
to
move
forward
visa
Vee
information
model.
Okay
with
that,
thank
you.
Everyone
see
you
back
tomorrow,.