Internet of Value Community Group charter

DRAFT: This CG has not yet been chartered, this charter is under discussion

Charter

• This Charter: {TBD: URI}
• Previous Charter: {TBD: URI}
• Start Date: 1 August 2015

Goals

The primary goal of the Internet of Value Community group is connecting the many payment networks around the world via the Web. The group's vision is an open, universal payment scheme built on Web standards that allows any payer to pay any payee regardless of the payer’s choice of payment instrument or the payee’s account.

NOTE: The group does not intend to limit itself to the exchange of value in the form of money but rather any digital asset that can practically be exchanged or used as a means of "payment".

Payment Schemes

All electronic payments today are executed under the rules and standards of a payment scheme. Payment schemes are set up by regional or domestic bodies or even by companies such as payment processors or networks.

Payment schemes define rules and technical standards (rule-books) which provide a common understanding on how to move funds from account A to account B.

Rulebooks for clearing and settlement generally include:

• Formats and protocols for messaging between participants
• Rules for the finalization of clearing and availability of funds
• Processes and timelines for the final settlement of funds between the participants

Traditionally payment schemes have evolved on the back of closed and proprietary payment networks as a means to define business rules on top of the network's infrastructure.

Web Payments

The broader goal of the Internet of Value Community Group is to leverage the ubiquity and decentralized architecture of the Web and define a payments scheme that connects the many existing schemes in much the same way that the Internet has connected private networks globally for the exchange of information. With such a scheme in place it will be possible for anyone on the Web to pay anyone else by moving value between existing payment networks using the rules and processes of this new scheme.

Vision

The group will define and publish a vision for the Internet of Value. The Internet of Value Manifesto is a draft document that provides a starting point for the group.

Scope of Work

A theoretical framework for a universal payments scheme is being documented in a technical whitepaper edited by members of the group.

The white paper describes a mechanism for creating broader payment system inter-operability by connecting payment networks (ledgers), both open and closed.

The group will focus on developing standards that can be implemented to bring this theory to life.

Out of Scope

This group will not address integration of payment schemes into user agents (for that is the scope of the proposed Web Payments Working Group).

Deliverables

Community Group Reports that are Specifications

The group will produce the necessary rulesets and process documents to define a new payments scheme that connects existing schemes and networks.

Community Group Reports that are not Specifications

The group may produce other Community Group Reports within the scope of this charter but that are not Specifications, for instance use cases, permission ceremonies, security hardening reports, etc.

Test Suites and Other Software

At present, there are no plans to create a test suite. If, however, the CG decides to develop a test suite, it will be developed in Open Source using the W3C Software License.

Dependencies or Liaisons

• W3C Web Payments Interest Group (specifically the Internet of Value Task Force)
• W3C Credentials Community Group
• W3C CryptoLedgers Community Group

Community and Business Group Process

Terms of in this charter that conflict with those of the Community and Business Group Process are void.

Work Limited to Charter Scope

The group will not publish Community Group Reports that are Specifications on topics other than those listed under "Community Group Reports that are Specifications" above. See below for how to modify the charter.

Contribution Mechanics

Who can make a Contribution

Contributions can only be made by Community Group Participants (so all Contributors have agreed to the CLA). Particular care must be taken by Chairs and Editors to ensure Contributions of content that is implementable comes from Community Group participants.

How to make a Contribution

Community Group Participants agree that all Contributions will be documented in pull requests and commits for a particular document in the group's GitHub repository.

Specifications

For Contributions to Specifications, if someone other than the Contributor makes the pull request, the pull request should indicate who the request was made on behalf of and should provide a reference to the relevant archived GitHub Issue or group mail thread where practical. The information should be specific enough to identify the Contributor easily as well as a clear intention to Contribute to a particular Specification.

If you are not the sole contributor to a contribution (pull request), please identify all contributors in the commit message. In the commit, include on a new line,

Contributors: +@githubusername1, +@githubusername2, ...

Software

For software, the GitHub CONTRIBUTING.md and LICENSE.md files describe how to Contribute and the license under which Contributions are made

Transparency

The group will conduct all of its technical work in public via the group's public mailing list and GitHub issues lists. For convenience, GitHub issues and pull requests will be archived to the group's contrib list. Other contributions may be directly posted to the contrib list.

Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the group's public mailing list.

Decision Process

Consensus Decisions

This group will seek consensus decisions. After discussion (via the mailing list or issues list) and due consideration of different opinions, the Chair should record a decision and any objections.

A common way to determine consensus for important decisions is to conduct a Call for Consensus (CfC) where the Chair puts a proposal to the group on the public mail list and asks for feedback from the Participants within some period of time that is at least 7 days. Silence implies consent. Direct feedback is encouraged, especially to weigh the degree of consensus when there is dissent.

When the group reaches a decision at a meeting, the decision is tentative. Any group participant may object to a decision reached at a meeting within 7 days of publication of the decision on the mailing list. That decision must then be confirmed on the mailing list.

Voting

Participants may call for an formal vote if they feel the Chair has not accurately determined the consensus of the group, or if the Chair refuses to assess consensus. This should be a rare event, only where the usual, less formal means of making decisions are not accepted. At least 5 Participants, no two from the same organization (or 50% of the organizations and individuals, whichever is smaller), must agree with the call for a formal vote. The call for a vote must specify the duration of the vote which must be at least 7 days and should be no more than 14 days. The Chair must start the vote within 7 days of the request, or group members may start it themselves. The decision is based on the majority of the ballots cast. It is the Chair's responsibility to ensure that the decision process is fair, respects the consensus of the group, and does not unreasonably favor or discriminate against any group participant or their employer.

Chair Selection

Participants in this group choose their Chair(s) and can replace their Chair(s) at any time using whatever means they prefer.

However, if 5 participants —no two from the same organization— call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777).

1. Participants announce their candidacies. Participants have 14 days to announce their candidacies, but this period ends as soon as all participants have announced their intentions. If there is only one candidate, that person becomes the Chair. If there are two or more candidates, there is a vote. Otherwise, nothing changes.
2. Participants vote. Participants have 21 days to vote for a single candidate, but this period ends as soon as all participants have voted. The individual who receives the most votes —no two from the same organization— is elected chair. In case of a tie, RFC 2777 is used to break the tie. An elected Chair may appoint co-Chairs.

Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.

Amendments to this Charter

The group may 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.