<del> : The DID of the Transparency Service that issued the Receipt. Verifiers MAY use this DID as a key discovery mechanism to verify the Receipt.  The verification is the same for Signed Statement and the signer MAY include the "kid" header parameter.  Verifiers MUST support the "did:web" method, all other methods are optional. </del> <ins> : The Transparency Service MAY include the Registration policy info header to indicate to Verifiers what policies have been applied at the registration of this Statement </ins> <del> The following requirements for the COSE signature of the Merkle Root are added: </del> <ins> Inside Reg_info, the Transparency Service may include the registration time to help Verifiers decide about the trustworthiness of the Transparent Statement. </ins> <del> The SCITT version header MUST be included and its value match the "version" field of the Receipt structure </del> <ins> The registration time is defined as the timestamp at which the Transparency Service has added this Signed Statement to its Append- only Log. </ins> <del> The DID of Issuer header (in Signed Statements) MUST be included and its value match the "ts_identifier" field of the Receipt structure </del> <ins> Editor's Note: The WG is discussing if existing CWT claims might better support these design principles. </ins> <del> Transparency Service MAY include the Registration policy info header to indicate to Verifiers what policies have been applied at the registration of this Statement </del> <ins> Here is an example transparent statement: </ins> <del> Since I-D.draft-steele-cose-merkle-tree-proofs uses optional headers, the "crit" header (id: 2) MUST be included and all SCITT- specific headers (version, DID of Transparency Service and Registration Policy) MUST be marked critical </del> <ins> 6.4.1. </ins> <del> The Transparency Service may include the registration time to help Verifiers decide about the trustworthiness of the Transparent Statement.  The registration time is defined as the timestamp at which the Transparency Service has added this Signed Statement to its Append-only Log. </del> <ins> 6.4.1.1. Notice the payload is detached, this is to support very large supply chain artifacts, and to ensure that Transparent Statements can integrate with existing file systems. Notice the unprotected header can contain multiple receipts. 6.4.1.2. Notice the content type, transparency services might support only certain content types from certain issuers, per their registration policies. Notice the CWT Claims, transparency services might support only statements about certain artifacts from certain issuers, per their registration policies. 6.4.1.3. Notice the unprotected header contains verifiable data structure proofs, see the protected header for details regarding the specific verifiable data structure used. 6.4.1.4. 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). 6.4.1.5. This is a decoded inclusion proof for RFC9162_SHA256, other verifiable data structures might encode inclusion proofs differently. </ins> 6.5.