Summary

  • On 25 September SCITT's chairs opened a formal adoption call for an individual draft on COSE receipts for Merkle Mountain Range ledgers; responses are due 9 October.
  • A July in-room poll asked who would review the work. Its four yes votes were not adoption, and the current draft still has no formal IETF standing.
  • RFC 9942 supplies a shared receipt envelope but warns that distinct verifiable data structures do not automatically interoperate. A verifier has to support the selected structure and its proof rules.

A receipt can share a wrapper with another receipt and still require a different verifier. That is the practical consequence behind SCITT's 25 September call on draft-bryce-cose-receipts-mmr-profile-03. The chairs want to know whether the group should adopt the document as a basis for continued work. They explicitly separate that choice from completion or readiness for publication. Responses—support or opposition, reasons and willingness to review or implement—are requested by 9 October. The date is a comment deadline, not a promised adoption decision.

The process did not start from a blank page. At IETF 126 in July, the MMR profile was discussed as a candidate to bring into SCITT. Meeting minutes record four people willing to review, none voting against review and three expressing no opinion, out of 34 present. The question was willingness to review, not whether the community had adopted a specification. Datatracker still labels the September revision an active individual Internet-Draft and says it is not endorsed by the IETF.

The draft is concrete about the object under consideration. Its Merkle Mountain Range is a post-order binary-tree arrangement with peaks that form an accumulator. It defines how an inclusion proof connects one candidate element to a signed state and how a consistency proof connects an older state to a later one. The proposed COSE receipt keeps the structure identifier in a protected header and carries proof material separately. A detached payload makes the verifier calculate the relevant root from the proof before checking the signature. Those are proposed rules for this profile, not a claim that a generic COSE parser already implements them.

RFC 9942 is the useful boundary. It standardized the common COSE receipt framework and explicitly cautions that implementers should not expect interoperability across different verifiable data structures. A service able to parse a receipt envelope, or even to verify a different tree profile, has not thereby shown it can verify this MMR proof. The live SCITT document list already includes a separate CCF profile. The adoption call would put another profile into the group's work if accepted; it would not merge the two algorithms or give either automatic support in deployed software.

This also limits the claim made by a successful local check. The MMR draft itself says an inclusion receipt proves inclusion in a ledger state, not whether an entry was legitimate. It says omission before inclusion is outside its scope. Those caveats matter, but this article's news is narrower: the adoption question is about maintaining a distinct proof format inside a shared framework. A relying party should ask which VDS identifier, proof type and profile version its verifier actually understands, and whether it can test both the single-state and state-to-state paths with known examples.

That is an editorial procurement test, not a requirement SCITT has adopted.

The response window is therefore a chance to distinguish three propositions: the draft is in scope, its proof algorithms are sufficiently specified for further review, and independent implementations interoperate under an agreed test. The chairs are asking the first question now. The other two cannot be inferred from a mailing-list call, a July review poll or a familiar COSE wrapper.

Sources