The Proposed 402-Receipts Standard

A Receipt is a message specifying that someone paid for access to a resource, or should otherwise be given access to the resource.

There are some practical limitations of the readily available cryptographic options, which are unlikely to be fixed in time for version 0.
In particular, the use of a fully blind signature means that, in practice, a given Notary can only issue Receipts for a single amount. Like other performance issues, we do plan to address this problem, but useable systems don’t need to wait for it.



A Receipt is an XML object describing a particular payment for a particular resource. The XML document is always expressed as a list of Receipts; the XML root is <receipts>. Receipts are uniquely identified by a UUID.

  <receipt xmlns="https://402.TBD">

Notary Signature

The Notary Signature is the <signature> tag within a Receipt. It’s an RSA Blind Signature of the contents of the Receipt, seriallized as described below.

The subject of the blind signature is the concatination, in this order, of the following key-value pairs:
domain, item, signer, time, units if there is one, amount if there is one, plan if there is one, and uuid.
String values should have any double-quote characters removed, and should be enclosed in double-quotes.
time should use the normal decimal integer representation: no leading zeros, sign, decimal-point, or thousands-markers.
amount should use signed decimal representation: no extra leading or trailing zeros, . decimal-point, no thousands-markers.
uuid should use just the lower-case hex bytes without braces, dashes, or quotes.
This will be hashed and signed as a utf-8 string.

The public key for a given Notary, identified by the Receipt’s signer field, is assumed to be known by the Client and Host.


Given an abstract receipt such as

  • domain:
  • item: This is "technically" a valid item string.
  • signer:
  • time: 1557944008
  • units: USD
  • amount: 5.0000001×10^-6
  • uuid: {{bf9c1367-9589-41ff-8f74-134877341cce}}

one would serialize it as

domain""item"This is technically a valid item string."signer""time1557944008units"USD"amount0.0000050000001uuidbf9c1367958941ff8f74134877341cce

which might yeild a Notary Signature like


to be used in the Receipt XML.

Systems to prevent sharing of receipts are desired, but not critical for version 0.

UUID Details

It’s the Client’s responsibility to generate a random version-4 UUID. Use of other UUID types may result in identifiers that are traceable back to the Client’s computer, or may risk collisions. Uniqueness is only enforceable on the signer/domain/UUID triplet; the global uniqueness of UUID’s can’t be relied upon here because a malicious client could deliberately violate it.

Bundled Receipts

The receipts XML object is a list because situations are likely in which a user will want to submit multiple receipts at once. For example, a website might give a Receipt Definition to the effect of “Pages are $0.05 each, up to $3.00/month.”. Once a customer had viewed enough pages that their receipts for that month totaled $3.00, their Client would begin submitting bundled Receipts instead of buying a receipt for each page.

The above configuration would be accomplished by serving two Receipt Definitions with each page; the first ($0.05) would specify the page as the item, and the second ($3.00) would have a blank (wildcard) item field.


XML Schema for Receipt XML objects.

Namespace: https://402.TBD
Tag Description Children/Type
Root elements:

The root element of an XML document containing a list of Receipts.

see below
Element types:

A list of Receipts.

List of receipt

A Receipt object, denoting that someone has paid for access to an item of content or a family of content.

  • domain
  • item
  • signer
  • time
  • cost
  • uuid
  • signature

Must match the domain from the Receipt Definition which this receipt is fulfilling.


    Must match the item from the Receipt Definition which this receipt is fulfilling.


      The absolute canonical HTTPS url identifying the Notary who issued the signature. Obviously this must match one of the signers in the Receipt Definition.


        The Unix Epoch time when the client says the transaction happened.


          Usually an expression of monetary value, which must match, total to, or exceed the cost from the Receipt Definition. While the actual charging of money is left to the Notery’s discretion, this is generally assumed to be the amount the user paid for the Receipt. Because of the cryptographic limitations of the current version of this protocol, Noteries will only honor Receipts for a single set amount.

          • units
          • amount
          • plan

          A currency code. ISO4217 codes are recommended.


            A decimal number amount of that currency’s major units. For example, six US cents would be 0.06, not 6.


              An identifier which is assumed to mean something to the various parties involved.


                An ID for a Bare-Receipt. This may be used to prevent reuse of a receipt by multiple parties (with caveats). Use of values other than properly-generated V4 UUIDs is unsafe.

                • pattern: \{?([0-9a-fA-F]{4}-?){8}\}?

                The Notary Signature of the receipt.