Add three high priority use cases into use cases document.
authorManu Sporny <msporny@digitalbazaar.com>
Mon, 12 Jan 2015 00:44:00 -0500
changeset 9 3fd5f6b5f436
parent 7 fdbef84a1e8d
child 10 efeda2da802d
Add three high priority use cases into use cases document.

These use cases were added:
2.1 Purchase Request
2.2 Choice of Payment Instrument
2.3 Push-based Payments
latest/use-cases/index.html
--- a/latest/use-cases/index.html	Mon Dec 15 01:15:54 2014 -0500
+++ b/latest/use-cases/index.html	Mon Jan 12 00:44:00 2015 -0500
@@ -22,7 +22,7 @@
           // previousMaturity:  "CG-DRAFT",
  
           // if there a publicly available Editor's Draft, this is the link
-          //edDraftURI:           "https://web-payments.org/specs/source/use-cases",
+          edDraftURI:           "https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html",
  
           // if this is a LCWD, uncomment and set the end of its review period
           // lcEnd: "2009-08-05",
@@ -34,18 +34,20 @@
           // editors, add as many as you like
           // only "name" is required
           editors:  [
-              { name: "Pat Doe", url: "http://patdoe.example.com/",
-                company: "ACME", companyURL: "http://acme.example.com/" },
+              { name: "Manu Sporny", url: "https://manu.sporny.org/",
+                company: "Digital Bazaar, Inc.", companyURL: "http://digitalbazaar.com/" },
           ],
  
           // authors, add as many as you like. 
           // This is optional, uncomment if you have authors as well as editors.
           // only "name" is required. Same format as editors.
  
-          //authors:  [
-          //    { name: "Your Name", url: "http://example.org/",
-          //      company: "Your Company", companyURL: "http://example.com/" },
-          //],
+          authors:  [
+              { name: "David Ezell", url: "http://example.org/",
+                company: "NACS", companyURL: "http://www.nacsonline.com/" },
+              { name: "Manu Sporny", url: "https://manu.sporny.org/",
+                company: "Digital Bazaar, Inc.", companyURL: "http://digitalbazaar.com/" },
+          ],
 
           // maximum level of table of contents
           maxTocLevel: 2,
@@ -75,13 +77,25 @@
 <body> 
   <section id='abstract'> 
     <p> 
-Abstract goes here.
+This document outlines and prioritizes desired functionality that the Open
+Web Platform should provide in the area of Web Payments. The purpose of this
+document is to provide future W3C Working Groups with specific requirements
+and functionality that should be achievable with new features that they 
+add to the Open Web Platform.
     </p> 
   </section> 
 
   <section id='sotd'> 
     <p> 
-Custom Status of the Document language goes here.
+This document is a work in progress and is being released early and often
+using an agile process; it is incomplete.
+    </p>
+The Web Payments IG has only had the opportunity to review a handful of the
+40+ use cases, 120+ requirements, and hundreds of pages of
+payments research submitted to the group via various other standards group
+output such as ISO20022, research documents from X9 and the US Federal Reserve, 
+documents from the Web Payments Community Group, and input from the 
+general public. Expect this document to be rapidly iterated upon.
     </p> 
   </section> 
 
@@ -93,6 +107,254 @@
   </section>
 
   <section> 
