Review Update Streams, supporting multiple vendors to submit
statements about an artifact
## Recap since 121 (10 mins) {#recap-since-121-10-mins}
Steve
AJ Stein: The diagram has that we have 2 organizations doing a
transaction, but we don't have any text for that?
Steve: We've definitely talked about it, but it might not be in the
draft now; but it is supported,
Multiple parties could make statements about the same subject (e.g. a
software security company could make a statement about some other
entity's software) and the provider could then make a counter statement
saying something like "that issue is fixed"
AJ: Not that there is a problem in the model, per se, but that the text
says it is singular.
Steve: will check the text
Henk: It isn't explicit in the text, but it is there since the first
use case is software
Scenarios
Non-equivicoation
Building Blocks
Erum Welling: Does the provenance contain the historical ownership?
Jon: Partially, it does capture some of it, but it depends on some
external searching ability; you have to be build to capture the subject
name and then find it
Erum: If the artifact gets modified, what happens?
Jon: SCITT only provides this signing and transparency; it is avowedly
agnostic to the content of the artifact; so it is possible to link
things together with their subjects and statements, but its not inherint
in SCITT.
Steve
What is stored on the append only log
Layering the SCITT architecture
Architecture
Choices around where meta data goes, what's protected and
unprotected
mcr: feeling on the fence about the unprotected header; selective
disclosure from teh SPICE mechanisms uses them potentially; it might
want behave differently. Might want a layer of indirection based on the
unprotected part. And the impacts of the subject from things that might
be the same, but have different unprotected material.
steve: we struggled with this, COSE says don't include the unprotected
header, and the receipt example is good with the expense report
mcr: e.g. capturing the exchange rate which is time dependent
aj: can you clarify what should and should not be stored in the
transparency log, you mentioned something about that quickly
steve: the ledger is only protecting of the signed statement, but an
implementation could include additional stores with the additional
information. So the unprotected header could be in the log, but it
doesn't have to be in the log
aj: so the draft does't use MUST on what you have to include and
exclude from the log
steve: there is a MUST that says you have to exclude the unprotected
header; want to make sure what is written to the log so that it can be
verified consistently
aj: okay - get what you're saying now
erum: is there a way for a chain to bypass this (so skipping a change in
the artifact)
jon: SCITT as defined is about making statements about artifacts; but
you can make policy around the use of the statements
roy: unsigned headers cannot prove a timeline of changes, etc.
henk: the arch says that its okay to send a set of stuff with a whole
pile of junk in the unprotected header; registration policies are
interesting because they could control the rules about notarized uses
and unprotected materials
MCR - really interesting icons, would like to see those understood
and standardized
Jon
Henk
Jon
Implementations
Jon
Challenges between 121 and 122
What we learned
Yang model for SBOMs
Is there hearburn about making statements about statements
MCR
A.J.
Henk
Thanks to Auoki
would you like to schedule a virtual interim in about 6 weeks to
review the last call documents
Erum
Chris
Henk
Chris