(WIP) Address feedback, wordsmith, update inspections

Signed-off-by: Aditya Sirish <aditya@saky.in>

ITE/11/README.adoc

@@ -53,8 +53,8 @@ called `expectedAttributes` that will live alongside the existing
 `expectedAttributes` will not support artifact rules but will instead evaluate
 each rule using the Common Expression Language (CEL).
 
-If this ITE is applied to the original in-toto layout, the schema for each step
-would look as follows.
+If this ITE is applied to the in-toto v1.0 layout schema, each step would look
+as follows.
 
 ```yaml
 name: string
@@ -66,7 +66,7 @@ pubkeys: list of authorized key IDs
 expectedCommand: list of strings
 ```
 
-If instead the ITE is applied to layouts with support for the in-toto
+If instead the ITE is applied to ITE-10 layouts with support for the in-toto
 Attestation Framework, the resultant step schema is as follows.
 
 ```yaml
@@ -86,7 +86,7 @@ functionaries: list of authorized functionary key IDs
 threshold: int
 ```
 
-Similarly, inspections in legacy layouts are updated to the following schema.
+Similarly, inspections are updated to the following schema.
 
 ```yaml
 name: string
@@ -96,24 +96,6 @@ expectedAttributes: list of CEL expressions
 run: list of strings
 ```
 
-And inspections in layouts with support for the Attestation Framework will have
-the following schema.
-
-```yaml
-name: string
-command: list of strings
-expectedMaterials: list of artifact rules
-expectedPredicates: list of expectedInspectionPredicates
-```
-
-Each `expectedInspectionPredicate` object has the following schema.
-
-```yaml
-predicateType: string
-expectedProducts: list of artifact rules
-expectedAttributes: list of CEL expressions
-```
-
 === Verifying Attribute Constraints
 
 An in-toto implementation supporting these checks must support the evaluation of
@@ -126,61 +108,66 @@ verification is aborted with an error indicating the failing rule.
 [[motivation]]
 == Motivation
 
-in-toto attestations, whether links from the original in-toto specification or
-contextual metadata from the Attestation Framework, contain various claims. The
-link metadata format has two opaque fields, `environment` and `byproducts`, that
-can hold arbitrary information. Contextual predicates also record various
-software supply chain specific attributes, though in predefined fields rather
-than in an arbitrary manner in opaque fields. In the current in-toto
-specification, the only way to verify these attributes are through inspections
-that require executing commands or scripts during verification. If invoked via
-scripts, they need to be communicated alongside layouts to the verifier and
-there are no in-toto specific guarantees as to their integrity or if they were
-issued by the authors of the layout. Further, these scripts can be complicated
-as they need to load attestations, once again verify their signatures using keys
-in the layout, before they can actually validate the attributes in question.
+in-toto attestations, whether link metadata from in-toto v1.0 or contextual
+metadata from the Attestation Framework, contain various claims. The link
+metadata format has two opaque fields, `environment` and `byproducts`, that can
+hold arbitrary information. Contextual predicates also record various software
+supply chain specific attributes, though in predefined fields rather than in an
+arbitrary manner in opaque fields. In the current in-toto specification, the
+only way to verify these attributes are through inspections that require
+executing commands or scripts during verification. If invoked via scripts, they
+need to be communicated alongside layouts to the verifier and there are no
+in-toto specific guarantees as to their integrity or if they were issued by the
+authors of the layout. Further, these scripts can be complicated as they need
+to load attestations, once again verify their signatures using keys in the
+layout, before they can actually validate the attributes in question.
 
 === Example: Verifying Result of a Test Run
 
 The in-toto Attestation Framework has a vetted predicate capturing the results
-of test runs. To verify that the test result attestation indicates a successful
-test run, the following CEL rule can be used.
+of
+link:https://github.com/in-toto/attestation/blob/main/spec/predicates/test-result.md[test runs].
+To verify that the test result attestation indicates a successful test run, the
+following CEL rule can be used.
 
 ```yaml
 ...
 expectedAttributes:
-    - "result == 'PASSED'"
+    - "predicate.result == 'PASSED'"
 ...
 ```
 
 === Example: Verifying SLSA Provenance Attributes
 
