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

@@ -91,6 +91,33 @@

+

+ 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:

    -
  1. 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}}. +
  2. If [=this=]'s [=relevant global object=]'s [=associated + `Document`=] is not allowed to use the "payment" + permission, then [=exception/throw=] a {{"SecurityError"}} + {{DOMException}}.
  3. Establish the request's id:
      @@ -587,17 +614,18 @@

  4. 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.
  5. [=set/Append=] |pmi| to |seenPMIs|.
  6. 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.
  7. If |serializedData| is not null, and if the specification that defines the @@ -701,9 +729,10 @@

  8. 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.
  9. Add the tuple (|modifier|.{{PaymentDetailsModifier/supportedMethods}}, @@ -794,15 +823,21 @@

  10. If the [=relevant global object=] of [=request=] does not have - [=transient activation=]: + [=transient activation=], the user agent MAY:
    1. 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. +

  11. -
  12. [=Consume user - activation=] of the [=relevant global object=]. +
  13. Otherwise, + [=consume user activation=] of the [=relevant global object=].
  14. 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}}.

  15. +
  16. If |document|'s [=Document/visibility state=] is not `"visible"`, + then return a promise rejected with an {{"AbortError"}} + {{DOMException}}. +
  17. 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|:
    1. Set |response|.{{PaymentResponse/[[request]]}} to |request|.
    2. @@ -2909,12 +2950,12 @@

    3. 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.
    4. Add |serializedData| to |serializedModifierData|.
    5. @@ -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. +

        +

        @@ -3268,12 +3335,6 @@

        The term internal slot is defined [[ECMASCRIPT]]. -

        - JSON-serialize runs JSON {{JSON/stringify()}}, passing the - supplied object as the sole argument, and returns the resulting - string. This can throw an exception. -