Update requirements.md

requirements.md

@@ -298,11 +298,25 @@ the service generating the provenance.
 
 <td> <td>✓<td>✓<td>✓
 <tr id="service-generated">
-<td>Build Service Reported
+<td>Service Generated
 <td>
 
-The provenance was populated with data reported by the build service, not by user-provided tooling
-running within the service.
+The data in the provenance MUST be obtained from the build service (either because
+the generator _is_ the build service or because the provenance generator reads the
+data directly from the build service).
+    
+Regular users of the service MUST NOT be
+able to inject or alter the contents, except as noted below.
+
+The following provenance fields MAY be generated by the user-controlled build
+steps:
+
+*   The output artifact hash from [Identifies Artifact](#identifies-artifact).
+    *   Reasoning: This only allows a "bad" build to falsely claim that it
+        produced a "good" artifact. This is not a security problem because the
+        consumer MUST accept only "good" builds and reject "bad" builds.
+*   The "reproducible" boolean and justification from
+    [Reproducible](#reproducible).
 
 <td> <td>✓<td>✓<td>✓
 <tr id="non-falsifiable">
@@ -311,6 +325,8 @@ running within the service.
 
 Provenance cannot be falsified by the build service's users.
 
+NOTE: This requirement is a stricter version of [Service Generated](#service-generated).
+    
 *   The provenance signing key MUST be stored in a secure key management system
     accessible only to the build service account.
 *   The provenance signing key MUST NOT be accessible to the environment running