Incorporated suggestions from Joerg Heuer
authorAdrian Hope-Bailie <adrian@hopebailie.com>
Mon, 13 Jul 2015 14:06:04 -0700
changeset 796 0dfd29c86bc4
parent 795 29b8cf54d58e
child 797 80e898eb0d52
Incorporated suggestions from Joerg Heuer
latest/charters/payments-wg-charter.html
--- 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>