Minutes

Agenda:

• Agree simple text for Registration Policies

• Revisit 117 hackathon aims (RPs, Healthcare)

• Review and prioritization of open issues

Notes:

Ray had previously not understood that RPs were the policy for inserting
things into the log.
KEYTRANS are a gleaming example of documenting what they're doing. And
they have a minimal registration policy - seemingly anyone can post! And
then maybe they check the PKI certs in the background or something.
So maybe a good minimal entry for Registration Policies would be to say
"there's a user connected by a secure channel. They'll have a key. We
need some way to relate that key to the authority to submit to a
channel."

Jon agrees that a minimal things that says "you should be able to
strongly identify the user, and you may implement controls on which
users can submit to a given feed."

Neal does not want to see a system that makes it hard/impossible for
people to make comments about a product. It depends what you're looking
for who is best placed to make certain kinds of statements. Preventing
spam is useful, but otherwise we need to preserve democratic integrity
of the transparency system.

Jon clarifies that access control is done per feed, not per product,
so the official software version can come from one place, while
vulnerabilities can come from another.

Neal likes the idea of going by use case and helping the relying party
work out which feeds to follow.

Dick suggests we not try to come to a conclusion on Reigstration
Policies today since lots of people are out for Juneteenth.

Cedric says the 'feed' concept is just a way of differentiating
different concerns from the same issuer. The issuer selecting a feed is
a way of the issuer saying what the statement is about.
It is not necessarily as intended originally in the first version of the
spec.

Jon took homework (and offered other poeple to) to read and clarify feed
definition to real-world concerns of mutually distrustful publishers of
claims on the same real-world artifact.

Henk: Seems like there is wild agreements that SCITT services should not
accept to be spammed with tons of crap landing on append only ledgers.
Good. But then he has no idea how we manage to achieve that.
Do we want feeds to have multiple registration policies?
Do we want multiple issuers to be able to contribute to the same feed?
Is the feed exclusive to the issuer who created it? That would be weird.

Are registration policies different per feed? Or the same for all feeds
on one TS?
Henk's assumption is that every issuer runs through a gate-keeping
funciton before their statements are accepted. Is that gate keeper also
aware of the feed?
Seems like the best MVP is for not restricting people from commenting on
artifacts, but also avoiding spam. So what's the answer to that?

Roy says that talking about 'products' means we're at a level higher
than the SCITT building blocks. It's a different question.
Makes sense to have controls on who in a business is authorized to
release product etc, but that's a different quesiton.

Cedric clarifies (thinking we are in agreement) it is critical to
express in the spec that we make efforts to prevent impersonation and
forgery. This, along with the spam problem, is the responsibility of the
TS. Also fairness metrics, censorship resistance etc.

Henk says we should define the main requirements but not how to
implement them - that's up to the implementation.

Ray expresses that he's pretty afraid of anything but a strict
mechanism. Opening the gates would become a messy spam magnet. A strict
mechanism (you can only submit here if you're the owner of the product,
for example). In elections there are great benefits to a strict model
(obviously!). So the lower level needs to support both loose and strict
Feed access, and the use case should choose which it wants.

Cedric says that even 'Spam' is a use-case defined concept. We can't
define the idea of 'a product' or the product's 'owner' at the SCITT
level.
And even then, what's the problem with spam? If I don't trust the issuer
I just won't listen to what they say. So the main problem is just the
problem of the TS properly searching, access controling and presenting
results.
From chat: Neal says spam can cause workload problems not just for the
transparency service itself, but also for relying parties.

117 hackathon

Do we want to stick with RPs or shall we switch to a use-case based one?

Floor given to Dick Brooks to present the medical devices SBOM+ use
case.
From 1st October FDA will be requesting:

• SBOM prviate to FDA for risk evaluation
• SBOM to users so they can manage their own risk
• Vulerability updates
• EOL/Support status
• (something else I missed)
  A good use for SCITT since it's more holistic than just SBOM
  point-to-point.
  S.524 further calls for additional assurances, process materials
  etc, which culminate in a Vendor Response File. Attesting this in
  SCITT would be useful.

Dick will share the slides.

Ray and Dick confirmed that the payload to be submitted is the VRF, not
everything in the middle.

Ray elaborates the KEYTRANS has a whole secondary structure that makes
it easy to find things. We may need something like this too - better
than urls? Dick says the specs do demand things be searchable.

Need to work out how we deal with VRFs that contain multiple products.

Neal wonders if we can deal with disclosures outside of the mainstream,
not yet recognized/regulated. Will people be ready and able to provide
proof that relying parties become interested in later? How to discover
instances and feeds? Foresees classic disagrement on identifiers etc.
Dick responds that this system is already bigger and more flexible than
NIST SSF - hould be possible to include new types of info, even
dependency/supply chain info.
Neal still ownders about subjective type stuff - environmental impacts
and so on. How do we deal with an ever changing landscape of search and
disclosure? Dick thinks his experience of working in the energy industry
says it's generic enough, but we'll have to work it through and find
out.

Jon observes that the VRF schema could become an output from the 117
hackathon - could be very useful!

Roy observes that we typcially rely on other groups to define use-case
level documents/structures. It's cool to have a hackathon that uses the
SCITT building blocks to prove this vertical use case but should we
really be defining the content? Isn't there a better group to do that?
Can we join forces with the SBOM groups?

Jon agrees, the hackathon should be proving that the building blocks
support a flexible VRF, we don't want to adopt an application layer
thing as a WG output.