►
From YouTube: IETF-SCITT-20230612-1500
Description
SCITT meeting session at IETF
2023/06/12 1500
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
F
G
D
A
Yep
Welcome
to
our
sort
of
weekly
virtual
intro
meeting
for
this
kid
working
group
we've
sent
around
well
last
week
at
last
week's
discussion.
We
concluded
that
we
wanted
to
talk
about.
The
registration
policy
is
at
this
meeting
in
case
you
have
some
other
topics.
It
would
be
good
to
bring
them
up
now,
so
we
can
do
a
little
bit
of
agenda
fine
tuning.
D
D
D
A
D
A
F
B
F
That
talk
in
a
minute
to
put
some
links
in
so
there
is
a
branch
in
the
public,
skit
Community
working
group
GitHub
for
my
implementation
of
the
end
to
end
receipts
process
which
people
are
free
to
look
at
and
discuss.
I
just
need
to
update
some
of
the
docs
before
I
turn
it
into
a
real
PR.
But
there
is
a
usable
implementation
and
the
Microsoft
provided
emulator
are
both
up
there
and
and
working.
If
people
are
interested.
A
A
A
So
you
can,
you
can
click
on
those
they
don't
contain
an
awful
lot
of
content,
but
we
talked
about
the
registration
policy
in
the
past,
and
the
architecture
draft
also
contains
a
little
bit
of
content
contains
a
few
attributes
of
that
policy,
but
it's
otherwise,
like
everything,
is
a
little
bit
on
the
on
the
sort
of
not
super
proposed
side.
So
the
question
is
like
for
me.
A
Obviously
we
want
to
make
some
some
progress
on
this
topic.
This
is
one
of
the
bigger
issues
in
the
architecture
document.
The
question
is
I'll,
be
a
little
bit
too
ambitious
here
for
an
initial
version.
Do
we
have
something
like
a
minimal
version
that
we
can
get
out
and
get
away
with
and
then
extend
it
later
on
or
where
are
we
with?
Are
we
with
this
topic
like
what
what's
the
sort
of
like
the
workable
version
that
we
could
put
together
without
going
a
little
bit
overboard
with
these
policies?
A
I
G
And
I
can
talk
hi
yeah
how
to
expediate
this.
We
need
a
functioning
middle
ground
in
specification
for
issue
messages
which
are
sign
statements
and
transparent,
Services
output,
which
is
a
transparent
statement.
That
is
correct.
Registration
policy
is
super
complex
at
the
very
least,
I
think
the
Gateway
function
that
limits
issuers
to
transparency,
service
I
think
should
be.
There
should
be
understood
how
that
works,
and
then
we
are
good
they're,
not
adding
anything.
G
It's
like
a
trusting
customer
I
assume
so,
which
Gateway
keeps
a
a
limited
number
of
issues
to
the
service,
I
think,
and
if
that
would
be
a
long
enough,
not
enough
flowing
food,
then
you
can
iterate
on
that.
This
is
me
speaking
without
anyone
having
a
stake
and
implementation
next
to
John
here
so
I
would
now
sneakily
put
that
Spotlight
back
keeps
on
and
ask
him.
G
F
F
F
One
is
going
down
the
road
of
formally
specifying
identities,
that's
how
we
got
into
all
the
did
web
and
did
urn
stuff
before
again.
If
people
feel
strongly
that
we
need
it,
I'm
happy
to
go
down
that
road,
but
actually
I,
think
it's
unnecessary
for
the
architectural
description
of
what
a
a
registration
policy
does
and,
more
worryingly,
at
116
we
had
a
bunch
of
conversations
about
how
registration
policies
might
be
much
more
complex
than
gatekeeping
the
requester
and
actually
include
all
sorts
of
other
contextual
abec
style
stuff.
F
Even
I
I,
don't
even
know
it
won't.
My
idea,
so
I
can't
represent
them
Faithfully,
but
there
were
ideas
of
registration
policies
having
some
semantic
understanding
of
the
payload
itself
and
I
wanted
to
make
sure
we
get
that
all
very
clean
and
clear
in
what
the
the
needs
of
the
group
are
because
I
think
that's
you
know,
making
it
more
complex
than
what
you
said.
F
F
Her
did
quite
a
bit
of
work
around
the
the
spec
at
116
hackathon
to
try
and
deal
with
things
like
that
and
then
Ori,
who
actually
is
here.
Okay,
so
or
you
might
remember,
better
Orion
and
at
least
both
of
those
people
I
think
some
others
were
looking
at
the
implications
of
remembering
and
Reporting
the
registration
policy
that
was
in
place
at
the
time
that
a
statement
was
made,
which
is
a
kind
of
Middle
Ground
I,
actually
quite
like
that
idea,
but
again
it's
more
complex
than
absolutely
strictly
necessary.
F
A
A
E
A
The
I
was
primarily
sort
of
like
there
needs
to
be
some
information.
I
can,
let's
use
the
DLS
as
an
example,
so
to
have
fewer
options
like
in
DLS
you.
If
you
get
a
certificate
from
this
server,
you
need
to
have
a
trust,
anchor
store
with
a
trust
with
one
or
more
trust
anchors
that
allow
you
to
do
the
path
validation
to
verify
the
the
signature
of
what
you've
received
through
the
protocol,
and
you
need
something
similar
something
kind
of
equivalent
in
in
this
context
as
well.
E
A
But
unfortunately
you
somehow
have
to
talk
about
those
as
well,
because
there
are
subtle
details
on
how
let's
say
it
did
web
did
key
Etc
works
with
relationship
to
these
trust
anchors.
They
all
have
something
equivalent,
because
otherwise
it
won't
work.
But
it's
just
different
terms.
Different
everything.
C
John
mentioned,
you
know
several
things
that
we
talked
about
and
they
are
kind
of
complicated
details,
but
the
I
think
the
primary
complicated
one
that
maybe
it's
possible
to
to
remove
from
the
discussion
is
the
dependencies
between
different
envelope
formats
as
related
to
a
registration
policy.
So
you
know,
for
example,
if
you,
if
you're,
storing
your
policies
in
the
transparency
service,
and
you
want
to
basically
reflect
the
policies
that
were
in
place
at
the
time
at
which
a
signed
statement
was
made
into
a
transparent
statement.
C
You
can
do
that
by
including
identifiers
in
the
transparent
statement
that
we
returned
and,
as
you
do,
that
you
start
to
build
the
sort
of
like
these
graphs
of
like
well.
This
thing
required
these,
and
these
are
the
policies
that
were
in
place
at
this
time
and
that
can
get
complicated
and
it
can
also
be
allowed
without
us
specifying
it
as
long
as
we,
you
know,
sort
of
describe
that
you
know
these
are
the
extension
extension
points
that
you
can
make
use
of.
You
can
make
use
of
the
protected
header.
C
You
can
make
use
of
the
unprotected
header,
and
you
know
what
you
do
with
those
values
is
kind
of
your
business,
but
it's
not
necessarily
ours.
The
issue
is
that
if
you
want
a
consistent
way
to
refer
to
a
sign
statement,
that's
been
made
transparent
in
a
particular
service.
You
will
have
to
sort
of
describe
some
identifier
scheme
for
that
it
could
be
a
URL.
C
So
that's
just
you
know
a
summary
of
kind
of
what
was
discussed
and
yeah
I.
Think
you
know.
The
important
part
here
is
like
you
have
signatures.
You
have
issuers,
those
are
the
entities
that
are
doing
the
signing.
You
need
to
discover
keys
that
are
authoritative
for
those
issuers.
Every
verifier
relying
party
may
have
their
own
way
of
doing
that,
but
you
won't
be
able
to
discuss
verifying
without
discussing
issue
or
identity
in
some
format.
That's
it.
C
Think
it's
what's
produced.
It
was
to
my
understanding.
It
was
out
of
scope
originally
to
discuss
policy
specific
details,
so
right,
I,
think
we're,
including
a
reference
to
a
policy
by
including
a
URI
or
URL,
is
something
that
you
can
always
do,
but
it
shouldn't
there
shouldn't
be
any
interoperability
impact
from
the
decisions
that
we
make
on
that
now,
if
we
say
actually,
there
are
these
specific
header
properties
that
are
supposed
to
be
used
to
establish
interoperability
around
references,
then
it's
in
scope.
A
F
B
So
I
think,
should
we
just
kind
of
because
a
bit
of
a
registration
policy
detail
could
be
a
very
much
an
implementation
kind
of
a
aspect
of
a
transparency
service.
Can
we
keep
it
at
a
high
level
where
we
say
that
the
minimum
guidelines
or
minimum
registration
policy
requirements
we
should
state
in
the
architecture
and
and
and
leave
it
to
there,
because
otherwise
we're
going
in
a
circle
where
there
is
very
much
tied
to
an
implementation
which
could
lead
to
an
endless
kind
of
circles
there?
B
Something
like
the
registration
policy
is
required
to
validate
the
issuers
with
a
certain
like
uniquely
able
to
identify
the
issuers
unambiguously
and
can
be
recognized
using
some
known
trust
anchors
or
something
like
that
at
a
high
level.
What
is
what
we
should?
The
registration
policy
should
do,
rather
than
how
it
should
do.
A
B
What
what
kind
of
ease
out
our
responsibility
in
a
way
that
we
don't
force
a
specific
way
of
doing
registration
policy,
because
policy
is
very
kind
of
complicated
matter?
And
if
you
lock
down
ourselves
to
a
very
rigid
policy,
then
also
it
reduces
the
scope
of
our
architecture.
I
think
so.
That's
all
I
wanted
to
say.
Okay.
D
D
Just
that
idea,
maybe
that'll
be
helpful
to
to
think
about
this
and
and
I.
It
was
helping
me
with
the
air
gap
thing,
because
what
I
came
to
was
that
it's
going
to
be
really
useful,
just
to
use
TLS
in
some
form,
for
both
sides
of
that
and
and
that
that's
going
to
be
a
another
good,
powerful
idea
that
can
help
thanks.
E
We're
already
talking
about
probably
trees
of
data
to
evaluate
with
the
current
security
posture
is
based
on
cves
and
vexes
and
s-bombs,
and
things
like
this
dealing
with
those
receipts
at
bulk
and
knowing
that
the
configuration
or
the
the
identity
trust
has
changed.
Since
the
last
time
we
audited
is
why
I
was
driving
to
say,
hey,
we
kind
of
need
some
Escape
hatched
here
to
understand
what
the
configuration
is.
There
was
other
thoughts
that
Hank
and
others
proposed
of
hey,
there's
a
feed,
but
not
everybody's,
going
to
be
sitting
monitoring
the
feed
2400
24x7.
E
So
this
is
a
way
to
deal
with
stored
or
air-gapped,
or
things
carried
across
boundaries,
both
you
guess
and
and
rare
correct
that
that
we
could
get
by
with
an
initial
State.
The
question
is:
do
we
want
to
think
about
it
now
because
pretty
soon
we're
going
to
have
to
do
something?
If
we
start
getting
clouds
federations.
A
E
Fair
I
think
from
a
a
product,
that's
built
with
the
skip
building
blocks,
there's
a
different
set
of
policy
outside
of
this
right.
So
you,
you
know
you
could
Envision.
Only
people
that
are
approved
to
be
able
to
publish
to
a
products
cluster
makes
sense,
but
that's
more
of
an
hour
back
problem
that
doesn't
belong
in
the
notary.
Ledger.
Half
of
this
thing.
E
What
really
is
in
the
The
Ledger
portion
of
it
is
what
identity
providers
and
what
sources
are
we
going
to
to
evaluate
and
store
the
information
for,
because
you
kind
of
need
to
know
that
it
passed
some
policy
bar
and
what
that
policy
bar
is
before
you
accept
the
receipt,
the
receipt
isn't,
a
hey,
you
can
go
back
to
The
Ledger
and
go
and
retrieve
all
the
raw
information
and
rebuild
the
certificate
chain,
or
did
document
yourself.
It's
more
of
a
case
of
hey.
It
exists.
E
H
E
G
Yeah
this
is
me
just
being
an
interim
summarizer.
So
what
I
a
true
strippered
is
that
I
think
pretty
much.
Everybody
agrees
that
a
key
list
of
public
Keys
somehow
is
required
to
have
validate
issue
identities.
If
you
don't
have
the
key,
that's
the
Gateway
gatekeeper,
not
in
so
that's
that's
called
this
list
of
public
Keys
wherever
you
get
them
from.
If
it's
a
justification
path,
this
is
basically
the
term
that
you
use
instead
of
a
certification
path.
G
That's
right
certificate
chain
today,
and
so
it
doesn't
matter
where
it
comes
from,
although
where
it
comes
from
the
influence,
the
second
item
here,
so
if
that
is
an
agreed
one,
the
next
step
we
have
to
agree
on.
How
is
that
represented?
How
do
we
represent
that
list
of
public
keys
that
are
coming
from
things,
for
example,
pkx,
certification,
Brands?
G
Then,
if
you
know
how
to
represent
it,
then
you
have
to
understand
where
to
find
it.
That
of
course
relates
to
bad
stored.
We
have
this
appendoli
log.
You
can
store
things
in
there.
I
heard
that
feed
might
not
be
the
only
thing,
because
you
have
to
monitor
that
and
or
have
an
understanding
of
at
least
when
last
you
monitor.
G
That's
your
current,
no
understanding
of
what
the
registration
policy
probably
looks,
fine
and
if
you
know
where
it
start,
how
to
point
at
it
from
a
receipt
that
is
basically
the
representation,
the
identifier
also,
if
you
are
just
not
needing
that,
so
so,
I
think
these
four
items
we
have
to
agree
on
somehow
in
in
sequence,
maybe
maybe
in
parallel
I,
don't
know,
and
then
we
can
progress.
Everything
because
then
have
a
baseline
registration
policy.
G
G
F
G
So
what's
the
representation
of
the
identifier
here,
the
lookup
or
resolve
whatever,
and
so
we
had
for
the
for
the
where
to
start
I
heard
some
concerns
that
feed
might
not
be
good
enough
and-
and
that
is
something
we
have
to
discuss
then,
but
I
think
these
four
decision
points
you
have
to
pass
and
then
from
there
we
can
write
text
pretty
fast
and
do
all
the
minimal
required
things
here
and
then
we
can
progress.
I
think
that's
my
naive
point
of
view.
Maybe
there's
some
caveats
there
yeah.
J
J
In
other
words,
you
know
this
notion
of
a
trust
anchors
in
a
list
of
keys
kind
of
way,
because
I
think
we
all
know
that
over
time
any
given
issuer
might
be
compromised.
So
a
relying
party
can't
just
trust
all
the
statements
that
make
it
into
a
particular
instance,
because
going
back
perhaps
some
arbitrary
amount
of
time
you
might
say
wow
that
that
issuer
was
actually
compromised
and
you
can't
trust
it.
So
relying
parties
still
already
have
to
deal
with
that.
J
J
Yeah
yeah
the
upward
framework.
It
provides
some
great
ways
to
deal
with
compromise
and
key
rotation
and
so
on
and
and
I
think
that
incorporating
that
into
the
inner
works
of
things
is
going
to
be,
in
a
sense,
more
helpful
than
trying
to
add
even
lots
of
issuing
party
registration
agreements.
So
I
don't
know
just
some
some
random
thoughts,
but
it
the
more
complexity
and
the
more
optional
stuff
and
the
more
opaque
stuff,
the
less
possible
it's
going
to
be
for
people
to
make
trustworthy
decisions.
You
know
to
make
actually
valid
decisions
thanks.
A
J
Well,
I
mean
I,
so
what
I'm
saying
is
that
as
a
relying
party
I
would
want
to
understand
things
like
tough
and
I
would
be
happy
working
with
people
who
sign
statements
using
keys
that
they,
you
know
assert,
are
using
tough,
but
that's
in
a
you
know
that
isn't
trying
to
make
I
I,
don't
know
they.
They
have
thought
through
a
very
you're
right
in
the
sense
that
they
have
thought
through
a
very
carefully
designed
set
of
policies
for
delegation
and
for
key
rollover
and
and
ultimate
trust
and
so
on.
J
B
Yeah,
so
basically,
what
I'm
trying
to
say
is
that
an
entity
X
registers,
initially
with
the
transparency
service,
to
say
that
hey
I
am
entity
X
and
it
it
has
an
identity
which
is
corresponding
to
entity
X,
but
it
is
using
for
five.
It
has
five
products
and
it
it
signs
these
five
products
with
a
different
identity,
but
it
produces
an
identity
X
as
part
of
the
transaction
when
it
is
registering
with
the
transparency
service.
So
the
transparency
service
identifies
that
this
is
a
guy
X.
Who
is
issuing
these
statements?
B
E
E
We
don't
even
talk
about
the
authenticated
connection
portion
of
this.
What
really
matters
is
the
signature
on
the
statements
themselves.
Those
are
the
things
that
are
validating,
whether
it
comes
over
a
a
pipeline
that
comes
from
a
factory
or,
let's
say,
AWS
or
or
cool,
has
a
build
service
they're
just
a
way
to
get
into
the
system
they're,
not
making
any
claims
of
of
the
product
or
whatever.
It's
the
statements,
identity
that
we're
talking
about
here
and
has
nothing
to
do
with
the
authentic
connection.
E
Correct,
but
it's
based
on
the
identity,
it's
similar
to
you-
can
have
your
wife
go
and
take
in
your
signed
contract
with
a
notary
on
it
from
from
from
Ontario
as
long
as
it's
Ontario
notary,
that's
understood
the
fact
that
your
wife
brought
it
in
doesn't
matter.
It
doesn't
change
the
statement
that
the
notary
backs
your
your
signature
right,
the
transport
mechanism,
how
it
got
to
to
the
notary
is
not
as
important
as
the
actual
contract
and
the
notarization
stamp.
E
D
Yeah,
but
this
will
be
a
really
good
example
of
a
registration
policy,
because
the
notary,
like
a
real
notary,
has
to
witness
the
actual
signature
of
the
person
signing
it
and
they
have
to
sit
there
in
real
time
and
verify
the
ID
and
so
forth
of
that
person.
So
the
idea
that
I
don't
think
they
allow
the
wife
to
bring
in
a
science
document
that
they
don't
witness.
That's
a
policy
of
what
you
would
be
the
you
know,
I.
H
I
totally
agree
with
that:
we're
really
spending
a
lot
of
time
on
you
know,
notaries
and
receipts
and
that
sort
of
stuff,
but
if
I
know
the
party,
if
I'm,
Hitachi
and
I'm
Contracting
with
I,
don't
know
you
know
Mitsubishi
for
part,
we
have
a
long-standing
relationship.
I,
don't
need
a
bunch
of
verification
on
that.
H
My
concern
is
mostly
that
we
can
track
Mitsubishi's
performance
on
delivery
and
all
that
stuff,
and
so
I
really
would
caution
us
about
getting
too
far
down
the
road
with
the
various
metaphors
of
you
know:
notaries
in
the
real
world
and
so
forth.
The
important
thing
here
is
the
payload,
not
so
much
the
you
know
the
the
various
pieces
of
administration
around
it,
which,
in
my
opinion,
are
you
know
optional,
additional
things
that
help
the
functionality,
not
vice
versa.
D
Yeah
well,
that's
true.
I
mean
that
the
point
there
is
that
you
can
and
what
I
actually
wanted
to
bring
up
was
was
how
let's
encrypt
used,
what
what
they
did
was
they
they
look
for
actual
evidence
on
the
domain
to
prove
that
the
domain
was
operated
by
the
you
know,
vanity
that
was
claiming
to
own
that
domain,
so
that
you
know
if
you,
if
you're
a
big
entity
like
Hitachi-
and
you
know
the
rest
of
these
big
companies,
then
certainly
you're
going
to
have
already
a
certificate.
That's
that's!
D
You
know
formal
certificate
and
there's
no
problem
509
certificate,
but
within
the
software
like
open
source
software
World,
you
don't
have
these
necessarily
established
entities,
you
may
have
people
submitting
it
and
the
the
idea
would
be
that
you
could
maybe
leverage
the
concept
of
how
what's
encrypt.
Does
it,
where
what
you're
doing
is
you're
having
a
skit
machine,
just
witness.
Okay,
look:
I
went
back,
and
this
guy
proved
that
he
has
this.
D
You
know
private
key
that
is
associated
with
the
public
key
at
this
time
and
and
so
then
the
skit
machine
is
witnessing
that
that
may
be
so
so
it
may
be.
The
policy,
though
Charlie
that
that
you
say
well
look
I,
need
a
wet
signature
on
things
or
I,
don't
like
I,
I'm,
I'm,
okay,
with
with
just
getting
you
know,
claim
that
they
have
this
private
key
or
or
that
they
have
the
the
artifact.
D
So
the
artifact
issue
is
another
one
where,
if
somebody
walks
in
and
says
here's
a
hash
value
and
and
I
have
this
artifact
on
my
side,
I'm
not
going
to
actually
let
you
see
it,
but
I
claim
to
have
it
well,
you
have
to
substantiate
that
claim
by
by
you
know,
give
giving
it
maybe
a
a
random
number
and
say
well
now
hash
it
with
this.
Random
number
is
the
same
way.
Hmap
does
and
then
you
do
it
two
times.
So
you
give
a
void
so
forth.
D
So
then
you
get
a
value
back
and
anyone
else
who
gets
that
could
do
the
same.
Here's
that
random
number
and
I
can
validate
that
when
they
got
the
guy
does
have
it,
even
though
we
didn't,
we
didn't
actually
exchange
it
or
actually
ever
see
it,
but
bringing
this
back
around
the
registration
policy.
I.
Think
the
question
in
my
mind,
is:
is
it
just
a
matter
of
of
how
well
we
check
the
certificates
and
so
forth?
D
Like
Charlie
says
we
already
know
these
entities,
we
don't
have
to
check
too
much
as
long
as
they're
in
our
list
or
we
have
to
have
wet
signatures,
or
is
it
more
than
that
on
saying
it
has
to
follow?
It
has
to
be
a
spdx
s-bomb
submission
before
I
accepted
and
so
forth.
That's
getting
kind
of
too
far
in
the
weeds
I
would
think,
but
that
I
think
is
a
question.
That's
good
to
talk
about
thanks.
A
I
C
I
F
D
I
Just
wanted
to
bring
a
point
like
I
understand,
Neil,
of
keeping
like
it's
simple,
but
I
also
see
a
lot
of
use.
Cases
where,
like
maybe,
for
example,
in
iot
or
stuff,
we
don't
have
the
power
to,
for
example,
verify
the
same
policy
with
the
same
concept,
not
for
like
the
same
level
of
security.
So
as
like
I
was
mentioning
also
like
right.
I
For
example,
if
we
want
to
I,
do
not
verify
that
the
private
Keys
Kept
Secret
inside
the
like
it's
completely
secret
and
stuff,
we
might
go
further
in
the
check
of
policies,
but
at
runtime
we
may
just
need
to
verify
that
it
was
not
later
on
invitated
or
removed
as
a
public
key.
So
I
feel
like
still
having
the
the
policies
there.
Something
can
fasten
up
once
we
we
are
run
time
without
removing
trust
or
without
moving
security.
I
I
would
say
so
if
you
like
I'm,
not
saying
that
you
should
be
inside
every
envelope
or
stuff
like
this.
It
might
also
be,
as
someone
suggested
directly
inside
The
Ledger,
that
we
can
query
and
check
which
policy
were
applied
or
how
were
the
policies
but
I
feel
that
removing
them,
let's
say
as
a
national
as
like
yeah
removing
them
completely
would
remove
some
use
cases
where
we
might
don't
want
to
reproduce
the
whole
policy,
but
maybe
just
check
the
validity
of
the
key
itself.
Still
so
now
we'll
move
the
stuff.
A
I
think
things
yeah
I,
don't
think
the
idea
is
to
remove
like
the
policy
functionality
all
together,
but
I
think
it's
just
a
question
of
what
is
coupled
at
what
stage
like.
Is
it
something
that
is
implementation,
specific,
both
standardized?
And
how
far
do
you
need
to
go
with
standardization
at
the
beginning
when
it
comes
to
sort
of
the
initial
version
of
the
protocol?
I
think
that's
that's!
Where
I'm
trying
to
make
a
judgment
of
what
the
group
wants.
I
Yeah
yeah,
nice-
sorry,
maybe
I
didn't
express
it
well,
but
yeah.
The
point
was
I
feel
we
need
to
standardize
still
how
we
what
we
applied.
Let's
say
it
so
that
I
can
avoid
reapplying
completely,
but
maybe
checking
a
sub
Justice
subsection
of
the
policies
or
these
kind
of
things
so
I
feel
I
would
need
completely
the
information
about
what
was
done
in
my
opinion,
so
that
I
don't
have
to
report
to
replicate
it
completely.
But
I
can
just
script.
Some
minor
points,
let's
say.
D
A
H
Can
you
hear
me
sounds
good
I
think
I
see
my
little
bars
Rising
here,
so
the
basically
the
you
know,
the
use
case
we've
been
talking
about
are
parties
that
don't
know
each
other
and
parties
that
have
no
exchange
of
hard
Goods
for
the
most
part,
we're
talking
about
I
think
the
major
use
case
that
a
lot
of
people
are
having
in
their
minds
here.
Maybe
it's
unstated,
but
it's
you
know
webcommerce
or
web
web
authentication,
and
things
like
that.
H
Think
if
you're
talking
about
a
strictly
software
use
case
you're
in
similar
situation,
because
you
know
you
know
identification
and
receiving
and
a
whole
bunch
of
those
things
are
just
you
know,
they're
all
self-attested
right
now
and
that
is
more
or
less
okay
to
start
so
I
would
Advocate
spending
less
time,
as
I
said
earlier,
on
the
superstructure
and
more
time
on
the
payload
and
how
that
how
that
could
be
stored
and
manipulated
in
volume
over.
Thank
you.
H
H
You
know
named
individuals
all
those
things
that
I'm
going
to
have
to
be
worried
about
when
The
Regulators
come
knocking
right,
so
yeah,
so
those
are
important
and
I
also
want
to
be
able
to
track
my
own
quality,
so
I
need
to
track
the
quality
of
suppliers,
and
it's
going
to
be
a
way
that
I
can
store
that
and
evaluate
it
in
real
time
for
the
most
part
or
periodically,
and
those
topics
just
haven't
gotten
any
attention
at
all.
So
I'm
concerned
that
we're
over
specializing
here.
A
Thanks
Charlie,
we
have
four
minutes
left
and
and
two
people
on
the
on
the
in
the
cube.
We
will
definitely
John
and
I
will
definitely
have
to
put
something
the
next
steps
on
the
mailing
list.
We
had
a
couple
of
good
things
brought
up
already,
so
we
will
sort
of
come
up
with
an
idea
on
how
to
move
forward
with
this,
but
Ray
and
and
Roy.
You
guys
still
have
the
the
floor.
D
Yeah
I
I
know
that
certainly
the
payload,
like
the
application,
specific
payload,
like
shooting
out
from
what
Charlie
said,
is
something
that
maybe
is
better
I,
don't
know,
if
maybe
it's
better
done
in
something
like
a
schema.org
type
thing
where
you're
working
on
the
exact
schema
of
the
content.
For
that
for
that
use
case.
D
D
We
can
basically
provide
the
mechanism
for
for
people
to
for
something
to
sort
of
review
things
before
it
goes
into
the
this
get
machine
and
and
yet
not
have
to
have
us
detail
out
exactly
how
it's
done
above
and
beyond
exactly
what
we
need
to
maintain
the
the
basic
certificates
and
so
forth
for
who's
putting
it
in
and
how
we
verified.
That
and
I
think
that's
the
basic
register.
H
E
Just
want
to
point
out
that
the
definition
of
of
s-bombs
and
Vex
and
cves
are
being
done
in
the
discussion
with
sisa
and
open
ssf
and
a
whole
bunch
of
other
committees.
The
relationship
of
those
documents
and
the
format
of
those
documents
is
being
defined
outside
the
ietf
and
that,
that's
perfectly
understandably,
acceptable
is
from
where
we're
seeing
because
there's
just
so
much
movement
between
various
governments.
At
this
point,
the
the
conversation
of
rats
and
how
it
does
things
invalidate
the
relationships
up
front.
I
have
no
problem
with
the
problem.
E
Here
is
how
do
you
detect
when
something's
changed
in
a
CCF,
confidential,
compute,
Foundation
sort
of
scenario
with
rats?
If
the
hardware
changes,
then
the
next
layer
is
not
going
to
run.
How
do
you
detect
in
this
case
is
exactly
the
same
thing
that
configuration
or
a
new
identity
provider
has
been
changed
since
the
last
time?
D
H
Yeah
I
too
I'm
happy
to
participate
in
that
Roy
and
Ray
I.
Just
think.
You
know:
we've
defined
that
I'm
involved
in
s-bomb
and
Vex
and
csap
and
all
kinds
of
other
crap
here
and
I'm.
So
I'm
very
familiar
with
all
that,
but
we
haven't
spent
any
time
on
how
we
would
you
know,
provide
a
utility
to
use
those
and
I,
which
I
think
is
the
the
essence
of
skit.
So
that's
that's
where
I'd
like
to
spend
a
little
more
time,
if,
if
possible,
so.
E
Make
sure
we
have
each
other's
thoughts
and
ideas
captured
correctly
then
we'll
I
sure
back
on
the
aliens
right
now
I
think
we're
missing
some
details
and
we're
talking
across
purposes
so
I'd
rather
have
an
author.
All
three
of
us
submit
something
into
the
mailing
list,
but
let's
get
it
clear.
First.