-SLSA Provenance predicates record various attributes such as the identity of the
-builder, source repository, and various other parameters. These attributes can
-be verified in in-toto layouts as follows.
+link:https://github.com/in-toto/attestation/blob/main/spec/predicates/provenance.md[SLSA Provenance]
+records various attributes such as the identity of the builder, source
+repository, and various other parameters. These attributes can be verified in
+in-toto layouts as follows.
 
 ```yaml
 ...
 expectedAttributes:
-    - "runDetails.builder.id == '<expected value>'"
-    - "externalParameters.repository == '<expected value>'"
-    - "externalParameters.ref == '<expected value>'"
+    - "predicate.runDetails.builder.id == '<expected value>'"
+    - "predicate.externalParameters.repository == '<expected value>'"
+    - "predicate.externalParameters.ref == '<expected value>'"
 ...
 ```
 
 === Example: Verifying Build Isolation via Runtime Trace Attestation
 
-This vetted predicate is used to record a trace of some supply chain step, such
-as the build step. It can be used to verify that the builder made no network
-calls. But first, it is necessary to verify that the monitor was of an expected
-type and that its trace policy included tracking network calls.
+This vetted predicate is used to
+link:https://github.com/in-toto/attestation/blob/main/spec/predicates/runtime-trace.md[record a runtime trace]
+of some supply chain step, such as the build step. It can be used to verify
+that the builder made no network calls. But first, it is necessary to verify
+that the monitor was of an expected type and that its trace policy included
+tracking network calls.
 
 ```yaml
 ...
 expectedAttributes:
-    - "monitor.type == 'https://github.com/cilium/tetragon'"
-    - "monitor.tracePolicy.policies.exists(p, p['Name'] == 'connect')"
-    - "size(monitorLog.network) == 0"
+    - "predicate.monitor.type == 'https://github.com/cilium/tetragon'"
+    - "predicate.monitor.tracePolicy.policies.exists(p, p['Name'] == 'connect')"
+    - "size(predicate.monitorLog.network) == 0"
 ...
 ```
 
@@ -195,9 +182,9 @@ opaque field, `environment`.
 ```yaml
 ...
 expectedAttributes:
-    - "size(byproducts['stderr']) == 0"
-    - "byproducts['return-value'] == 0"
-    - "environment['<key>'] == '<expected value>'"
+    - "size(predicate.byproducts['stderr']) == 0"
+    - "predicate.byproducts['return-value'] == 0"
+    - "predicate.environment['<key>'] == '<expected value>'"
 ...
 ```
 
@@ -234,12 +221,12 @@ method of writing custom inspections also remains an option.
 [[backwards-compatibility]]
 == Backwards Compatibility
 
-This ITE is entirely backwards compatible with both the original layout schema
-and the updated one with support for the in-toto Attestation Framework. It adds
-one field to step and inspection declarations. Old in-toto implementations can
-safely ignore this field with the impact being the lack of attribute
-verification. This does not weaken in any way the security properties of such
-scenarios.
+This ITE is entirely backwards compatible with both the in-toto v1.0 layout
+schema and the one proposed in ITE-10 with support for the in-toto Attestation
+Framework. It adds one field to step and inspection declarations. Old in-toto
+implementations can safely ignore this field with the impact being the lack of
+attribute verification. This does not weaken in any way the security properties
+of such scenarios.
 
 [[security]]
 == Security
@@ -268,7 +255,7 @@ None.
 [[prototype-implementation]]
 == Prototype Implementation
 
-None yet.
+See: https://github.com/adityasaky/in-toto-attestation-verifier/
 
 [[testing]]
 == Testing
@@ -282,7 +269,7 @@ on the CEL engine.
 == References
 
 * link:https://github.com/google/cel-spec[CEL]
-* link:https://github.com/in-toto/docs/blob/master/in-toto-spec.md[in-toto Specification]
+* link:https://github.com/in-toto/docs/blob/master/in-toto-spec.md[in-toto v1.0]
 * link:https://github.com/in-toto/attestation[in-toto Attestation Framework]
 * link:https://kubernetes.io/docs/reference/using-api/cel/[CEL in Kubernetes]
 * link:https://www.openpolicyagent.org/docs/latest/policy-language/[Rego: Open Policy Agent's Policy Language]