Version negative one.
This document describes a standard way for a website to demand or accept payment for access to resources without having a prior relationship with the customer or at any point collecting any card/bank information. The proposed standard is a suite of HTTPS headers, HTML head elements, and surrounding utilities to make direct monetization of web-accessible resources low-stress and safe even for non-specialist human users.
Goal of this document:
This standard needs to be sufficiently defined that tools within it can be built independently and work together. It must be a suitable tool for producers and consumers, so if you have questions, ideas, or suggestions about the technical details or about the high-level user experience then please reach out to us.
Once the standard is complete in the sense of describing a workable protocol from end to end, we will declare Version 0.0 so that people can start implementing it.
How to help
This website is on GitHub; pull requests are welcome. You can also email us with questions or suggestions at email@example.com.
The 402 HTTPS response code implies that a request is being denied because payment must be provided for the requested resource. No standard way of following up to a 402 response has been normalized. The 402 response code has seen only niche usage, mostly for subscription-only APIs, and is effectively non-standard for human-facing HTTPS resources. This standard will fix that.
Table of contents:
Overview — An overall summary of how the system works.
Parties — Describes the roles of the Client, the Host, and the Notary. Also outlines the behavior of the tools they’ll use.
HTTP Components — Documentation of HTTPS headers and response codes used in the 402-Receipt Proposed standard.
Receipt Definitions — Explains what Receipts will be required or accepted when accessing a resource. Includes the XML schema.
Receipts — Describes Receipt documents and the blind-validation scheme for them. Includes the XML schema.
Blind Signatures — Describes the RSA Blind Signature scheme used, and links to a reference implementation.
Compression — Exact specification of how larger objects should be compressed, for example for use in HTTPS headers.