WebPaymentsCommunityGroupCharterProposal

From Web Payments
Jump to: navigation, search

Goals

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:

  • TBD (list of specs go here - we need to vote on which ones the group wants to accept as work items)

Dependencies or Liaisons

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):

  1. 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.
  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.
  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

Amendments to this Charter

  • At present this Charter is under development and discussion. It has not yet been voted on by Community Group members.
  • 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.