content: draft: define how downstream users can verify the SLSA source track level of revisions

docs/spec/draft/source-requirements.md

@@ -129,3 +129,61 @@ Trusted robots MAY be exempted from the code review process. It is RECOMMENDED t
 **[Different persons]** The organization strives to ensure that no two user accounts correspond to the same person. Should the organization discover that it issued multiple accounts to the same person, it MUST act to rectify the situation. For example, it might revoke project privileges for all but one of the accounts and perform retroactive code reviews on any changes where that person's accounts are the author and/or code reviewer(s).
 
 Benefits: A compromise of a single human or account does not result in compromise of the project, since all changes require review from two humans.
+
+## Source Attestations
+
+There are two uses for source attestations within the source track:
+
+1. Assertions: Communicate to downstream users what high level security properties a given source revision meets.
+2. Evidence: Provide trustworthy metadata which can be used to determine what high level security properties a given source revision meets.
+
+To provide interoperability and ensure ease of use, it's essential that the 'assertions' are applicabile across all Source Control Platforms.
+Due to the significant differences in how SCPs operate and how they may chose to meet the Source Track requirements it is preferable to
+allow for flexibility with 'evidence' attestations.  To that end SLSA leaves 'evidence' attestations undefined and up to the SCPs to determine
+what works best in their environment.
+
+### Source Level Assertions
+
+Source level assertions are issued by the SCP or some other authority that has sufficient evidence to make the determination of a given
+revision's source level.
+
+These assertions are communicated in [Verification Summary Attestations (VSAs)](./verification_summary.md) as follows:
+
+1. `subject.uri` SHOULD be set to a human readable URI of the revision.
+1. `subject.digest` MUST include the revision identifier (e.g. `gitCommit`) and MAY include other digests over the contents of the revision (e.g. `gitTree`, `dirHash`, etc...).
+SCPs that do not use cryptographic digests MUST define a canonical type that is used to identify immutable revisions (e.g. `svn_revision_id`)[^1].
+1. `resourceUri` MUST be set to the URI of the repository, preferably using [SPDX Download Location](https://spdx.github.io/spdx-spec/v2.3/package-information/#77-package-download-location-field) and SHOULD
+provide the branch or refs.  E.g. `git+https://github.com/foo/hello-world@refs/heads/main`.
+1. `verifiedLevels` MUST include the SLSA source track level the issuer asserts the revision meets. One of `SLSA_SOURCE_LEVEL_0`, `SLSA_SOURCE_LEVEL_1`, `SLSA_SOURCE_LEVEL_2`, `SLSA_SOURCE_LEVEL_3`.
+1. `dependencyLevels` MAY be empty as source revisions are typically terminal nodes in a supply chain.
+
+Source Level Assertion issuers MAY issue assertions based on their understanding of the underlying system, but SHOULD prefer to issue assertions based on Source Level Evidence appropriate to their SCP.
+
+#### Example
+
+```
+"_type": "https://in-toto.io/Statement/v1",
+"subject": [{
+  "uri": "https://github.com/foo/hello-world/commit/9a04d1ee393b5be2773b1ce204f61fe0fd02366a"
+  "digest": {"gitCommit": "9a04d1ee393b5be2773b1ce204f61fe0fd02366a"}
+}],
+
+// Predicate
+"predicateType": "https://slsa.dev/verification_summary/v1",
+"predicate": {
+  "verifier": {
+    "id": "https://example.com/source_verifier",
+  },
+  "timeVerified": "1985-04-12T23:20:50.52Z",
+  "resourceUri": "git+https://github.com/foo/hello-world@refs/heads/main",
+  "policy": {
+    "uri": "https://example.com/slsa_source.policy",
+  },
+  "verificationResult": "PASSED",
+  "verifiedLevels": ["SLSA_SOURCE_LEVEL_3"],
+}
+```
+
+[^1]: in-toto attestations allow non-cryptographic digest types: https://github.com/in-toto/attestation/blob/main/spec/v1/digest_set.md#supported-algorithms.
+
+