Original text:
tree-proofs. This section describes at a high level, the three main roles and <del> associated processes in SCITT: Issuers and the Signed Statement issuance process, Transparency Service and the Signed Statement Registration process, as well as Verifiers of the Transparent Statements and the Receipt validation process. </del>  5.1. 5.1.1. Before an Issuer is able to produce Signed Statements, it must first <del> create an identifier and obtain an identity document, that is acceptable to the Transparency Service.  Transparency Services MAY support many different identity document formats. </del>  Issuers SHOULD use consistent identifiers for all their Statements <del> about Artifacts, to simplify authorization by Verifiers and auditing. If an Issuer uses multiple identifiers, they MUST ensure that statements signed under each identifier are consistent. Issuers MAY rotate verification keys at any time, or at a consistent cryptoperiod.  Issuers MAY migrate to new signing and verification </del>  algorithms, but the Transparency Service remains responsible for <del> admitting signed statements that match its policies. The Issuer's identifier is required and appears in the "1 iss" claim of the "15 CWT_Claims" protected header of the Signed Statements' Envelope.  The version of the key used to sign the Signed Statement is written in the "4 kid" protected header. Key discovery protocols are out of scope for this document. </del>  5.1.2.

Reviewer comments:
Renamed to: Structure and Content of Signed Statements Updated content based on this thread: URL Added and made both CWT_Claims and mandatory as per the output of discussions added refs and figure label (which are missing all over the place)
LGTM
LGTMLGTM

Revised text:
tree-proofs. This section describes at a high level, the three main roles and  <ins> associated processes in SCITT: Issuers and Signed Statements, Transparency Service and the Signed Statement Registration process, as well as Verifiers of the Transparent Statements and the Receipt validation process. </ins> 5.1. 5.1.1. Before an Issuer is able to produce Signed Statements, it must first  <ins> create an identifier and obtain an identity document that is acceptable to the Transparency Service.  Transparency Services MUST support the capability to associate an X.509v3 certificate with a Signed Statement using a hash (thumbprint) of the certificate as specified in RFC9360 by supporting the "x5t" COSE header parameter. The "x5t" COSE header parameter MUST be included in the protected header of a Signed Statement's COSE envelope.  The mechanisms how Transparency Services obtain corresponding X.509v3 certificates, e.g., as part of enforcing Registration Policy, is out-of-scope of this document.  Transparency Services MAY support many other identifier formats for identifying many other identity document formats.  Alternative identifiers for identity documents MUST also be included in the protected header of the COSE envelope.  Only one type of identity document identifier MUST be included in a Signed Statement's COSE envelope. </ins> Issuers SHOULD use consistent identifiers for all their Statements  <ins> about Artifacts to simplify authorization by Verifiers and auditing. If an Issuer uses multiple identifiers across their Statements, they MUST ensure that Statements signed under each identifier are consistent. Issuers MAY rotate verification keys at any time and SHOULD rotate verification keys at an appropriate and consistent cryptoperiod (see KEY-MANAGEMENT).  Issuers MAY migrate to new signing and verification </ins> algorithms, but the Transparency Service remains responsible for  <ins> admitting Signed Statements that complies with its active Registration Policies.  The version of the key used to sign the Signed Statement MAY be included via the "kid" COSE header parameter in the protected header.  Key discovery protocols are out-of-scope of this document. An Issuer identifier is required to be included in the COSE envelope. The protected header of a Signed Statement MUST include the "CWT Claims" header parameter as specified in CWT_CLAIMS_COSE.  The CBOR map that constitutes the corresponding "CWT Claims" value MUST include the "Issuer Claim" (Claim label 1, see IANA.cwt) where the value MUST represent the Issuer identifier. An Subject identifier is also required to be included in the COSE envelope.  The CBOR map that constitutes the corresponding "CWT Claims" value MUST include the "Subject Claim" (Claim label 2, see IANA.cwt) where the value MUST represent the Subject identifier. Figure fig-signed-statement illustrated a normative CDDL definition for the composition of the protected header in COSE envelope of SCITT Signed Statements. </ins> 5.1.2.