From e7156cce69c61485e88ebdb3ec2a4f274661a40d Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Wed, 17 Aug 2016 15:16:11 -0500 Subject: [PATCH 1/2] Add privacy and security considerations * Added short section based on https://github.com/w3c/webpayments-methods-card/issues/2#issuecomment-23 8986060 * Also corrected 2 heading levels --- index.html | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 74ba467..f65790f 100644 --- a/index.html +++ b/index.html @@ -167,7 +167,7 @@

Payment Method Identifier

Payment Method Flow

-

The following represent the flow for all the supported payment method identifier strings as they could be used by a website

+

The following represent the flow for all the supported payment method identifier strings as they could be used by a web site

The blue call-outs show where and how the API is invoked.

@@ -188,7 +188,7 @@

Payment Method Response

PaymentRequest API when a user accepts payment with a Basic Payment Card payment method.

-

BasicCardResponse

+

BasicCardResponse

         dictionary BasicCardResponse {
           DOMString cardholderName;
@@ -232,7 +232,7 @@ 
BasicCardResponse
-

BillingAddress

+

BillingAddress

         dictionary BillingAddress {
           // [...] fields TBC - most likely the same as shipping address
@@ -255,6 +255,14 @@ 
BillingAddress

       payment method selected and then Basic Card Payment values would need to be defined in this
       document.
     
+    
+    

+      
Security and Privacy Considerations

+
+      
Owners of web sites SHOULD NOT store the payer's card information except where warranted, such as storage for future and recurring payments. When card information is stored, web site owners SHOULD take measures to prevent its disclosure.

+
+      
Note: Implementers may be subject to PCI DSS or other regulations, but discussion of those considerations lies outside the scope of this document.

+    

 
   
 

From 3d4d8487e715a909242c6334f79bfa323ef4d16b Mon Sep 17 00:00:00 2001
From: Ian Jacobs 
Date: Fri, 26 Aug 2016 08:40:06 -0500
Subject: [PATCH 2/2] Editorial suggestions

- revised intro
- link to flow from payment request api dependency section
- remove specific identifiers for now since we are likely to have just
one
- moved flow diagram to the end
- simplified intro to init-data section
- edited issue 55 description. In particular, suggest that encryption
is not necessary for this basic card spec.
---
 index.html | 67 ++++++++++++++----------------------------------------
 1 file changed, 17 insertions(+), 50 deletions(-)

diff --git a/index.html b/index.html
index f65790f..5fe002f 100644
--- a/index.html
+++ b/index.html
@@ -107,15 +107,8 @@
     

       
Introduction

       

-        This specification is a Payment Transaction Message Specification used by the PaymentRequest API
-        [[!PAYMENT-REQUEST-API]] to support payment by payment cards such as credit or debit cards. It is intended
-        to provide compatibility for merchants who currently request card details from customers to ease adoption
-        of the PaymentRequest API.
-      

-      

-        In the future, merchants should favor payment methods that provide a tokenized response rather than
-        clear text credit card details.
-      

+        This specification is a Payment Method Specification for use with the PaymentRequest API [[!PAYMENT-REQUEST-API]]. With it, merchants can collect the basic card details (card holder name, card number, etc.) through the PaymentRequest API that they have traditionally collected through Web forms, but with an improved user experience.

+      
The Web Payments Working Group is also investigating payment methods that offer greater security (e.g., through tokenization).

     

 
     
 
@@ -131,7 +124,7 @@ 
Dependencies

         [[PAYMENT-ARCH]].
         
Payment Request API

         
The term PaymentRequest constructor is defined by the PaymentRequest API
-        specification [[!PAYMENT-REQUEST-API]].

+        specification [[!PAYMENT-REQUEST-API]]. A flow diagram illustrates how the PaymentRequest API is used for basic card payments.
         
Payment Method Identifiers

         
The term Payment
         Method Identifier is defined by the Payment Method Identifiers specification
@@ -144,42 +137,12 @@ 
Dependencies

     

       
Payment Method Identifier

       
The following payment method identifier strings are supported by the Basic Card Payment data formats.

-
-      
-        
-        
-        
-        
-        
-        
-        
-        
-        
-        
-        
-	    
-        
-	    
-	    
-	    
-      
Identifier StringDescription
visaVisa (Credit, Debit and Electron)
visa/creditVisa Credit
visa/debitVisa Debit
visa/electronVisa Electron
mastercardMasterCard (and EuroCard)
mastercard/creditMasterCard Credit
mastercard/debitMasterCard Debit
amexAmerican Express
discoverDiscover
maestroMaestro
dinersDiners Club
jcbJCB
unionpayUnionPay
unionpay/creditUnionPay Credit
unionpay/debitUnionPay Debit

+      
 The Web Payments Working Group is leaning toward a single identifier for basic card payments, combined with a filtering mechanism.

     

 
-	

-      
Payment Method Flow

-      
The following represent the flow for all the supported payment method identifier strings as they could be used by a web site

-      
The blue call-outs show where and how the API is invoked.

-
-  	  

-	
-    

-	
     

       
Payment Method Specific Data for the PaymentRequest constructor

-      
This section describes payment method specific data that is supplied as part of the data
-      argument to the PaymentRequest constructor.

-      
There is no payment method specific data used by the PaymentRequest constructor when processing
-      Basic Card Payment methods.

+      
For this payment method, there is no data passed as input to the PaymentRequest constructor.

     

 
     

@@ -219,16 +182,11 @@ 
BasicCardResponse

         
cardSecurityCode

         
The cardSecurityCode field contains a three or four digit string for the
         security code of the card (sometimes known as the CVV, CVC, CVN, CVE or CID).

-		
-      
+     
 
-      

-There is a requirement for payment apps to be able to return data that is
-hidden from the payee themselves (perhaps for PCI scope reasons) as they will
-pass it on to their payment service processor who can then decrypt it and use
-it.
-      

 
+      
For security reasons (e.g., PCI scope) the Web Payments Working Group is discussing whether field-level encryption is necessary for this
+	specification, or whether that is unnecessary for this specification, which is a simple replacement for Web forms.

       

 
       

@@ -264,5 +222,14 @@ 
Security and Privacy Considerations

       
Note: Implementers may be subject to PCI DSS or other regulations, but discussion of those considerations lies outside the scope of this document.

     

 
+    

+      
Payment Method Flow

+      
The following represent the flow for all the supported payment method identifier strings as they could be used by a web site

+      
The blue call-outs show where and how the API is invoked.

+
+  	  

+	
+    

+