content: source track v.next draft, address remainder of pre-merge issues

docs/spec/v1.1/source-requirements.md

@@ -1,22 +1,12 @@
 # SLSA Source Track
 
-## Objective
-
-The SLSA Source Track mitigates [Threat A ("Submit unauthorized change")](/spec/v1.0/threats#a-submit-unauthorized-change), scoped to a code repository and the organization that owns that repository. Concretely: an attacker must compromise the accounts of two organization members to publish code in a Source Level 3-conformant repository, and the evidence of those unauthorized changes cannot be destroyed without further attacks.
-
-## Changes from v0.1
+## Status: DRAFT
 
--   **Scope** The Source track is now scoped to Revisions rather than builds.
-Why?: To facilitate verification without anchoring it to a build.
+Open issues are tracked with the [source-track](https://github.com/slsa-framework/slsa/issues?q=is%3Aissue+is%3Aopen+label%3Asource-track) label in the [slsa-framework/slsa](https://github.com/slsa-framework/slsa) repository.
 
--   **Model** Added a model, definitions, and the concept of verification.
-Why?: SLSA does not yet have a model for version control systems, and we need such a model to be able to discuss them.
-
-## Outstanding TODOs
+## Objective
 
--   [] Flesh out the definition and bounds of 'identity', and why they're required.
--   [] Refine requirements/guidance for trusted robots.
--   [] Either identify the unique value of L1 or merge it with L2.
+The SLSA Source Track mitigates [Threat A ("Submit unauthorized change")](/spec/v1.0/threats#a-submit-unauthorized-change), scoped to a code repository and the organization that owns that repository. Concretely: an attacker must compromise the accounts of two organization members to publish code in a Source Level 3-conformant repository, and the evidence of those unauthorized changes cannot be destroyed without further attacks.
 
 ## Source model
 
@@ -28,7 +18,7 @@ The Source track is scoped to a single project that is controlled by some organi
 | Organization | A collection of people who collectively create the Source. Examples of organizations include an open-source projects, a company, or a team within a company.
 | Change | A set of modifications to one or more source files and associated metadata. Change metadata MUST include any information required to situate the change in relation to other changes (e.g. parent revision).
 | Version Control System | Software for tracking and managing changes to source. Git and Subversion are examples of version control systems.
-| Revision | The canonical source at a given point in time as identified by the version control system. As an example, you can identify a git revision by its tree hash.
+| Revision | A specific identifier provided by the version control system that identifies a given state of the source. As an example, you can identify a git revision by its tree hash.
 | Change History | A record of the history of changes that went into the revision.
 | Source Control Platform | A service or suite of services for hosting version controlled software. GitHub and GitLab are examples of source control platforms, as are combinations of tools like Gerrit code reviews with GitHub source control.
 

docs/spec/v1.1/whats-new.md

@@ -17,6 +17,7 @@ changes in v1.1 relative to the prior release, [v1.0].
 -   It is now recommended that the `digest` field of `ResourceDescriptor` is
     set in a Verification Summary Attestation's (VSA) `policy` object.
 -   Further refine the [threat model](threats).
+-   Add draft of [SLSA Source Track](source-requirements.md).
 
 <!-- Footnotes and link definitions -->