Because the 402-Receipts system is designed to be used passively by the human user, we mostly speak in terms of the Client (the web-browser).
The Client is an HTTPS client requesting a resource for which a receipt is required. Typically the Client will be a web browser being used by a human to view websites.
It needs to detect 402 Responses and parse the attached Receipt Definitions so that it can obtain the necessary receipts.
It needs to compose the Receipt and communicate with the Notary to get it signed. Finally, it will include the Receipt in the Header of the HTTPS request.
Existing web browsers don’t have the behavior defined in this standard, so the user will need to install a browser plugin.
A wallet is a (presumably encrypted, etc) storage location separate from the Client where receipts owned by a user can be stored for reuse. This is necessary specifically because users will want to reuse receipts across devices.
The Host is the computer (the server) which provides the web pages to the Client. The Host is not exactly just “the website”, although this is an OK layperson’s approximation.
The Host is, by definition, the server receiving the HTTPS request with the
This standard specifies further responsibilities for the Host leading up to such a request and in how such requests should be handled.
It is the Host’s responsibility to validate incoming receipts; they must accept any receipt satisfying the Receipt Definition published for the given resource. If appropriate Receipts are provided, then the Host will respond like any other HTTPS host. If the Receipt is missing, inappropriate, or invalid, then the the Host will give an informative 402 Response.
We assume that the Host’s address will match the
domain (and often
item) of the Bare Receipt, and this may be enforced by the Client or Notary.
A fully static host will not be suitable for this standard because validating receipts and saving them for
future reimbursement is critical to the process.
At absolute minimum the host will need to be able to strip the identifying key and signature and forward the receipt and Notary signature to the Notary;
otherwise the Notary would never know to pay the Host.
In practice, the Host should also be obliged to validate the receipt as part of request handling, and the Host should not forward the receipt until handling of the HTTPS request in question has finished. Submitting receipts to the Notary in batches (for example, every hour) can (in conjunction with some defensive behavior on the part of the Clients) prevent deanonymization of Receipts by timing analysis.
The Notary is a third party, analogous to a traditional monetization platform but fundamentally less powerful. The Notary sells Receipts to Clients; the Receipts are used to access websites.
The Notary signs the receipt.
It is up to the parties involved to agree in advance what is promised when a receipt is signed; here we assume that the Notary has collected the money in question from the Client and will forward those funds to the Host by some outside channel. In this sense the “Notary” is properly thought of as a “Broker”.
Of course it’s the Notary’s responsibility to make themselves valuable to the other parties, but it’s illuminating to explain here some of the ways they might do that.
- The Notary will generally relieve the Host of payment processing complexity, and account-management more generally.
- When a Host joins a Notary’s network, they hope to receive payments from a wide audience of consumers; the Host can focus on traffic and audience retention instead of a sales funnel.
- The Notary can protect the Client from abusive Hosts in various ways, including proactive monitoring of member Hosts and post-hoc remediation. (Point-of-sale protections are generally not feasible for the Notary, as receipt signatures are issued blindly. Such protections can be built into the Wallet.)
- For a Client to set up an account with a given Notary generally constitutes pre-authorization of certain kinds of payments for certain kinds of resources. In this sense Notaries act like “channels” to which a user can subscribe.
In practice, we only anticipate two kinds of Notaries.
- A Host could be their own Notary. This could accomplish any of the same functionalities as existing paywalls offer, although the standardized machine interface would enable smoother user-experiences.
- A Notary can act as a network, channel, buyer’s club, or federation. Many Hosts and many Clients are assumed to have prior arrangements (accounts) with a given Notary; this is the Notary’s network. As long as a Host and Client have a network in common, payment for resources can typically proceed automatically.
Notaries with larger networks will obviously have an advantage toward attracting new members of both kinds.
On the one hand, the variety of use-cases this standard can accommodate, and the variety of legal, technical, and business paradigms people operate in, will likely ensure a plurality of Notaries. On the other hand, it is still desirable to include protections against the Notaries. Consumers are presumed to have given their payment processing information (a debit card, for example) directly to the Notary, but privacy of their data can still be protected by insisting on a blind-signature scheme, and by proper design of Wallets and Clients. Producers (Hosts) can best be protected by making sure self-Notarization is a viable option (although this does put the onus of payment processing back in their lap).
A Notary is required to expose a canonical URL endpoint by which they can be identified, and which is sufficient to interact with that Notary.
- A GET request to the canonical URL should return an HTML page which a human could use to complete a purchase and obtain a receipt.
In practice this page would probably also prompt the user to open an account with the Notary.
TODO: specify how a receipt could be passed into this page from the URL hash for blind-signing and how the Notary's signature would be communicated back to the Client.
- A POST request to the canonical URL is used to obtain a Notary Signature;
a signature with a pre-approved Client’s private key should be sufficient authentication for this.
TODO: the details of this process will be filled in as the cryptographic details of receipt signing are determined.
- A PUT request to the canonical URL is used by the Host to redeem receipts, in batches.