--- a/latest/charters/payments-wg-charter.html Mon Jul 13 13:19:05 2015 -0400
+++ b/latest/charters/payments-wg-charter.html Mon Jul 13 13:32:25 2015 -0700
@@ -112,9 +112,12 @@
<li>Increased scope for <a href="#wallets">digital wallet</a> innovation by banks, retailers, mobile operators,
card networks, and other wallet providers.
</li>
+ <li>Lower costs for merchants due to increased competition between payment instrument providers and easier
+ adoption of new instruments.
+ </li>
<li>Added value through machine-readable digital payment requests and payment responses.</li>
</ul>
- <p>The W3C is also planning other Working Groups to develop standards, on topics such as security, that will
+ <p>The W3C is also planning other Working Groups to develop standards, covering topics such as security, that will
facilitate payments on the Web.</p>
<p>
@@ -130,31 +133,34 @@
manually select a payment scheme, manually select their own <strong>payment instrument</strong> for that
payment scheme, manually capture the details of that instrument into the page (along with any other
essential data such as a shipping address) and then submit this data back to the <strong>payee.</strong> The
- payment data briefly passes through the Web (from the payer's user agent to the payee's Website) on it's way
+ payment data briefly passes through the Web (from the payer's user agent to the payee's Website) on its way
to a payment processor. At that point, much of the communication to complete a payment takes place among
banks, card networks, and other parties in the payment ecosystem typically outside of the Web.</p>
<p>In an effort to improve upon this process, various parties have innovated ways to make the payment flow
easier, for example by caching payment instrument information in browsers, registering users on eCommerce
websites to facilitate re-use of customer data and/or payment credentials, and even developing new payment
- schemes. Unfortunately, these efforts all suffer from a lack of standardization of the high level flow of a
- Web payment, of the interfaces between the various parties, the user agent and the Web application, or of
- the messages exchanged between these parties over the Web.</p>
+ schemes. Unfortunately, these efforts all suffer from a lack of standardization. Standardization of the high
+ level flow of a Web payment, of the interfaces between the various parties (example: the user agent and the
+ Web
+ application) or of the messages exchanged between these parties over the Web.</p>
- <p>This group will create open Web standards for the interfaces in and out of the Web context to provide
+ <p>This group will create open Web standards for the <em>interfaces</em> in and out of the Web context to
+ provide
interoperability between payer and payee systems (for existing and future payment schemes), and encourage
greater automation of the steps in a typical payment. The interfaces between the payment schemes and the Web
- are via the user agent and the Web application, therefore the scope of the initial charter is focused on the
- interactions between these two components and the external actors that will interface directly with
+ are usually at the user agent and the Web application, therefore the scope of the initial charter is focused
+ on the interactions between these two components and the external actors that will interface directly with
them.</p>
- <p>The group will focus primarily on standardisation of a set of messages and a message flow for the initiation.
+ <p>The group will focus primarily on standardisation of a set of messages and a message flow for the initiation,
confirmation and completion of a payment. By focusing on the message format and flow the group leaves open
the standardisation of the delivery mechanism for these messages as this will vary depending on the use case
- and technology stack. The group will aim to standardise the delivery mechanism for common scenarios such as
- WebIDL APIs for the use cases where the messages are proxied between payer and payee via a Web browser or
- Web APIs where the messages are exchanged directly over the Web between two online entities in the classic
- REST pattern.</p>
+ and technology stack. To support use cases where messages are proxied between payer and payee using
+ different technologies, the group will aim to standardize delivery mechanisms for common scenarios. This
+ will include WebIDL APIs for the use cases where the messages are proxied between payer and payee via a Web
+ browser or Web APIs where the messages are exchanged directly over the Web between two online entities in
+ the classic REST pattern.</p>
<p><strong>Note:</strong> W3C expects to deal with a wider variety of of eCommerce scenarios over time,
including digital receipts; loyalty programs and coupons; peer-to-peer payments; and harmonization of user
@@ -217,46 +223,57 @@
</ul>
</dd>
</dl>
+
+ <figure>
+ <figcaption><strong>Figure 1:</strong> An example basic payment flow where messages are proxied via a user
+ agent.
+ </figcaption>
+ <img src="images/WebPaymentsBasicPaymentFlow.png" alt="Web Payments Basic Payment Flow"/>
+ </figure>
+
<p>The group will also address exceptions that may occur during these steps, including payment authorization
failure.</p>
<h3 id="security">Security and Privacy Considerations</h3>
- <p>Security is obviously critical in payments and while the initial work of the group will leave much of the
+ <p>Security is obviously critical in payments. While the initial work of the group will leave much of the
required security and authentication to the payment schemes it is important to ensure that any additions to
the Web platform are secure and tamper-proof. The ability to manipulate any message in a payment flow has
- potentially massive financial impact therefore message integrity and verification of all message originators
- should be a key consideration for any work done by the group.</p>
+ potentially massive financial impact. Therefore the ability to prove message integrity and verification of
+ all message originators should be a key consideration for any work done by the group.</p>
<p>Protection of the privacy of all participants in a payment is essential to maintaining the trust that payment
- systems are dependent upon to function. Any payment process defined by the group should not disclose private
- details of the participants identity or other sensitive information without their explicit consent and the
- design of any public facing API should ensure it is not possible for such data to be leaked through
- exploitation of the API.</p>
+ systems are dependent upon to function. Any payment process defined by the group should not require
+ disclosure of private details of any of the participants' identity or other sensitive information without
+ their explicit consent. The design of any public facing API should ensure it is not possible for such
+ data to be leaked through exploitation of the API.</p>
<h3 id="out_of_scope">Out of Scope</h3>
<p>This group will not define a new payment scheme, or redefine that which is already addressed today by payment
schemes. The standards from this group will provide a channel for protocols and messages defined by payment
- schemes, or that can be used across payment schemes.</p>
+ schemes.</p>
</div>
<div>
<h2 id="wallets">Wallets</h2>
- <p>The standards from this group may be implemented in a variety of ways, including as stand-alone applications,
- in the cloud, or within user agents such as browsers. Some of the functionality provided by the standards
- from this group can be found in various Web services today, as well as in digital wallets. Because the
- "digital wallet" concept can be useful as a shorthand, but means different things to different audiences,
- this charter includes a definition to clarify the intent of this group.</p>
+ <p>The standards from this group may be implemented in a variety of ways, including within native applications,
+ applications in the cloud, or user agents such as Web browsers. Some of the capabilities provided by the
+ standards from this group can be found in various Web services today, as well as in digital wallets. Because
+ the "digital wallet" concept is useful as a shorthand, but means different things to different
+ audiences, this charter includes the following definition to clarify the intent of this group.</p>
<p>In this charter we define a <strong>wallet</strong> as a software service, providing similar functions in the
digital world to those provided by a physical wallet, namely:</p>
<ul>
- <li>It holds payment instruments registered by the wallet owner.</li>
- <li>It supports certain payment schemes and enables the payer to use registered payment instruments to
- execute a payment in accordance with that scheme.
+ <li>It holds and allows access to payment instruments registered by the wallet owner.</li>
+ <li>It provides logic to support certain payment schemes and enables the payer to use registered payment
+ instruments to
+ execute a payment in accordance with the rules and processes of that scheme.
</li>
- <li>It may hold one or more balances of some digital asset that can be used to make payments.</li>
+ <li>It may hold digital assets, in the form of one or more account balances, that can be used to make
+ payments.
+ </li>
</ul>
<p>This definition of wallet may expand in the future to include other items people find in physical wallets
such as digital receipts, coupons, and identification. What the group defines today as a wallet service may
@@ -265,8 +282,9 @@
this service may be expected to provide under future versions of any standards produced by the group.</p>
<p>The group intends to create a standard interface from the Web to a user's wallet so that a user with any
- conforming wallet can seamlessly make payments with any conforming Web application running in a conforming
- user agent. The group may define APIs that will also be used outside of a browser context (such as between
+ conforming wallet can seamlessly make payments with any conforming application running in a conforming
+ user agent. The group may define APIs that will also be used outside of a user agent context (such as
+ between
Web services, or from within a native application, where the browser is not the proxy between wallet and
payee application).</p>
@@ -276,11 +294,11 @@
instruments the user has available.</p>
<p>
- <strong>Note:</strong> The Working Group anticipates a rich ecosystem of eCommerce and payment functionality,
- including loyalty schemes and coupons, digital receipts, location services, marketing additions, and so on.
- Some of this functionality may be provided by a digital wallet, or by other aggregating services available
- to the user. This charter does not seek to preclude those additional services, and in the future W3C may
- look for standardization opportunities to increase interoperability of such services.</p>
+ <strong>Note:</strong> The Working Group anticipates a rich ecosystem of eCommerce and payment
+ functionality, including loyalty schemes and coupons, digital receipts, location services, marketing
+ additions, and so on. Some of this functionality may be provided by a digital wallet, or by other services
+ available to the user. This charter does not seek to preclude those additional services, and in the future
+ W3C may look for opportunities to standardize and increase interoperability of such services.</p>
</div>
<div>
<h2 id="deliverables">Deliverables</h2>
@@ -295,7 +313,7 @@
schemes, and by payers to represent their available payment schemes and instruments.
</li>
<li>
- <strong>Payment Term Description</strong>: used to define the terms requested by the payee in the
+ <strong>Payment Terms Description</strong>: used to define the terms requested by the payee in the
payment initiation request and the terms accepted by the payer in the payment initiation response. It
includes information such as amount, currency, payee account information, recurrence, transaction
reference and any scheme specific data that is required.
@@ -327,7 +345,7 @@
advising of the result of a payee initiated payment.
</li>
</ul>
- <p>The Working group will standardise the delivery mechanism for these messages in at least the following
+ <p>The Working group will standardize the delivery mechanism for these messages in at least the following
scenarios:</p>
<ul>
<li><strong><a href="http://www.w3.org/TR/WebIDL/">WebIDL</a> API</strong>: Where the payment messages may
@@ -338,7 +356,7 @@
via that service's REST API endpoint(s) and where HTTP callbacks may be used to pass responses to other
Web services.
</li>
- <li><strong>Inter-app on mobile devices (Optional)</strong>: If possible the group will standardise a
+ <li><strong>Inter-app on mobile devices (Optional)</strong>: If possible the group will standardize a
delivery mechanism for payment messages between apps on a mobile device so that wallet apps can
seamlessly interface with Websites running inside the mobile device's user agent (browser).
</li>
@@ -346,7 +364,7 @@
<h4 id="Card_Payments_1.0">Card Payments 1.0 (optional)</h4>
<p>A very large proportion of payments on the Web are conducted using payment cards from one of the global card
- schemes. The group should attempt to define a standardised specialisation of the payment flow specifically
+ schemes. The group should attempt to define a standardized specialisation of the payment flow specifically
for payment cards.</p>
<p>A generic card payment standard could:</p>
@@ -357,12 +375,18 @@
<li>Take advantage of new security technologies such as EMVco Tokenisation to improve on the existing
methods of using cards on the Web.
</li>
- <li>Standardise a single payment scheme that is reusable by all payment card schemes globally to kick-start
+ <li>Standardize a single payment scheme that is reusable by all payment card schemes globally to kick-start
adoption of the Web Payments 1.0 standard.
</li>
</ul>
<p>Development of such a standard will require collaboration by the group with the owners of the existing global
card schemes.</p>
+
+ <h4>Test Suites</h4>
+
+ <p>The Web Payments Working Group will allocate the necessary resources to build Test Suites for each
+ specification.</p>
+
<h4>Milestones</h4>
<table width="80%" class="roadmap">
<tfoot>
@@ -482,9 +506,9 @@
<h2 id="participation">Participation</h2>
<p>To be successful, the Web Payments Working Group is expected to have active participants for its duration.
- Effective participation to Web Payments Working Group may consume for each participant; for editors. The Web
- Payments Working Group will allocate also the necessary resources for building Test Suites for each
- specification.</p>
+ Effective participation in Web Payments Working Group may consume .1FTE for each participant; for editors
+ this commitment may be higher. The Web Payments Working Group will allocate also the necessary resources for
+ building Test Suites for each specification.</p>
</div>
<div class="communication">
<h2 id="communication">Communication</h2>