Clarify mapping between provenance and requirement specifications

[MarkLodato]

Currently it is unclear how the provenance spec maps to the requirements.

• How is a builder expected to populate the provenance at each level?
• What exactly is a verifier expected to check at each level?
• How do the Source requirements fit in?

At a high level, I think we need to do three things:

1. Use consistent terms between the two specifications. For example, it is called "hermeticity" in the requirements but completeness.materials in the predicate.

2. Spell out the logic of the two use cases above. For example, to verify:

   • At L1+, require presence of an attestation whose type is X and subject matches the artifact.
   • At L2+, verify that the signature matches the builder using some pre-configured root of trust. (Anything about service-generated?)
   • At L3+, verify that the builder is on a pre-configured list of builders certified for L3+ (or L4+ if verifying L4).
   • At L4, verify that the parameters is empty, reproducible is true (unless there is an exception), and completness.materials is true.

3. Clarify how source requirements are going to be verified. (My suggestion for v1.0 is to drop source requirements for now, but that will be decided as part of the v1.0 discussion.)

/cc @laurentsimon

[laurentsimon]

Maybe also worthwhile thinking about separating the requirements from the service (isolation, ephemeral, etc), the developers (reproducible, etc) and the consumers (verification, point 3 in the description).

Since this helps break down the work to be done by different teams, it may be useful to capture this more explicitly.

[shaunmlowry]

+1 on resolving for 1.0

[MarkLodato]

I think this has been addressed. If not, please open a more specific issue.