Code change:
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

Related discussion:
text: headers: Receipts (label: "TBD", temporary: "394"): Array of Receipts, <del> defined in </del> <ins> defined below.  This allows the Receipt to be attached to the Signed Statement, thus making a Transparent Statement. </ins> In CDDL RFC8610 notation, the Envelope is defined as follows: 6.2. <ins> Receipts are based on COSE Signed Merkle Tree Proofs (I-D.draft- steele-cose-merkle-tree-proofs) with an additional wrapper structure that adds the following information: version: Receipt version number; this should be set to "0" for implementation of this document.  We envision that future version of SCITT may add support for more complex receipts; for instance, registrations on multiple TS, receipts for dependency graphs and endorsements of Signed Claims, etc. ts_identifier: The DID of the Transparency Service that issued the claim.  Verifiers MAY use this DID as a key discovery mechanism to verify the COSE Merkle Root signature; in this case the verification is the same as for Signed Claims and the signer should include the Key ID header.  Verifiers MUST support the "did:web" method, all other methods are optional. We also introduce the following requirements for the COSE signature of the Merkle Root: The SCITT version header MUST be included and its value match the "version" field of the Receipt stucture. The DID of issuer header (like in Signed Claims) MUST be included and its value match the "ts_identifier" field of the Receipt structure. TS MAY include the Registration policy info header to indicate to verifiers what policies have been applied at the registration of this claim. Since -COSEMTP uses optional headers, the "crit" header (id: 2) MUST be included and all SCITT-specific headers (version, issuer DID and Registration Policy) MUST be marked critical. The following registration policies are built-in and MAY be used by verifiers to help decide the trustworthiness of the Transparent Statement: Registration time: the timestamp at which the TS has added this Signed Claim to its Registry DID Manifest: the manifest that was retured by resolving the DID of the issuer at registration, according to the TS. Sequence number: the sequence number of this statement with relation to other statements with the same issuer and feed.  There is no guarantee that all Signed Statements are registered with contiguous sequence numbers; only that it is monotonic and follows the issuer sequence numbers. 6.3. </ins> There are many types of Statements (such as SBOMs, malware scans, audit reports, policy definitions) that Issuers may want to turn into Signed Statements.  An Issuer must first decide on a suitable format