This is an experimental document that is being actively worked on by the W3C Web Payments Community Group<\/a>. All feedback on this document should be sent to public-webpayments@w3.org<\/a> (archive<\/a>).<\/p>\n\n\n\n If you wish to make comments regarding this document, please send them to public-webpayments@w3.org@w3.org<\/a> (subscribe<\/a>, archives<\/a>).<\/p>\n\n\n\n This document outlines the technology stack and development timeline for the set of technologies being worked on by the Web Payments Community Group. It is intended for those people that want to understand all of the technical pieces being proposed, how they fit together, and the development timeline for each technology.ISSUE 1<\/p>\n\n\n\n Readers should understand that this roadmap document is a work in progress and while many of the technologies discussed in this document have been implemented and are in production, others may be changed or modified heavily if driven through a standardization track at W3C. This document is a proposed roadmap, not the final roadmap for version 1.0.<\/p>\n\n\n\n A common question that’s raised when someone is introduced to the Web Payments work is whether or not a particular payment technology, like blockchain-based ledgers, are supported or whether their existence invalidates the specification stack that is being proposed. In general, the realization that the Web Payments Community Group has come to over the many years that it has been operating is that there will never be only one way of doing payments. Therefore, the specifications that are being proposed do not assume a single dominating payment instrument or technology. Instead, the specifications focus on the more general mechanisms that are required to express a transaction and not the specifics that move value from one account to another. For example, the technology proposed by this group primarily focuses on the following:<\/p>\n\n\n\n The Web Payments Community Group realizes the importance of supporting the current payment instruments that exist today (e.g. credit cards, ACH, electronic checks, etc.) as well as the established value benchmarks (e.g. WM Reuters Spot Rate) while also ensuring that the proposed technologies take other more future-facing solutions into account (e.g. blockchains, sidechains, smart contracts, DAOs, etc.) as well as new methods for algorithmic pricing and benchmarking. Rather than hard-coding each of these technologies into the Web Payments specifications, we take a more general approach. Each one of these current and future systems and technologies is supported in a generic way in order to ensure that the specifications remain as agnostic as possible to the underlying operation of each payment instrument, value benchmark, and payment clearing technology.<\/p>\n\n\n\n The Web Payments technology stack is designed on generally accepted design principles outlined for the Architecture of the World Wide Web[WEBARCH<\/a>]. It also heavily re-uses W3C and IETF technology, such as JSON-LD [JSON-LD-SYNTAX<\/a>] and HTTP [RFC7230<\/a>]. A high-level diagram of the technology stack is shown below for reference:<\/p>\n\n\n\n A description of the technologies shown in the diagram above is provided for those that may be unfamiliar with the technologies:Javascript Object Notation [RFC4627<\/a>]JavaScript Object Notation (JSON) is a text format for the serialization of structured data. JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays). It is a very popular format among Web developers.HyperText Transport Protocol [RFC7230<\/a>]The Hypertext Transfer Protocol (HTTP) is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do not need to be aware of each client’s purpose: an HTTP request can be considered in isolation rather than being associated with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used effectively in many different contexts and for which implementations can evolve independently over time.JSON for Linking Data [JSON-LD-SYNTAX<\/a>]JSON-LD is a lightweight syntax to serialize Linked Data in JSON [RFC4627<\/a>]. Its design allows existing JSON to be interpreted as Linked Data with minimal changes. JSON-LD is primarily intended to be a way to use Linked Data in Web-based programming environments, to build interoperable Web services, and to store Linked Data in JSON-based storage engines.Signing HTTP Messages [HTTP-SIGNATURES<\/a>]When communicating over the Internet using the HTTP protocol, it can be desirable for a server or client to authenticate the sender of a particular message. It can also be desirable to ensure that the message was not tampered with during transit. The “Signing HTTP Messages” specification describes a way for servers and clients to simultaneously add authentication and message integrity to HTTP messages by using a digital signature.RDF Dataset Normalization [RDF-NORMALIZATION<\/a>]RDF (which JSON-LD uses) utilizes a graph-based data model for making claims about the world and provides the foundation for reasoning upon that graph of information. At times, it becomes necessary to compare the differences between graphs, digitally sign graphs, or generate short identifiers for graphs via hashing algorithms. RDF Dataset Normalization outlines an algorithm for normalizing RDF graphs such that these operations can be performed on the normalized graphs.Secure Messaging [SECURE-MESSAGING<\/a>]The Secure Messaging specification describes a simple, decentralized security infrastructure for the Web based on public key cryptography. This system enables Web applications to establish identities for agents on the Web, associate security credentials with those identities, and then use those security credentials to send and receive messages that are both encrypted and verifiable via digital signatures.Web Commerce [WEB-COMMERCE<\/a>]In order to support standardized commerce over the Web, it is vital that product offers and the result of purchases can be expressed in a simple manner. This specification enables the decentralized offer of products and services for sale and the transaction process resulting in a digitally verifiable receipt between the buyer and the vendor.Identity Credentials [IDENTITY-CREDENTIALS<\/a>]An identity is a description of a particular entity such as a person, software agent, or organization. A credential is a qualification, achievement, quality, or information about an identity’s background such as a name, government ID, home address, or university degree. The Identity Credentials specification describes mechanisms for reading credentials from and writing credentials to an identity while ensuring that the information is only accessible to authorized applications.Web Commerce API [WEB-COMMERCE-API<\/a>]This specification outlines a browser polyfill that makes financial transactions easier to initiate and verify while also making them more secure. The solution is designed to work with both proprietary (PayPal, Google Wallet) and non-proprietary (PaySwarm, Bitcoin, Ripple) payment solutions.<\/p>\n\n\n\n The technologies proposed by the group are layered in such a way to allow the base technologies to be re-used by other Web-based standards. Thus, there is a natural order of progression in developing these technologies, from low-level to high-level:<\/p>\n\n\n\n [HTTP-SIGNATURES]Mark Cavage; Manu Sporny. IETF. HTTP Signatures<\/a>. 4 May 2013. W3C Working Draft. URL: https:\/\/datatracker.ietf.org\/doc\/html\/draft-cavage-http-signatures<\/a>[IDENTITY-CREDENTIALS]Manu Sporny; Dave Longley. W3C Credentials Community Group. Identity Credentials<\/a>. CG-DRAFT. URL: http:\/\/opencreds.org\/specs\/source\/identity-credentials\/<\/a>[JSON-LD-SYNTAX]Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. JSON-LD 1.0<\/a>. 3 November 2020. W3C Recommendation. URL: https:\/\/www.w3.org\/TR\/json-ld\/<\/a>[RDF-NORMALIZATION]Dave Longley; Manu Sporny. W3C JSON for Linking Data Community Group. RDF Dataset Normalization<\/a>. CG-DRAFT. URL: http:\/\/json-ld.org\/spec\/latest\/rdf-graph-normalization\/<\/a>[RFC4627]D. Crockford. IETF. The application\/json Media Type for JavaScript Object Notation (JSON)<\/a>. July 2006. Informational. URL: https:\/\/datatracker.ietf.org\/doc\/html\/rfc4627<\/a>[RFC7230]R. Fielding, Ed.; J. Reschke, Ed.. IETF. Hypertext Transfer Protocol (HTTP\/1.1): Message Syntax and Routing<\/a>. June 2014. Proposed Standard. URL: https:\/\/httpwg.org\/specs\/rfc7230.html<\/a>[SECURE-MESSAGING]Dave Longley; Manu Sporny; David I. Lehn. W3C Web Payments Community Group. Secure Messaging<\/a>. CG-DRAFT. URL: https:\/\/web-payments.org\/specs\/source\/secure-messaging\/<\/a>[WEB-COMMERCE]Dave Longley; Manu Sporny; David I. Lehn. W3C Web Payments Community Group. Web Commerce<\/a>. CG-DRAFT. URL: https:\/\/web-payments.org\/specs\/source\/web-commerce\/<\/a>[WEB-COMMERCE-API]Manu Sporny; Dave Longley; David I. Lehn. W3C Web Payments Community Group. Web Commerce API<\/a>. CG-DRAFT. URL: https:\/\/web-payments.org\/specs\/source\/web-commerce-api\/<\/a>[WEBARCH]Ian Jacobs; Norman Walsh. W3C. Architecture of the World Wide Web, Volume One<\/a>. 15 December 2004. W3C Recommendation. URL: https:\/\/www.w3.org\/TR\/webarch\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"table of contents<\/h2>\n\n\n\n
1. Introduction<\/h2>\n\n\n\n
![\"web](\"https:\/\/wordpress-502921-2292315.cloudwaysapps.com\/wp-content\/uploads\/2021\/05\/2021-05-28_20-48-24-1024x505.jpg\")
2. Technology Stack<\/h2>\n\n\n\n
![\"\"](\"https:\/\/wordpress-502921-2292315.cloudwaysapps.com\/wp-content\/uploads\/2021\/05\/2021-05-28_20-48-24-1-1024x505.jpg\")
3. Timeline<\/h2>\n\n\n\n
![\"\"](\"https:\/\/wordpress-502921-2292315.cloudwaysapps.com\/wp-content\/uploads\/2021\/05\/2021-05-01_23-31-24.webp\")
<\/figure>\n\n\n\n4. Active Collaborators<\/h2>\n\n\n\n
![\"\"](\"https:\/\/wordpress-502921-2292315.cloudwaysapps.com\/wp-content\/uploads\/2021\/05\/2021-05-01_23-28-35-1024x466.webp\")
<\/figure><\/div>\n\n\n\nA. References<\/h2>\n\n\n\n
A.1 Informative references<\/h3>\n\n\n\n