Original text:
fig-transparent-statement-cddl illustrates a normative CDDL definition of Transparent Statements. <del> fig-transparent-statement-edn illustrates a payload that is detached. The unprotected header can contain multiple receipts. </del>  <del> Notice the verifiable data structure used is RFC9162_SHA256 in this case.  We know from the COSE Verifiable Data Structure Registry that RFC9162_SHA256 is value 1, and that it supports -1 (inclusion proofs) and -2 (consistency proofs). </del>  <del> Notice the unprotected header contains verifiable data structure proofs, see the protected header for details regarding the specific verifiable data structure used. </del>  <del> This is a decoded inclusion proof for RFC9162_SHA256, other verifiable data structures might encode inclusion proofs differently. </del>  <del> 4.3.1. </del>  Relying Parties MUST apply the verification process as described in <del> Section 4.4 of RFC9052. </del>  APIs exposing verification logic for Transparent Statements may provide more details than a single boolean result.  For example, an

Reviewer comments:
Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM

Revised text:
fig-transparent-statement-cddl illustrates a normative CDDL definition of Transparent Statements.  <ins> fig-transparent-statement-edn illustrates a Transparent Statement with a detached payload, and two receipts in its unprotected header. The label 394 "receipts" in unprotected header can contain multiple receipts. </ins>  <ins> fig-receipt-edn one of the decoded Receipt from fig-transparent- statement-edn.  The Receipt contains inclusion proofs for verifiable data structures.  The unprotected header contains verifiable data structure proofs.  See the protected header for details regarding the specific verifiable data structure used.  Referencing the COSE Verifiable Data Structure Registry, RFC9162_SHA256 is value "1", which supports "-1" (inclusion proofs) and "-2" (consistency proofs). </ins>  <ins> fig-receipt-protected-header-edn illustrates the decoded protected header of the Transparent Statement in fig-transparent-statement-edn. The verifiable data structure ("-111") uses "1" from (RFC9162_SHA256). </ins>  <ins> fig-receipt-inclusion-proof-edn illustrates the decoded inclusion proof from fig-receipt-edn.  This inclusion proof indicates that the size of the transparency log was "8" at the time the receipt was issued.  The structure of this inclusion proof is specific to the verifiable data structure used (RFC9162_SHA256). </ins>  <ins> 4.4.1. </ins> Relying Parties MUST apply the verification process as described in  <ins> Section 4.4 of RFC9052, when checking the signature of Signed Statements and Receipts. A Relying Party MUST trust the verification key or certificate and the associated identity of at least one issuer of a Receipt. A Relying Party MAY decide to verify only a single Receipt that is acceptable to them, and not check the signature on the Signed Statement or Receipts which rely on verifiable data structures which they do not understand. </ins> APIs exposing verification logic for Transparent Statements may provide more details than a single boolean result.  For example, an