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.
Receipt
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.
<receipts>
<receipt xmlns="https://402.TBD">
<domain>https://www.example.com/</domain>
<item>/path/image.png</item>
<signer>https://receipts.dmn.network/path</signer>
<time>1557944008</time>
<cost>
<units>USD</units>
<amount>0.05</amount>
</cost>
<uuid>bf9c1367-9589-41ff-8f74-134877341cce</uuid>
<signature>1234567890ABCDEF</signature>
</receipt>
</receipts>
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:
https://www.example.com/
- item:
This is "technically" a valid item string.
- signer:
https://receipts.dmn.network/path
- time: 1557944008
- units:
USD
- amount: 5.0000001×10^-6
- uuid: {{bf9c1367-9589-41ff-8f74-134877341cce}}
one would serialize it as
domain"https://www.example.com/"item"This is technically a valid item string."signer"https://receipts.dmn.network/path"time1557944008units"USD"amount0.0000050000001uuidbf9c1367958941ff8f74134877341cce
which might yeild a Notary Signature like
a659953eaff5e9585445f4fccb454dd9e5cc3b124aadada5651746b2ab0ab222f0c0a29a4473535e08f1f2eedbff572c0b263ed7f984d5fb5a5e019f53a93ef1f3eccf3d54c4d605cfe3b45cae2f89e4f1cf7808678f0c9a48b0bea576b6bd67d462a740b79e8eb242b047e5efd02f13fb233c3552ee6085fe60c66929610be7b4de0831ca1bb202febd58b04d6fcb13a060b2617da6b2dc2a03f09e1d2ada1d9b3449fe6ce5ef13f8e2a4e0b4150498f980877e3265b78cb18716167925011812488bf03754d52b92b9cf885c8f5f42dc4ba2b7ab47702f68a4d6d49f555e97698d7bad096398cffd33e5443f48dc74c5edcf8af59474b2808c7f7b846052bh
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.
Schema
Tag | Description | Children/Type |
---|---|---|
Root elements: | ||
receipts |
The root element of an XML document containing a list of Receipts. |
see below |
Element types: | ||
receipts |
A list of Receipts. |
List of receipt
|
receipt |
A Receipt object, denoting that someone has paid for access to an item of content or a family of content. |
|
domain |
Must match the |
string
|
item |
Must match the |
string
|
signer |
The absolute canonical HTTPS url identifying the Notary who issued the |
anyURI
|
time |
The Unix Epoch time when the client says the transaction happened. |
unsignedInt
|
cost |
Usually an expression of monetary value, which must match, total to, or exceed the |
|
units |
A currency code. ISO4217 codes are recommended. |
string
|
amount |
A decimal number amount of that currency’s major units. For example, six US cents would be |
decimal
|
plan |
An identifier which is assumed to mean something to the various parties involved. |
string
|
uuid |
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. |
string
|
signature |
The Notary Signature of the receipt. |
hexBinary
|