--- a/latest/charters/payments-wg-charter.html Sun Jul 12 07:14:14 2015 -0700
+++ b/latest/charters/payments-wg-charter.html Mon Jul 13 17:46:55 2015 -0700
@@ -105,6 +105,9 @@
transactions abandoned prior to completion ("shopping cart abandonment").
</li>
<li>Increased customer satisfaction due to additional payment options available to users.</li>
+ <li>Improved transparency and confidence in digital payments for consumers as a result of increased choice and
+ standardised flows and experiences.
+ </li>
<li>Improved security and privacy by providing information only to those parties that require it to complete a
transaction.
</li>
@@ -112,16 +115,23 @@
<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
- facilitate payments on the Web.</p>
-
<p>
- <strong>Note</strong>: The Web Payments Interest Group expects to provide more detailed technical input to
- relevant W3C Working Groups including this one, based on a detailed analysis of the relevant <a
- href="http://www.w3.org/TR/web-payments-use-cases/#an-overview-of-the-payment-phases">Web Payments Use
- Cases</a>.</p>
+ The Web Payments Interest Group will continue to guide the W3C in the Web Payments activity and may propose new
+ working groups to cover topics such as identity, credentials and commerce (including invoicing, receipts,
+ loyalty programs, coupons, discounts, offers etc.).</p>
+
+ <p>As part of this work the Web Payments Interest Group expects to provide technical input to this and other
+ relevant W3C Working Groups, based on a detailed analysis of the relevant <a
+ href="http://www.w3.org/TR/web-payments-use-cases/">Web Payments Use
+ Cases</a>.</p>
+
+ <p>The W3C is also planning other Working Groups to develop standards, covering topics such as security, that will
+ be important in facilitating payments on the Web.</p>
<div class="scope">
<h2 id="scope">Scope</h2>
@@ -130,31 +140,35 @@
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>
+ websites to facilitate re-use of customer data and/or payment credentials (increasingly through the use of
+ tokenization), and even developing new payment 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. The result is that users are lead through entirely different flows and verification
+ routines every time they make a payment on 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
@@ -174,8 +188,8 @@
<ul>
<li>
<strong>Registration</strong>, by the payer with their <a href="#wallets">wallet</a>, of any
- conforming <strong>payment instrument</strong> they wish to use on the Web (e.g. a credit card,
- electronic cash, cryptocurrency, etc).
+ conforming <strong>payment instrument</strong> they wish to use on the Web (e.g. a credit or
+ debit card, electronic cash, cryptocurrency, etc).
</li>
</ul>
</dd>
@@ -217,56 +231,85 @@
</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>
+
+ <p>The group will also consider the work of other W3C groups working on hardware-based security standards.
+ Hardware-based security solutions can elevate security beyond that which pure software solutions are able to
+ provide. In particular the group will consider how hardware-based solutions may be used to securely generate
+ and store secrets for secure transactions and how hardware devices may be used to verify a user's
+ authenticity via biometry or other mechanisms. This hardware integration is outside the scope of the Web
+ Payments WG but will be an important part of the security models employed by wallets and payment schemes so
+ it is important to ensure the standards put forward by the group are considerate of how these hardware
+ integrations may fit into the payment flow.</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 stand-alone Web or
+ native applications, within applications in the cloud, within user agents such as Web browsers or in the
+ form of user agent extensions or plug-ins. 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 payer.</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>
+ <li>It may enrich the payment flow by implementing business logic for loyalty, coupons, ticketing or other
+ function that is complimentary to its payment capabilities.
+ </li>
</ul>
+ <p>The group will not attempt to standardize all functions of a wallet in this first version of standards but
+ will be focused primarily on the payment flow as described in the <a href="#scope">scope</a> and the wallet
+ capabilities required to execute this flow.</p>
+
<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
+ such as digital receipts and digital credentials. What the group defines today as a wallet service may
in future offer new functionality that even makes the wallet metaphor entirely inappropriate. Therefor the
label <em>"wallet"</em>, while appropriate today, should not imply any limitation on the functionality that
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 +319,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 +338,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 +370,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 +381,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 +389,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 +400,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 +531,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>
@@ -499,8 +548,8 @@
<h2 id="decisions">Decision Policy</h2>
<p>As explained in the Process Document (<a href="/Consortium/Process/policies#Consensus">section 3.3</a>), this
- group will seek to make decisions when there is consensus. When the Chair puts a question and observes
- dissent, after due consideration of different opinions, the Chairs should put a question out for voting
+ group will seek to make decisions when there is consensus. When a Chair puts a question and observes
+ dissent, after due consideration of different opinions, the Chair should put a question out for voting
within the group (allowing for remote asynchronous participation -- using, for example, email and/or
web-based survey techniques) and record a decision, along with any objections. The matter should then be
considered resolved unless and until new information becomes available.
--- a/latest/use-cases/index.html Sun Jul 12 07:14:14 2015 -0700
+++ b/latest/use-cases/index.html Mon Jul 13 17:46:55 2015 -0700
@@ -1615,19 +1615,93 @@
</dd>
</dl>
- <dl id="uc-regulatory-blocks" class="dl-horizontal">
- <dt>Regulatory Blocks</dt>
+ <dl id="uc-kyc" class="dl-horizontal">
+ <dt>KYC</dt>
<dd>
-PayCo must ensure that their customers do not appear on any regulatory
-blacklists when performing <a>transaction</a>s above a certain monetary amount.
+A number of Know Your Customer (KYC) requirements must be met when a financial
+service provider authorizes access to a particular <a>payment instrument</a>:
+ <ul>
+ <li>
+BigBank performs KYC clearing on a continuous basis to ensure that their
+customers are properly vetted before participating in financial transactions.
+ </li>
+ <li>
+Multigen, a wealth management company, must ensure that their customer's
+are accredited investors before allowing them to directly manage certain
+investments in their account.
+ </li>
+ <li>
+The Central Bank of Pakistan enables independent mobile resellers to
+perform minimal thumbprint-based KYC clearing in remote regions of the
+country.
+ </li>
+ <li>
+Pharmaxis, a medical drug reseller, requires that a customer is licensed to
+practice medicine and write prescriptions for Class 2 medications (highly
+addictive drugs with a known medical use) before a purchase is allowed to
+proceed.
+ </li>
+ <li>
+Dr. Kubo provides a set of explosives expert KYC credentials at the time of
+transaction to meet transaction requirements managed by the financial
+institution and merchant.
+ </li>
+ </ul>
</dd>
<dt>Target version</dt>
<dd>Uncategorized</dd>
<dt>Motivation</dt>
<dd>
-Easing compliance with Know Your Customer (KYC) and
-Anti-Money Laundering (AML) regulations
-will ensure safer and faster <a title="payment scheme">payment schemes</a>.
+Authorization to access an instrument depends on more than just authenticating
+with the payment service provider, it may also require the <a>payee</a> to
+have other provable qualities before the transaction can proceed.
+ </dd>
+ <dt>Regulation</dt>
+ <dd>
+In many countries, a variety of regulations exist that require merchants and
+financial service providers to prove that they have vetted their customers
+before allowing a transaction to proceed.
+ </dd>
+ </dl>
+
+ <dl id="uc-" class="dl-horizontal">
+ <dt>AML</dt>
+ <dd>
+Financial service providers, and some merchants, are required to adhere to
+Anti-Money Laundering (AML) regulations by blocking transactions involving
+known bad actors or by reporting suspicious activity related to financial
+transactions:
+ <ul>
+ <li>
+Corresponda Bank's AML system notices an outgoing payment to an account listed
+as frozen by FinCEN and prevents the payment from proceeding.
+ </li>
+ <li>
+FasterPay, a payment service provider, notices tens of thousands of small
+transactions flowing from high-risk foreign accounts into a previously dormant
+domestic account and automatically files a Suspicious Activity Report.
+ </li>
+ <li>
+Eastern Group, an international remittance system, verifies that both the
+sender and a recipient of an international remittance are not on a watch
+list and have known accounts at the source and destination of funds
+before authorizing the transaction.
+ </li>
+ <li>
+The Flamingo, a casino, automatically files a Currency Transaction Report
+when one of its systems detects a customer withdrawing over $10,000 USD
+in winnings over the course of a day.
+ </li>
+ </ul>
+ </dd>
+ <dt>Target version</dt>
+ <dd>Uncategorized</dd>
+ <dt>Motivation</dt>
+ <dd>
+Financial service providers, and some merchants, are required to adhere to
+Anti-Money Laundering (AML) regulations by reporting suspicious activity
+related to financial transactions or by blocking transactions involving
+known bad actors.
</dd>
<dt>Exceptions</dt>
<dd>