[COSE] Re: RFC 9942 on CBOR Object Signing and Encryption (COSE) Receipts

[Anders Rundgren <[e-mail]>]

I guess I have been asleep since I haven't even heard about this work-item before...

FWIW, I'm personally developing a e-receipt-scheme for the EU Wallet when used for payments.  It has almost nothing in common with RFC 9942.  The following are the most obvious differences:

- e-Receipt type is given by a top-level tag in analogy with the rest of the payment-related messages.  In my case object types are provided as URLs which is a de-facto standard outside of the CBOR community.

- There is no "bstr" wrapping of e-receipt data; deterministically encoded CBOR is trivial to accomplish in current mobile phones.  Embedded signatures does the rest.

- Since creating a global root for e-receipts seems unrealistic, compatible receipts are supposed to include a URL to the public key.  This URL must belong to the same domain as the payment request.  That is, trust is leveraging the trust in the WebPKI.

Anders
Predecessor using JSON: https://cyberphone.github.io/doc/defensive-publications/signed-e-receipts.pdf


On 2026-07-01 00:44, [e-mail] wrote:
> A new Request for Comments is now available in online RFC libraries.
> 
>          RFC 9942
> 
>          Title:      CBOR Object Signing and Encryption (COSE) Receipts
>          Author:     O. Steele,
>                      H. Birkholz,
>                      A. Delignat-Lavaud,
>                      C. Fournet
>          Status:     Proposed Standard
>          Stream:     IETF
>          Date:       June 2026
>          Mailbox:    [e-mail],
>                      [e-mail],
>                      [e-mail],
>                      [e-mail]
>          Pages:      20
> 
> 
>          I-D Tag:    draft-ietf-cose-merkle-tree-proofs-18
> 
>          URL:        https://www.rfc-editor.org/info/rfc9942
> 
>          DOI:        10.17487/RFC9942
> 
> CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs.
> 
> This document is a product of the CBOR Object Signing and Encryption Working Group of the IETF.
> 
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and
> suggestions for improvements. Distribution of this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>    https://www.ietf.org/mailman/listinfo/ietf-announce
>    https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search/
> For downloading RFCs, see https://www.rfc-editor.org/series/rfc-download/
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [e-mail].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> 
> _______________________________________________
> COSE mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]