SLSA v1.0: address more feedback on levels.md

- Use consistent terminolgoy around "transitive" and link directly to
  the specific FAQ entry.
- Add infrastructure providers to "Who is SLSA for?"
- Fix typos and improve wording.
- Add TODO about avoiding the term "signing".

Signed-off-by: Mark Lodato <[email protected]>

docs/spec/v1.0/levels.md

@@ -28,19 +28,20 @@ Importantly, SLSA is intended to be a primitive in a broader determination of a
 software's risk. SLSA measures specific aspects of supply chain security,
 particularly those that can be fully automated; other aspects, such as developer
 trust and code quality, are out of scope. Furthermore, each link in the software
-supply chain has its own, independent SLSA level ([FAQ](../faq.md)). The benefit
-of this approach is to break up the large supply chain security problem into
-tractable subproblems that can be prioritized based on risk and tackled in
-parallel. But this does mean that SLSA alone is not sufficient to determine if
-an artifact is "safe".
+supply chain has its own, independent SLSA level---in other words, it is not
+transitive ([FAQ](../faq.md#q-why-is-slsa-not-transitive)). The benefit of this
+approach is to break up the large supply chain security problem into tractable
+subproblems that can be prioritized based on risk and tackled in parallel. But
+this does mean that SLSA alone is not sufficient to determine if an artifact is
+"safe".
 
 > **TODO:** SLSA is in the eye of the beholder: software consumers make their
 > own SLSA determinations, though in practice they may delegate to some
 > authority.
 
 ## Who is SLSA for?
 
-There are three main audiences for SLSA:
+SLSA is intended to serve multiple populations:
 
 -   **Project maintainers,** who are often small teams that know their build
     process and trust their teammates. Their primary goal is protection against
@@ -56,13 +57,18 @@ There are three main audiences for SLSA:
     addition to the goals above, organizations also want to broadly understand
     and reduce risk across the organization.
 
+-   **Infrastructure providers,** such as build services and packaging
+    ecosystems, who are critical to achieving SLSA. While not the primary
+    beneficiary of SLSA, they may benefit from increased security and user
+    trust.
+
 ## Levels and tracks
 
 SLSA levels are split into *tracks*. Each track has own set of levels that
 measure a particular aspect of supply chain security. The purpose of tracks is
 to recognize progress made in one aspect of security without blocking on an
 unrelated aspect. Tracks also allow the SLSA spec to evolve: we can add more
-tracks without invaliding previous levels.
+tracks without invalidating previous levels.
 
 | Track/Level | Requirements | Benefits |
 | ----------- | ------------ | -------- |
@@ -71,7 +77,7 @@ tracks without invaliding previous levels.
 | [Build L2]  | Signed attestation, generated by a hosted build service | Reduced attack surface, weak tamper protection |
 | [Build L3]  | Hardened build service | Strong tamper protection |
 | [Build L4]  | (not yet defined) | |
-| [Source]    | (not yet defined) | |
+| [Source L…] | (not yet defined) | |
 
 > Note: The [previous version] of the specification used a single unnamed track,
 > SLSA 1–4, roughly corresponding to the equivalently numbered Build + Source
@@ -176,8 +182,8 @@ attack surface and increasing the difficulty to forge the provenance.
 <dt>Intended for<dd>
 
 Projects and organizations wanting to gain moderate security benefits of SLSA by
-switching to a hosted build service, while waiting changes to the build service
-itself required by [Build L3].
+switching to a hosted build service, while waiting for changes to the build
+service itself required by [Build L3].
 
 <dt>Requirements<dd>
 
@@ -205,6 +211,8 @@ All of [Build L1], plus:
 </section>
 <section id="build-l3">
 
+> **TODO:** If possible, avoid being overly specific about "signing".
+
 ### Build L3: Hardened builds
 
 <dl class="as-table">
@@ -247,7 +255,7 @@ All of [Build L2], plus:
 ### Build L4: (not yet defined)
 
 Build L4 is not yet defined. For reference, [previous version] of SLSA defined a
-"SLSA 4" that included the following requirements, which *may or may not* be
+"SLSA 4" that included the following requirements, which **may or may not** be
 part of a future Build L4:
 
 -   Pinned dependencies, which guarantee that each build runs on exactly the
@@ -268,11 +276,11 @@ against tampering of the source code. It will be defined in a future version of
 the specification.
 
 For reference, the [previous version] of SLSA included the following
-requirements, which *may or may not* be part of a future Source track:
+requirements, which **may or may not** be part of a future Source track:
 
--   Strong authentication of author and reviewer identities to resist account
-    and credential compromise, such as 2-factor authentication using a hardware
-    security key.
+-   Strong authentication of author and reviewer identities, such as 2-factor
+    authentication using a hardware security key, to resist account and
+    credential compromise.
 -   Retention of the source code to allow for after-the-fact inspection and
     future rebuilds.
 -   Mandatory two-person review of all changes to the source to prevent a single
@@ -290,4 +298,4 @@ requirements, which *may or may not* be part of a future Source track:
 [build]: #build-track
 [previous version]: ../v0.1/levels.md
 [provenance attestation]: terminology.md
-[source]: #source-track
+[source l…]: #source-track