The purpose of the Web Payments Community Group is to discuss, research, document, prototype and test web payment systems. This work is done in order to make progress toward possible future standardization and interoperability of these solutions. The goal of this Group is to forge a path for a secure, decentralized system of web payments that would empower both individual people and organizations on the Web to send and receive money as easily as they exchange instant messages and email today. In addition to documentation, this Group collaborates on and shares various proof-of-concept solutions and components through open source methods, unencumbered by patents or royalties.
The solutions developed in this group may be voted on by its membership via decision-making approaches described by W3C, IETF, or similar standardization bodies.
In general, this Community Group provides an inclusive venue where web payment solutions, regardless of their origin, can be incubated, evaluated, refined, and tested. The focus of the group is to promote payment innovations based primarily on their technical merit. This approach invites competing technical designs to be submitted and incubated in the same group. The hope is that this strategy will lead to either the merging of the best aspects of each technical design, or a clear differentiation emerging between alternative designs.
Scope of Work
In general, the topics that are “in scope” include anything related to enabling interoperable payments on the Web. These topics include:
- The listing of products, assets, and services for sale on the Web/Internet.
- Transaction mechanisms where the Web/Internet is used as the communication medium.
- Digital receipt and digital contract data formats and protocols.
- Identity and privacy technologies as they relate to ensuring the proper identification and protection of parties engaging in the exchange of goods, assets, services, or value.
- Security as it relates to ensuring the proper end-to-end protection and authenticity of the exchange of goods, assets, services, or value.
- Methods to accommodate transaction currency choice and single-currency/multi-currency price management in association with listings.
- Technologies that are vital for the proper operation of the solutions listed above, but that are not incubated via any other standardization body under a W3C-compatible licensing mechanism.
- Bridging open payment methods and protocols with restricted payment methods and protocols.
- Legal, regulatory, and policy concerns that affect the successful deployment of any of the use cases or technology concepts listed above.
In general, the topics that are “out of scope” involve anything not directly related to enabling interoperable payments on the Web. Some examples of these topics are:
- The relative merits of various economic, political or sociological theories. (i.e. The focus of this Community Group is on Web-based financial transaction methods under any economic, political or sociological scenario.)
- The relative merits of various currencies or units of account. (i.e. The focus of this Community Group is on Web-based financial transaction methods with any currencies or units of account as determined by users.)
- Marketing or evangelizing of technologies not intended to be released under a license compatible with W3C specifications. (Discussion of restricted solutions should be limited to elaborating upon technological advantages/disadvantages.)
Work Items
In general, all documents related to payments on the Web are welcome. If there is someone who will commit to being an editor for a document, the group should agree to accept it as a work item even if it conflicts with previous work adopted by the community. Newly-accepted work items that extend beyond the scope of this Community Group Charter will lead to a reconsideration of the Charter. The Community Group may vote to revise the Charter in order to include new work, or to determine that the proposed work is unrelated to Web Payments.
The following work items have been included by members of the Web Payments Community Group:
- Web Payments Design Principles – An outline of the design principles and general philosophy used to guide the standards making process behind the technology that the Web Payments group creates. The principles are meant to be a set of general guidelines rather than a set of prescriptive rules.
- Web Payments Use Cases – The primary goal of the Web Payments work is to empower individual people or organizations on the Web to send and receive money as easily as they exchange instant messages and email today. The solutions should establish safe, decentralized systems and be open and unencumbered by patents and royalties. The following use cases focus on concrete scenarios that the technology created by the group should enable.
- Web Payments – The base layer of the Web Payments architecture; enables the creation of a monetary transaction between two participants on the Web. This enables a person or organization to send money to another entity via the Web. The specification also includes Linked Data vocabularies covering commerce and payments (aka PaySwarm).
- Web Commerce – The electronic commerce portion of the Web Payments architecture; enabling the decentralized listing of assets for sale and the transaction of those assets resulting in a digitally verifiable receipt between the buyer and the vendor. This enables a vendor to list an item for sale on the Web, have a buyer purchase that item via the Web, and the purchase result in a detailed digital receipt of the sale. The work also includes Linked Data vocabularies covering commerce, credit cards, payments, and security.
- Price Benchmarking – Vendors can select one of the available online price indexing services, which could be a currency exchange rate, or another type of index more relevant to the scope and dynamics of their particular business that would enable greater price stability, variability with key input prices, or some other criterion. For example, a baker could tie the price of their goods to an index that takes the price of wheat, water, and energy (the primary inputs for their product) into account when listing prices to their customers.
- Crowdfunding – This specification details how decentralized, open crowd-funding works over the Web. This is the “parameterized transactions” layer of the Web Payments architecture. This enables anyone with a web page to be able to crowdfund in a standard way.
- Web Identity – A decentralized read/write identity mechanism for the Web that allows arbitrary Linked Data to be read from and written to an identity URL. This enables things like age verification, and “Know Your Customer” assertions (required by most national banking regulation) for the Web. This is designed to integrate with one-click Web login mechanisms like Mozilla Persona and potentially OpenID and is not a replacement for those solutions.
- Secure Messaging – A secure and verifiable messaging mechanism built using Linked Data principles to produce a distributed Public Key Infrastructure for the Web. This enables financial transactions and the data associated with them to be protected in a way that is easy for Web Developers to understand and implement. This work also includes a Linked Data security vocabulary.
- HTTP Signatures – A digital signature mechanism for the HTTP protocol that adds origin authentication and message integrity to HTTP requests. The work also includes a complete security audit of the HTTP Signatures specification. This enables the Web Payments clients to operate as an agent for people – unattended operation, finding and negotiating prices, automatically managing repetitive financial tasks (billpay), and in general, performing algorithmic transactions. Specifications covering HTTP Signature Nonces and HTTP Signature Trailers are also included in the work, but are a much lower priority since the Web Payments work does not depend on that functionality.
Dependencies or Liaisons
- Potential Future Web Payments Working Group – The Web Payments Community Group will incubate and experiment with draft solutions, specifications, and technologies before writing technical reports that may be voted on by the group to be proposed for standardization via a yet-to-be-established Web Payments Working Group.
- Multilateral, Central and Commercial Banks (incl. US Federal Reserve)
- World Chambers Network and the International Chamber of Commerce
- World Association for Small and Medium Enterprises
- International Federation of Purchasing and Supply Management
- International Consumer Protection and Enforcement Network (ICPEN)
- econsumer.gov (working to enhance consumer protection and consumer confidence in e-commerce)
- IETF HTTPbis and HTTPauth Working Groups
- W3C Web Crypto Working Group
- Mozilla Persona / FirefoxID Community
- W3C Open Digital Rights Language (ODRL) Community Group
- W3C Web Security Interest Group
- W3C Web Apps Working Group
- W3C Web and Mobile Interest Group
- W3C Web and TV Interest Group
- W3C Web and Broadcasting Business Group
- W3C The Web Schemas Task Force of the W3C Semantic Web Interest Group
- GoodRelations Web Vocabulary for e-Commerce
- Research Institutions contributing to the field of Web payments (Academic, Industry, Governmental)
Community Group Process
Anything in this charter that conflicts with requirements of the Community and Business Group Process is void.
Choosing a Chair
- A Chair’s duties include:
- Driving inclusivity, identifying consensus within the group, and recording decisions.
- Ensuring compliance with all W3C rules applicable to the group.
- Being a liaison between the group and all groups with which the group is coordinating.
- Organizing the smooth operation of the group.
- Engaging with media, performing outreach, and ensuring the transparent operation of the group.
- Chairs are elected by the group for a 2 year term. There may be up to two Chairs at any given time. There are no limits to how often chairs can be re-elected by the group.
- For an individual to run for election, they must be nominated by at least two people (other than themselves or an acting chair) and agree to the nomination. The nomination period lasts 14 days. Once an election date is set, each candidate has one week to submit a position statement about their qualifications to chair the group. The voting poll will stay open for a minimum of 14 days and the candidate with the most votes wins. If there is only one candidate at the end of the 14 day nomination period, that person immediately becomes the chair.
- Chairs may be removed from their duties through a simple no-confidence vote. The no confidence vote must be requested by at least 3 members of the group and the vote will carry if 2/3rds of the votes cast request that the Chair is removed. A Chair who has been removed may stand for re-election.
Decision process
The decision making process goes through three possible steps and a decision is accepted as soon as it passes the requirements of any of the steps (in the following order):
- Working Consensus – When general agreement is found with no members being “strongly opposed” to a particular straw poll. Routine decisions can be made via discussion on the mailing list, without formal votes. If working consensus cannot be reached, then proceed to step 2.
- Chair Decision – When working consensus has not yet been reached, the Chair will propose that the matter be discussed further via the mailing list or will convene a conference call. When the group discusses an issue on the mailing list or a conference call, and there is a request from a member for assessing consensus, after due consideration of different opinions, the Chair should record a decision and any objections (with reasons if these have been expressed). If at least 3 members agree to take the matter to a formal vote, then proceed to step 3.
- Formal Vote – When all efforts to achieve working consensus fail and the Chair or various members consider that a determination must be made within limited time. Three participants may call to set aside “working consensus” on an specific written issue, and to initiate a simple majority vote. (This includes if they feel the Chair has not accurately determined the votes of the group or if they feel the Chair has refused to assess consensus.) Only members of the Community Group prior to this initial call for a vote may participate in the vote. Within 7 days of such a request, the Chair must announce the start and end dates, and the venue for the vote. Such a vote must be open at least 7 days and should be no more than 14 days, using a structured online voting solution, ensuring that no member votes more than once. In these cases, a decision shall be based on a simple majority of the votes cast (more than 50%).
The Chair is accountable to both the W3C and to Community Group members to ensure that all deliberation and decision processes are fair, respectful, aligned with these guidelines, and neither favouring or discriminating against any participant or their associates (incl. employer).
Transparency
- The group will conduct all of its work on its public mailing list and the public weekly teleconference.
- Any decisions reached at any face to face meeting are tentative and must be confirmed on the mailing list.
Amendments to this Charter
- The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process.
- The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.
- Changes to the Dependencies and Liasons list does not constitute an amendment to the charter that requires a rechartering vote.