Introduce new terms: "Manifest Store" and "Manifest Indexing Service"

[alilleybrinker]

This is building off the conversation in the most recent WG meeting (thanks @ashleygwilliams!)

Right now, we talk about persisting manifests to "the local file system," though
this opens up questions like:

• What is "local"?
• Can I persist manifests to a networked file share?
• Can I have multiple "local" places I persist manifests? (Maybe I want to persist manifests for different projects to different places)
• What if I want to persist them to some block storage service I can access, not a file system?
• What if I am in a scratch container with no file system and no OS and I hate everything and do not believe in file systems?

It may be more useful to invent a term for "place that manifests are stored such that they are accessible for analysis." Enter: "Manifest Store".

This can then also be distinguished from (another new term), a "Manifest Indexing Service". Per the discussion, the goal is that producers of software do not have to change their workflows for distributing the artifacts they make; they can just include the Artifact Input Manifest alongside the artifact, however that's currently distributed. Manifest Indexing Services then index and store those manifests and provide a singular API for consumers. So consumers of the manifests don't have to handle extracting manifests from the many different potential places / ways they may be distributed.

So you'd have a local Manifest Store, into which any manifests you produce or consume would go. You may in fact have multiple Manifest Stores if you'd like! Then, when you're publishing an artifact, your tools would know to grab the manifests for the things you're publishing from the Manifest Store, and bundle them up with your release. Manifest Indexing Services could then gather the manifests, and consumers could then pull manifests for things they consume into their own Manifest Stores, to use for analysis.

---

This is a rough sketch in advance of actually writing up spec language. Happy for feedback!

[alilleybrinker]

@AevaOnline has pointed out the analogies to Rekor and SCITT (mechanisms for distributing software attestations). It's entirely possible that these could just be used instead of inventing new concepts. Worth exploring more deeply to understand the agreement / disagreement between concepts.

[alilleybrinker]

There are likely other examples of prior art to investigate as well.