Original text:
<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>  <del> The following requirements for the COSE signature of the Merkle Root are added: </del>  <del> The SCITT version header MUST be included and its value match the "version" field of the Receipt structure </del>  <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>  <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>  <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>  <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>  6.5.

Reviewer comments:
This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:

Revised text:
 <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>  <ins> Inside Reg_info, the Transparency Service may include the registration time to help Verifiers decide about the trustworthiness of the Transparent Statement. </ins>  <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>  <ins> Editor's Note: The WG is discussing if existing CWT claims might better support these design principles. </ins>  <ins> Here is an example transparent statement: </ins>  <ins> 6.4.1. </ins>  <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.