Communications Strategy Task Force/Doc Relations

Status: This is a draft for discussion that has no standing within the Web Payments IG. The purpose of this page is to specify the primary (chartered) deliverables of the IG, their intended audiences, and the relationship among them.

All deliverables are intended for both Payment Industry professionals and Web Developers. However, they may vary in technical knowledge (either of the payments world or Web architecture) required to understand them. For that reason, we propose both core deliverables (that will lead to standards work) and complementary materials (to help foster understanding between the two communities).

Questions? Please contact the Interest Group's Communications Strategy Task Force.

Core Deliverables

Please note that these are called out as separate deliverables, but how we implement them (e.g., one or multiple documents) has not been established.

Web Payments WG Charter

• Current draft: Draft Web Payments WG Charter
• Lead: Adrian Hope-Bailie, Ian Jacobs
• Description: Proposed charter for new Web Payments WG.
• Technical Detail: Low
• FAQ: A FAQ has been prepared to summarize discussion around the charter. It is here.

Use Cases

• Current draft: Web Payments Use Cases
• Lead: Manu Sporny
• Description: The IG wishes to define a scope of what it means to them (at a particular point in time) to improve payments on the Web. The IG will establish that scope through a list of stories that briefly describe scenarios at various times of diverse transactions.
• Technical Detail: Low

Architectural Vision

• Current draft: Vision
• Lead: Adrian Hope-Bailie
• Description: The group will then seek to describe at a high level goals for a payments architecture for the Web.
• Technical Detail: Low

Requirements

• Current draft: draft requirements; See also Web Payments Use Cases
• Leads: Ian and Erik
• Description: Requirements --that which is necessary to fulfill the use cases-- will be derived from use cases as well as from more general Web-style requirements for privacy, security, accessibility, internationalization, device-independence, etc. Regulatory requirements (driven by use cases) are included in this work.
• Technical Detail: High

Capabilities

• Current draft: draft arch doc, but some information appears in the priorities wiki
• Leads: Pat and Joerg and Adrian
• Description: Capabilities are functional modules or features that the group deems necessary to satisfy the requirements. The Interest Group will describe capabilities and responsible parties in some detail, but not at the level of detail expected of future Working Groups. Capabilities will range from higher level (e.g., loyalty programs, expression of offers, receipts, discovery of payment instruments, etc.) to lower level and more generally useful (e.g,. identity, authentication, credentials).
• Technical Detail: Medium

Roadmap

• Current draft: Roadmap
• Leads: Ian and Manu
• Description: The roadmap describes our prioritization in fulfilling the requirements, who is responsible for fulfilling (e.g., existing w3c group, proposed new W3C group, or external organization), and on what schedule. See an example roadmap for the mobile web.
• Technical Detail: Low

Glossary

• Current draft: Glossary
• Editor(s): Evert Fekkes
• Description: In order to interoperate with existing standards and models in the payments industry, it is important that we build a shared understanding of terms. The glossary will be shared across other group deliverables. We recognize that there will be a spectrum of terms, and that we may wish to use more technical terms in some contexts and less technical terms in others. The glossary will be the place where meanings come together.
• Technical Detail: Low to High

Supporting Materials

See also the communications strategy for additional deliverables such as slide decks to help communicate the group's work.

Executive Summary

• Current draft: Executive Summary
• Editor(s): Charles McCathieNevile
• Description: The IG recognizes the need to communicate its vision for Web Payments with payment industry professionals, Web developers, media, and other audiences. The Executive Summary will (briefly) describe the group's goals as well as the benefits to various stakeholders (users, merchants, payment processors, banks, etc.) of an Open Web Platform payments infrastructure.
• Technical Detail: Low

Organizing Framework for Use Cases

• Current draft: Framework for organizing use cases
• Editor(s): Ian Jacobs
• Description: The IG charter sets the expectation that the priority will be "to ease payments on the Web for users (payers) and merchants (payees), and to establish a common ground for payment service providers on the Web Platform." With that in mind, it is useful to paint a picture at a high level of the steps of a typical payment. Those steps can then be used to organize the use cases, which will help explain how the use cases fit together, as well as help ensure they are not overlapping, and that we are considering all of the steps necessary for a (standards-based) Web payment.
• Technical Detail: Low

Payment Narrative

• Current draft: Single Narrative for Web Payments Use Cases
• Editor(s): Ian Jacobs
• Description: To help illustrate the (somewhat abstract) steps of a typical transaction, it is useful to have a single narrative that covers all of the steps at a high enough level to be understandable by a very general audience. Once the reader has a solid grasp of the steps of a payment, it will be easier to understand how the use cases have been organized. Note: It may be useful to create a number of these "complete narratives" for different scenarios.
• Technical Detail: Low

Diagrams

• Payment flows
• Payer/Payee interactions (higher level)

Ideas for Organizing Deliverables

Here is one idea (based on conversation On a use cases call:

• Executive Summary
• Use cases, which includes the following:
  • Intro: Organizing framework
  • Short use cases (organized by phases, and enough use cases to cover all the priority scenarios)
  • Appendix: One complete narrative illustrated an important subset of use cases, followed by very brief alternative complete narratives. The purpose of the alternative narratives is so that readers do not think the primary narrative is the only one the group is addressing.
• Architecture and Requirements (in a single document)
• Roadmap
• Glossary