--- a/latest/charters/payments-wg-charter.html Mon Jul 13 13:32:25 2015 -0700
+++ b/latest/charters/payments-wg-charter.html Mon Jul 13 14:06:04 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>
@@ -142,8 +145,9 @@
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. 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>
+ 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 <em>interfaces</em> in and out of the Web context to
provide
@@ -248,6 +252,15 @@
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
@@ -257,11 +270,12 @@
<div>
<h2 id="wallets">Wallets</h2>
- <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>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>
@@ -274,9 +288,16 @@
<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>