From f10efb70ffdca2f4b4dd3fe7d25302d9527cbe67 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marcos=20C=C3=A1ceres?= Date: Tue, 9 Jul 2024 08:06:42 +1000 Subject: [PATCH] Revert spec to REC state (#1021) --- index.html | 87 ++++++++++++++++++++++++------------------------------ 1 file changed, 39 insertions(+), 48 deletions(-) diff --git a/index.html b/index.html index 97ac2ae2..69a0ad6a 100644 --- a/index.html +++ b/index.html @@ -3,13 +3,13 @@ - Payment Request API 1.1 + Payment Request API

- Payment Request API 1.1 + Payment Request API

@@ -143,13 +143,36 @@

Changes since last publication

- This version of the specification removes data features from the API, - essentially pushing data details to payment method descriptions. The - complete list of changes, including all editorial changes, is - viewable in the commit - history. Key set of changes are viewable in the Changelog. + In September 2022 the Web Payments Working Group published a Payment + Request Recommendation. Following privacy and + internationalization reviews, the Recommendation excluded + capabilities related to billing and shipping addresses. However, + implementations have continued to support those features + interoperably, and so the Working Group has decided to try to + re-align the specification with implementations, and re-engage the + community on associated issues. +

+

+ This document is a Candidate Recommendation Snapshot based on the + text of the original Recommendation. A subsequent Candidate + Recommendation Draft will add back address capabilities and a small + number of other changes made since publication of the Recommendation. +

+

+ In adding back support for addresses, the group plans to refer to the + address components defined in the Contact Picker API rather + than define those components itself. Indeed, the Contact Picker API + is derived from the original definitions found in Payment Request + API, and pulled out of the specification because addresses are useful + on the Web beyond payments. +

+

+ The Working Group would engage in discussion and follow the usual + review process before advancing the specification to Proposed + Recommendation status.

@@ -419,7 +442,7 @@ 

           async function doPaymentRequest() {
             try {
-              const request = new PaymentRequest(methodData, details, options);
+              const request = new PaymentRequest(methodData, details);
               const response = await request.show();
               await validateResponse(response);
             } catch (err) {
@@ -459,7 +482,7 @@ 

         

         
           async function doPaymentRequest() {
-            const payRequest = new PaymentRequest(methodData, details, options);
+            const payRequest = new PaymentRequest(methodData, details);
             const payResponse = await payRequest.show();
             let result = "";
             try {
@@ -823,21 +846,15 @@ 

           
  • 
           If the [=relevant global object=] of [=request=] does not have
-          [=transient activation=], the user agent MAY:
+          [=transient activation=]:
             
      
               
    1. Return [=a promise rejected with=] with a {{"SecurityError"}}
               {{DOMException}}.
               
      2. 
             
    
-            
    
-              This allows the user agent to not require user activation, for
-              example to support redirect flows where a user activation may not
-              be present upon redirect. See  for security considerations.
-            
    
           
    • 
-          
  • Otherwise,
-          [=consume user activation=] of the [=relevant global object=].
+          
  • [=Consume user
+          activation=] of the [=relevant global object=].
           
    • 
           
  • Let |document| be |request|'s [=relevant global object=]'s
           [=associated `Document`=].
@@ -3283,32 +3300,6 @@ 
    
           opening multiple windows (tabs or pop-ups).
         
    
       
-      
    
-        
    
-          User activation requirement
-        
    
-        
    
-          If the user agent does not require user activation as part of the
-          {{PaymentRequest/show()}} method, some additional security
-          mitigations should be considered. Not requiring user activation
-          increases the risk of spam and click-jacking attacks, by allowing a
-          Payment Request UI to be initiated without the user interacting with
-          the page immediately beforehand.
-        
    
-        
    
-          In order to mitigate spam, the user agent may decide to enforce a
-          user activation requirement after some threshold, for example after
-          the user has already been shown a Payment Request UI without a user
-          activation on the current page. In order to mitigate click-jacking
-          attacks, the user agent may implement a time threshold in which
-          clicks are ignored immediately after a dialog is shown.
-        
    
-        
    
-          Another relevant mitigation exists in step 6 of
-          {{PaymentRequest/show()}}, where the document must be visible in
-          order to initiate the user interaction.
-        
    
-