The Proposed 402-Receipts Standard

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 dmn@directmonetization.network.

The name

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.