►
From YouTube: IETF115-SCITT-20221110-0930
Description
SCITT meeting session at IETF115
2022/11/10 0930
https://datatracker.ietf.org/meeting/115/proceedings/
A
At
all,
yeah.
A
Let's
get
started!
Welcome
to
this
kid
working
group
meeting.
So
obviously
our
first
meeting,
my
name
is
hanis
jupinik
and
this
is
from.
A
We
are
your
new
chairs
for
this
working
group,
our
first
meeting
so
happy
to
see
you
all
here.
Note
well
you've
seen
that
already,
obviously,
because
we're
in
the
middle
of
the
week,
Roman.
C
Good
morning,
everyone
it's
exciting
to
have
our
first
kickoff
meeting.
I
just
wanted
to
publicly
say
you
know,
as
you
just
did
your
introduction,
harness
and
John.
Thank
you
for
your
willingness
to
serve
to
kind
of
get
us
started
so
again.
Very
much
appreciate
it.
A
As
you've
seen,
we
have
a
pretty
full
agenda.
We,
we
will
start
with
a
problem
statement,
document
kind
of
the
problem
statement,
assuming
that
skit
hasn't
been
done
yet
so
pre-skit
type
of
thing,
then
we
talk
about
the
use
case
is
same
as
well.
Yogesh
is
going
to
talk
about
those.
Then
we
switch
into.
How
does
the
solution
look
like
with
an
architecture
using
skit?
We
have
a
presentation
about
this
kit
receipts.
A
Another
document,
if
you
click
at
the
slide,
you
get
to
the
documents
themselves,
there's
a
hackathon
report,
which
explains
how
you
would
use
kit
technology
to
actually
solve
some
of
those
use
cases.
And
then
we
have
some
some
time
left
to
for
any
questions
that
you
may
have.
Is
there
any
agenda,
patching
requests
haven't
received
any
so
I,
don't
see
anyone
jumping
to
the
microphone
and
if
you
go
to
the
microphone,
please
use
the
QR
code
to
add
yourself
to
the
queue
okay
yeah.
We
thank
Roman
already.
A
Thank
you
again
for
getting
the
working
group
scheduled
so
quickly
and
one
administrative
thing.
So
we've
had
regular
conference
calls.
We
are
going
to
continue.
Those
and
I
will
send
out
the
or
we
will
send
out
the
doodle
poll
to
confirm
that
the
date
that
we
had
used
or
that
which
was
a
Monday
and
the
first
day
called
that
that
is
actually
good
for
everyone.
A
But
we
would
switch
to
using
IDF
tools
and
the
whole
IDF
Machinery
so
that
we
don't
have
to
use
sort
of
company
individual
company
sort
of
mechanisms
here.
Okay,
enough
said.
D
Hey
I'm
Ori
Steele
I'm
here
to
present
the
problem
statement.
We
thought
we'd
start
with
a
quote
this
time
about
what
Supply
chains
are
and
I'm
going
to
read.
The
quote.
For
you
all
a
supply
chain
is
a
network
of
individuals
and
companies
who
are
involved
in
creating
a
product
delivering
it
to
the
consumer.
Links
on
the
chain
begin
with
the
producers
of
the
raw
materials
and
end
when
the
van
delivers
the
finished
product
to
the
end
user.
D
In
the
context
of
software,
we're
interested
in
software
Supply
chains,
so
maybe
the
van
part
of
the
last
piece
is
the
only
major
difference.
Software
is
an
inherent
part
of
everyday
digitally.
Enabled
life
from
smartphones
to
iot,
Data
Centers,
widely
discussed
tax
on
the
software
supply
chain
have
helped
raise
awareness
of
risks.
Many
of
the
other
vulnerabilities
highlight
the
need
for
greater
visibility
into
the
supply
chain,
Integrity,
transparency
and
Trust
to
make
an
informed
decision
just
to
be.
You
know
concrete
about
this.
D
That's
it
so
transparency
and
Trust
transparency
does
not
prevent
me.
Are
you
good?
Transparency
does
not
prevent
dishonest
or
compromised
issuers,
but
it
holds
them
accountable.
Any
artifact.
B
D
And
we're
back
so
any
artifact
that
may
be
used
to
Target
a
particular
user
that
checks
for
receipts
must
have
been
recorded
in
the
tamper-proof
registry
and
will
be
subject
to
scrutiny,
scrutiny
and
auditing
by
other
parties.
What
is
what
does
this
sentence
mean?
What
are
we
trying
to
get
at
here?
The
important
part
is
that
when
you
ask
about
transparency,
you
want
the
answer
to
that
question
to
be
answered
consistently.
D
So,
if
I
ask
about
a
particular
artifact
today
and
my
friend
Mike
Pro
Rock
in
the
back,
asks
that
same
question
in
a
few
seconds,
he
should
get
a
similar
answer
if
nothing
has
changed.
So
it's
important
that
the
that
entity
providing
that
transparency,
not
the
be
dishonest
or
be
choosing
how
they
answer
those
kinds
of
questions,
and
so
we're
interested
in
creating
transparency
and
Trust
in
that
sense
and
skit.
An
architecture
for
trustworthy
and
transparent
digital
Supply
chains
is
a
link
available
on
this
slide.
E
Hello
good
morning,
everyone
I
hope
you
have
all
have
a
good
morning
and
enjoying
the
session
so
far
and
I
want
to
keep
you
all
all
engaged.
Thank
you
already
for
a
great
great
introduction
of
the
problem
statement.
So
I
hope
everyone
is
clear
about
the
problem.
We
faced
the
challenge
we
faced
in
the
industry
today.
E
E
So,
as
you
can
see
here,
there
is
the
software
supply
chain
is
really
complex
system.
You
have
multiple
software
producers
like
the
operating
systems,
be
it
Microsoft
Ubuntu,
and
then
you
have
the
component
vendors
who
are
generating
the
chips
or
the
firmware's
on
top
of
it,
and
then
you
have
the
package
managers
like
Pi
Pi
or
any
software,
and
then
finally,
there
is
much
other
open
source
code
or
any
proprietary
code.
That
gets
goes
to
the
integrator.
E
Who
then,
basically
picks
and
chooses
these
components
to
produce
integrated,
builds
and
that
to
have
multiple
flavors,
because
different
compilations,
which
has
different
features,
generate
multiple
products,
multiple
Integrated
Solutions
out
of
the
same
code
base,
and
then
eventually
it
goes
to
different
companies
which
then
load
those
software
onto
the
devices
and
the
device
gets
deployed
into
the
field
and
gets
to
the
hands
of
the
users
like
we
have
laptops
mobile
phones,
all
running
comp,
complicated
software,
and
this
is
the
end
user
who
is
ultimately
using
that
software.
E
E
It
is
not
having
a
consistent
and
coherent
information
at
the
state
of
the
each
published
components
and
there
is
no
standard
way
for
integrator
to
query
or
receive,
even
if
we
have
software
bill
of
materials
as
as
we
discussed
just
now
like
s-bomb
to
be
getting
delivered,
we
don't
know
how
is
it
the
right
guy?
Who
is
shipping
me,
the
S
form
is,
can
can
I
fully
trust
him
can
I
fully
identify
his
trustworthiness?
E
Is
the
supplied
component
clean
of
any
unexpected
or
any
problems
like
vulnerabilities
or
anything,
or
how
do
I
know
that
it
has
not
been
an
accepted
unexpectedly,
modified
or
or
suddenly
changed,
because
somebody
hacked
it
and
somebody
modified
it.
So
how
does
these
kind
of
complex
situations
and
problems
the
integrator
facing
today?
How
can
he
deal
with
it.
E
So
we
we
start
with
a
specific
scenario.
We
have
built
here
to
highlight
the
problem
and
explain
you
and
I
hope
we.
We
all
understand
the
problem
and
the
scale
of
the
problem.
So
here
on
the
left,
we
have
an
operating
system
producer,
be
it
any
anything
as
I
mentioned
earlier,
Microsoft,
Linux
or
any
operating
system
producer
generates
an
executable
and
delivers
it
to
the
device
integrator
to
integrate
it
into
its
system,
and
it
has
shipped
this
binary
for
device
integrator
and
on
a
one-to-one
channel.
E
So
next
slide,
please
now
the
device
integrator
as
we
saw
in
the
first
slide.
He
has
taken
other
bits
of
components.
The
Box,
the
pink
box,
could
not
just
be
one
component,
but
again
a
series
of
components
coming
from
other
places
and
he
has
done
generated
an
integrated
device
software
and
it
has
been
given
to
the
device
distributor
for
Distributing
it
by
loading
it
into
the
on
the
device.
E
Now
the
device
device
distributor
has
the
device
ready
it
has
the
software
deployed
and
the
user
is
using
that
device
and
suddenly
user
faces
a
problem.
He
he
finds
something
problematic
with
the
software.
He
has
some
vulnerability
or
he
has
running
some
he's
running
some
scan
or
something
and
suddenly
something
pops
up.
He's
scared.
Where
exactly
in
which
software
component
is
a
problem,
he
doesn't
understand
anything
because
he's
at
the
end
of
the
day,
he's
end
user
he's
just
a
user
of
a
software
he's
not
doesn't
understand.
E
So
you
go
back
to
the
distributor
here
and
here
it
is
everybody's.
This
this
slide
just
flows
shows
the
flow
that
the
end
user
is
complaining
to
the
distributor.
Now
the
distributor
is
not
much
knowledgeable
about
things,
so
he
goes
to
the
device
integrator
complaining.
That
here
is
some
problem.
How
do
I
fix
it?
Where
is
the
solution?
E
The
device
integrator
probably
tries
to
do
some
kind
of
a
root,
cause
analysis
and
is
not
sure,
though,
but
he
hopes
to
identify
and
believes
that
it's
the
OS
producers
whose
binary
or
the
executable
he
has
received
has
something
problematic.
That's
why
this
chaos
has
created
has
been
created,
but
that
just
a
belief
that
just
a
kind
of
a
a
kind
of
assumption
on
here,
Happening
Here.
E
So
next
slide
now
now
here
we
are
in
a
stuck
State,
basically,
because
everybody
is
in
a
limbo,
a
situation
where
nobody
understands
what's
going
on
here.
The
the
integrator
is
waiting
for
the
Os
Os
producer
to
say
something
about
it
to
make
a
statement
to
say
that,
yes,
there
is
a
problem
or
not,
he
wants
to
get
an
acknowledgment.
The
OS
binary
producer
is
still
investigating
looking
at
it,
and
there
is
no
coherent
way
of
understanding
and
shared
communication
between
them.
E
E
The
system
details
how
I
have
built
this
software,
the
build
enrollment,
the
architecture,
I'm
willing
to
show
you
everything,
but
he's
he's
just
stating
that
or
he's
just
showing,
maybe
maybe
six
months
when
the
problem
happened
and
the
time
between
when
he
produced
the
binary
and
the
time
when
he's
showing
it
is
six
months
apart
and
there
is
he's
just
showing
it
there's
no
verifiable
proof
that
what
he's
showing
is
exactly
mapping
to
the
binary
which
he
has
given,
because
there
is
there,
there
is
no
verifiability
in
the
system
and
and
who
knows,
the
operating
system.
E
Software
producer
thinks
that
it's
the
device
integrator
who
is
blaming
me
unnecessarily,
though
it
may
be,
integrates
integration
problem
in
one
of
his
software,
so
that
here
there
we
are
just
kind
of
doing
a
trust
and
a
blame
game.
We
are
in
a
stuck
situation
where
each
one
of
them
is
just
trying
to
play
and
leave
the
blame
to
others,
and
this
is
this:
struck
situation
can
have
no
clear
resolution
unless
we
have
a
standard
means
to
conclude,
based
on
verification
where
you
can
verify
what
is
happening
is
a
problem.
E
So
going
further,
these
are
the
problems
we
think
the
customers
also
faces
when
he
and
the
end
user
uses
the
the
end
user
uses
the
software
as
well
as
the
the
distributor
who
distributes
the
software,
receives
that
software.
Then
it
doesn't
have
any
means
to
assess
the
risks
or
vulnerabilities
in
the
binaries
we
distribute
the
system.
Integrator
has
no
means
to
assess
the
vulnerabilities,
as
well
as
the
OS
binary.
E
Producers
doesn't
have
the
same
ecosystem
in
place
there,
where
they
can
see
what
software
is
produced,
what
vulnerabilities
they
exist
and
when
suddenly
the
software
changes,
how
what
has
changed?
What
vulnerabilities
have
been
fixed
and
there's
no
standard
mechanisms
to
track
this
information
next
slide,
please.
E
So
we
identified
this
problem
and
that's
why
we,
along
with
our
colleagues
in
the
community,
decided
to
form
this
excellent
working
group,
which
is
short,
formed
or
acronym
desk
kit
supply
chain,
Integrity,
transparency
and
Trust.
Basically,
we
are
trying
our
efforts
are
towards
defining
set
of
specifications
which
precisely
deal
with
the
problem
which
I
have
presented
you
just
now
to
introduce
transparency
in
the
ecosystem,
where
an
individual
can
look
how
the
software
was
built.
He
can
precisely
download
the
stuff
from
in
a
transparent,
Manner
and
verifies
next
slide
please.
E
So
this
is
just
the
details
about
the
working
group,
which
defines
compact
Integrity
protected
protocols.
Supporting
interoper
activity
between
multiple
Supply
chains
is
focused
on
software
supply
chain
use
cases
specifically,
but
it's
very
much
in
our
Focus
to
include
software
package
repositories,
container
Registries
services
and
in
the
ecosystem
we're
trying
to.
E
We
would
attempt
to
build
a
system
which
can
deal
with
other
use
cases
also,
but
right
now
our
focus
is
primarily
on
software
supply
chain
and
we
work
closely
with
an
already
existing
ITF
standard
groups
like
cozy
rats,
cheap
and
suit
as
well,
and
we
we
learn
from
them
and
we
interoperate,
and
hopefully
we
we
build
a
greater
ecosystem
with
along
with
them.
So
thank
you.
Everyone
I
think
that
is
the
problem.
Now
I
would
introduce
my
colleague
Anton,
who
would
explain
you
the
architecture
of
State
ecosystem.
Thank
you
so
much.
F
You
may
notice
that
we
have
slightly
updated
some
of
the
terminology,
but
there
is
still
quite
a
bit
of
controversy
on
some
of
the
terms
that
we
use
to
describe
the
concept
of
skit,
so
there
is
still
possibly
some
challenges
coming
and
don't
hesitate
to
make
your
position
known
on
the
many
list.
So,
starting
from
the
left
side
of
the
picture,
we
have
the
verifier.
So
the
verifier
is
the
person
that
is
consuming
the
software
artifacts
and
everything
that
we
do
in
skits
is
for
the
benefits
of
the
verifier.
F
So,
every
day,
people
that's
new
software
and
they
want
to
know
what's
what's
a
bad
things
could
happen
if
they
use
software
or
help
them
decide
whether
some
software
is
trustworthy.
So
the
other
important
concept
at
the
top
is
the
concept
of
the
artifact
itself.
So
this
could
be,
of
course,
a
very
wide
variety
of
things
by
Design,
we
are
very
abstract
in
the
architecture
about
what
the
artifact
is.
It
could
be
a
binary
package.
F
It
could
be
a
container
image,
it
could
be
escaped
could
be
a
git
tag,
really
anything
we
only
so.
The
other
important
points
is
that
we
want
to
provide
information
to
the
verifier
about
the
artifact,
and
one
of
the
observation
is
that
the
information
about
the
artifact
can
be
coming
from
many
different
kind
of
sources
Heights.
F
So
it's
not
necessarily
only
the
author
of
The
artifact
or
the
owner,
or
the
producer
of
the
artifacts
that
can
provide
useful
or
meaningful
information
to
the
verifier
about
its
trustworthiness
and
that's
why
we
introduce
on
the
right
side
the
concept
of
issuer,
so
the
issuer
it's
any
entity
that
can
provide
meaningful
information
about
the
artifacts
that
you
use.
So
it
could
be
not
only
just
the
author
of
the
Gods,
it
can
be
the
distributor
of
the
code.
It
can
be
even
automated
systems
like
Ci
system,
build
system
that
provides
build
reports.
F
F
It's
essentially
any
serializable
information
about
the
artifacts,
and
what
we
require
execute
is
that
we
want
to
hold
issuers
accountable
for
the
statements
that
they
make.
So
we
are
going
to
require
all
issuers
to
sign
the
statement
they
make
and
we
are
going
to
standardize
the
formats
that
they
use
to
sign
this
information,
and
this
is
what
we
call
a
claim.
So
that's
the
info,
the
the
claim,
It's
The,
Sign
information
from
the
issuer,
and
we
are
going
to
explain
a
bit
later
this
climate
Insurance
process
in
the
next
slide.
F
The
other
critical
concept
and
that's
kind
of
the
stronghold
concept
of
skits
is
the
idea
of
the
registry,
and
this
is
where
the
terminology
is
still
a
little
bit
controversial.
So
initially,
this
was
called
the
transparency
service
or
The
Ledger
Service.
Now
we
use
the
registration
or
the
transparent
registry
or
the
notary.
F
So
if
you
prefer
any
of
these
terms,
it's
there
is
still
a
little
bit
of
the
children
being
made
about
what
is
the
right
way,
but
the
concepts
of
the
of
the
notary,
it's
an
authority
that
is
partially
trusted.
F
So
the
verifier
is
going
to
rely
on
the
notary
service
or
the
transparency
service,
to
figure
out
information
and
to
make
sure
that
this
information
is
globally
consistent
for
all
verifiers,
which
is
going
to
give
us
some
of
the
security
guarantees
that
we
provide
with
kit
and
the
the
role
of
the
of
the
notary
or
the
registry
is
that
it's
going
to
take
claims
from
insurers
and
it's
going
to
verify
their
signature
and
is
going
to
register
them
inside
the
registry,
which
is
this
evidence
that
a
structure
that
you
can
use
to
make
sure
that
everyone
has
a
consistent
view
of
the
claims
that
have
been
made
by
the
issuers
and
the.
F
A
Please
Dave:
there
was
a
question.
H
Taylor's
terminology,
question
or
comment
comparing
this
to
like
the
rats
architecture
and
I'm
looking
at
and
so
I
was
listening
to
your
description
of
the
registry
and
rotary
service,
where
it
says
that
verifies
information
from
issuers
or
the
entity
on
the
left
is
the
verifier
and
it
doesn't
use
the
word
verify
on
the
left
side.
So
there's
a
little
bit
of
terminology,
confusion
that
says
the
energy
that
verifies
isn't
the
verifier.
H
The
little
scroll
piece
there
you
called
that
evidence,
okay,
which
in
the
rats
terminology,
means
something
in
which
case
the
verifier
on
the
left
really
is
a
verifier
in
the
same
sense
as
rats
is,
and
the
other
one
isn't
really
doing
verify,
and
so
just
ask
if
you
would
elaborate
on
Hank.
H
If
you
actually
agree
that
the
one
on
the
left
is
a
verifier
in
the
same
sentence
as
rats,
and
if
this
is
evidence
and
if
so
then
say
more
about
what
the
registry
does
to
verify,
because
the
verifier
is
the
one
that
actually
does
the
appraisal.
F
Yes,
so
I
think
to
summarize
your
points,
what
you're
saying
is
that
the
verifier
verifies
the
transparent
claim
of
the
receipt,
not
the
claim
itself.
So
it's
a
bit
of
an
abuse
in
something
that
is
a
fair
point.
I
will,
as
I
will
explain
later,
the
the
claim
can
also
be
verified
by
the
verifier.
It's
a
kind
of
advanced
form
of
verification.
But
yes,
I
I
do
understand
that
the
client
terminology
is
a
little
bit
problematic
and,
of
course,
has
everything
in
the
architecture.
H
Yeah
so
I
guess
that
I'll
let
in
case
Hank
has
anything
but
the
it
would
be
useful
to
draw
comparisons
in
text
to
the
rats
architecture
right.
One
way
to
do
it
is
to
say
the
registry
is
like
a
rats
verifier
and
the
verifier
is
like
a
relying
party.
Yes,
another
way
to
do
it
is
to
say
that
the
registry
is
just
a
store
and
forward
caching
service.
Maybe
it
checks
signatures,
but
it
doesn't
look
at
the
claims
or
whatever,
and
the
verifier
here
is
the
verifier
right.
J
So
so,
yes,
if
the
verifier
looks
into
the
claim
so
and
into
the
actual
statement
that
is
signed
by
the
issuer,
then
it
becomes
more
like
a
verifier
on
rats
because
it
has
to
have
reference
values
and
policies
about
the
content
if
it
is
just
adjust
yeah,
and
that
is
that
the
Simplicity
we
provide
here
with
transparency
if
it's
verifying
the
transparent
claim
it
becomes
a
signature
Checker
in
the
end,
because
it
is
not
necessarily
required
to
look
at
any
statements
and
to
understand
them.
J
So
that's
first
of
all,
nice,
but
then
also
we
understand
the
claim
is
used
now
for
the
third
time
in
a
different
way
and
so
I
I
understand.
We
understand
that
and
and
making
a
mapping
like
that
will
also
maybe
probably
make
us
converts
a
a
place
to
look
at
how
to
improve
it.
In
the
end.
E
A
We
still
have
one
person
in
the
queue
Dan.
Are
you
okay?
Good?
If
you
go
to
the
microphone,
please
use
the
tool,
scan
the
QR
code
and
and
put
yourself
in
the
queue
remote
participant
thing
can
also
see
your
name.
That's
kind
of
benefit.
L
Thank
you,
dendro
the
atnt
I
I,
like
the
architecture
I'm,
just
questioning
the
need
for
this
forked.
You
know
verification
process
is
it?
Is
it
absolutely
necessary
to
have
a
notary
service
registry
where,
in
reality,
you
can
actually
pass
inbound
with
the
artifact,
the
verification
and
then
the
second
part
is
basically
also
about
you
know
the
issuer,
and
maybe
this
is
a
bigger
problem
for
Supply
chains.
I'll
use
the
the
log4j
example.
You
can
have
five
issuers
in
a
one
supply
chain.
L
You
know
flow
that
will
issue
a
log
for
Jake,
you
know
being
part
of
their
their
components.
Who
do
you
trust?
Who?
How
do
you
reconciliate
in
the
end?
That
is
exactly
the
same
one.
How
do
we
address
that?
Thank
you.
Okay,.
A
F
You
need
to
ask
yourself
if
you
want
to
respond.
I
will
start
with
the
first
part
of
the
question,
so
the
first
part
of
the
question
is
yeah.
What
is
kind
of
the
role
of
the
of
the
registry,
and
can
we
just
pass
the
claim
directly
from
the
issuer
to
the
verifier?
So
the
reason
that
we
introduced
the
notary
is
to
give
a
stronger
guarantee
to
the
verifier.
F
That's
essentially
the
whole
point
of
skit
and
that's
to
make
sure
that
any
claim
that
is
accepted
by
the
verifier,
the
issuer
can
be
made
accountable
for
and
I
will
give
some
examples
of.
The
attacks
that
are
prevented
by
using
the
notary
in
the
in
the
future.
Slides.
J
This
is
saying
just
small
editing,
there's
also,
of
course,
the
benefit
of
a
the
point
of
Singularity
provides
Simplicity
to
a
scalability
and
and
things
that
might
have
no
idea
what
the
statement
actually
means.
So
putting
trust
into
this
fog
enables
like
billions
of
devices
to
just
forward
it
to
the
policy
engine,
for
example,
they
have
nothing
to
know
about
it,
which
isn't
possible
if
you
can't
put
this
trust
into
the
middleman
yeah,
so
so
it
is
a
for
scalability
and
also
for
offline
validation
and
I.
M
Thank
you,
hi
everybody.
This
is
Elliot,
so
I
think
there's
another
possibility.
M
There
Dan,
which
is
I,
submit
a
claim
to
the
registry
and
I
get
back
a
response
and
then
I
query
the
registry
for
the
verification,
as
the
as
the
claim
as
the
claimant
and
then
I
just
incorporate
that
in
my
packaging
and
that
way,
and
that
way
you
don't
have
the
you
don't
have
to
go
online
if
you
don't
want
to,
but
you
can,
if
you
want
to
what's
important,
is
that
first
of
all,
the
trust
anchors
be
in
place
so
that
the
trust
is
is
possible
and
second,
as
part
of
that,
there
should
be
enough
information
in
the
verification
to
say.
M
F
So
I
suggest
you
know
it's
of
course,
very
advantageous
feature
of
the
fact
that
you
can
attach
the
receipt
produced
by
the
notary
to
your
artifact
or
to
the
software,
so
that
you
don't
need
to
do
any
online
track
and
that's,
as
also
Hank
said,
a
way
to
have
to
avoid
the
for
the
verifier
to
understand
all
of
the
issuers
of
the
artifact
that
they
consume
and
it's
very
difficult
to
decide
whether
they
trust
them
using
the
semi-trusted
cell
party
of
the
notary.
F
N
Hi
this
is
Brendan
Morin
and
just
to
provide
a
Counterpoint
to
the
deliver.
The
claims
with
the
artifact
side
of
things
I
noticed
that
firmware
was
one
of
your
use
cases
and,
if
you're
delivering
artifacts
to
constrained
nodes,
you
probably
don't
want
to
deliver
all
of
the
claims
with
them.
That
would
actually
be
a
terrible
idea.
So
the
the
the
point
there
is
that
that
means
that
you
need
somewhere
to
store
those
claims
or
you
just
lose
them,
and
this
gives
you
a
standardized
way
to
do
that.
N
G
A
O
O
So
if
you
had
software
deployed
with
some
particular
package
that
had
a
vulnerability
unknown
at
the
time
later
on
that
vulnerability
is
fixed,
possibly
even
inadvertently
right,
you
don't
realize
this
being
able
to
go
back
and
backtrack
after
an
incident
to
understand
why,
when
and
exactly
where,
that
vulnerability
existed
and
having
that
record
of
time,
and
when
did
this
exactly
happen,
who
witnessed
it
did?
Were
there
multiple
attestations
about
this
particular
item?
O
Right,
you
know,
say
a
third
party
verification,
Etc
all
in
one
place,
so
I
think
that
notion
of
intersection
of
time,
especially
in
post
event,
is
absolutely
critical
when
going
through
and
analyzing
an
issue.
G
Yeah
Eric
not
much
I
was
gonna.
Ask
things
around
the
same
thing:
right:
sort
of
a
registry
notary
you
could
just
record
here's
a
set
of
you
know:
claims
and
I'm
gonna
store
them.
I'm
they're
not
going
to
disappear.
They're
sort
of
handling
non-repudiation
right,
but
you
could
also
say
well,
don't
you
want
to
keep
track
of?
What's
the
most
recent
version
of
that
software
yeah,
but
normally
you
need
to
have
a
naming
scheme,
so
they
can
actually
do
that
and
then
the
question
comes
out.
G
F
We
expect
that
some
notaries,
so
first
of
all,
there
isn't
going
to
be
any
synchronized
notary
for
everyone,
so
every
company
or
every
organization
can
operate
the
whole
notaries
and
some
of
them,
as
you
said,
are
going
to
be
very
sophisticated.
So,
for
instance,
they
can
indeed
on
for
advanced
policies
to
make
sure
that
verify
your
only
consumed
the
most
up-to-date
version-
and
this
is
a
something
that's
I
think-
is
in
scope
for
some
of
the
notaries.
F
But
of
course
they
are
also
going
to
be
very,
very
simple,
notaries
that
simply
regards
on
the
on
the
registry
and
provide
this
evidence,
persistence,
storage
of
all
of
the
claims,
and
that
is
of
course,
much
cheaper
to
operate
so
so.
In
summary,
we
expect
that
there
will
be
many
levels
of
complexity
on
the
instances
of
notary
that
are
created
in
the
white.
P
Okay
weapon
from
Huawei
I
have
two
questions.
First,
I'd
like
to
know
what
to
what
degree
the
the
issue
will
be,
for
example,
for,
for
example,
Microsoft
will
deliver
the
OS
operating
system
and
and
well
Microsoft
exposed
for,
for
example,
which
which
employee
developed,
which
code
to
the
notary
service
or
some
kind
of
that
and
second,
is
about
here.
The
notary
service
will
verify
the
information
from
issuers
and
the
verify
will
also
do
some
verification.
I
I
want
to
know
the
difference
between
these
two
verifications.
Okay,.
F
So,
first
otherwise
the
first
question.
So
the
first
question
is
I
think
actually
I
understand
it
as
a
privacy
question
right.
So,
for
instance,
if
you
have
an
s-bomb
that
is,
for
instance,
let's
say
your
git
history,
it's
a
very
useful
information,
but
some
of
its
maybe
privacy
sensitive
right.
F
So
yes,
if
you
have,
for
instance,
the
Microsoft
Windows
s-bomb,
it
will
have
the
name
of
every
Microsoft
developer
that
contributed
good
right
and
in
some
cases
the
question
is:
should
this
information
be
released
to
everyone
or
not
right
and
in
general
this
is
essentially
your
choice
of
the
notary.
So
if
you
want
to
only
partially
reveal
some
of
this
information,
you
have
essentially
control
over
what
other
claims
in
the
registry
that
can
be
publicly
accessed
or
you
can
introduce
some
Access
Control
to
the
rgc.
F
A
We
had
okay,
the
other
person
dropped
out
of
the
queue,
but
let's
keep
on
going
yep.
F
So
yes,
so,
as
I
said
in
the
previous
slide,
there
are
three
important
flaws
of
processes
in
skits,
so
the
first
one
is
claim
issuance.
The
second
one
is
validation
of
claims
at
the
notary
and
the
third
one
is
verification,
verification
of
receipts
at
the
verifier,
so
I'm
going
to
start
with
the
first
one.
How
do
you
actually
issue
a
claim?
So
it's
it
has
some.
So,
as
I
said
previously,
the
claim
contains
a
statement
and
skits
doesn't
really
assume
anything
about
the
format
of
your
statements.
F
You
just
needs
to
be
able
to
serialize
it
into
some
kind
of
byte
string
and
it
could
use
all
kind
of
standardized
or
defined
formats
for
for
carrying
s-bomb,
for
instance.
So
there
are
many
many
formats
and
the
goal
of
skit
is
to
support
all
of
them.
The
second
piece,
which
is
also
interesting
and
a
little
bit
controversial,
is
how
are
you
going
to
represent
the
identity
of
the
issuer
right,
and
this
is
where
we
have
to
make
a
technical
choice
for
interoperability
and
one
of
the
things
that
is
specific
to
skits.
F
Is
this
ID
that
the
evidence
that
is
produced
by
issuer?
We
want
it
to
be
long-term
rights,
which
means
that
you
want
to
be
able
to
go
back
in
time
and
verify
all
dividends,
and
one
of
the
important
requirement
that
we
identify
is
separation
between
the
long-term
identity
of
the
issuer
and
the
short-term
credential.
That
the
issue
are
used
to
sign
the
statement
and
that's
why
we
currently
decided
to
use
distributed
identity
as
the
framework
to
represent
the
issue.
F
Identity,
and
our
expectation
is
that,
because
of
the
flexibility
of
did
in
terms
of
defining
new
methods,
this
should
be
compatible
with
all
kinds
of
identity
systems,
including,
for
instance,
pki
based
Onyx,
509
certificates
or
identity
system.
Based
on
open
educonate
any
kind
of
protocol.
You
should
be
able
to
Define
dag
methods
to
represent
the
identity
of
a
of
an
issuer
using
the
ID,
and
you
should
be
able
to
associate
verification
Keys
using
the
did
resolution
mechanism,
which
transforms
this
stable
identifier
into
sets
of
credentials,
essentially
selling
keys.
F
So
the
last
point
is
that
there
are
some
standard
sets
of
informational
headers
that
must
be
part
of
the
skids
envelope,
and
so,
when
you
want
to
produce
a
claim,
you
need
to
combine
your
serialized
statements
with
this
envelope
information
and
currently
in
the
current
architecture.
We
use
the
following
mandatory
field,
and
so
the
most
important
one
is
the
issuer.
So,
as
I
said,
the
issuer
must
be
in
the
current
architecture
did
identifier
that
represents
the
long-term
identity
of
the
issuer.
Then
you
have
the
information
about
the
artifact.
F
So
for
any
claim
you
want
to
know
what
artifacts
does
this
claim
refer
to
right
and
that
information
is
encoded
in
the
feed
header
and
that
you
also
have
the
content
type,
which
tells
you
what
format
you
use
to
represent
your
statements.
So
if
it's,
for
instance,
spdx
s-bomb,
then
you
need
to
put
that
in
the
content
type.
You
also
have
two
additional
things.
So
kid
is
a
mechanism
to
select
the
right
key
from
the
reserved
did
documents,
so
you
can
have
a
you,
can
change
your
certificates
but
keep
your
same.
F
The
ID
and
the
kid
will
tell
you
which,
which
certificate
to
use
to
verify
that
particular
signature
and
registration
info
is
used
to
will
be
explained
in
a
later
slide
next
slide.
F
So
then
moving
on
to
the
registration
of
the
claim.
So
this
is
the
the
process
that
is
done
at
the
notary
when
you
want
to
register
a
claim
on
the
registry
service.
So
so,
first
of
all,
the
the
person
that
actually
submits
the
claim
does
not
necessarily
have
to
be
the
issuer
himself.
It
could
be
some
other
party
and
the
reason
for
that
is
because
sometimes
you
want
to
take
a
claim
that
has
been
produced
by
someone
and
you
want
to
import
it
into
your
own
skit
instance
right.
F
And
the
second
thing
is
that
the
the
notary
may
also
apply
all
kind
of
access
control
for
her
authorization
procedures
for
deciding
whether
the
claim
can
be
registered
or
not,
and
that's
it's
not
really.
The
trusted
part
of
the
decision
is
that
you
have
to
decide,
for
instance,
as
a
notary
worth
the
issuers,
that
you
trust
or
what's
the
issue
that
you
consider
valid
and
as
part
of
this
process,
you
are
even
possibly
allowed
to
inspect
the
contents
of
the
statement
itself
right.
F
So
you
can
have
a
notary
that
looks
at
automated
logs
and,
for
instance,
will
apply
some
vulnerability,
detection
or
try
to
detect.
If
the
respawn
that
has
been
submitted
contains
vulnerable
information
and
if
it
does,
it
will
rejects
the
registration
and
all
of
that,
the
the
notary
has
full
freedom
of
applying
any
check
that
they
want.
The
only
thing
that
is
required
in
the
architecture
is
that
the
notary
Mass
return.
F
If
the
claim
is
accepted,
a
skit
receipts,
which
is,
as
I
said,
the
proof
that
it's
offline,
verifiable
proof
that
the
statement
has
been
registered
in
the
registry.
F
Okay,
so
the
last
flow
is
the
verification
that
happens
at
the
verifier
right
and
there
is
a
little
bit
of
subtlety
there.
That
is
introduced
because
not
all
the
verifiers
are
the
same.
So
there
are
different
levels
of
sophistication
between
the
verifiers,
so
I'm
going
to
start
with
the
simplest
type
of
verifier,
and
that's
verifier
that
mostly,
we
trust
the
notary,
and
the
idea
is
that
we
want
to
have
the
easiest
time
for
the
for
this
type
of
verifiers.
F
It
should
be
very
easy
right,
so
you
should
be
able
to
validate
registration,
completely
offline
and
using
minimum
information
without
having
to
even
look
at
the
statements
inside
the
claim
right
and
so
for
that
you
are
just
going
to
use
the
receipt
validation
procedure
that
is
defined
in
the
receipts
pack
and
make
we'll
talk
about
that
in
the
next
session.
F
But
of
course
you
have
some
verifier
that
don't
fully
trust
the
notary
right,
and
in
that
case
they
can
repeat
if
they
want
to
some
of
the
checks
that
were
applied
at
the
notary.
But
so
this
type
of
advanced
verifier,
we
call
them
Auditors
and
the
purpose
of
the
Auditors
is
to
have
effectively
keep
the
notary,
honest
right.
So
if
nobody
cares
about
what
the
notary
is
doing,
then
you
don't
really
get
a
very
strong
property
for
the
everyday
verifier.
F
N
So
just
a
quick
clarifying
question
is
the
notary,
or
is
the
auditor
replaying
the
whole
Ledger
or
just
relevant
to
some
particular
application?
What
what
exactly
is
the
auditor
auditing
uh-huh?
Yes,.
F
So
so
it's
up
to
the
auditor
to
decide
so
it's
possible
to
audit
the
full
Ledger.
Of
course
the
text
can
take
a
lot
of
time,
but
you
can
also
partially
audit
in
the
sense
that
you
can,
for
instance,
select
an
issuer
and
only
replace
the
registration
under
the
claim
for
that
particular
issue
or
any
kind
of
subset
right.
So
so
I
think
part
of
the
point
that
is
maybe
not
answering
your
question
is:
how
do
you
as
an
auditor?
F
How
do
you
query
The
Ledger
and
currently
we
have
decided
we
are
not
really
specifying
what
is
a
standard
API
for
auditing
or
accessing
the
registry,
and
that
is
definitely
one
of
the
open
items
for
the
working
group
to
work
on
whether
we
so
what
kind
of
queries,
what
kind
of
apis
can
be
used
to
actually
audit
The
Ledger?
That
is
still
an
open
question.
So.
N
D
Fact,
okay
or
a
steel
just
to
restate
the
answer
that
was
given,
there's
sort
of
three
ways
to
think
about
the
audit
process.
The
simplest
case
is
your
auditing,
a
specific,
transparent
claim
like
one,
the
more
advanced
cases,
all
transparent
claims
made
by
partic
associated
with
a
particular
issuer,
and
the
third
is
the
entire
transparency
registry
which
it
you
know
would
be
very
expensive.
That's
it.
F
Okay,
so
no
the
going
back
to
what
we
discussed
earlier
about
the
the.
What
is
the
guarantee
that
we
give
to
the
verifier
right,
because,
ultimately,
there
is
all
of
this
machinery
for
the
issuers
to
operate
the
register,
the
notaries.
So
all
of
that
it
only
makes
sense
if
there
is
some
benefits
for
the
for
the
for
the
verifiers,
and
so
the
the
main
benefits
of
heat
is
to
guarantee
the
accountability
of
issuers.
F
So
we
want
to
be
able
to
prevent
equivalating
issuers,
which
would
be
a
class
of
issuer
that
give
different
claims
about
the
same
artifact
to
different
people
and
that's
kind
of
a
way
to
distribute
bad
code.
F
There
is
also
this
idea
of
accountability
of
the
notaries
themselves,
so
we
don't
want
to
Blind
it
also
notaries,
and
that's
why
the
registry
is
there
to
keep
all
of
the
evidence
to
allow
an
audit
after
the
facts
of
what
registration
and
policy
and
what
tracks
were
performed
at
the
registry
right,
and
this
gives
the
both
the
auditability
of
the
claims
and
auditability
of
the
registration
policies
that
were
applied
by
the
notaries
question.
L
Yeah,
thank
you
Deandra,
the
18t
now
that
everybody
convinced
me
that
Registries
are
good.
I
just
still
have
a
challenge
with
the
architecture,
because,
as
far
as
I
understand
you
look
at
the
architecture,
you
got
the
issuers
and
verifiers
and
that
gets
replicated
so
a
verifier
can
be
an
issue
or
maybe
using
a
different
registry,
and
at
that
point,
I'm
questioning.
How
will
the
Registries,
inter
inter-registry
trust,
yes
and
and
and
then,
how
do
you
really
reconcile
with
this?
L
F
Yes,
obviously
that
that's
that's
an
important
question
and
it's
not
an
easy
one,
and
we
are.
We
had
a
lot
of
discussion
about
this
during
the
hackathon
and
this
will
be
addressed
in
some
of
hang
slides
in
the
hackathon
report.
F
D
H
Dave
here
I
was
just
going
to
ask
if
you
can
elaborate
and
just
say
more
about
how
you
detect
incorrect
questions.
F
Yes,
if
you
can
just
say
more
so,
I
do
have
some
concrete
example
to
show
you
okay,
so
so
this
is
a
concrete
example
of
an
equivocating
issuer
right.
So
it's
an
issuer
that
is
going
to
to
produce
two
versions
of
the
of
of
the
software,
and
one
is
going
to
be
using
honest
Scott
and
one
is
going
to
have
malware
or
virus
or
whatever.
F
So
in
that
case,
the
issuer
is
a
malicious
one
and
he
wants
to
attack
some
of
the
users,
and
the
idea
is
that
if
you
first
the
so
if
every
verifier
is
going
to
require
a
receipt
from
the
notary,
then
the
only
way
that
this
would
actually
be
possible
is
if
the
issuer
registers
both
of
these
claims
on
the
notary
and
then
two
things
could
happen
so
either
you
have
a
quite
Advanced
notary.
F
That
is
going
to
actually
look
at
the
contents
of
the
claim
and
possibly
detect
that
the
second
claim
is
a
bad
one.
In
that
case,
the
second
grade
may
even
not
get
registered
at
all,
but
that's
kind
of
optimistic,
so
pessimistically,
let's
assume
that
the
notary
is
relatively
basic
and
the
boss
claims
actually
get
registered.
F
So
in
that
case
you
still
have
the
registry
itself
as
essentially
long-term
proof
that
can
be
used
to
detect
by
auditor
that
the
issuer
was
equivalating
and
it
can
keep
the
issue
accountable
because
you
have
enough
proof
to
blame
the
issuer.
So
the
the
non-reparation
arguments
through
the
through
the
Ledger
I'll
tell
you
that
it
was
the
issuer
that
was
manifested
that's.
G
H
I
I
think
so
let
me
tell
you
what
I
got
is
the
answer
that
your
definition
of
correct
relies
on
the
same
answer
being
given
to
everybody?
Yes,
if
you
give
the
same
wrong
answer
to
everybody,
it
is
not
incorrect.
That's
cool!
H
A
A
B
Yeah,
the
other
just
because
this
is
about
the
fourth
time,
I
think
the
same
form
of
question
has
come
up.
So
if
you
refer
back
to
ori's
Second
statement
on
what
transparency
offers,
the
first
thing
is:
yes,
we
can
see
it,
but
the
really
important
second
thing
is:
you
have
to
have
registered
your
claims
at
a
verifiable
point
in
the
past.
B
In
order
for
them
to
be
valid,
which
means
you
have
to
have
all
of
your
operations
laid
open,
which
means
you
can't
selectively
lie
cheat
repudiate
or
whatever
and
and
it's
a
responsibility
on
the
verifier
to
not
accept
statements
that
are
given
post
facto
out
of
band
or
whatever,
because
otherwise,
all
of
these
other
Things
Fall
Apart.
So
it
is
a
whole
system,
responsibility,
okay,.
Q
Two,
a
couple
of
things
regarding
the
roles
of
the
notary,
the
issue
you
mentioned
one
thing
that
will
somehow
concern
me
when
you
say
that
the
notary
is
a
very
simplistic
one
and
cannot
verify
that
the
malware
is
there
or
not.
My
understanding
of
the
notary
is
that
this
is
a
totally
I
mean.
The
operator
of
the
transparent
registry
is
not
going
to
make
another
additional
text,
because
in
that,
in
that
case
the
notary
would
become
an
issue.
Q
It
doesn't
I
mean
you're,
not
against
that
that
you
have
notaries
with
issuers
inside
that
make
a
additional
issues,
but
my
understanding
is:
is
that
the
notorious
yes
I
mean
it
puts
an
envelope,
a
sealed
envelope
around
wrapping
the
the
decline
right
or
are
we
thinking
about
other
roles
for
the
notary,
because
that
to
complicate
the
whole
thing
you
know.
F
F
We
require
that
it
means
that
the
notary
must
have
checked
the
issuer.
Signature,
that's
the
Baseline,
but
you
can.
You
can
also
perform
additional
checks
for
which
the
endorsements
in
the
receipts
would
be
essentially
a
witness
that
these
checks
have
been
performed.
F
Than
this
is
not
an
issue
at
all,
it's
it's
it's
a
again.
There's
a
difference!
Is
that
it's
an
endorsement!
You
accept,
you
accept
a
claim
that
was
made
by
someone
having
checked
some
additional
property,
but
it
doesn't
mean
that
you
are
authoritative
for
that
particular
information.
The
claim
Remains
the
responsibility
of
the
issue.
Q
And
that
that
brings
me
to
the
second
is
about
I
mean
composure
issues,
because
in
the
in
all
the
examples,
the
issue
is
apparently
the
developer
or
the
vendor
of
the
software,
but
as
an
user
I
could
make
want
to
make
another
issue
to
issue
another
thing
that
say:
I
tested
it
and
it
was
right.
Yes
and
that's
fine
right.
F
F
A
F
A
A
little
bit
of
out
of
time
but
I
I've,
maybe
we
could
shorten
the
policy.
You
want
to
shorten
the
policy
about
this.
One.
F
So
I
was
hoping
to
just
brief.
Okay,
maybe
we
can
go
to
the
last
one,
which
is
how
do
we
solve
the
use
case
right?
It's
a
customer.
G
F
Yeah,
okay,
so
yes,
I
think
this
one.
We
don't
really
want
to
serve,
because
this
is
supposed
to
connect
everything
I've
explained
towards
yogesh,
as
explained
before.
So
it's
basically
a
summary
right.
So
we
want
to
be
able
to
assess
the
risk
of
social
availabilities
from
the
artifact
that
we
consume
and
we
achieve
that
by
requiring
at
the
verifier
to
have
this
endorsements
from
notaries
or
the
purification
of
the
receipts
to
make
sure
that
everything
can
be
audited
later
and
that's
the
issuer
ends.
F
Notaries
are
kept
auditable,
so
the
architecture
supports
uniform
methods
for
issuing
statements.
So
that's
the
first
row
that
we
reviewed
the
verification
of
the
Integrity,
authenticity
and
timeliness
or
freshness
of
statement.
That's
the
role
that
is
mostly
assigned
to
the
notary
and
creating
consistent
abundantly
verifiable
recursive
statements.
That's
the
role
of
the
skit
receipts
and
that's
what
drives
the
verifier
flow,
so
user
defined
are
the
policy
for
determining
which
statements
are
trusted.
F
So,
unfortunately,
you
are
able
to
skip
over
my
policy
slides
because
there
are
three
types
of
policies
as
a
policy
at
the
issuer.
What
statement
do
you
endorse?
Do
you
sign?
There
is
a
policy
at
the
notary.
What
claims
do
you
accept,
which
is
a
form
of
endorsement,
and
then
there
is
a
policy
at
the
verifier.
Is
this
notary
or
what
additional
check
should
I
perform
right?
So
I
hope
that
was
a
useful
overview
of
the
architecture.
Everyone
is
welcome.
It's
available
on
the
data
tracker
to
submit
comments
on
the
mailing
list
and
suggest
improvements.
A
Excellent,
are
there
some
further
questions
on
this
this
topic?
So
it's
obviously
a
lot.
The
document
contains
terminology
talks
about
other
things
we
spoke
about
just
now
and
and
more
because
we
skipped
a
few
things,
and
so
it
was
our
impression
that
we
should
do
a
call
for
adoption
on
this
architecture
document
there's
a
kind
of
a
starting
point
so
that
we
have
something
to
to
work
with
and
I'm
going
to.
A
Of
course,
we
have
to
confirm
that
on
a
mailing
list,
but
I
wanted
to
do
a
show
of
hands
using
our
famous
show
offense
tool
if
I
figure
out
how
to
formulate
the
question.
A
Okay,
so
in
essence,
I'm
asking
in
a
complicated
way
of
whether
you
you
agree
or
if
you
don't
trace
your
hand,
disagree
with
adopting
this
the
architecture
document
as
a
starting
point
that
I'm
saying
as
a
starting
point
because,
like
as
we
as
Antoine
mentioned
at
the
beginning
of
the
talk
test,
the
terminology
is
the
rough
edges
and,
of
course,
there
was
feedback
during
the
meeting
which
we
we
need.
We
we
need
to
capture
and
I'm
sure
a
lot
of
other
things
missing.
A
Okay,
so
here's
what
I
have
and
I
end
the
session
oops.
It
was
36
to
3
so
set
this
for
a
meeting
minute
taker
33
36
people
were
in
favor
and
three
were
against
them.
A
A
F
I'm
going
to
another
to
make
for
the
receipts.
I
I
Registration
means
that
you
have
your
registration
policy
is
applied
and
what
that
means
what
Antoine
said
already?
You
know
you
need
to
verify
the
claim
signature
and
there
can
be
other
policies.
Obviously,
then,
as
part
of
registration,
you
store
the
claim
in
the
registry,
so
The
Ledger,
you
produce
eventually
a
receipt
and
return
that
to
the
submitter
and
obviously,
if
we
Define
apis
Etc,
then
there's
always
also
a
way
to
retrieve
the
receipt,
not
just
by
the
submitter,
but
also
you
know
at
a
later
point
in
time.
I
I
think
we'll
probably
do
that
and
yeah
the
important
bit
is
that
the
receipt
you
know
it's
it's
an
offline
verification
of
the
claim,
so
we
should
probably
qualify
that
what
that
really
means,
but
it
it
means
all
the
points
that
happened
before
has
have
happened
and
you
can
by
verifying
the
receipt
you
can
make
sure
if
you
trust
the
notary,
that
those
things
happened
so
yeah,
it's
quite
simple.
It
should
be
simple.
I
think!
That's
that's
the
idea
next
slide.
I
Okay,
so
now
we
get
into
a
bit
more
of
what
and
receipt
actually
is,
and
if
you
think
of
in
a
transparency
service,
you
can
think
of
it
a
bit
like
an
electronic
notary.
So
it
does
certification
on
the
authenticity,
odd
authenticity,
sorry,
I'm,
German
salt
for
me
of
the
claim
signature.
So
that's
one
thing
and
then
it
also
certifies
any
additional
registration
policies
applying
to
the
claim,
and
so,
if
we
look
at
it
like
that,
then
treating
it
like
a
counter
signature
on
a
technical
level.
I
Then
it
means
you
have
this
nice
property
that
you
can
embed
receipts
in
the
the
unprotected
part
of
your
claim,
and
so
you
have
this
nice
bundle
and
you
don't
need
to
create
another
wrapper
structure
that
makes
it
even
more
complicated,
and
so
we
basically
take
inspiration
from
cozy
counter
signatures.
But
it's
not
exactly
that
and
I.
Think
yeah
I'll
talk
more
about
that
on
the
next
slide.
I
So
why
do
we
need
a
new
format?
Then
can't
we
just
use
standard
cozy
counter
signatures
for
that,
since
it
sounds
the
same
well,
not
quite
because
a
cozy
counter
signature
would
countersign
a
single
individual
claim,
but
in
transparency
Services,
usually
what
happens?
Is
you
put
claims
on
The
Ledger
and
then
eventually
you
sign
the
democratri
root
of
that
ledger
and
and
so
there's
a
bit
of
an
indirection
there
and
that's
that's
handled
with
inclusion
proofs
and
this
extra
step
means
we
need
something.
I
You
know
that
allows
verifiers
to
do
this
step
and
we
had
some
discussions
that
we've
now
abandoned
on
whether
we
can
you
know
kind
of
shoehorn.
Those
those
details
in
existing
cozy
Concepts
so
actually
do
use
normal
cozy
counter
signatures
and
we
had
the
idea
of
okay.
Maybe
we
can
actually,
you
know
just
create
like
a
new.
You
know:
skit
received
signature,
algorithm
and
then
stuff
everything
into
the
signature
bytes
and
make
it
a
bit
more
of
a
meta
thing,
but
the
community
widely
disagreed.
I
That's
a
good
idea,
so
I
think
we'll
just
abandon
that
because
it
would
just
lead
to
too
many.
You
know
roadblocks
on
the
way,
and
people
generally
agree
that
exposing
the
concept
of
transparency,
the
fact
that
you
have
ledgers-
you
know
they
do
have
inclusion
proofs
a
bit
more
to
the
top
of
the
format,
seems
to
make
sense,
and
if
anyone
wants
to
look
up
the
discussion
we
had
on
the
mailing
list,
there's
a
link
at
the
bottom
next
slide
all
right.
So
don't
look
at
that
too
closely.
I
It's
just
a
very
rough
first
draft
and
I'm
kind
of
I'm
really
glad
that
we
have
so
many
people
in
here
that
deeply
care
about
formats
and
that
are
also
involved
in
cozy
and
structures
and
all
of
that,
so
the
idea
is.
We
have
this
new
thing.
We
call
it
receipt
and
we
have
very
likely
I
mean
at
the
moment
we
do
have
a
protected
header.
We
can
also
add
an
unprotected
one
if
that
makes
it
easier
to.
I
You
know
slot
into
existing
structures,
and
then
we
have
all
the
other
stuff,
which
is
the
inclusion
proof,
the
actual
signature
and
yeah,
and
then
we
have
to
figure
out
exactly
how
that
works.
One
of
the
challenges
is
that
we
have
to
think
about
multiple
types
of
you
know
ledgers
because
they
may
have
different
local
trees
even
and
and
slightly
different
ways
of
ways
of
hashing.
You
know
the
leaves
and
and
the
intermediate
nodes.
So
there
has
to
be
a
bit
of
flexibility
on
you
know.
I
We
call
this
at
the
moment
the
tree
algorithm,
but
we
have
to
see
which
parts
we
can
make
common
in
this
format
and
which
parts
are
just
kind
of
like
a
like
an
algorithm
that
you
have
to
Define
somewhere
and
then
you
have
to
define
the
the
pieces
that
would
go
into
like
you
know
something
like
a
signature
by
its,
but
in
this
case
it's
not
a
signature
bytes,
it's
more
like
the
yeah.
How
do
we
call
this
natural
bytes,
but
yeah?
I
Let's
and
I
think
that's
where
we'll
have
a
lot
of
actually
discussions
and
I
hope
we
can
Converge
on
something
that
makes
sense
the
protected
header?
What
do
we
have
in
mind,
for
that?
Is
that
it's
it's
not
too
much
different
from.
You
know
the
protected
header.
I
What
you
could
put
in
there
in
in
normal
cozy
signed
messages,
so
it
needs
to
be
some
kind
of
identifier
of
this,
the
the
transparency
service,
so
that
you
can
do
key
lookups
and
have
you
know
a
strong
identity
over
that,
and
you
know
there
even
on
that
level.
There
are,
there
are
variations
on
what
that
could
be.
I
It
could
even
be
a
did
at
this
point,
but
you
know
there
are
some
services
that
may
use
mainly
certificates.
So
you
know
we
have
to
see
how
that
how
that
all
fits
together.
I
Certainly
it
would
be
a
little
bit
nicer
if
we
actually,
since
we
already
intend
to
use
the
IDS
for
for
claims,
it
may
make
sense
to
also
do
that
for
the
transparency
Services
themselves
so
and
then
yeah
as
I
said,
we
have
two
algorithms
Microsoft
has
recently
open
sourced
a
kind
of
prototype
implementation
of
this
so
and
for
that
we
use
CCF
and
again.
The
format
for
that
is
is
this.
I
You
know
draft,
but
we
can
imagine
that
there
are
more
than
that
trillion,
for
example,
qldb,
and
apart
from
that,
there
may
even
be
different
variations
of
receipts.
So
we
have
some
some
thoughts
on.
I
You
know
the
kind
of
the
primary
receipt
when
you
store
something
in
The
Ledger,
but
then
also
something
like
when
you
read
something
from
The
Ledger
and
you
want
to
get
extra
guarantees
that
this
is
still
fresh.
So
there
may
be
different
types
that
also
we
have
to
encode
somewhere
in
there
yeah
and
then
in
issue
time
time
of
registration.
It's
very
useful.
I
Yeah
and
then
the
proof
as
I
said,
that's
in
the
draft
by
the
way
we
call
it
contents
at
the
moment,
but
maybe
that's
not
a
great
word.
Proof
is
also
probably
not
a
great
great
world.
So
there
has
also
been
some
suggestions
to
actually
split
this
up
into.
You
know,
kind
of
Ledger
bits
and
then
have
signature
as
a
separate
field.
Maybe
that
works.
I
Let's
see
next
slide
yeah
and
we
had
an
extremely
short
slot
India,
because
the
working
group
session
on
Tuesday,
so
just
a
few
minutes
to
advertise
that
I,
guess
and-
and
you
know,
get
the
idea.
Oh
there
was
no
immediate
objection,
but
I
wouldn't
necessarily
count
that
as
approval
or
anything
because
the
time
was
so
short.
So
if
anyone
has
any,
you
know
feedback
or
wants
to
collaborate
on
that.
I
You
know
find
us
on
the
mailing
list
and
we
will
also
do
the
same,
really
engage
with
the
Cozy
folks
and
work
together
on
defining
bringing
transparency
to
Cozy.
That
will
be
the
goal.
M
D
Yeah
so,
or
or
SEO
just
to
ask
about
the
draft
status
for
receipts.
The
document
associated
with
with
this
is:
are
we
at
a
similar
stage
for
a
call
for
adoption
for
the
working
group,
or
do
we
still
want
to
wait
for
the
call
for
adoption
for
receipts
I.
A
I
would
let
it
settle
still
a
little
bit
until
we
like
there's
some
like
as
next
steps
on
on
so
in
general,
we
have
to
use
case
document
which
I
expect
to
to
be
Rewritten
and
improved,
and
then
there's
the
architecture
document,
which
has
obviously
lots
of
open
issues
like
getting
some
of
the
terminology
sorted
out,
so
that
we
don't
don't
use
different
terms.
A
All
over
the
place
would
be
would
be
good
and
then
that
that
people
do
have
a
call
for
adoption
of
the
architecture
document
next
week,
and
so
I
hope.
This
advances
and
I
mean,
while
there
was
more
feedback
from
the
from
the
Cozy
group
and
also
from
this
group,
I
think
the
attention
is
still
at
the
architecture.
Level
use
case
level
use
case
description
right
now
because
of
our
first
meeting.
Obviously
but
yeah
Roman.
C
Hi
Roman
Janelle
I
was
jumping
the
queue
to
really
endorse
that
position
for
the
working
group.
Let's
get
what
we
want
to
do
settled
and
then
you
know
we
can
talk
about
how
we
want
to
solve
it,
because
I
don't
want
to
get
us
in
a
position
where
we're
talking
all
about
solution
things
while
we're
iterating.
What
exactly
we
want
to
solve
and
I
think
that's
just
going
to
give
us
a
lot
of
focus.
J
Hi
this
is
Hank.
I'm
gonna
give
a
first
part
about
what
we
call
a
hackathon
report.
We
did
not
produce
any
code
at
the
hackathon,
so
we
we
wasted
a
lot
of
paper,
I'm
apologizing
to
the
impact
on
trees.
J
Next
slide,
please.
So
what
we
were
talking
about
is
the
thing
that
again
is
a
terminology.
Snuff
who
saw
the
administrative
information
that
is
about
the
artifact
is
the
statement,
and
then
the
statements
can
be
big,
so
we
are
talking
about
how
to
detach
the
actual,
and
you
register
that
the
actual
statement
from
the
place
where
you
register
the
statement
so
that
you
can
have
a
tree
because
most
of
these
Registries
slash
notaries,
are
trees,
hash,
trees,
macro
trees.
J
We
would
like
to
separate
terabytes
sized
statements
from
that.
We
found
1952
that
says
not
our
problem.
Do
this
on
the
application
Level
we
found
1954
that
has
at
least
the
how
to
find
things
via
that
I
think,
based
on
through
these
two
fragments
and
maybe
a
location
where
to
find
it
I'm
doing
some
cross
advertisement
here.
This
can,
of
course,
be
a
URI
that
is
resolvable
or
a
CRI.
That
is
resolvable
or
a
URL
or
a
CA
URL
crl.
Sorry
that
isn't
actually
a
thing
I
know
so.
J
Yeah,
you
know
the
it
you're
also
for
humans,
your
eyes
for
humans,
crisp
of
machines,
and-
and
this
will
be
big
at
some
point,
so
you
want
to
make
the
small
and
concise
little
proposal
is
to
actually
I'm,
not
sure
if
this
have
been
done
before
so
if
it
has
been
done
before,
we
were
happy
about
pointers
but
create
a
detached
cozy
envelope,
especially
for
the
sign
statements
in
skit
next
slide.
Please,
and
maybe
Brent-
wants
to
say
something
before
but
next
slide.
Please
again,
you
should
know.
N
J
A
J
Good
thing,
but
shoot
is
different,
it's
just
saying
yes,
and
maybe
we
will
do
it
the
exact
same
way,
but
we
have
to
go
through
all
the
steps
again
to
find
out
if
you're
doing
that,
with
access
hempstick,
so
I'm
not
entirely
convinced,
but
maybe
that's
the
result
so
discussions
why
there
are
things
out
there,
so
we
want
to
not
only
just
build
totally
new
systems
with
our
building
blocks.
We
want
to
help
existing
systems.
We
want
to
be
integratable
into
systems
easily.
J
So
and
one
of
those
are
content,
addressable
storages,
they
are
already
out
there
like
a
ton
of
them
and-
and
that
would
be
in
trouble
support
of
those
and
I
already
highlighted
as
a
spoiler.
That
statements
can
be
big
and
there
might
be
drawbacks
and
having
the
statement
included
in
the
tree,
and
then
there
are
also
regulation
problems.
J
First
of
all,
it's
it
might
just
do
them
want
to
expose
it.
You
want
to
expose
the
fact
that
you
are
accountable
for
what
you
say.
You
want
to
expose
the
fact
that
you
said
it
or
what
exactly
was
said.
If
you
want
to
have
more
fingering
control
about
more
than
the
notary
might
allow
for
so
these
are
then
hosted
somewhere
else,
and
you
have
more
fine-grained
control
about
the
accessibility
and
then
again
there
might
be
a
person
identified
information
in
there.
J
So,
of
course,
we
have
to
address
that
some
of
them
disclosable
claims,
there's
work
in
w3c
about
this
might
be
a
solution
here,
but
again
that
is
a
separation
of
Duty,
and
that
is
again
another
reason
why
we
would
like
to
do
this
and
now
Michael
has
a
hands
up.
O
Yes,
Hank
I'm,
gonna
iterate,
the
need
for
statements
being
big
with
some
of
the
data
sets
we're
dealing
with,
and
software
assets.
We're
dealing
with
that
feed
into
this
I
did
also
want
to
ask
with
your
experience
with
the
hackathon
side.
Did
it
expose
anything
around
like
terminology
and
use
cases
that
you
know
would
Echo
support
for
what
Romans
stated
earlier
as
far
as
landscape
core
architecture,
because
I'm
noticing
a
lot
of
conflicts
between
terminology
slide
to
slide.
J
So
that
is
my
first
initial
response.
Also,
we
have
I
think
we
have
developed
a
few
good
proposals
that
we
will
admit
to
the
list.
So
there's
another
thing,
so
the
hackathon
also
has
something
about
that,
but
we
can't
show
everything
the
hackathon
because
of
you
know
time
so
go
let's
go
to
the
next
output.
This
is
basically
output.
One
output
two
is
also
about
statements,
and
so
this
is
my
title.
We
are
not
the
curators
of
a
thousand
semantics.
J
J
This
is
not
a
centralized
thing
that
can
be
standardized.
You
can
maybe
standardize
a
module
interface
for
some
specific
statements
that
you
plug
in,
but
they're
self-responsible.
For
that
maybe
even
issue
your
own
claim
on
the
registry
that
you're
responsible
for
that.
That
would
be
funny
but
also
possible.
J
It
is
actually
a
nice
system,
so
so,
but
the
important
Point
here
is
that
maybe
some
of
these
statements
are
not
opaque
to
the
Note
3
by
standard.
Maybe
we
want
to
create
some
standard
statements
and
we
can
go
to
example,
a
which
is
this
deferral,
hash,
link
and
there's
the
actual
statement.
That
is
a
standard
statement
that
we
could
Define
and
there
might
be
more
than
just
this
one.
J
So
the
proposals
here
to
define
a
small
set
of
named
and
registered
standard
statement,
structures
that
are
actually
transparent
to
the
node
View
and
everybody
using
Solutions
in
the
register
notice
system.
So
next
slide,
please.
There
are
two
examples
that
we
found
interesting
to
discuss.
There
might
be
Universal
ones
like
a
revocation,
but
we
don't
really
revoke
anything
because
we
are
audible
after
the
fact
we
refresh
our
opinion,
foreign.
J
Of
course
we
were
wrong
and
maybe
it's
still
okay
to
say
the
one
thing
like
build
buildings
with
this
I'm
doing
a
non-software
analogy
right,
build
building
for
this
and
20
years
later,
it's
like
yeah,
okay,
buildings
are
still
fine
building
of
this,
but
it's
not
fine
for
humans,
so
maybe
not
the
buildings
for
humans
with
this
and
and
so
this
is
an
additional
information
you
want
to
augment,
and
so
that's
that's
something
that
is
a
semantic
relationship
that
can
be
transparent,
so
refreshing
a
statement
could
be
a
a
standard
statement
structure
that
is
also
not
opaque
to
the
system.
J
Then
we've
talked
about
endorsements
a
lot.
I
is
you're
talking
about
the
another
statement
that's
already
in
there,
and
that
might
be
something
that
you
really
want
to
elaborate
on.
That
could
be,
for
example,
yet
another
transparent
statement,
so
why
this
is
in
support
of
the
solution.
So
we
can't
just
build
building
blocks
because
they
look
nice.
We
won't
enable
people
to
interrogate
them
into
the
systems
or
build
new
systems
with
them.
And
typically
you
have
something
to
query
for
the
information
there
will
be
apis.
There
will
be
indexing
servers.
J
There
will
be
huge
scalable
systems
that
help
you
understand
that
I
want
to
and
can
use
this
software.
So,
in
order
to
do
that,
you
need
some
well
interlinked
things
and
now
going
through
the
third
output,
there
might
be
interlinked
things
that
you
don't
understand
with
open
next
slide,
please
exactly.
J
There
might
be
references
to
other
transplant
statements
that
are
opaque
to
the
notary
and
maybe
even
to
the
consumer
at
some
point,
Auditors
might
understand
them
or
a
very,
very
informed
end
user
might
understand
them,
and
still
you
want
to
understand
easily
to
build
graphs
that
they
are
linked,
so
there's
a
semantic
relationship.
That
is
super
simple.
That
is
kind
of
obvious
when
you
don't
want
to
talk
about
content
of
statement.
That
is
this.
This
statement
refers
to.
J
The
other
statement
like
a
refresh,
would
restore,
of
course
refer
to
its
complement,
and
now
we
are
asking
ourselves
how
we
do
this.
Actually,
if
we
can't
really
infer
by
the
statement
content,
because
we
are
not
the
curators
of
thousand
statements,
how
do
you
do
basic
relationships
and
is
one
Edge
like
you
know
connected?
Is
that
enough?
Is
that
enough,
as
an
agnostic
way,
to
do
this
and
next
slide?
Please,
and
then
micro
can
say
something.
O
I,
do
I
just
wanted
to
emphasize
an
interesting
thing,
that's
kind
of
topical
in
the
US.
We
have
a
food
safety
regulation
that
just
hit
the
wire
it's
been
debated
for
a
while,
but
is
now
going
out
where
the
FDA
has
specified
the
content
and
the
payloads
and
all
these
things
that
have
to
be
collected.
But
it
has
no
mechanism
right
or
way
to
go
ahead
and
actually
provide
auditability
on
when
certain
events
have
happened
from
a
traceability
standpoint.
O
So
it's
this
intersection
between
the
digital
side
and
the
physical
side,
and
so
one
of
the
things
I
like
about
this
is
that
it
provides
that
ability
to
say
oh
yeah.
These
guys
over
here
said
what
content
has
to
be
tracked.
What
types
of
events
have
to
be
tracked
and
how
you
need
to
be
able
to
get
that
data
back
to
me,
and
this
provides
a
mechanism
to
verify
that
data.
So
it's
highly
important
from
that
food
safety
aspect
for
sure.
So.
J
Yeah
and
a
lot
of
other
supply
chain
world
in
the
software
supply
chain-
World,
okay,
now,
okay,
whatever
so,
why?
So
again,
as
I
said,
integration
into
existing
system
is,
is
really
really
important
to
us.
We
want
to
have
feedback
of
people
who
are
who
can
see
a
benefit
of
adding
components
to
their
solution
and
understand
how
integration
really
works
in
the
end
and
I.
J
Think
one
example
here
is
that
you
need
your
own
software
and
you,
you
actually
have
a
few
transparency
services
like
and
already
sorry
registers
that
again
terminology
and
that
you
trust,
so
you
need
a
remediation
Guardian,
because
you
know
about
your
vulnerability
disclosure
report
of
about
use
software
and-
and
you
can
actually
identify
that
software
via
Suite
in
your
system.
J
So
that's
a
complicated
query.
All
these
things
have
to
be
kind
of
followed
in
a
semantic
transition
array.
There's
some
there's,
no
direct
relationship
between
them
and
still
you
want
to
have
a
remediation
guidance,
because
what
you
want
to
do
is
the
most
important
thing
for
incident
remediation.
So
that
is
a
good
I.
J
Think,
example,
why
why
these
relationships
are
necessary
to
some
extent
and
why
we
can't
still
make
them
specific
to
the
to
the
state
and
content,
because
that
again
might
be
pii,
confidential
or
totally
obscure
or
in
an
OCR
and
not
OCR
PDF
endorsement
I
I've
seen
these
things
everybody's
seen
these
things
right,
so
it
might
not
be
as
as
possible
as
you
like,
and
so
so
these
are
digests
from
the
hackathon.
J
There
were
more,
but
literally
digesting
three
relevant
topics
out
of
two
days
of
hard
discussions
all
over
the
place.
I
think
that's
a
pretty
good
summary
of
three
of
those
and
we'll
hand
off
the
multiple
The
Ledger,
a
scenario
to
to
Ari.
If
there
aren't
any
questions
here
right
now
and
that's
not
the.
O
D
Sorry,
I'm
gonna
have
to
move
this
down
a
little
bit
there.
We
go
yeah
right.
So
there's
a
number
of
wait
like
as
Hank
just
mentioned,
there's
a
number
of
ways
where
there
might
be
some
first
thing
pointing
to
a
second
thing
and
based
on
the
architecture
you've
all
seen
today.
You
can
probably
imagine,
there's
more
than
one
way
to
do
this,
so
we
thought
about
this.
D
We
talked
a
lot
about
this
at
the
hackathon
and
we
have
some
strong
statements
to
make
about
how
we
think
it
should
be
composed
and
if
you
agree
great,
if
you
don't
agree,
also
great-
and
please
share
your
opinions
about
this
on
the
list
and
engage
in
the
documents
and
issues
but
I'd
like
to
explain
this
picture
just
a
bit
because
you
can
see
here
there's
this
first
statement,
there's
validation.
The
issuer
performs
the
issuance
operation,
they
get
the
sign
statement.
D
If
you
have
a
good
reason
why
you
think
that
this
is
good
or
you
know
the
other
one
that
was
bad.
Please
come
talk
to
us,
we'll
be
happy
to
have
those
conversations,
but
this
is
the
ye.
Yes,
this
one
is
the
one
we
think
should
happen,
and
you
know
there's
there's
good
reasons.
Lots
of
good
reasons
for
that.
D
So
we
we
talked
about
a
software
supply
chain
use
case
before
and
I
wanted
to
show
another.
You
know
brief
summary
of
an
example
in
a
different
sort
of
domain
and
I
wanted
to
explain
what
it
might
look
like
with
a
single
transparency
service
to
solve
this
problem
and
then
I'm
going
to
show
you
some
other
pictures
that
have
some
additional
benefits
in
terms
of
confidentiality.
D
So
in
this
story
here
we're
going
to
have
a
device
driver
author
who's
going
to
make
a
first
Claim
about
some
GPU
Hardware,
firmware
versions,
measurements
fips,
certification,
I,
have
that
first
claim
is
going
into
the
transparency
service
and
we're
getting
receipt
out.
Then
later
an
OS
vendor
is
preparing
their
OS
bundle,
vendor
name
fips,
compliant
build
versions
and
they're,
including
this
first
receipt
here,
and
this
little
square
failed
a
year
to
process.
Utf
encoding
deal
is
signifying
that
this
is.
D
There
could
be
a
problem
here
in
the
inclusion
of
information
about
this
device
driver's
output
and
so
I'm
when
I'm,
trying
with
this
little
black
question
marks,
is
trying
to
indicate
that
there
can
be
at
any
point.
There
could
be
inclusion
of
information
that
you
might
want
to
get
back
to
and
that's
why
you
want
those
going
into
the
transparency
service.
D
So,
at
the
end
of
the
second
process,
a
second
receipt
is
generated,
and
in
this
final
one
you've
got
claim
three
and
claim
three
is
from
a
cloud
service
provider
and
they
are
going
to
be
creating
some
claims
about
the
information
they
have
about
receipt,
one
some
information.
D
They
have
about
receipt,
two,
the
workload,
measurements
and
SLA
promises
and
they're
going
to
generate
a
final
receipt,
and
in
this
this
is
what
the
auditor
would
see
if
they
view
this
transparency
Services
each
of
these
claims
and
receipts-
and
in
this
case
we
might
imagine,
this
cloud
service
provider
is
offering
a
new
magical
streaming.
D
Video
streaming
service
on
top
of
an
operating
system
and
some
GPU
device
driver
information
to
process
video
at
scale,
and
so
they
want
to
get
committed
transparently
to
all
of
the
components
that
go
into
delivering
that
service
in
case
in
the
future.
Something
bad
is
happening
with
the
video
streaming
processing
and
they
need
to
do
an
analysis.
D
I
should
say
so
and
this
one
here
we've
got
the
same
story,
but
we
have
now
three
transparency
services
and
in
in
this
case
here
I'm
not
no
longer
having
Unicode
parsing
issues,
because
I'm
just
here
to
to
talk
to
you
about
the
the
flow
in
the
happy
case,
not
in
the
case
where
there's
a
an
error
injected
in
the
system.
D
In
this
case,
we
have
receipt
one
and
receipt
two
going
into
claim
three.
So
this
one,
the
OS
vendor,
doesn't
see
that
intermediate
piece
because
receipt
one
is
going
over
the
OS
vendor
and
into
the
cloud
service
provider
directly
instead
of
through
the
OS
vendor.
So
this
is
one
of
those
cases
where
it's
like
did:
I
bundle
that
dependency
or
did
I
ship
a
binary
that
would
require
the
integrator
to
bundle
that
dependency.
D
This
is
a
difference
between
this
one
and
that
one
before,
and
also
the
transparency
services
at
the
bottom
now
we're
not
commingling
claims
and
receipts
from
three
parties
into
one
transparency
service
we've
actually
given
each
of
them
their
own
transparency
service
to
store
these
next
slide
questions.
G
D
D
Awesome
next
slide.
D
So
the
the
main
point
I
want
to
make
here
is
that,
in
the
case
where
the
transparency
service
is
segregating
claims,
previously
we
were
looking
at
the
auditor's
view
across
three
separate
transparency
services,
and
maybe
each
of
those
entities
operating
that
transparency
service
is
going
to
comply
with
that
auditor
and
that
auditor
will
have
deep
visibility
into
the
the
claims
on
that
transparency
service.
D
But
it
is
also
possible
to
have
just
the
view
from
the
device
a
driver,
author's
perspective
which
so
for
my
transparency
service
for
my
device
driver,
artifacts
I
can
see
everything
that
I've
put
in
there
and
I
can
see
all
the
receipts
that
I've
got
and
that
I
can
hand
out
to
all
of
my
friends
who
desperately
want
the
receipts
from
me.
But
I
can't
see
any
of
these
other
things.
D
So
just
go
back
for
one
second
to
show
behind
the
cloud
one
more
time,
there's
a
lot
of
complexity
that
happens
afterwards,
but
I'm
as
the
you
know
original.
If
you
think
about
it
in
the
original
definition
from
the
beginning
of
the
slides,
the
raw
raw
supply
chain
materials
producer,
they
don't
get
to
see
how
their
outputs
are
consumed
at
every
intermediary.
From
that
point
on
in
time,
one
forward
one
slide
again
to
them.
They
make
their
first
raw
material
output
deliverable
and
then
it
goes
into
the
supply
chain.
It
moves
along
they.
D
They
still
have
visibility
into
the
transparency
service
that
they're
anchoring
their
claims
and
they're
generating
receipts
from,
but
other
parties
are
consuming
that
information
and
seeing
those
receipts
nested
into
subsequent
layers
within
the
supply
chain.
So
we
talked
about
these
different
deployment
models
for
the
same
architecture
and
the
benefits,
especially
in
terms
of
confidentiality-
and
you
know,
segregating
by
use
case
for
the
different
vendors
Etc,
and
this
was
another
output
from
the
hackathon,
not
code,
but
pictures.
O
Mike
perock
here
Ori
did
the
topic
of
say
in
this
case
right.
The
vice
driver
author
getting
receipt.
One
of
the
thing
they
checked
in
did
the
topic
of
the
author.
Knowing
who
was
requesting
their
receipts
out
of
the
transparency
service
come
up
at
all.
D
Yes,
so
yeah
go
go
back
one
slide,
so
here
it's
very
clear.
You
know
cloud
service
provider
needs
receipt
one
and
you
can
imagine
that
maybe
cloud
service
provider
is
just
one
of
many
cloud
service
providers
that
needs
receipt.
One.
The
important
part
is
that
the
receipt
one
is
there
and
can
be
given
out
to
anyone
who
may
need
it
did.
I
answer
your
question.
O
O
Does
the
author?
Oh
the
author,.
D
O
D
I
suspect
Antoine
may
be
Q
to
answer
this
question,
but
I
think
the
short
answer
is
the
access
control
policy
for
the
transparency
Services,
the
gating
factor
that
answers
that
question
and
not
the
original
issuer
of
the
claim.
So
the
answer
is
no.
The
original
issue
of
the
claim
is
not
informed.
Every
time
a
receipt
is
handed
out
to
a
relying
party
or
requesting
party
in
yeah.
F
Yes,
so
right,
so
my
comment
is
on
this
idea
that
you
always
have
to
when
you
are
consuming
or
depending
on
receive
data.
In
other
transparency,
it's
always
because
the
downstream
and
one
other
thing
that
was
discussed
in
the
academy
is
not
just
only
how
to
refer
to
these
dependencies
by
value
with
a
detached
thing,
but
also
there
is
a
question
of
how
do
you
actually
refer
to
this
dependency
by
reference,
in
a
way
that
you
can
have
essentially
a
global,
addressing
scheme
for
accessing
claims
that
can
be
registered
at
any
transparency
service?
F
D
D
Yeah,
so
in
the
case,
where
a
claim
is
a
Content
addressable
identifier
to
a
large
artifact
sitting
in
an
artifact
repository,
how
do
I
find
all
receipts
for
that
content?
Addressable
identifier
across
multiple
transparency,
Services,
a
query
in
question
and
there's
a
section
in
the
architecture
where
we
talk
about
potential
querying
interfaces
that
could
help
and
in
Antoine's
slides
when
you're,
looking
at
the
header
you're,
seeing
the
content
type,
the
feed
and
the
issuer.
These
are
all
hints
about
how
to
get
back
to
the
claims
you're
interested
in.
E
Yeah
I
just
wanted
to
kind
of
highlight
to
why
that
this
model
is
very
much
specific
to
us
deployment
where
the
device
driver
author
is
maintaining
its
transparency
service
and
it's
kind
of
the
rest
of
the
how
it
it's
received
is
utilized
is
really
not
for
him
to
kind
of
proceed.
E
Make
on
make
understanding.
But
this
one
is
this
one.
D
E
The
right
one
to
say
that
the
receipt
is
gone
is
gone.
Who's
who
is
using.
It
is
up
for
up
to
them
to
basically
put
it
into
down
down
the
line.
Yeah.
D
R
Yeah
custom
moment
these
are
all
services
where
we
really
want
to
have
a
choice.
I
think
that's
really
important.
R
R
Service
I,
use
and
I
think
Beyond
Integrity,
which
is
right
now
our
main
consideration
I
think
we
also
have
to
look
at
confidentiality
at
some
point.
Confidentiality.
Yes,
yes,
and
in
particular
the
Privacy
aspect,
I
think
they're
pretty
much
orthogonal
in
in
many
ways,
but
I
think.
In
the
end,
it
is
support
for
the
whole
system
to
function,
to
have
certain
quality
criteria
with
respect
to
privacy
that
that
these
Services
may
or
may
not
fulfill
yeah.
R
D
Excellent,
yes,
so
in
this
picture,
I
made
each
of
the
sort
of
tiers
a
different
color,
but
you
could
imagine
that
maybe
device
driver
and
Os
vendor
use
the
same
kind
of
transparency
service,
but
the
the
third
one
uses
a
different
kind.
So
that's
to
speaking
to
your
question
about
choices
in
transparency
service.
D
You
know,
if
there's
only
one,
then
there's
not
a
lot
of
choice.
There
we'd,
like
I
personally,
would
like
to
see
a
lot
of
choices
in
interoperable
transparency
services
and
then
the
second
point
is
about
the
confidentiality,
and
that
applies
to
the
registration
policy
from
the
architecture
slides
before.
So,
if
my
registration
policy
is
I'm,
going
to
be
very
careful
about,
registering
anything
thing
that
isn't
by
that's
by
value,
I
want
to
only
include
registrations
by
references.
D
That's
my
preference,
because
I'm
very
concerned
about
accidentally,
including
large
amounts
of
information
that
might
can
include
pii.
The
registration
policy,
can
communicate
that
to
potential
transparency
service
consumers
so
that
they
can
evaluate
that
policy
and
decide.
Is
this
the
kind
of
transparency
service
that
I
I
want
to?
You
know
submit
data
to
do
they
reflect
the
Privacy
values
that
I
have.
D
You
just
want
one
other
thought
on.
That
is
I,
think
it's
mentioned
somewhere
in
the
slides,
but
the
idea
that
part
of
my
registration
policy
evaluation
might
have
to
do
with
claims.
I've
already
seen
have
already
been
been
anchored,
so
I
think
that's
another
dimension
of
what
you're
saying.
K
Yeah,
thanks
for
the
answer,
I
I
just
want
to
reaffirm
that
it's
a
critical
part
of
the
architecture
to
enable
flexible
Federation.
So
it's
completely
okay
to
have
multiple
transparency.
Services.
You
don't
have
to
agree
on
a
single
transference
service
to
foreign.
K
State
in
your
policies,
which
transparency
services
are
good
enough
from
your
Viewpoint
as
a
consumer
of
a
claim
to
know
that
it's
auditable.
Another
very
important
point
is
that,
as
we
said
earlier,
when
circling
is
issued,
there
may
be
some
access,
control
and
dissemination,
but
essentially
it's
out
there
and
it's
com.
It's
perfectly
acceptable
for
the
same
client
will
registered
in
intermediate
transparency
service
to
make
sure
that
it
remains
available.
K
So
in
the
on
the
slide,
for
example,
if
West
vendor
doesn't
know
or
doesn't
trust
transferences
at
Israel,
it
would
typically
re-register
the
first
Clement
to
its
own
transparency,
service
or
possibly
a
transparency
service
history
to
make
sure
that
it
passes
the
Reliant
participalities
and
we
are
building
a
lot
of
flexibility.
There
I
know
you,
you
can
have
a
policy
that
is
super
demanding,
but
that
that's
really
not
mandated
by
the
architecture.
L
L
How
do
you
trace
the
dependencies
and
and
and
that's
one
use
case,
that
I'm
I
think
it's
missing
in
our
you
know
work
because
it
is
a
very
complex
dependency
because
you
don't
know
exactly
what
you're
running
on
top
as
a
customer,
unless
you
have
some
very
well
packaged
claims
that
say
well,
these
were
given
to
you,
but
maybe
that
is
the
solution.
L
I,
just
don't
know,
I
think
it
will
be
worth
you
know,
taking
into
account
that,
especially
since
you
brought
up
the
the
yeah
because
in
the
end
I
represent
an
operator
and
for
us
risk
management
is
the
most
important
thing,
and
what
we
want
to
know
is
if,
if
there's
an
incident,
how
how
do
I
make
sure
that
I
I
assess
my
risk
I
shut
down
some
applications,
I
turn
off
some
some
devices,
whatever
right
so
I
want
to
be
able
to
use
that
use
case.
L
D
Yes,
it's
it's
a
great
Point
like
we're,
telling
a
story
kind
of
in
the
line
of
the
original
definition
of
the
supply
chain
from
the
first
slide,
starting
with
the
raw
materials
producer.
There's
another
way
to
tell
that
story,
starting
with
the
the
end
consumer
sort
of
experience
of
you
know
using
an
artifact.
You
know
this.
We
we
tried
to
tell
the
story
in
the
software
use
case.
D
The
art
of
the
final
artifact
is
having
some
challenges
and
how
do
I
trace
backwards
from
that
final
artifact
and
every
step
of
the
way
that
components
of
that
artifact
were
integrated
and
passed
along.
There
was
a
risk
assessment,
maybe
not
a
good
one,
but
but
there
could
have
been,
and
we
can
improve
the
quality
of
the
risk
assessment
at
that
time
that
it's,
the
valuation
is
made
by
making
it
easier
to
identify
the
information,
that's
relevant
to
the
risk
assessment
and
that
that's
the
sort
of
one
of
the
higher
level
objective.
L
And
to
be
clear,
the
risk
management
on
software-
you
know
supply
chain
is
only
one
piece
of
the
big
puzzle.
You
got
processes,
you
got,
you
know
actual
physical
Supply
chains
and
other
things
yeah
I
just
want
to
emphasize
the
fact
that
we
should
look
from
a
customer
perspective
from
the
user's
perspective
from
an
operator
project.
Why
do
you
need
this
in
the
first
place?
Well,
the
reason
is
because
we
want
to
be
able
to
to
know
what's
affected,
how
can
we
remediate
and
how?
How
to
address
the
issue?
Thank
you,
foreign.
S
This
is
I,
I
love
the
architecture
I'm,
seeing
it
makes
a
lot
of
sense.
One
of
the
questions
I
had
and
it
refers
to
someone
when
we
look
in
the
receipt
structure,
you
know
the
the
receipt.
Basically,
the
statement
was
made.
The
receipt
claim
of
the
receipt
provides.
Verification
of
all
the
steps
above
have
proceeded.
Like
kind
of
the
thing
has
been
registered,
it
was
signed,
it
was
accepted,
the
notary,
X
units
policy.
How
do
you
deal
with
policy
changes
over
time?
D
D
D
So
one
of
the
things
we've
already
looked
at
and
there's
been
some
prototyping
of
evaluating.
This
is
embedding
parts
of
the
policy
in
in
the
Registries
themselves
as
claims,
so
you
can
imagine
a
bootstrapping
scenario
for
a
transparency
service
that
may
be.
The
first
couple
claims
are
all
the
current
state
of
the
art
for
the
policies
that
will
be
used
to
evaluate
subsequent
claims
that
might
be
included
then
over
time.
D
When
one
of
those
changes,
you
can
actually
provide
a
receipt
that
the
policy
changed
and
then,
when
there's
a
attempt
to
register
something
that
violates
the
latest
policy
but
would
have
previously
been
accepted.
You
have
some
ability
to
even
explain
exactly
you
know.
What's
going
on
as
part
of
that.
S
That
makes
a
lot
of
sense,
and
that's
when
I
was
thinking
through
is
probably
when
that's
kind
of
where
my
mind
went
to
the
first.
But
you
then
have
trust
in
the
operator
of
the
notary
in
a
way
that
you
didn't
before
right
and
that
you're
then
trusting
them
to
keep
their
policy
up
to
date.
To
keep
registering.
D
J
D
Know
about
it
yeah
so
that
that's
an
important
part
and
I
think
we've
skipped
over
the
the
freshness
component
in
your
slides
Antoine,
but
there
is
a
freshness
component
that
answers
part
of
that
question.
So,
if
I
wanted
to
prove
that
the
a
given
policy
that
was
evaluated
as
part
of
a
registration
was
the
latest,
there
is
a
mechanism
to
do
that
and
there's
tree
structures
underneath
there's
a
tree
structure
that
supports
the
inclusion
of
the
claims.
D
We
there's
many
different
terms
for
this,
but
I
one
term
I,
think
of
it
as
the
right
tree
and
then
there's
a
tree
structure
that
can
help
support
the
freshness
of
the
receipts,
I.
Think
of
that
as
a
reed
tree.
Sometimes
combining
these
two
allows
you
to
answer
these
kinds
of
questions.
You're
asking.
However,
you
are
trusting
that
that
transparency
service
operator
to
manage
these
trees
consistently.
So
if
you
don't
trust
a
single
person
single
entity
to
do
that
fairly,
then
you
might
even
want
a
multi-service
system
that
was
mentioned.
L
S
Architecture
because
I
think
that
there
is
this
assumption
that
you
don't
need
to
trust
the
transparency
service
yeah.
Actually
you
look
at
it
and
maybe
you
do
the
other
quick
comment
I
had
was
earlier.
There
was
a
comment
about
time.
Stamps
I
mean
when
you
have
multiple
instances.
It
does
get
have
things
to
say
about
how
we
can
keep
those
timestamps.
You
know
have
timestamp
integrity
and
things
like
rough
time
and
so
on.
T
Hey
Chris
and
I'll
see
you
tmu,
so
I
I,
just
maybe
it's
more
to
you
Antoine.
So
if
you
don't,
somebody
mentioned
the
comment
and
there's
an
answer
about.
If
you
don't
trust
transparency
service
one
then
maybe
you
have
the
does
that
you
don't
trust
transparency
service
one,
and
so
then
you
resign.
It
so
like
help
me
understand
because
time
matters
a
lot
here.
D
Services
right,
yeah,
I'll,
try
and
Antoine
gave
the
answer
before
I'll.
Try
it
again
in
the
case
of
receipt,
one
the
time
stamp
for
that
is
related
to
claim
one
in
that
transparency
service
in
the
case
of
if
I,
if
I
want
to
Anchor
claim
one
again
to
to
transparency
service,
two
I'm
gonna
get
a
different
time
for
that
anchoring
and-
and
so
that's
totally
okay
and
there's
a
lot
of
reasons
why
you
might
want
to
do
that.
I
think
Antoine
or
Cedric
mentioned
something.
T
So
maybe
I
misheard
it
for
the
explanation,
so
I'm
good.
That
I
just
was
looking
for
the
clarification
foreign.
J
Exactly
so,
we
have
a
mega
ton
of
things
here
in
the
ITF
that
are
dealing
with
trustworth
in
this
proofs
and
rats
and
such
so.
One
idea,
of
course,
that
we
initially
already
highlighted
in
the
first
buff
is
that
every
no
that
a
transparency
service
is
not
a
monolithic
service,
can
be
a
set
of
replicate
nodes.
J
All
of
these
must
have
the
independent
and
circuitry
proof
based
on
well,
that's
technology,
remote
registration,
the
TCG,
Global
platform,
ietf,
all
of
them
at
the
same
time,
there's
a
lot
of
if
they've
said
this
here,
there's
a
lot
of
CCC
output
that
is
going
to
classify
the
qualities
of
the
the
nodes
you're
running
on
the
confidentiality,
for
example.
J
In
this
case
and
there's
a
corresponding
ID
called
attestation
results
for
secure
interaction
and
rats
that
can
basically
be
incorporated
and
received
to
understand
what
are
the
qualities
I'm
trusting
in
here
right
now.
So
these
are
trustworthiness
qualities
that
you
trust
not
only
just
assertions,
and
then
we
were
talking
about
freshness
and
time,
also
a
very
strong
red
topic.
So
a
inside
a
node
of
redundance
consensus
protocol
working
nodes
of
a
transparency
service.
J
You
can
have
a
distribution
of
a
new,
Epoch
or
freshness
with
Epoch
markers,
using,
for
example,
signed
civil
time
tags
or
traditional
tsats
time
some
token
for
things.
So
timing
is,
of
course,
very
important
to
us,
but
this
is
complexity
that
we
didn't
want
to
bring
up
in
the
first
session.
But
yes
we're
thinking
about
that.
Of
course.
Thank
you.
F
Yes,
Antoine
again
so
I
just
want
to
say
a
few
words
on
these
questions
about
policy
and
policy
updates,
because
we
didn't
really
cover
that
in
the
architecture.
So
so
I
think
this
is
quite
important
right
that
for
the
verified
year,
you
want
in
some
cases
to
have
some
ideas
of
what
policy
will
applied
and
we
are
discussing
as
part
of
the
architecture
of
the
mechanism
to
actually
have
ways
to
indicate
in
the
claim
itself
what
policies
are
meant
to
be
applied.
F
So
I
think
one
of
the
very
important
kind
of
claim
that
we
have
is
C
control
claims.
So
a
claim
that
updates
another
one,
and
in
that
case,
even
if
internally,
the
notary
knows
that
a
claim
is
more
recent
than
another
one.
It's
not
necessarily
obvious
to
the
verifier
without
having
to
look
at
the
payloads
right.
F
So
this
is
why
there
is
kind
of
this
topic
of
being
able
to
have
a
declaration
of
registration
policy
that
can
actually
be
interpreted
by
verifiers,
and
so
that's
kind
of
one
way
to
better
understand
the
guarantees
that
you
get
at
the
verifier
from
checking
the
receipt.
And
there
is
also
this
aspect
of
freshness,
which
is
very
important
right.
So
if
you
are
using
a
piece
of
code,
you
want
to
know
that
you
have
the
latest
version,
that's
a
very,
very
common
use
case
and
I.
Think
for
that.
F
As
already
said,
we
can
actually
specialize
the
receipts,
so
we
can
have
form
of
receipts
to
prove
ocsp
style
that
you
have
checked
you
have.
The
receipt
is
collectively
fresh
for
a
given
window
and
you
can
do
that
without
having
to
do
any
online
check,
just
as
we
have
with
staple.csp
right.
So
this
is
a
kind
of
mechanism
that
can
be
used
to
address
this
policy
and
between
different
transparency,
Services
yeah.
D
Just
one
point
on
the
registration
piece
in
this
visual
you
have
here,
you
have
claim
one
claim
two
and
claim
three
and
they're
coming
into
three
individual
transparency
services.
That
means
they're
each
being
evaluated
against
the
registration
policy
for
that
service.
D
There's
a
minimum
set
of
evaluation,
which
is
mentioned
previously-
and
you
can
imagine
actually
all
three
of
these
sharing
additional
policies
layering,
so
that
they're
all
going
to
implement
the
minimum
in
their
own
way,
but
they
might
be
able
to
share
actually
major
chunks
of
policies
amongst
each
other
for
specific
to
certain
content
types.
For
example,
you
can
imagine
a
lot
of
use
cases
where
they've
all
agreed
to
handle.
You
know
spdx
s-bomb
in
a
very
specific
way,
and
they
can
all
share
the
policy
for
evaluating
those
forms
of
claims.
F
Yes,
and
and
to
the
last
question,
which
was
how
do
you
actually
trust
that
that
policy
that
was
meant
to
be
applied,
that
ts1
was
actually
applied
right,
and
this
is
where
using
things
like
remote
data
sessions
or
attestation,
to
actually
prove
that
that
transparency
server
applies
the
policy
as
it
claims.
Of
course,
you
always
have
the
auditability
aspects,
but
that
gives
you
only
a
pastor,
your
guarantee.
If
you
want
a
guarantee
at
registration
time,
then
you
need
something
stronger.
E
Thank
you,
I
I
wanted.
K
E
Highlight
the
point
which
Dan
Dan
mentioned
here
is
a
great
point
that
these
slides
start
from
the
device
manufacturer,
but
thinking
from
a
cloud
service
provider,
I
think
what
I
want
to
touch
base
on
what
exactly
Hank
I
wanted
to
highlight
or
elaborate
more
that
in
confidential
Computing
we
do
talk
about
workload,
measurements
and
workload
registration,
so
that
precisely
addressed
the
concerns,
the
cloud
service
providers
or
the
users
of
the
cloud
may
have
about
the
security
guarantees
provided
by
the
applications
that
run
in
that
kind
of
an
environment.
E
So,
though,
we
have
not
explicitly
put
a
slide
which
goes
at
the
other
direction,
but
that
doesn't
mean
that
we
have
ignored
that
kind
of
an
aspect
into
the
system,
and
second
thing
I
wanted
to
highlight.
Is
these
transparency
Services,
as
as
Anton
mentioned,
has
a
very
well
connectivity
to
the
rats
architecture
where
these
transparency
Services,
when
running
in
a
particular
security
boundaries,
can
very
well
attested
to
enhance
the
trustworthiness
of
these
services.
A
Okay,
thanks
all
right,
so
we've
consumed
our
aob
and
wrap
up
time,
but
it
was
a
good
discussion,
so
we
didn't
want
to
stop
it.
L
Thank
you
one
last
comment:
I
like
this
work
and
I
think
it
will
benefit
tremendously
companies
like
mine.
One
thing
that
concerns
me,
the
most
I
didn't
see.
I
didn't
hear
a
word
about
s-bombs
in
this
discussion
and
and
and
and
and
and
and
it
may
be
implied,
but
there
there
are
these
standards
that
already
Trace
dependencies.
L
So
if
I
have
actually
an
s-bomb
that
is
truly
built
from
ground
up
with
all
the
dependencies
and
the
and
the
and
the
and
the
and
the
digital
signatures
and
the
you
know
the
the
traceability
at
that
point.
L
It
is
a
com
combined
artifact,
and
it
is
probably
what
what
many
people
assume
but
I'd
like
to
to
make
sure
that,
in
that
in
the
process,
we
are
acknowledge
the
fact
that
there
are
already
standards-
and
we
may
have
hybrid
modes
of
of
addressing
this
and
I
I-
want
to
make
sure
that
that's
actually
captured
because
it
may
come
out
as
basically
we're
creating
another.
You
know
we're
decomposing
the
s-bomb
into
some
Atomic
artifacts
that
then
can
be
traced.
Thank
you.
E
Sorry
I
know
why
I
asked
Hennis
because
we
are
running
out
of
time,
so
I'm
not
sure
whether
I
should
be
speaking
here
but
Dan
great
point,
I
think
I
in
my
slide,
I
mentioned
explicitly
about
as
well.
So
on
my
slide
software
use
cases,
one
slide
does
mention
about
s-bomb.
Yes,
we
greatly
acknowledge
the
great
work
they
have
done,
and
that
is
the
first
step
of
standardization,
where
you
you,
standardize
the
software
dependencies
or
the
components,
various
components
using
as
forms
be
it
spdx
server,
Cyclone,
DS.
E
A
P
Allow
me
for
a
quick
comment:
yeah.
This
is
just
to
come
up
to
my
mind,
and
the
examples
here
shows
that
clamps
are
some
specific
content.
But
what
if
the
client
says
that
please
refer
to
some
URL
link
to
see
the
com,
details
and.