+    <h2>High Priority Use Cases</h2> 
+    <p>
+The following use cases have been identified by the Web Payments Interest
+Group as high-priority items.
+    </p>
+    
+    <section>
+      <h3>Purchase Request</h3>
+      <p>
+A buyer selects a product or service to purchase on a website. The website 
+generates a payment request that is sent to the buyer's payment processor 
+for processing.
+      </p>
+
+      <section>
+        <h4>Examples</h4>
+        <ul>
+          <li>
+Customer POV: Penny logs into the HobbyCo website, providing her payment 
+processor credential in the process. Penny selects a model train for purchase. 
+The store generates a payment request which is then forwarded to her preferred 
+payment processor.
+          </li>
+          <li>
+Merchant POV: A FarmCo customer selects a 10 kg bag of grass seed for purchase. 
+FarmCo performs a few database lookups to determine the current market price 
+of grass seed and generates an invoice for the purchase of the selected 
+product. The invoice is transmitted to the customer's Payment Agent, which 
+then transmits the invoice to the customer's payment processor for processing.
+          </li>
+          <li>
+Payment Processor POV: A PayCo customer receives a payment request to send 
+funds to RetailCo. Upon approval by the customer, the transmission of funds 
+are initiated from the customer's financial account to RetailCo's 
+financial account.
+          </li>
+        </ul>
+      </section>
+      
+      <section>
+        <h4>Details</h4>
+        <p>
+All payments start somewhere and they typically follow the same basic flow: 
+1) a payer requests a product or service, 2) the payee advertises the final 
+price for the product or service, and 3) the payer initiates payment to the 
+payee. This use case explores the initiation of a payment from the customer, 
+merchant, and payment processor perspectives. 
+        </p>
+        <p>
+A payment request contains all of the details necessary to perform a purchase 
+including: 1) an optional list of requested products or services,
+2) the exchange value (price) for the products/services, 3) the acceptable 
+payment instruments, and 4) a cryptographically verifiable signature on 
+the important data in the request. The payment request is an extensible, 
+cryptographically verifiable, self-contained document that can be used 
+interchangeably with any payment processor.
+        </p>
+      </section>
+        
+      <section>
+        <h4>Requirements</h4>
+        <ul>
+          <li>
+A messaging format that can encapsulate a list of goods and services being 
+sold and the current value required to acquire the goods and services. 
+          </li>
+          <li>
+The messaging format should be extensible (e.g. Linked Data, JSON-LD). 
+          </li>
+          <li>
+The messaging format should be cryptographically verifiable (e.g. via 
+digital signatures, PKI).
+          </li>
+          <li>
+The messaging format should enable the receiver of funds to specify 
+acceptable payment instruments.
+          </li>
+          <li>
+A protocol that is capable of transmitting the payment request from the 
+origination point of the payment request to the payer's payment processor.
+          </li>
+          <li>
+A protocol that is capable of discovering the payer's payment processor(s).
+          </li>
+          <li>
+A protocol that is capable of discovering the payer's payment instrument(s).
+          </li>
+        </ul>
+      </section>
+    </section>
+
+    <section>
+      <h3>Choice of Payment Instrument</h3>
+      <p>
+When a payee intends to make a payment, they are given a choice to pick among 
+the intersection of the payment instruments they have available to them and 
+the payment instruments that are accepted by the merchant/payee.
+      </p>
+
+      <section>
+        <h4>Examples</h4>
+        <ul>
+          <li>
+Daniel wants to pay the taxi fare with his credit card. The cab company promotes
+the payment via its web site which offers, on Daniel's smartphone, to choose 
+between several instruments offering different payment means: 1) the basic 
+credit card (Visa, MasterCard, etc.) channel; 2) or an indirect aggregators 
+(PayPal, Google checkout); 3) or the personal wallet detected as available on 
+Daniel's phone.
+          </li>
+          <li>
+Amantha downloads the latest version of her favorite game. It's only a couple 
+of euros that she'd like to pay on top of her telecom operator's bill. The game 
+store web site accepts payment via credit card and operator billing. Amantha 
+selects the "operator billing" payment option.
+          </li>
+        </ul>
+      </section>
+      
+      <section>
+        <h4>Details</h4>
+        <ul>
+          <li>
+Each payment instrument is registered with a set of attributes in order to 
+filter, sort, and display them. 
+          </li>
+          <li>
+Each payment processor is registered and 'subscribes' to a the payment 
+instrument it is able to provide.
+          </li>
+          <li>
+Each merchant provides a list of acceptable payment instruments.
+          </li>
+          <li>
+Over time, each buyer iteratively builds a list of preferred payment 
+instruments for their commonly used merchants.
+          </li>
+        </ul>
+      </section>
+        
+      <section>
+        <h4>Requirements</h4>
+        <ul>
+          <li>
+The browser and the host are able to negotiate a payment instrument with 
+respect to their preferences and support capabilities.
+          </li>
+        </ul>
+      </section>
+    </section>
+
+    <section>
+      <h3>Push-based Payments</h3>
+      <p>
+When a customer wants to make a purchase, the merchant presents the customer 
+with an electronic invoice which in turn can be presented to a payment 
+processor.  The payment processor then provides a validated proof-of-payment 
+to the merchant.
+      </p>
+
+      <section>
+        <h4>Examples</h4>
+        <ul>
+          <li>
+Customer POV: John goes to CandyCart.com and clicks “buy” to purchase 
+chocolates. John is redirected to the CandyCart.com’s payment processor's 
+website which presents him with a payment UI. John completes the purchase, 
+and is redirected to CandyCart.com’s website, to which he can now post a 
+digital receipt confirming the purchase.  
+          </li>
+          <li>
+Customer POV: Francis purchases items in a local novelty store.  The store 
+system notifies his mobile application what methods of purchase can be used, 
+and also sends his mobile application an electronic invoice for the 
+transaction.  The mobile app presents Frances with options for payment, and 
+Frances chooses to pay with his tokenized credit card.  The token and invoice 
+are sent to the payment processor from the mobile app.  The payment processor 
+responds with a signed proof of payment electronic document.
+          </li>
+          <li>
+Merchant POV: A customer scans or clicks 5 items to purchase.  The merchant 
+system presents an electronic invoice (either total only or with a breakdown 
+of the transaction), including the merchant's identifier, to the customer's 
+device.  The customer's device returns a digest of the invoice, having been 
+created with the payment processor's private key.
+          </li>
+          <li>
+Payment Processor POV: A customer sends an electronic invoice, including 
+the merchant and customer identifiers, to the payment processor.  The payment 
+processor checks the customer and merchant for validity, posts the requested 
+amount to the merchant's acquirer, which returns a digest on the 
+merchant/customer/amount/time tuple for proof of payment.  The payment 
+processor then returns a signed digest of the invoice plus the acquirer 
+digest proving payment to the customer's device, which it in turn posts to 
+the merchant system to prove payment.  
+          </li>
+        </ul>
+      </section>
+      
+      <section>
+        <h4>Details</h4>
+        <p>
+For this use case, the customer asks the payment processor for payment 
+directly, preventing the need for sensitive customer information to be shared 
+with the merchant, keeping the merchant out of "PCI scope."  No direct 
+communication between merchant and payment provider is required for this use 
+case. It may be possible to create an electronic receipt format that satisfies 
+the requirements for this use case as well as others. 
+        </p>
+      </section>
+        
+      <section>
+        <h4>Requirements</h4>
+        <ul>
+          <li>
+All acquirers must have an available public key.
+          </li>
+          <li>
+All payment processors must have an available public key.
+          </li>
+          <li>
+All merchants must have a global identifier.
+          </li>
+          <li>
+All customers must be recognized by the payment processor. 
+          </li>
+        </ul>
+      </section>
+    </section>
+
+  </section>
+  
+  <section> 
+    <h2>Medium Priority Use Cases</h2> 
+    <p>
+
+    </p>
+  </section>
+
+  <section> 
+    <h2>Low Priority Use Cases</h2> 
+    <p>
+
+    </p>
+  </section>
+
+
+  <section> 
     <h2>Acknowledgements</h2>
  
     <p>