diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
new file mode 100644
index 00000000..ca722e8a
--- /dev/null
+++ b/.github/CODEOWNERS
@@ -0,0 +1,2 @@
+/.github/ @marcoscaceres
+index.html @marcoscaceres @ianbjacobs @stephenmcgruer @rsolomakhin
diff --git a/.github/workflows/auto-publish.yml b/.github/workflows/auto-publish.yml
index 0970f4a5..f8223cf6 100644
--- a/.github/workflows/auto-publish.yml
+++ b/.github/workflows/auto-publish.yml
@@ -16,8 +16,8 @@ jobs:
- uses: w3c/spec-prod@v2
with:
TOOLCHAIN: respec
-# W3C_ECHIDNA_TOKEN: ${{ secrets.ECHIDNA_TOKEN }}
-# W3C_WG_DECISION_URL: "https://www.w3.org/2016/04/14-wpwg-minutes.html#item02"
+ W3C_ECHIDNA_TOKEN: ${{ secrets.ECHIDNA_TOKEN }}
+ W3C_WG_DECISION_URL: "https://www.w3.org/2016/04/14-wpwg-minutes.html#item02"
W3C_NOTIFICATIONS_CC: "${{ secrets.CC }}"
-# W3C_BUILD_OVERRIDE: |
-# specStatus: CRD
+ W3C_BUILD_OVERRIDE: |
+ specStatus: WD
diff --git a/errata.html b/errata.html
new file mode 100644
index 00000000..29116fff
--- /dev/null
+++ b/errata.html
@@ -0,0 +1,50 @@
+
+
+
+
+ Payment Request API Errata
+
+
+
+
+
+ ## Abstract
+ This document catalogues errata for the [Payments Request API](https://w3.org/TR/payment-request/) W3C Recommendation.
+
+
+ ## Process for submitting errata
+
+ Please [file an issue](https://github.com/w3c/payment-request/issues) on Github.
+
+ ## Unaddressed errata
+ None.
+
+ ## Errata approved by the Working Group
+ None.
+
+
diff --git a/index.html b/index.html
index 59303a32..97ac2ae2 100644
--- a/index.html
+++ b/index.html
@@ -3,13 +3,13 @@
- Payment Request API
+ Payment Request API 1.1
- Payment Request API
+ Payment Request API 1.1
+
+ The W3C published
+ Payment Request API 1.0 as a Proposed Recommendation in September
+ 2021. Since then, W3C has been working to resolve two Formal Objections
+ from W3C Members; see the Team Report for
+ details. At this time, a Council is evaluating the Formal Objections to
+ determine whether Payment Request API 1.0 should advance to
+ Recommendation or be returned to the Working Group for changes.
+
+
+ In the meantime, the Editors have continued to update this
+ specification with new features (see change log below). To provide
+ devellopers and implementers with more confidence about these features,
+ the working group has decided to formally publish the a new W3C Working
+ Draft. This will also provide the group with a foundation for potential
+ discussion at TPAC about the future of Payment Request.
+
+
+ It is not uncommon for a Working Group to work on different revisions
+ of a specification simultaneously (e.g., see the CSS WG). With that in
+ mind, and because our current charter
+ anticipates enhancements to Payment Request 1.0, we've publish this 1.1
+ draft.
+
The working group maintains
@@ -542,10 +569,10 @@
|details|) constructor MUST act as follows:
- - If the current settings object's [=relevant global
- object=]'s [=associated `Document`=] is not allowed to use the
- "payment" permission, then [=exception/throw=]
- a {{"SecurityError"}} {{DOMException}}.
+
- If [=this=]'s [=relevant global object=]'s [=associated
+ `Document`=] is not allowed to use the "payment"
+ permission, then [=exception/throw=] a {{"SecurityError"}}
+ {{DOMException}}.
- Establish the request's id:
@@ -587,17 +614,18 @@
- If |seenPMIs| [=set/contain|contains=] |pmi| throw a
- {{RangeError}} {{DOMException}} optionally letting the
- developer this [=payment method identifier=] is a duplicate.
+ {{RangeError}} {{DOMException}} optionally informing the
+ developer that this [=payment method identifier=] is a
+ duplicate.
- [=set/Append=] |pmi| to |seenPMIs|.
- If the {{PaymentMethodData/data}} member of
|paymentMethod| is missing, let |serializedData| be null.
- Otherwise, let |serializedData| be the result of
- JSON-serializing
- |paymentMethod|.{{PaymentMethodData/data}} into a string.
- Rethrow any exceptions.
+ Otherwise, let |serializedData| be the result of [=serialize
+ a JavaScript value to a JSON string|serialize=]
+ |paymentMethod|.{{PaymentMethodData/data}} into a JSON
+ string. Rethrow any exceptions.
- If |serializedData| is not null, and if the specification
that defines the
@@ -701,9 +729,10 @@
- If the {{PaymentDetailsModifier/data}} member of
|modifier| is missing, let |serializedData| be null.
Otherwise, let |serializedData| be the result of
- JSON-serializing
- |modifier|.{{PaymentDetailsModifier/data}} into a string.
- Rethrow any exceptions.
+ [=serialize a JavaScript value to a JSON
+ string|serialize=]
+ |modifier|.{{PaymentDetailsModifier/data}} into a JSON
+ string. Rethrow any exceptions.
- Add the tuple
(|modifier|.{{PaymentDetailsModifier/supportedMethods}},
@@ -794,15 +823,21 @@
-
If the [=relevant global object=] of [=request=] does not have
- [=transient activation=]:
+ [=transient activation=], the user agent MAY:
- Return [=a promise rejected with=] with a {{"SecurityError"}}
{{DOMException}}.
+
+ 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.
+
- - [=Consume user
- activation=] of the [=relevant global object=].
+
- Otherwise,
+ [=consume user activation=] of the [=relevant global object=].
- Let |document| be |request|'s [=relevant global object=]'s
[=associated `Document`=].
@@ -811,6 +846,10 @@
not [=Document/fully active=], then return a promise rejected
with an {{"AbortError"}} {{DOMException}}.
+ - If |document|'s [=Document/visibility state=] is not `"visible"`,
+ then return a promise rejected with an {{"AbortError"}}
+ {{DOMException}}.
+
-
Optionally, if the user agent wishes to disallow the call
@@ -1380,8 +1419,8 @@
-
An object that provides optional information that might be needed by
- the supported payment methods. If supplied, it will be
- JSON-serialized.
+ the supported payment methods. If supplied, it will be [=serialize a
+ JavaScript value to a JSON string|serialized=].
@@ -1733,8 +1772,8 @@
-
An object that provides optional information that might be needed by
- the supported payment methods. If supplied, it will be
- JSON-serialized.
+ the supported payment methods. If supplied, it will be [=serialize a
+ JavaScript value to a JSON string|serialized=].
@@ -1815,7 +1854,8 @@
An object that provides optional information that might be needed by
the {{PaymentResponse}} associated [=payment method=]. If supplied,
- it will be JSON-serialized.
+ it will be [=serialize a JavaScript value to a JSON
+ string|serialize=].
@@ -1924,7 +1964,7 @@
|response|.{{PaymentResponse/[[request]]}}.
Let |document:Document| be |request|'s relevant global
- object's associated Document.
+ object's associated `Document`.
If
@@ -1954,8 +1994,8 @@
If
|errorFields:PaymentValidationErrors|.{{PaymentValidationErrors/paymentMethod}}
member was passed, and if required by the specification that
- defines |response|.{{PaymentResponse/methodName}}, then [=converted
- to an IDL value|convert=] |errorFields|'s
+ defines |response|.{{PaymentResponse/methodName}}, then
+ [=converted to an IDL value|convert=] |errorFields|'s
{{PaymentValidationErrors/paymentMethod}} member to an IDL value
of the type specified there. Otherwise, [=converted to an IDL
value|convert=] to {{object}}.
@@ -2149,8 +2189,9 @@
Let |promise:Promise| be a new promise.
- Let |serializedData| be the result of JSON-serializing
- |details|.{{PaymentCompleteDetails/data}} into a string.
+ Let |serializedData| be the result of [=serialize a JavaScript
+ value to a JSON string|serialize=]
+ |details|.{{PaymentCompleteDetails/data}} into a JSON string.
If serializing [=exception/throws=] an exception, return a
promise rejected with that exception.
@@ -2701,7 +2742,7 @@
|request|.{{PaymentRequest/[[response]]}} if |isRetry| is true, or a
new {{PaymentResponse}} otherwise.
- If |isRetry| if false, initialize the newly created |response|:
+ If |isRetry| is false, initialize the newly created |response|:
- Set |response|.{{PaymentResponse/[[request]]}} to |request|.
@@ -2909,12 +2950,12 @@
If the {{PaymentDetailsModifier/data}} member of
|modifier| is missing, let |serializedData| be null.
- Otherwise, let |serializedData| be the result of
- JSON-serializing
- |modifier|.{{PaymentDetailsModifier/data}} into a
- string. If JSON-serializing throws an
- exception, then abort the update with
- |request| and that exception.
+ Otherwise, let |serializedData| be the result of
+ [=serialize a JavaScript value to a JSON
+ string|serialize=]
+ |modifier|.{{PaymentDetailsModifier/data}} into a
+ JSON string. If it throws an exception, then abort
+ the update with |request| and that exception.
Add |serializedData| to |serializedModifierData|.
@@ -3214,9 +3255,9 @@
The {{PaymentRequest/canMakePayment()}} method provides feature
detection for different payment methods. It may become a
fingerprinting vector if in the future, a large number of payment
- methods are available. purposes. User agents are expected to protect
- the user from abuse of the method. For example, user agents can
- reduce user fingerprinting by:
+ methods are available. User agents are expected to protect the user
+ from abuse of the method. For example, user agents can reduce user
+ fingerprinting by:
- Rate-limiting the frequency of calls with different parameters.
@@ -3242,6 +3283,32 @@
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.
+
+