Original text:
The SCITT architecture consists of a very loose federation of Transparency Services, and a set of common formats and protocols for <del> issuing, registering and auditing Transparent Statements.  In order to accommodate as many Transparency Service implementations as possible, this document only specifies the format of Signed </del>  Statements (which must be used by all Issuers) and a very thin wrapper format for Receipts, which specifies the Transparency Service <del> identity and the Registry algorithm.  Most of the details of the Receipt's contents are specific to the Registry algorithm.  The I- D.birkholz-scitt-receipts document defines two initial Registry algorithms (for historical and sparse Merkle Trees), but other Registry formats (such as blockchains, or hybrid historical and indexed Merkle Trees) may be proposed later. </del>  In this section, a high level the three main roles and associated processes in SCITT: Issuers and the Signed Statement issuance

Reviewer comments:
As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM

Revised text:
The SCITT architecture consists of a very loose federation of Transparency Services, and a set of common formats and protocols for  <ins> issuing, registering and auditing Transparent Statements. In order to accommodate as many Transparency Service implementations as possible, this document only specifies the format of Signed </ins> Statements (which must be used by all Issuers) and a very thin wrapper format for Receipts, which specifies the Transparency Service  <ins> identity and the agility parameters for the Merkle Tree Proof.  Most of the details of the Receipt's contents are specified in the COSE Signed Merkle Tree Proof document I-D.draft-steele-cose-merkle-tree- proofs. </ins> In this section, a high level the three main roles and associated processes in SCITT: Issuers and the Signed Statement issuance