►
From YouTube: IETF-SCITT-20230828-1500
Description
SCITT meeting session at IETF
2023/08/28 1500
https://datatracker.ietf.org/meeting//proceedings/
A
D
B
A
A
A
A
B
Not
really
it's
school
has
started
and
I'm
thinking
it
seems
like.
Maybe
people
are
still
thinking
it's
summer.
Sometimes
I
know
next
weekend
is
Memorial
Day
or
is
it
Labor
Day
Labor
Day
Monday
is
Labor
Day,
so
that's
a
federal
holiday
so
that
today,
though,
is
I'm,
surprised,
I.
Think
as
you're
saying,
maybe
still
some
people
are
trying
to
squeeze
in
their
summer
vacation
or
something.
B
A
E
A
D
E
Yep
can
do
so
I'll
give
an
intro
then,
hopefully,
Ori
can
speak
to
some
some
progress
and
Steve
I.
Think
yeah
Steve
is
not
not
here
today,
so
we
may
have
to
postpone
again,
but
essentially
what
we
found
from
the
117
work
and
trying
to
sort
of
maintain
our
minimal
status
as
building
block
providers
and
format
specifiers,
but
not
straight
too
far
into
the
sort
of
big
systems
or
semantic
inference
space,
meaning
we
don't
know
what's
inside
the
payload,
so
it's
kind
of
hard
to
search
for
them.
E
We
need
to
have
some
way
of
locating
the
documents
artifacts
and
receipts
and
things
that
we've
made
and
identifying
if
we've
got
the
same
one
as
we
requested
and
all
sorts
of
things
like
that,
so
it
became
apparent
that
explicit
feed
specification
is
is
necessary.
We
have
to
have
at
the
very
least
an
identifier
format
for
them,
and
probably
some
kind
of
very
minimal
structure
for
for
how
a
feed
is
actually
represented,
returned
potentially
searchable.
E
We
can
do
everything
with
cozy
as
it
stands,
there's
a
couple
of
things
that
we'll
need
to
build
into
stuff
like
a
loud
tree
identifiers
and
things
like
that.
So
there's
some
work
to
do
it's
already
sort
of
straightforward
and
fits
into
existing
ietf
documents
and
formats.
But
the
one
thing
that's
really
interesting
is
how
we
manage
user
specified
feeds.
So
right
now
you
know:
there's
things
like
the
user
gets
to
choose
what
the
feed
ID
is,
but
then
it
has
to
be
treated
as
unique.
E
So
that
has
some
interesting
challenges
as
far
as
sort
of
eventual
consistency
and
things
go
and
also
being
able
to
know
if
a
user
chosen
feeder
one
transparency
service
is
sort
of
morally
the
same
or
not.
Morally,
the
same
need
to
have
the
interplay
between
issuer
IDs
feed,
IDs
transparency,
service,
IDs
and
indeed
whole
bunch
of
other
metadata,
and
have
a
consistent
approach
to
how
that
works.
E
A
John
is
there
something
written
down
on
the
on
the
feed
structure
already
well,
like
I
I
have
a
hard
time
sort
of
like
understanding
like
what
you
could
really
specify
here,
because
skit
is
in
some
sense,
very
generic,
and
so
it's
a
little
tricky
to
say.
Like
point
line.
For
example,
I
could
imagine
that
the
the
feet
would
be
different
for
something
describing
an
artifact
describing
software
versus
something
that
is,
for
example,
Hardware
based
already
so.
E
This
is
the
whole
point
of
having
this
exercise
in
this
discussion
and
focusing
on
it
for
the
next
sort
of
two
or
three
weeks
of
these
interims
is
to
see
you
know,
can
we
actually
get
away
with
just
an
identifier,
or
do
we
have
to
specify
some
minimal
and
I
mean
minimal,
metadata
or
data
structure?
To
allow
you
to
express
this?
Is
a
software
artifact
feed
or
this
is
a
something
else
feature?
That's
that's
the
open
question.
A
D
D
D
D
Is
feed,
I,
think
receipts
or
is
feed
a
thing
that
can
go
on
any
sign
statement
so,
but
once
we've
added
feed
to
those
places
in
the
API,
we
can
have
registration
policies
that
receives
that
require
the
feed
be
a
specific
string
and
we
can
have
check
checks
on
the
transparent
statements
there
value.
That's
it.
A
D
Just
to
respond
like
the
the
header
parameter
needs
to
be
there
and
there
needs
to
be
a
way,
certainly
on
the
the
receipt,
but
but
it's
pretty
straightforward
to
do
that,
and
we've
been
kind
of
hand
waving
around
all
the
complexity
that
you
might
see
in
feeds.
By
just
saying
this
value
could
be
really
complicated.
It
could
be
a
URI,
it
could
be
a
c
URI.
It
could
have
you
know
all
of
the
you
know.
All
of
these.
D
B
A
B
B
B
Right
there
there
we
go
there,
we
go
okay,
yeah,
thank
you,
so
products
and
suppliers
going
into
the
box.
So
this
is
the
product
here
and
so
then
there's
a
documentation
about
the
product
right.
So
we
have
what
we've
been
working
with
is
available
materials,
that's
all
of
the
stuff
that
goes
in,
usually
there's
an
approved
vendor
list
or
whatever
they
call
it.
Where
can
you
buy
this
stuff
from?
How
do
you
fabricate
it
fabrication?
Instructions
that
could
be
a
whole
bunch
of
stuff
there?
How
does
it
get
tested?
B
This
is
all
about
the
product
like
how
is
it
created
now?
This
is
all
for
software,
it's
a
digital
product.
So
it's
all
kind
of
put
into
this
thing.
Although
the
test
instructions
he's
learned
in
there
but
how
it
gets
installed
and
the
bill
materials
is
in
there,
but
that's
kind
of
made
after
the
fact
you
know
so,
the
the
actual
like
container
of
of
you
know,
oci
container
has
all
the
instructions
for
how
it
gets
installed,
but
a
hardware
product
would
have
a
bunch
of
others.
B
You
know
maybe
a
whole
lot
more
than
this
here.
Different
documents,
right
that
are
in
the
documentation
level
and
sometimes
at
this
level,
there's
also
a
digital
product
right,
which
is
something
that
we're
actually
going
to.
You
know,
because
software
is
a
digital
yeah,
it's
digital,
so
we
can
also
process
it
the
same
way
as
any
of
the
documentation.
B
This
is
my
product
and
that's
the
thing
right
there
that
describes
it
to
whoever
you're
talking
to
and
that's
the
thing
that
dick
was
saying
he
he
needed
because,
like
you're
working
with
the
Food
and
Drug
Administration,
they
want
to
know
okay,
what
is
your
product
and
what
does
it
describe
it?
Maybe
it
is
just
the
bottom
okay,
you
know.
Maybe
that's
all
you
have
to
provide,
but.
B
B
I,
don't
quite
understand
how
someone
would
use
these,
but
then
eventually
gets
into
skit
here
where,
where
we're,
we
know
we're
signing
each
I
mean
each
one
of
these
right,
I,
I,
guess
and
that
would
be
the
feed
I
mean
if
the
way
people
are
visualizing
it,
but
there
may
be
in
each
one
of
these
skit
things
as
we're
saying
I
think
it
has
to
be
the
product
ID
of
some
kind
here
and
an
entity
that
is
doing
it.
The
rest
can
be
fuzzy.
B
G
Good
morning
Ray,
so
every
document
that
we
for
the
use
case
of
course
gets
signed
and
then
ends
up
with
a
kind
of
receipt
from
let's
get
another
The
Ledger
I
think
those
all
get
stored
in
in
a
storage
subsystem
and
that's
where
the
queer
engine
that
run
runs
against
anyway.
I
agree
with
you.
The
and
I
was
talking
to
Steve
Lasker
about
this
last
week
that
the
composition
of
asking
whether
a
product
is
okay
or
whatever.
G
Unless
we're
careful,
we'll
end
up
with
so
many
round
trips,
that
will
just
saturate
the
network
so
having
either
a
cash
value
or
a
cash
devaluation
of
the
statements,
the
way
they're
doing
software
supply
chain
with
s-bombs
and
everything
else
becomes
an
interesting
question.
In
the
way
we
wrote.
The
original
proposal
for
cozy
was
that
the
receipt
is
returned
as
part
of
the
the
signed
statement
that
comes
back
from
from
the
skipper
industry.
G
The
identity,
though
problem
has
already
been
dictated
by
the
s-bomb
ID
that
they've
created
to
allow
you
to
hook
s-bombs
to
other
s-bombs.
So
I
think
that
is
your
version.
Product
instance,
identifier
for
your
for
your
software
as
to
whether
a
software
has
a
list
of
of
IDs
to
deal
with
architecture,
specific
things
like
the
OS
for
arm
64
versus
nd64
versus
Intel
versus
whatever
you
know.
What's
skew
those
would
come
out
of
a
product
catalog,
so
there
isn't
necessarily
A
one-to-one
product
to
ID.
B
Well,
I
think
so
I
think
you
were
saying
to
me
that
maybe
like
once,
we
get
like
this
this
product
description,
sometimes
I,
think
people
are
going
to
want
to
put
that
in
into
a
big
chunk
and
give
it
to
someone
else
and
they're
going
to
want
to
put
everything
in
there.
So
they
can
hand
it
to
someone
else
and
yeah,
but
the
problem.
G
B
G
The
identity,
the
document
that
dick
was
putting
out
there
yeah
kind
of
exists
today
from
you
know
where
it's
wrapped,
potentially
an
s-bomb
ID.
There
is
this
concept
of:
do
you
take
a
sellable
product
and
it
points
that
here's,
the
current
version
of
the
product,
yeah
I,
get
that
has
to
bundle
it
all
up.
D
B
B
All
of
this
stuff
and
they're
gonna
put
in
there
what
they
need
for
that
particular
Agency
for
their
product
that
period
of
time
and
get
approval
for
it
and
then
whatever
their
their.
You
know
their
policies
are
in
terms
of
you
know.
If
you
make
a
new
product,
sometimes
you
can't
do
that.
You
can't
there
is
no
freshness
idea.
You
have
to
lock
it
into
permanent,
but
I.
G
The
Way
We,
Were
I
was
thinking
of
that
is
that
skip.
They
would
have
a
local
skip
instance
on
their
firewall,
their
endorsement
from
their
Auditors
control
and
apply
to
their
view
of
the
world
and
whether
there's
a
something
they
take
off
buying
outside
a
skit.
That's
an
interesting
question,
or
whether
it's
just
an
offline
skit
instance
that
keeps
it
consistent
as
to
whether
they're
intermittently
online
or
not.
G
A
I
think
the
the
FDA
case
is
interesting
because
at
least
in
my
reading
they
didn't
explain
on
how
they
are
going
to
use
that
information
or
whether
that
will
be
made
available
to
anyone
and
so
on
and
so
on.
So
it's
basically
so
far.
It
looks
more
to
me,
like
a
one-way
communication.
Vendors
send
this
stuff
over
to
to
them
or
am
I
wrong,
am
I
risk.
Reading
physics.
G
B
B
D
F
A
submission
that
you'd
make
as
part
of
a
document
package.
For
your
say,
it's
a
device
you
want,
you
know
you
want
approval
for
that
device
and
the
FDA
has
to
go
out
and
do
a
bunch
of
things
and
they
require
a
bunch
of
prerequisites
and
among
them
are
many
documents,
and
one
of
them
would
be
an
s-bomb.
For
example,
another
might
be
a
consumer
labeling.
You
know
data.
G
F
I
mean
but
but
the
Practical
matter
is
I,
think
it
the
it's.
You
know
it's
a
correspondence
between
two
entities
and
you
know
it's
emailed
or
it's.
You
know
uploaded
into
an
FDA
website
from
an
authorized
person
and
that's
how
the
authenticity
is
I.
Guess
it's
not
authenticated,
but
it's
assumed
authentic
because
of
a
bunch
of
security
controls
over
the
process.
G
The
question
I
have
there:
Charlie
is
how
concerned
they
want
the
cves
and
the
vexes
and
the
s-bomb
tree
of
you
what
you're
dependent
upon
to
also
be
visible
without
having
the
distribution
system
you're
going
to
get
into
this?
How
do
you
keep
live?
How
do
I
publish
cves,
how
do
I,
publish
vexes
and
the
disconnected
One-Shot
model
is
counter
to
what
they're
talking
about.
F
True
but
I
think
again
we're
gonna
have
to
make
a
case
for
stronger
authentication,
because
right
now,
false
positives-
and
you
know,
pirating
of
that
stuff-
has
really
not
been
an
issue
at
all.
It's
consumable,
of
course,
that
it
could
be
down
the
road,
but
right
now,
there's
just
no
there's
no
use
case
that
says:
oh
you'll
get
a
problem
here.
We
need
something
to
fix
it
and
skip
to
the
rescue
so
yeah.
A
D
F
A
B
D
F
A
A
F
I
guess
my
point
is
that
right
now
they
have
a
system
that
they
think
works.
Of
course,
if
you
had,
if
you
had
a
concerted
effort
to
thwart
it
sure,
they'd
have
a
problem,
but
right
now
there
hasn't
been
that
so
we
you
know,
we
need
to
do
two
things.
I
think
one
is
to
make
skit
as
easy
as
the
default
all
right
and
then
the
second
is
to
make
the
case
that
this
is
a
sort
of
a
proactive
way
of
heading
off
possible
attacks
in
the
future
and
we're.
G
G
The
Counterpoint
of
that,
though
Charlie
is
I,
spent
time
with
Dave
waltermeyer
at
the
last
ietf
meeting.
You
know
two
hours
of
talking
about
cves
and
he's
going.
You
know.
Maybe
we
just
pushed
the
cve
publication
to
be
a
skit,
compliant
query
and
yeah,
and
just
all
folds
in
so
even
they
are
moving
their
model.
They
were
trying
to
figure
out
how
to
combine
into
product
and
I
said
you
should
just
abide
by
the
s-bomb
and
the
identifier
there
and
Ray.
You
were
part
of
that
conversation
for
a
while.
G
F
Of
theoretical
and
CIS
is
practical
and
both
of
them
are
prescriptive
and
the
agency
has
to
then
go
Implement
things,
so
obviously,
a
uniform
and
someone
else
pays
for
its
solution
from
cisa
would
be
terrific
for
all
these
agencies,
so
I
think
that
would
be
I
mean.
That
is
certainly
a
great
use
case
for
skin
I.
Just
I
do
think,
though,
that
there
is
a
Chasm
to
hurdle
here
before
we
get
to
the
point
where
people
say:
oh
yeah,
this
is
really
needed,
and
this
added
complexity
is
necessary
right,
which.
G
Where
I
struggle
with
this
and
we
dick
has
been
pushing
on
he's
looking
for
a
product
and
it's
the
query
and
storage
of
system
that
Rey
is
getting
into,
which
is
over
and
above
what
our
current
Charter
is
in
proposing
the
solution
to
all
these
organizations
is
fine
and
I
think
it
should
happen.
The
question
is:
is
this
the
venue?
Should
we
take
this
on
and
climate
Spanish
or
is
what
I
struggle
with
I've
been
trying
to
keep
them
separate?
But
maybe
now
is
the
time
to
have
that
discussion.
C
So
is
it
my
turn:
yeah,
okay,
so
I'm
a
little
bit
surprised
that
we
but
I
think
that
somehow
related
all
these
things
like
using
the
whole
system,
we've
started
with
feeds
and
we
ended
up
with
Authentication,
somehow
and
I.
Think
that's
that's
fine,
because
I
assume
that
the
the
consumer
that
sorry,
the
consumer
is
now
a
bad
term.
The
users
of
the
system
that
would
include
skit
building
blocks.
Has
these
two
things
like?
C
C
Actually,
it
could
be
how
cve.org
Works,
who
knows,
but
that's
my
is
a
little
bit
cloudy
I'd
only
say
it's,
it's
very
useful
to
understand
how
a
structured
feed
that
is
more
than
a
character
array
looks
like
and
I
think
that
that's
the
interesting
point
for
me
still,
because
when
people
tells
me
talk
about
structured
feeds
or
I,
I,
think
it's
more
than
a
byte
array
or
more
than
a
string
array.
I
think
it's
it's!
C
Are
we
compressing
it
into
a
uniform
identifier
that
are
just
one
layer
still
or
concatenate
them
which
which
I
would,
of
course,
do
not
recommend
to
do
but
I
think
that's
that's
the
thing
I'm
thinking
about
when
we're
talking
about
feeds,
and
so
so
I
wanted
to
bring
that
back
to
the
to
the
topic
here.
I
hope.
That's
fine,.
A
We
don't
try.
We
don't
know
right
now
whether
we
need
a
structure
or
whether
at
the
level
of
skit,
it
would
be
useful
to
have
a
structure
for
the
tree.
So
in
that
sense,
it
sounds
to
me
like.
The
best
way
forward
is
to
assume
that
there's
this
header,
this
feed
header
and
the
API
just
uses-
assumes
that
there's
some
unstructured
data,
at
least
a
structure
that
we
don't
know,
and
we
just
use
that.
C
I
think
Aria's
opinion,
so
I
will
use
the
floor
just
in
a
second
but
I
think
we
should
start
there
because
we
must
we
can.
We
can
use
I,
don't
know,
string,
concatenation
and
and
do
everything
we
want
there
in
a
string
for
starters
and
if
you
find
out
oh,
this
is
getting
complex.
Maybe
we
need
more
structure
to
the
value.
Then
we
can
add
value
add
here
by
introducing
other
values
than
the
string,
but
it
feels
to
me
that's
okay,
to
start
with
that,
because
otherwise
we
are
not
starting
so,
but
are
we.
A
D
Think
we
want
some
structure
Beyond,
just
a
string
and
the
reason
for
that
is.
We
expect
feeds
to
be
an
interoperability
point,
and
so
we
expect
sharing
of
feed
identifiers
to
be
an
important
part
of
the
workflow
and
the
context
in
which
skit
is
used.
So
we
we
think,
based
on
the
ietf
I,
would
say
we
think
that
feed
should
be
a
URL
potentially
encoded
in
a
compact
form.
But
you
know
we
don't
think
it
should
just
be
any
arbitrary
string.
D
A
D
It's
true,
but
if
you're
navigating
any
search
interface
related
to
the
software,
you
are
navigating
URLs.
So
packages
are
not,
you
know
always
identified
with
URLs,
but
still
the
feed
structure
having
some
defined
behavior
is
important.
In
particular,
it's
important
if
feeds
are
going
to
be
exposed
on
arrest,
API,
then
you've
kind
of
you
kind
of
expect
that
the
feed
is
a
rest.
Api
might
also
document
so
I
think
if
we
don't
say,
hey,
they're,
URLs,
we're
making
our
API
documentation
not
very
useful
or
usable
and
we're
destroying
a
potential
interoperability
Point.
D
C
B
B
In
my
case,
it's
the
election,
Department
right
and
they've
got
all
their
election
data
and
that
nothing
much
is
going
to
happen
to
it.
After
that,
this
that's
just
gets
exposed
so
so
that,
but
in
any
software
product
or
other
product,
you
have
a
bunch
of
documentation
you
want
to
expose.
It
could
be.
B
Just
hashes
of
these
these
documents
right.
So
this
is
a
description
of
these
documents,
they're
not
in
there
they're
just
describing
the
documents
that
are
that
are
involved,
and
this
is
stored.
These
are
stored
or
available
somewhere
else,
probably
with
fewer.
But
then
then,
the
product
description,
the
way
I
see
it
is
combined
with
all
the
receipts
and
that's
the
thing
that
that
you
would
then
hand
to
someone
whatever
format
it
is.
So
if
the
FDA
says
we
have
this
format,
you
must
comply
with
and
we
go.
Okay,
that's
fine!
B
We've
got
all
of
these
receipts
that
we
have
for
either
this
entire
thing.
We
can
submit
it
or
the
individual
items
within
there.
That
may
be
part
of
it
already,
but
the
signed
statement
and
the
receipts
would
go
back,
probably
to
be
combined
here
now.
The
way
Dick
had
it,
which
I
don't
quite
agree
with,
is
at
least
the
way
they
had.
B
The
structure
of
the
thing
is
that
they
put
the
entity
sort
of
inside
the
product
description
inside
this
file
here,
which
you
could
do,
but
it
needs
to
be
at
a
different
level,
but
basically
that
would
be
part
of
these
receipts
here,
because
that
that's
gonna,
these
receipts
I
think
provide
all
the
information
that
you
need
to
to
go
and
validate
this
stuff
up
here,
at
least
that's
what
you'd
like
you'd
like
to
have
I
mean
I'm.
Just
talking,
you
know,
Blank
Slate
forget
about
skit.
What
do
we
need?
B
We
have
a
bunch
of
product
descriptions.
We
need
receipts
to
say
these
are
right.
This
stuff
up
here,
I've
got
a
receipt
for
every
damn
thing
in
it
and
in
itself
too,
perhaps
I
I,
just
don't
know
what
what
it
is
now,
where
is,
the
feed
I
was
thinking
when
I
first
started
that
the
feed
was
this
low-level
API
just
gushing
out.
A
Well,
I
should
explain
that
at
least
from
my
understandings,
like
you
have
feet
the
feet
showing
up
in
two
places.
The
first
one
is
when
the
issuer
submits
or
registers
the
sign
statement.
It
has
this.
It
includes
the
feed
as
a
as
a
parameter
in
the
head-up
and
then
but
that's
when
uploading,
to
skip
to
this
kit
database
and
but
then
there's
the
other
part
where
users
of
the
skid
system
make
use
the
API.
A
The
API
is
the
other
document
that
that
was
posted
into
the
chat
window
somewhere
at
the
beginning
of
the
call
where
we
actually,
but
these
users
is,
or
consumers
make
lookups
and
they,
but
they
need
to
make
lookups
based
on
something
and
what
they
use
is
the
the
feed
information
to
look
up
for
a
specific
product,
artifact
or
whatever,
that's
sort
of
like
different
different
interfaces.
In
some
sense.
A
B
That
makes
sense,
I,
I
I,
understand
what
you're
saying,
but
I
I
think
that
now
the
way
things
are
are
tending
to
look
is
that
that
this
low-level
API
is
not
going
to
have
that
capability,
and
it's
going
to
end
up
the
searching
for
stuff
is
going
to
end
up
basically
looking
at
these
these
things
that
whoever
it
is
wants
to
make
public.
So
if
you're,
if
you
are
the
FDA
and
someone
has
provided
this,
this
crap
that
you
want
here,
then
you
have
receipts
for
it.
B
That
says
this
is
endorsed
it's
from
this
party,
and
so,
if
we
can
go
check
on
it,
and
this
is
yeah
somehow
on
the
receipts,
it
has
to
say
this
is
the
skit
thing
that
you
can
go
and
check
on
this.
Everything
is
right
that
that's
the
level
there.
Where
definitely
you
know
people
are
going
to
want
to
be
able
to
search
through
the
FDA.
That's
already.
A
Set
up
that's
a
good
question
and
in
some
sense
it's
a
question
for
us
to
to
to
make
a
decision
on
like
in
this
in
the
Hank
calls
it
the
scrappy
API
whether
that's
Scrappy
API,
is
indeed
what
you
describe
here
is
the
low
level
low
level
API
that
doesn't
actually
have
any
feed
information,
because
it's
just
the
interface
used
for
sort
of
low
level
tasks.
As
you
write
it
on
the
screen.
B
B
I,
don't
think
they're
going
to
want
to
to
subscribe
to
just
a
mess
of,
maybe
they
will
and
then
you
can
I.
Don't
I.
Don't
think
that,
like
this,
this
coming
out
at
this
low
level,
API
just
a
gushing
feed
which
I
think
of
everything
comes
out.
You
want
to
subscribe
to
it.
You
get
everything
in
the
world.
You
don't
want
those
like
Twitter
right,
you
pass
it
up
and
go
I'm,
not
interested
in
that
post.
What.
A
But
look
at
the
look
at
the
API
document
and
and
for
example,
it
has-
it
has
currently
the
following
apis
India,
there's
a
register
site,
sign
statement
and
the
that's.
Then
it
has
a
receive
operation
status.
I,
think
that
is
just
a
way
to
get
the
the
transparent
receipt
back,
retrieve,
sign,
statement,
Hank
or
or
I.
C
D
A
D
A
G
The
science
thing
you
have
a
you,
have
a
hanging,
HTTP
request
or
whatever
to
do
async
here.
The
the
batching
problem
to
me
is
a
more
useful
for
A
system
that
wants
to
get
storage
onto
their
database,
waiting
for
the
receipt
to
come
back
right,
you're,
going
to
pend
a
whole
bunch
of
of
operations
on
a
very
busy
system
and
come
back
with
batches
and
say:
okay,
now
that
I
have
a
receipt,
I'll
I'll
store
these.
Until
that
happens,
the
transaction
can
start
against
the
database
right.
G
B
A
B
You
get
out
here
to
this
all
of
these.
The
receipt
I
re,
I
I
view
as
a
sort
of
an
endorsement
to
this
thing
here
that
we
can
that
that
somebody
like
dick,
can
put
on
the
end
of
his
whatever
file.
It
is
and
then
they're
happy.
Then
they
say:
okay.
This
thing
But
realize
then
that
this
is
one
level
of
a
supply
chain.
B
Right
and
they've
got
this
thing
here
and
then,
when
you
put
these
all
together
the
next
guy
may
he
may
want
to
have
suppress
all
this
or
he
may
want
to
allow
you
know
if
it's
oppressed
in
his
filamentary.
He
doesn't
care
about
this
level
of
stuff
right
he's
using
this
as
just
one
thing
in
his
larger
product.
But
if
you
want
to
dig
into
it,
then
you
can't
that's
the
question.
Then,
if
you
have
one
level
up
here
with
specifying
this
okay,
now
I
I
know
about
this
thing.
A
The
results,
that's
exactly
the
feed
discussion
and
and
like
if
you
look
at
the
the
apis,
those
I
think
would
call
really
qualify
as
low
level
FDI.
So
there's
no
feat
in
there
and
for
what
it's
worth
I
believe
the
what
you
call
in
the
API.
The
retrieve
sign
statement
is
actually
not
the
sign
statement.
It's
the
transparent
statement.
B
B
G
B
G
Yeah
the
way
the
original
architecture
was
written
is
the
receipt,
is
slowly
returned
to
the
out
of
The
Ledger.
The
fact
that
when
you
query
it
to
get
back
the
transparent
statement,
they
all
come
back
as
three.
We
gave
away
the
represent
it
and
store
it
as
the
receipt
inside
the
Cozy
signature.
If
you
have
a
detached
signature
now,
they've
got
three
separate
documents.
I
think
that's.
Over
and
above
the
Ledger
The
Ledger
may
not
even
see
the
document,
and
they
only
see
a
detached
signature
and
return
a
receipt.
G
A
G
A
G
Good
for
me,
but
even
the
way
it's
written
is
here's
how
we're
going
to
store
it
back
in
the
Cozy
receipt.
There's
no
sense.
Returning
the
signed,
the
detached
signature
itself,
if
we're
just
saying
here's
how
you
could
staple
the
two
of
them
together
and
there's
this
open
question
that
Rory
and
I
were
talking
about
last
week,
which
is
when
we
were
talking
to
one
of
the
government
agencies
for
physical
supply
chain.
You
could
end
up
with
multiple
receipts
and
that's
a
future
discussion
like
one
for
each
nationality.
B
G
D
Yeah
so
I
agree
with
everything.
That's
been
said.
You
just
remember
that
when
you're
making
a
signed
statement,
transparent,
you're,
adding
a
receipt
receipt
to
the
unprotected
header
for
it,
you
might
add
to
the
unprotected
header
in
the
future.
So
that's
the
the
concept
of
the
concept
of
this
signed.
D
D
But
the
point
I
guess
is
that
the
receipt
needs
to
be
combined
with
sign
statement
to
get
to
the
transparent
statement
at
the
end,
and
if
the
client
is
sending
that
a
signed
statement
all
the
way
up,
they
definitely
don't
need
the
server
to
return
it
to
them
and
they
might
not
even
send
need
to
send
Apple
sign
statement
up.
They
could
actually
send
a
reference
to
the
server
and
the
server
could
go,
get
the
thing
and
say:
okay,
I'm,
okay
with
it
at
this
time.
So
it's
it's
just
important
to
you
know.
D
Remember
that
there's
the
the
client
sending
the
data
up
the
server
is
generating
one
or
more
receipts
and
making
them
available
to
the
client
and
I
would
say
that
and
I
would
say.
The
client
is
the
one
assembling
these
things
for
them,
an
API
that
is
also
acting
as
a
kind
of
client
acting
as
a
kind
of
client
and
assembling
these
things
and
furthering
you
know,
sending
them
in
our
in
our
architecture.
Today,
the
thing
the
thing
you
get
back
you
send
is
a
signed
statement.
We
don't
specify
any
more
advanced
apis
for
returning.
D
A
combination
of
the
signed
statement
and
the
receipt
or
other
artifacts
related
to
the
signed
statement,
plus
the
sign
statement,
plus
the
sign
statement
and
a
receipt,
but
you
can
imagine
those
those
cases
might
Exodia.
Software
vendor
is
storing
their
artifacts
right
next
facts
right
next
to
storing
their
Ledger
and
they're
produced.
D
B
B
And
that
sounds
like
a
reference
to
the
skid
instance.
So
we
can
go
back
and
check
on
them
would
be.
This
block
right
here
of
is
is
kind
of
like
the
interface
it's
sort
of
like
a
a
little
bit
meta
interface.
If
you
will,
where
we
don't
care
what
happens,
but
in
terms
of
the
receipts
and
the
reference
of
the
skit
instance
and
and
what
that
has
to
be
part
of
the
receipt
so
that
you
can,
you
can
create
another
reason.
Every
receipt
has
that
you
know
the.