add DigestSets

teps/0109-better-structured-provenance-retrieval-in-tekton-chains.md

@@ -370,31 +370,9 @@ results:
 
 In this way, every time when Tekton Chains tries to support a new type of artifacts, users can form in-toto provenance from this schema format, without needing to change Tekton Chains much. In general, Tekton Chains itself doesn't want to distinguish the types of artifacts from attestation generation point of view. The namings of these artifact results would be much more flexible as well.
 
-#### Optional Alternatives for Schemas
+### DigestSets
 
-It will be more flexible if users can define the provenance following the defined schemas, but don't necessarily have to follow the naming patterns. Users can provide a result in array type, with name consistent with the signable target, and have a list of result names that are under that category. An example can be like:
-
-```yaml
-results:
-        - name: SIGNABLE-VCS
-          value: ["FOO", "BAR"]
-        - name: FOO
-          value:
-            src_type: git
-            uri: git+https://github.com/foo/bar.git
-            digest_ago: sha256
-            digest: abc
-        - name: SIGNABLE-OCI_IMAGE
-          value: ["IMAGE1"]
-        - name: IMAGE1
-           value:
-             name: gcr.io/somerepo/someimage
-             digest: abc
-             alg: sha256
-```
-
-And the result that contains the provenance still need to be aligned with the schema we defined in Chains. This way, users don't need to name the results.
-This is not chosen because Chains would need to be aware of the difference between different types of artifacts.
+The in-toto provenance supports digest in terms of [DigestSets](https://github.com/in-toto/attestation/blob/main/spec/field_types.md#field-type-definitions) for an artifact, which means users can provide different digests for different digest SHAs. This would be hard to support in Chains, as Results doesn't support nested objects yet. In the proposal, only one pair of SHA and digest can be provided. `DigestSets` can be supported when nested objects are supported in `Results`.
 
 ## Design Evaluation
 
@@ -462,6 +440,32 @@ Why should this TEP _not_ be implemented?
 
 ## Alternatives
 
+### Alternatives for Schemas
+
+It will be more flexible if users can define the provenance following the defined schemas, but don't necessarily have to follow the naming patterns. Users can provide a result in array type, with name consistent with the signable target, and have a list of result names that are under that category. An example can be like:
+
+```yaml
+results:
+        - name: SIGNABLE-VCS
+          value: ["FOO", "BAR"]
+        - name: FOO
+          value:
+            src_type: git
+            uri: git+https://github.com/foo/bar.git
+            digest_ago: sha256
+            digest: abc
+        - name: SIGNABLE-OCI_IMAGE
+          value: ["IMAGE1"]
+        - name: IMAGE1
+           value:
+             name: gcr.io/somerepo/someimage
+             digest: abc
+             alg: sha256
+```
+
+And the result that contains the provenance still need to be aligned with the schema we defined in Chains. This way, users don't need to name the results.
+This is not chosen because Chains would need to be aware of the difference between different types of artifacts.
+
 ### Inputs / Outputs Distinguishment
 
 We can also separately collect inputs provenance from params, and outputs provenance from TaskRun results. The signable artifacts being found in params will be the inputs, and those found in TaskRun results will be the outputs. However, params are not reliable as users don't really specify those human less readable provenance metadata formats mentioned in in-toto attestations in neither PipelineRun nor TaskRun params.