►
From YouTube: IETF-SCITT-20230220-1600
Description
SCITT meeting session at IETF
2023/02/20 1600
https://datatracker.ietf.org/meeting//proceedings/
B
B
D
D
D
They
were
I
posted
an
agenda
for
today
there
were
two
topics:
one
was
on
the
the
the
identity
topic,
which
we
also
discussed
on
the
on
the
mailing
list
and
then
the
second
one
was
some
terminology,
something
that
it's
an
open
issue
for
quite
some
time
already.
We
covered
that
if
time
permits
and
at
the
beginning,
I
also
wanted
to
very
briefly
talk
about
the
use
cases,
because,
as
you've
seen
last
week,
the
use
case
document
was
submitted.
D
E
Yeah
hello,
good
morning,
everyone
good
afternoon,
everyone
so
yeah.
Last
week
me
Hank
dick
Brooks
and
Monty
Wiseman
had
a
brainstorm,
and
we
kind
of
Incorporated
his
use
case,
because
his
use
case
was
slightly
a
different
flavor
of
what
we
already
have
a
firmware
update,
use
case,
where
what
we
focus
on
the
firmware
update
use
case
was
the
prior
to
applying
the
firmware.
E
What
checks
we
do
and
stuff
like
that,
but
his
use
case
is
using
skit
transparency
to
kind
of
elevate
the
post,
the
firmware
update
where
this
is
not
possible
or
in
use
cases
where
the
post
boot
activities
are
also
equally
relevant.
So
we
we
concluded
that
we
should
have
it
so
we
have
added
it
only
after
reviewing
the
document
once
submitted,
I
had
also
a
closer
look
as
Hennis
you
wanted
to
know.
Has
anyone
had
a
closer
look?
E
So
I
did
myself
reviewed
the
documents
and
I
felt
that
the
sequence
of
basically
the
the
the
the
secret
post
boot
thing
could
have
gone
in
the
last
subsection
of
this
list
of
sequences,
so
the
order
of
the
mess
use
cases
could
be
improved
a
bit,
but
I
thought.
Maybe
I
should
take
feedback
from
others
in
the
community
and
if
they
all
think
it
is
fine,
then
I'm
happy
to
go
ahead
and
change
the
order
and
I
am
planning
to
create
a
GitHub
issue.
If
every.
E
D
F
First
of
all,
I
apologies
for
being
late,
I'm
struggling
with
technology
and,
second
of
all,
I
think
it's
what
we
as
good
one.
First
do
we
want
to
go
through
adoption
core
first
and
fix
this
as
a
working
writing
because
effectively
we
are
tweeting
the
document
already
as
a
working,
providing
with
all
the
consensus
and
such
so
maybe
we
move
on
some
be
quick,
I,
think,
that's
that's
a
visibility
thing
and
then
fix
it.
F
D
Yeah
I
I
was
hoping
to
see
some,
like
obviously
like
I
expected
yogish
to
review
the
documents.
He
since
he's
a
co-author,
well
read
through
the
document
but
like
at
this
stage,
I
think
it's
the
the
real.
The
only
question
is,
in
my
opinion
whether
the
document
is
is
good
enough
to
as
a
starting
point
for
the
working
group,
because
then
we
would
start
the
the
call
for
adoption
or
or
not
so
yeah
so
Bob
do
you
have
a
view.
G
H
Oh,
thank
you.
Harness
yeah,
I
I,
concur
with
Bob
I
I
think
what
we
have
is
is
good
enough.
It's
it's
certainly
not
perfect,
but
there's
enough
there
I
think
to
set
us
on
a
path.
A
starting
point,
for
you
know
the
software
supply
chain.
So
I
would
agree
that
we
move
forward
and
adopt
the
document,
as
is
thanks.
I
D
C
That's
perfect
because
that
actually,
then
it's
part
of
the
reason
why
we've
been
pushing
so
hard.
The
last
couple
of
meetings
is
that
if
that
call
fails
for
some
substantial
reason,
we
just
about
have
time
to
do
an
edit
round
before
1
16
and
then
resubmit
it
for
116..
It
should
be
good,
so
yeah.
Let's
do
it.
D
J
Yeah,
perhaps
this
is
a
good
time
for
someone
just
to
review
the
the
full
set
of
steps
that
we
contemplate.
So
you
would
you
would
call
for
adoption.
People
would
discuss
that
if
it's
adopted
that
would
Tee
It
Up
for
good
review
by
The
Wider
community
and
the
working
the
ITF
meeting
itself
is
a
great
opportunity
to
do.
That
is
what
are
the
steps
that
would
follow
that
and
is
there
I
mean
this
is
for
publication
as
an
RFC,
yet
at
some
future
point
or
how
does
what's
the
rest
of
the
process.
D
Yes,
so
the
so
we
would
do
the
call
for
adoption.
Assuming
nobody
has
objections.
The
authors
would
then
resubmit
the
working
group
item.
There
would
be
enough
time
for
also
for
discussions
and
in
an
update
for
the
IDF
meeting
itself.
We
would
put
it
on
the
agenda.
The
next
IDF
meeting
we'll
discuss
it
there
and
probably
get
some
more
feedback
and
then
we'll
see
how
the
feedback
goes
and
at
what
stage
the
group
thinks
that
it's
ready.
D
J
So
in
what
is
what
are
the
considerations
in
terms
of
what
you
want
in
a
good
use
case
document
I
mean
I,
I'm
I'm,
guessing
that
it's
okay
for
there
to
be
things
in
the
use
case
that
don't
actually
get
addressed
in,
let's
say
the
first
version
of
an
architecture
or
an
implementation,
or
something
that
are
for
further
down
the
the
road.
Are
there
other
aspects
of
what
makes
it
quality
use
case
document
that
we
should
consider,
as
we
kind
of
think
about
how
mature
it
is.
D
Yeah,
it's
like
before
the
documents
it's
a
little
bit
in
the
eye
of
the
beholder,
but
in
in
general,
like
if
the
group
thinks
that
the
the
content,
the
use
cases,
inform
the
debate
on,
for
example,
the
architecture
and
also
like
the
requirements
that
come
out
of
it.
I
I
would
say.
Then
that's
actually
a
good
document.
D
D
F
That's
described
a
little
bit
more
than
what's
on
the
plate
right
now
and
and
then
also
maybe
have
an
idea
where
this
is
used
and
and
then
maybe
maybe
later
we
have
to
write
a
user
scenario
in
any
case,
so
I
think
it's
okay,
the
scope,
as
is,
unless
there
are
some
blatant
problems
with
it,
that
turn
up
are
doing.
Adoption
review.
H
H
It
has
to
provide
some
benefit
to
someone,
and
in
this
case,
My
Hope
Is,
that
the
consumers
are
the
beneficiaries
of
skit
and
that
the
skit
registry
answers
the
question
they
care
about
which
is
is,
is
a
piece
of
software
trustworthy
enough
to
install
in
a
in
their
ecosystem
and
I?
Think
if
we
can
give
consumers
that
visibility,
then
skit
will
be
hugely
usually
successful.
Thank
you.
D
J
All
right
there
you
go
I
just
wanted
to
again
push
back
on
the
notion
that,
like
there's
going
to
be
a
statement
in
skit
that
says
this
piece
of
software
software
is
trustworthy
and
you
should
trust
it.
I.
Don't
I!
Don't
imagine
that
that
that
there
will
be
a
statement
like
that.
I
would
frame
it
more
that
the
purpose
of
skate
would
be
to
document
evidence
which
each
individual
can
use
to
make
their
own
decision,
each
supplier,
provider
and
user
whatever
to
make
their
own
decision
of
other
for
their
purposes
their
threat
model.
J
D
G
D
D
D
I
I
I,
after
listening
or
reading
various
email
comments,
I
I
did
submit
an
email
just
before
the
meeting,
and
it
goes
along
with
what
Neil
was
just
saying:
there's
sort
of
a
disconnect
between
what
dick
usually
says
and
what
I
usually
see
as
what
the
transparency
server
of
skit
and
so
forth
are
doing
and
and
there's
kind
of
a
model
where
we
can
look
at
two
layers.
One
and
the
question
is
like
how
much
crud
do
we
add
on
to
one
entry
in
a
skit
you
know
server.
I
I
would
like
to
suggest
that
that
these
are
act.
You
know
kind
of
concise
and
simple,
and
it
may
take
a
lot
of
them
to
figure
things
out.
Kind
of,
like
a
risk.
Processor
has
small
statements
as
opposed
to
a
you
know:
a
assist
processor
that
tries
to
put
a
lot
into
each
one.
The
risk
process
is
very
powerful
because
of
the
Simplicity
and
the
same
with
the
transparency
server.
If
we
can
put
in
simple
claims
evidence
into
the
server
so
think
of
it
as
an
Evidence
or
transparency
server.
I
The
only
thing
that
goes
in
there
is
evidence
and
no
really
evaluation
of
the
evidence
and
then
there's
a
next
layer
up
which
would
be
an
evaluation
of
all
the
evidence
regarding
a
product
and
in
terms
of
how
old
is
it
you
know,
is
there
did
they
go
bankrupt?
All
these
things
are
pretty
complex
and
so
to
put
that
in
the
transparency
server
I
think
would
be.
I
I
You
know
specific
use
cases
and,
as
as
dick
was
saying
yeah,
he
wants
to
address
that
end
user.
Well,
that's
one
kind
of
use
case,
but
the
other
use
case
that
we
heard
about
which
I
think
is
maybe
going
to
be
more
common,
is
between
business
to
business,
supplier
and
user,
where
we
want
this
machine
to
be
really
streamlined
and
not
have
maybe
so
much
of
that
upper
layer.
Okay,
well,
I,
put
that
in
the
email.
I
think
it
might
be
a
good
thing
to
to
think
about
thanks.
E
Neil
and
one
more
I,
think
Bob,
and
that
this
system
is
ecosystem
is
not
only
for
end
user
or
consumer,
but
it
should
assist
the
all
the
stakeholders
of
the
system,
so
the
support
for
the
suppliers
also
how
Downstream
they
are
dependent
on
other
suppliers
and
those
kind
of
things
should
be
also
should
be,
should
also
benefit
from
our
ecosystem
and
in
addition
to
that,
there
are
auditing
and
those
kind
of
processes
also
baked
into
this,
which
are
also
users
of
the
system.
So
consumers
means
not
just.
E
We
should
not
see
it
from
one
prism
that
that's
what
I
all
I
wanted
to
say
and
what
Ray
mentioned
about
the
evidence.
Layer
I
think
it's
slightly
tricky,
because
the
evaluation
of
a
price
appraisal
of
evidence
is
very
much
could
be
policy
driven
based
on
individual
use
cases,
but
we
can
have
some
basic,
simple
verification
steps
like
yes,
this
claim
is
indeed
present.
E
K
Yeah
so
indeed,
I
think
we
are
largely
in
agreement
and
despite
I,
just
want
to
emphasize
that
I
think
it's
for
a
user,
knowing
if
some
artifact
is
trustworthy,
is
completely
legitimate
and
I.
Think
that
that's
that's
a
good,
that's
probably
the
simplest
way
of
using
skit,
but
I
really
believe
that
in
that
case,
the
parties
policy
should
know
which
issue
is
authoritative
for
that
artifact,
and
so
the
simplest
policy
is
that
I
I
I
want
to
know.
If
this
is.
K
That
I'm
a
trusting
for
it
and
as
long
as
it's
transparent
and
recorded
others
will
be
able
to
do
checks,
but
I'm
going
to
trust
a
clan
issued
by
that
party
by
the
data
effect
and
I.
Think
on
that
basis,
it's
much
easier
to
implement
them
to
assume
the
skid.
Ledger
will
be
authoritative
for
her
saying
whether
a
particular
artifact
is
good
or
bad.
K
So
I
and
I
think
there
is
a
lot
of
value
in
more
advanced
scenarios
where
fine
particular
in
the
business
to
business,
where
people
would
read
a
longer
or
more
complex
series
of
statements
and
we'll
do
some
auditing.
But
knowing
who
to
trust
as
an
issue
for
a
given
artifact
I'm.
Very
single
claim,
is
you
know,
songs
or
canonical
simplest
policy
for
our
heading
parties,
so
I
think
it's
legitimate
as
long
as
you
look
at
who?
The
visual
is
because
the.
K
A
Yeah,
just
I,
hear
this
and
and
I
hear
the
the
range
of
conversations
where
dick
is
talking
about.
Like
the
end
user
wants
to
be
able
to
have
some
trust
and
confidence
and-
and
we
all
agree,
I-
think
the
question
kind
of
goes
to
to
someone
to
what
Kathleen
has
also
brought
up
around,
who
the
end
users
are
and
do
they
actually
have
enough
knowledge
themselves.
You
know
we.
A
We
have
this
motto
where
we
do
defer
trust
to
entities
that
we
trust
that
are
making
the
analysis
for
us,
whether
it
be
you
trust
stuff
from
an
Apple.
You
know
the
Apple
Store
or
you
know
your
grocery
store
unrelated
to
Apples
as
well.
You
know,
I
think
that
that's
an
important
aspect
and
that
comes
back
to
a
brand
and
identity.
A
You
know,
if
you
have
two
documents,
one
that
you
know
has
this
whole
thing
about
how
software
should
be
done
a
certain
way
and
it's
just
a
blank
heading
you
find
on
the
street
versus
another
one
that
has
an
official.
You
know
government
agency
on
the
top
of
it.
That
is
gives
it
more
credibility
and,
of
course,
we
need
to
make
sure
that
it's
not
you
know
the
normal
checks
you
do
when
you
look
for
emails
or
things
that
are
phishing
attacks
right.
A
You
know
what
goes
on
because
it's
to
make
sure
that
the
identity
is
being
put
on
or
are
accurate
and
then
the
consumers
choose.
The
consumer
is
not
being
end.
Consumers,
the
the
entities
that
are
pulling
information
off
skit
will
use
that
information
to
make
logical
decisions
so,
whether
it's
you
know
Vex
and
s-bombs
today
and
some
new
document
in
the
future,
the
evolution
the
system
will
evolve
and
we
still
need
to
be
able
to
trust
the
source
of
information.
A
A
Is
you
know
what
we
know
at
that
point
on
April
1st
April
Fool's
Day.
We
get
infected
with
some
virus
that
actually
was
put
in
the
software
last
December,
but
we
didn't
know
about
it.
Yet
so,
there's
a
freshness
angle
that
we
also
need
to
make
sure
that
we
cover
as
well
so
I
believe.
All
of
those
you
need
to
go
back
to
a
source
that
you
can
get
information
that
you
trust
and
then
you
can
make
continued
decisions
on
that.
H
You
Johannes
so
I
I
agree
with
what
Steve
just
said
that
you
know
it's
really.
The
consumer
of
software
can
be
the
end
user
or
could
also
be
an
intermediate
intermediary.
Like
A
supplier
who's
bringing
open
SSL
into
their
product.
They
are
a
consumer
of
open
SSL
as
well
by
virtue
bringing
it
into
their
products.
So
it's
not
just
the
end
consumer.
It's
a
party
that
is,
you
know,
relying
on
the
trustworthiness
of
whatever
that
is
and
I.
Think
Neil
made
a
really
good
point
when
he
said
that
we're
making
a
statement
of
trust.
H
H
Or
are
we
saying
that
the
product
which
the
evidence
supports
is
trustworthy?
So
this
is
all
part
of
the
scope
and
the
purpose
of
skit
that
I
believe
we
need
to
nail
down
where,
where
does
this
trust
boundary
end,
so
that
when
someone
checks
skit
for
an
entry
in
the
registry?
What
does
that
entry
mean?
Does
it
mean
the
evidence
is
trustworthy?
Does
it
mean
the
product
is
trustworthy?
So
the
question
is:
what
does
a
skit
entry
really
indicate?
What
is
the
thing
that's
trusted?
Thank
you.
A
J
You
know,
I've
got
a
hack
for
this
and
you
should
you
know
contact
me
if
you
want
to
buy
it
on
the
black
market
and
I
I
I'll.
Note
the
the
ability
these
days,
people
have
post
papers
on
how
to
make
a
zero
knowledge
proof
that
a
piece
of
software
is
vulnerable
to
something
that
you
might
want
to
publish
before.
You
actually
reveal
how
it
works
and
try
to
get
a
bug
Bounty
or
whatever.
So
it
raises
for
me
the
question
of:
will
there
if.
E
J
Are
multiple
skid
instances
how
you
know
what
we've
we
usually
are
using
language
like
check
skit
as
opposed
to
look
at
the
skits
that
I'm,
you
know
interested
in
which,
of
course,
dramatically
complicates
the
life
for
the
relying
party?
How
do
you
find
the
skid
instances
that
might
have
evidence
that
you
wanna
to
work
with
and
do
we
have
any
use
cases
that
deal
with
that
notion,
if
they're
being
instances
that
are
more
authoritative
for
some
perceptions
and
others
that
are
very
interesting,
even
though
you're
really
not
sure
whether
to
trust
them
or
not?.
F
Yeah,
this
is
saying
sorry,
I
lost
track
of
my
my
notes.
There
I
I
switched
the
tap,
and
now
they
come
so
from
the
top
of
my
head.
So
dick
was
highlighting
customer
consumers
Bob
was
highlighting
yeah,
but
definitely
supply
chain
entities.
You
know
and-
and
you
said
I
told
us
to
do
a
small
recap
here,
but
it
should
not
include
the
decisions,
would
be
the
basis
for
decision
making
right
if
you
wanna,
I,
wanna
accountability
and
auditability
here
by
the
facts,
not
by
some
opinion
and
I.
F
Think
that's
that's
a
very
good
scoping
profession
of
content.
We've
never
talked
about
a
semantic
relationship
or
semantic
interoperability
and
labeling
items
there
are.
There
are
some
things
that
we
definitely
want
to
have
as
non-opaque
data,
for
example,
a
very
structured
thing
that
says
the
actual
content
you're
looking
for
is
not
here,
but
it
stored
at
some
other
place
because
it
already
existed
there.
We
are
not
transferring
the
whole
thing
here
so
there
are.
F
There
will
be
some
non-nopaque
structures
here
that
will
help
with
this
everyday
problems
like
where's
the
actual
data,
but
then
also
I.
Think,
that's!
That's
a
that's
a
that's
a
scoping
and
chartering
question
so
for
now
the
very
minimum
is
what
what
Neil
said.
I
think
it's
it's
about
the
basis
for
decision
making,
but
when
you
look
at
it
from
a
rats
point
of
view,
it
definitely
also
is
the
decision
making
is,
for
example,
endorsement
documents
like
reference
integrative
manifests.
F
These
are
statements
coming
from
a
supply
chain
entity
now
addressing
Bob's
scope
a
little
bit
more
and
they're,
of
course,
also
from
users,
but
the
other
users
sometimes
also
are
supply
chain
entities.
So
I
think
it's
it's
very
hard
to
differentiate
by
roles
such
as
consider
consumers,
supply
chain
entities
or
by
message
type
complexity
like
it's.
The
bear
I
want
to
say,
build
evidence
now
because
or
remote
attestation
evidence
or
some
other
evidence,
and
sometimes
it's
also
an
endorsement
or
a
result
that
you
may
want
to
make
publish
like
a
virus.
F
So
if
you
put
a
virus
scan
in
here
as
a
reaffirming
fact,
then
you
could
also
put
an
attestation
result
in
here
as
a
reinfirming
fact.
So
that's
not
the
pure
evidence,
anymore,
right
and
and
I
think
that
is
a
again
a
scoping
questions
on
two
parts:
it's
what
we
are
addressing
here,
who
are
the
communication
partners
that
consume
and
put
something
onto
skit
and
there's
another
dimension
here
about
the
complexity
of
the
message
you
put
into
skit?
Is
it?
Is
it?
F
Is
it
very,
the
original,
very
first
data
item
or
did
I
already
have
some
informed
opinion
about
it?
I
think
both
dimensions
are
okay,
but
they
have
to
be
very
documented
and
for
the
first
round
here
in
the
scope
of
this
Charter
I,
think
that
has
to
be
well
defined
and
we
that
that
might
be
part
of
the
threat
security
model.
It
might
be
part
of
the
architecture,
but
I
think
it
must
become
an
issue
or
a
task
that
we
address
these
two
dimensions.
D
G
G
F
G
Know
enough
has
been
done
that
you
can
rely
on
this
product
if
you're
making
a
different
product,
you
would
have
a
different
Ledger
and
in
the
permissions
would
be
the
you
know.
Are
you
from
this
company
and
therefore
authorized
to
write
to
it
or
about
these
product
lines,
but
then
there
could
be
other
ledgers
where
you're,
making
a
more
public
statement
and
you're
using
the
facts
from
those
kind
of
more
confidential
corporate
ledgers
to
support
it
and
you're
endorsing
what's
there
but
making
it
more
publicly
available
and
searchable.
G
I
D
B
C
C
So
so
that's
the
the
line
we're
going
to
and
now
there's
a
request
for
concrete
examples
of
where
this
is
is
useful
or
to
Neil's
question
about
the
various
different
roles.
So
I
have
two
which
I
think
illustrate
this
very
nicely
of
real
things
that
I
actually
do
commercially
so
for
the
UK
and
us
well,
UK
public
sector
and
the
usdod.
C
But
you
know
same
same
kind
of
same
kind
of
thing:
we've
done
some
some
projects
and
feasibilities
on
large
collaborative
systems
and
in
particular
the
basic
thing
is
to
say:
well,
if
I'm
going
to
have
self-driving
vehicles
on
the
road,
with
AI
models
controlling
how
they
conduct
themselves,
there
are
lots
and
lots
of
moving
Parts
here
and
somebody
can
say:
yeah
we've
just
published
the
software
and
that's
great
and
somebody
else
can
publish
the
firmware
for
a
particular
chip.
That's
in
the
car.
C
So
we
absolutely
have
real
life
cases
today,
where
many
people
can
make
claims
on
things
that
they
don't
even
own,
which
may
or
may
not
be
interesting
to
a
large
community
of
different
relying
parties
on
the
other
side.
Just
to
illustrate
the
question
of
whether
things
are
actually
true
or
not,
because
we
do
talk
about
these
claims
or
statements
or
whatever
on
the
build
side,
something
that
I
do
something
my
company
does
for
a
bit
of
transparency
is
that
we
publish
vulnerability
reports
in
every
release.
C
We
have
for
our
front
end,
because
our
front
end
is
a
mainly
a
JavaScript
application.
It
uses
npm
npm
has
a
built-in
audit
function
that
will
tell
you
how
many
vulnerable
packages
you
have.
So
that's
a
pretty
simple
smoke
test
to
make
sure
you
don't
know
anything
silly
and
we
can
publish
a
build
artifact.
That
says
we
ran
npm
audit
and
it
said
no
vulnerabilities
that
isn't
necessarily
true
I,
mean
I,
hope
it's
true
since
I'm
talking
about
my
own
business,
but
it
doesn't
have
to
be.
C
But
the
fact
that
we
said
it
was
is
heavily
recorded
and
non-reputable
in
the
skit
Ledger,
which
means
that
if
somebody
else
makes
a
decision
based
on
that
and
it
turns
out
to
be
provably,
not
true,
because
you
then
run
npm
audit
on
the
same
code
and
it
shows
up
something
else
that
that
hasn't
saved
you
necessarily
from
a
very
specific,
very
Niche
cyber
security
or
software
composition
threat.
But
it
does
tell
you
an
awful
lot
about
the
quality
of
your
supply
chain
whose
fault
something
was
and
who's
on
the
hook
to
remedy
it.
C
So
I
think
the
other
thing
that
we
need
to
bear
in
mind
that
gets
lost
a
lot
in
these
conversations.
Is
that
we're
not
necessarily
trying
to
make
things
100,
bulletproof
or
trying
to
somehow
create
a
world
where
things
are
100
True,
once
they're
set?
What
we're
trying
to
do
is
make
decent
basis,
as
hink
said,
a
really
strong
basis
for
decision
making,
which
is
auditable
and
reliable
after
the
fact
I
think
any
any
deviation
from
that
is
going
to
take
us
forever
to
finish
the
use
cases.
A
's
watching
clock
and
I'm
just
trying
to
figure
out
the
right
thing.
I
mean
we've
talked
about
the
multiple
instances,
a
couple
of
times
and
I
believe
we've
captured
this
and
I'll
go
back
and
look
at
the
architecture.
Docs
I
think
the
multiple
instances
are
really
important
for
reasons
that
Ali
had
brought
up
and
others
where
you're
going
to
have
different
software
vendors
that
are
producing
things.
Different
entities
and
Hardware
manufacturers
that
are
producing
their
information.
A
A
You
know
we
run
various
security
scanners
that
are
making
recommendations
and
decisions
on
other
software
companies,
so
I
could
think
of
skit
being
multiple
instances
from
the
software
companies
that
I
choose
to
do
business
with
or
aggregators
that
I
choose
to
do
business
with
and
then
I
might
contract
with
a
particular
security
company.
That
is
also
providing
information
on
their
skit
Ledger
and
because
they're
all
using
the
same
standards
that
we're
developing
here
I
can
make
tools
that
can
read
from
various
skid
ledgers
and
I
trust.
A
A
F
K
Registered
on
one
transparency
service
and
then
we
can
make
it
more
General
and
maybe
some
people
repeat
different
transparency
services.
But
for
that
to
work,
it
means
that
the
transparency
service
that
will
be
constant
in
in
many
of
the
basic
relay
participation
should
be
reasonably
stable
and
reputable
and
long-lived.
Yes,
people
will
have
more
detailed
lectures
around
the
production
side
or
maybe
on
the
editing
side,
but
for
sharing
your
information
about
the
class
of
artifacts
in
a
liquid
system.
K
J
J
More,
what
I'll
call
the
six
store
model
where,
as
I
understand
that
there's
a
single
kind
of
big
public
facing
anybody
or
Commerce
instance,
which
feels
good
because
it's
you
know
I
have
a
sense
that
it's
going
to
be
there.
If,
if
what
I'm
hearing
I
I
I'm
hearing
some
suggestion
that
each
company
will
run
their
own
instance,
their
own
servers,
their
own
API,
endpoints
and
I,
wouldn't
want
to
have
to
trust
that
the
suppliers
will
keep
them
up
and
running.
J
Maybe
I'm
misunderstanding
what
people
are
suggesting,
but
another
aspect
of
this
is
I
can
I
it
might
help
to
have
a
use
case
that
reflects
two
different,
relying
parties,
each
looking
at
the
same
skid
instances
and
making
different
decisions.
You
know
one
saying
well,
you
know
that
that
convinces
me
sure
yeah
Google,
said
it's
good
for
the
App
Store.
So
it's
good
for
me,
another
saying!
H
Oh,
thank
you,
harness
yeah
I
think
we
could
make
some
really
good
progress
if
we
could
reach
a
consensus
on
what
that
trust
statement
refers
to
in
the
registry.
If,
if
indeed
we
say
that
the
trust
statement
simply
means
the
evidence
is
trustworthy.
Well,
I
can
live
with
that.
It
just
means
I
have
to
pull
down
the
evidence
and
and
process
it
in
order
to
reach
the
ultimate
conclusion
I'm
looking
for,
which
is,
is
a
software
product
trustworthy.
H
So
we
can
either
say
that
a
registry
entry
means
that
evidence
that
evidence
is
trustworthy
or
it
can
mean
that
our
software
product
is
trustworthy
or
it
can
mean
something
else.
So
I
I
think
if
we
can
come
to
some
closure
on
what
we
think
or
what
we
agreed.
A
trust
statement
in
a
skit
registry
means
we
can
really
then
just
take
it
from
that
point
and
start
to
flush
out
the
details.
Thank
you.
D
H
Harnesses
what
does
it
mean?
What
are
the
semantics?
Does
it
mean
the
evidence
is
trustworthy,
or
does
it
mean
the
software
product
is
supposedly
so
I
think
if
we
encounter
some
closure
on
what
we
all
agree
and
Trust
statement
represents,
then
I
think
we
can
start
to
flush
out
some
of
the
details.
Thanks.
A
Jack
I
think
the
the
question
is,
the
trust
statement
will
probably
vary
to
the
industry
and
the
area,
that's
being
pertained.
Government
agencies
will
have
different
statements
that
they're
looking
for
doesn't
meet.
You
know
federal
government
policy.
Xyz,
an
emergency
management
system
will
look
for
a
house
that
meet
their
policy.
A
gaming
company
might
look
for
a
different
thing
and
vice
versa,
so
I
think
it's
a
matter
of.
A
Is
there
a
definition
of
what
a
format
of
a
statement
is
just
like
when
you
give
a
document
to
a
notary,
there's
a
place
where
you
put
signatures
and
dates
and
who
endorses
it?
The
types
of
ideas
you
provide
and
then
there's
a
link
to
a
document,
I
think
that'll
be
the
the
same
thing
here.
I
I,
don't
think
it's
up
to
the
skit
working
group
to
define
whether
and
we've
had
this
conversation
a
couple
of
times
before
whether
a
particular
Vex,
a
particular
s-bomb
format
is
the
right
format
for
the
statement.
A
I
think
the
idea
is
that
there
is
a
statement
made
and
there's
a
way
to
represent
a
statement
and
it's
based
on
an
identity
and
then
based
on
who,
what
the
cons,
The
Entity
trying
to
consume
this
information.
They
are
looking
for
certain
statements.
They
might
look
for
vex
versus
s-fum.
They
might
look
for
Foo
versus
bar
I.
Think
the
question
is:
how
do
we
provide
something
that
hope
that
will
stand
the
test
of
time?
A
A
And
I
think
it's
just
on
the
other
instance,
one
I
think
we
just
there's
different
and
you
know
again.
It's
same
the
same
thing:
the
government
agencies
will
be
running
their
instance.
In
fact,
different
government
agencies
will
probably
run
different
instances
because
of
within
whether
it
be
FBI,
CIA
or
whatever
I.
You
know,
I
think
we
can
use
TV
show
acronyms
to
kind
of
glamorize
it,
but
it's
those
are.
The
reality
is
there's
different
boundaries.
A
Software
companies
have
lots
of
software,
they
build
themselves
that
they
never
make
public.
It's
their
internal
software
and
that
kind
of
information
wouldn't
be
public
either,
but
they
still
have
the
need
to
put
statements
on
that
they
can
verify
through
in
within
that
supply
chain
that
they're
building,
so
I
think
the
multiple
instances
you
know
make
sense
in
the
sense
that
that's
just
kind
of
natural
how
Distribution
Systems
work
and
that's
the
mod,
that's
I
think
it's
the
model
that
we're
trying
to
do
here.
A
It
doesn't
say
that
there
aren't
some
large
instances
that
might
exist
out
there
right
that
might
this
is
part
of
Kathleen's.
You
know
position,
there
might
be
an
emergency
management
system
that
has
stood
up,
that
only
entities
that
are
can
be
trusted
for
that
kind
of
those
statements
are
allowed
to
write
to
and
who
has
access
to
pull
information
from
it
all
depends.
F
F
I
also
think
if
we
just
put
in
exactly
plain
statements
that
are
all
opaque,
we
cannot
address
the
use
cases.
Dick
and
Bob
are
highlighting.
So
there
has
to
be
a
minimal
amount
of
understanding.
What
you
get
I
think
that's
what
we
have
to
focus
on
to
make
it
work
and
then,
unfortunately,
today
the
I
want
to
say
six
star
folks
are
not
joining
in
I.
F
Guess
it's
a
U.S
holiday,
but
nevertheless
they
have
some
core
semantics
and,
for
example,
at
looking
at
those
and
putting
those
in
on
a
on
a
layout
that
is
already
in
the
statement
level
or
maybe
in
between
the
skid
notarization
function
and
the
statement
level
might
be
an
option.
We
can
talk
about.
I
think
we
can
learn
a
lot
and
it
would
be
a
low
heading
fruit
for
interoperability,
but
somebody
exists
and
not
pulling
in
the
identity
discussion
that
some
people
are
worried
about.
F
So
so
that's
something
to
do,
but
for
now
let's
start
with
the
Assumption,
everything
is
opaque.
We
add
some
semantics
along
the
way.
When
we
see
we
can't
answer
a
simple
question
in
bigger
systems
that
dick
or
Bob
would
like
to
be
either
answered
or
Neil
right.
So
that's
our
our
litmus
test.
Basically,
but
but
start
with
the
simple
thing
address:
John's
concern
of
this
explodes
so
in
complexity.
F
If
you
do
it
more,
but
we
also
have
to
answer
in
the
end,
with
some
proof
of
concept,
implementations,
actual
questions
coming
from
consumers
or
supply
chain
entities.
So
there's
a
middle
ground
here.
There's
some
I
think
reference
semantics:
we
can.
We
can
pull
in
prop,
probably
as
a
low
hanging
fruit.
J
E
I
kind
of
agree
with
what
John
and
John's
point
was
and
also
Hank's
point.
The
point
we
are
trying
to
make
using
skit
is
making
a
statement
in
transparent
Manner
and
making
the
issuer
of
the
statement
accountable
for
what
statement
he
is
making.
Now
how
the
consumer
would
like
to
establish
a
trust
based
on
the
statement
is
between
the
issuer
and
the
consumer.
It's
like
a
policy
it.
The
skit
Ledger,
cannot
by
default.
Making
an
Evidence
statement
makes
it
trustworthy.
E
It
is
something
like
how
how
do
we
explain
that
is,
it
is
for
it
is
for
the
individuals
and
the
individual
policy
of
all
you
can
verify
through
skit.
Is
that
yes,
skit
can
guarantee
that?
Yes,
this
statement
was
is
present
and
you
can
verify
that
cryptographically
that
its
presence
can
be
proved,
the
Cs
it
is
present,
but
how
to
interpret
that
is
between
how
the
supplier
would
like
the
consumers
to
interpret
and
how
the
consumers
would
interpret
based
on
their
policies.
E
I
Yeah
I
just
wanted
to
reflect
on
what
what
Steve
was
saying
in
terms
of
the
confidentiality
of
these
ledgers.
I
put
it
in
the
chat
too
I'm
kind
of
worried
about
that
Dimension,
because
I
I
mean
in
terms
of
I,
don't
think
it's
in
our
use
case
in
terms
of
whether
the
entries
are
confidential
or
public
and
whether
the
whole
Ledger
is
public
or
confidential.
I
think
that's
getting
into
that
I
think.
Maybe
we
should
try
to
explicitly
avoid
that
one
one
thing,
but
Food
For
Thought
for
next
time.