Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert spec to REC state #1021

Merged
merged 16 commits into from
Jul 8, 2024
Merged

Revert spec to REC state #1021

Changes from 13 commits
Commits
Show all changes
16 commits
Select commit Hold shift + click to select a range
c37921b
Revert spec to REC state
marcoscaceres Feb 5, 2024
1a4263b
Editorial: use different global (#997)
marcoscaceres Sep 21, 2022
c6b5aff
tidy
marcoscaceres Feb 5, 2024
ad55944
Editorial: Define JSON-serialize using the Infra algorithm for it. (#…
jyasskin Oct 7, 2022
65d7373
Editorial: use serialize to JSON string directly
marcoscaceres Oct 7, 2022
0ad4f66
Editorial: clarify it's a JSON string
marcoscaceres Oct 7, 2022
66785eb
[Spec] Only allow show() to be called in a foreground tab (#1005)
stephenmcgruer May 30, 2023
ed9e46d
tidy
marcoscaceres Feb 5, 2024
648669b
Editorial: Small fixes (#1016)
ianbjacobs Jan 16, 2024
5876801
tidy
marcoscaceres Feb 5, 2024
7330136
Editorial: link allowlist self properly.
marcoscaceres Feb 5, 2024
26078ea
Remove third arg from examples
marcoscaceres Feb 19, 2024
e48dfbe
Update index.html
marcoscaceres Mar 18, 2024
3f6d838
Apply suggestions from code review
marcoscaceres Mar 18, 2024
2901541
remove options args from exqmples
marcoscaceres Mar 18, 2024
eb4b985
Add sotd text
marcoscaceres Apr 22, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
81 changes: 11 additions & 70 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,13 +3,13 @@
<head>
<meta charset='utf-8'>
<title>
Payment Request API 1.1
Payment Request API
</title>
<script src='https://www.w3.org/Tools/respec/respec-w3c' class=
'remove'></script>
<script class='remove'>
var respecConfig = {
shortName: "payment-request-1.1",
shortName: "payment-request",
github: "w3c/payment-request",
specStatus: "ED",
group: "payments",
Expand Down Expand Up @@ -74,13 +74,13 @@
},
doJsonLd: true,
xref: "web-platform",
mdn: "payment-request",
mdn: true,
};
</script>
</head>
<body data-cite="payment-method-id">
<h1 id="title">
Payment Request API 1.1
Payment Request API
</h1>
<section id='abstract'>
<p>
Expand All @@ -90,34 +90,7 @@ <h1 id="title">
facilitate the payment flow between merchant and user.
</p>
</section>
<section id='sotd' class="updateable-rec">
<p>
The W3C <a href=
"https://www.w3.org/TR/2021/PR-payment-request-20210930/">published
Payment Request API 1.0</a> as a Proposed Recommendation in September
2021. Since then, W3C has been working to resolve two Formal Objections
from W3C Members; see the <a href=
"https://www.w3.org/2022/03/prapi-fo-report.html">Team Report</a> 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.
</p>
<p>
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.
</p>
<p>
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 <a href=
"https://www.w3.org/Payments/WG/charter-201912.html">charter</a>
anticipates enhancements to Payment Request 1.0, we've publish this 1.1
draft.
</p>
<section id='sotd'>
<p>
The working group maintains <a href=
"https://github.com/w3c/payment-request/issues?utf8=%E2%9C%93&amp;q=is%3Aopen%20is%3Aissue%20-label%3A%22Priority%3A%20Postponed%22%20">
Expand Down Expand Up @@ -419,7 +392,7 @@ <h3>
<pre class="example js" title="Constructing a `PaymentRequest`">
async function doPaymentRequest() {
try {
const request = new PaymentRequest(methodData, details, options);
const request = new PaymentRequest(methodData, details);
marcoscaceres marked this conversation as resolved.
Show resolved Hide resolved
const response = await request.show();
await validateResponse(response);
} catch (err) {
Expand Down Expand Up @@ -459,7 +432,7 @@ <h3>
</p>
<pre class="example js" title="POSTing with `fetch()`">
async function doPaymentRequest() {
const payRequest = new PaymentRequest(methodData, details, options);
const payRequest = new PaymentRequest(methodData, details);
marcoscaceres marked this conversation as resolved.
Show resolved Hide resolved
const payResponse = await payRequest.show();
let result = "";
try {
Expand Down Expand Up @@ -823,21 +796,15 @@ <h2>
<li data-tests=
"payment-request-show-method.https.html, show-method-postmessage-manual.https.html">
If the [=relevant global object=] of [=request=] does not have
[=transient activation=], the user agent MAY:
[=transient activation=]:
<ol>
<li>Return [=a promise rejected with=] with a {{"SecurityError"}}
{{DOMException}}.
</li>
</ol>
<p class="note">
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 <a href=
"#user-activation-requirement"></a> for security considerations.
</p>
</li>
<li data-tests="show-consume-activation.https.html">Otherwise,
[=consume user activation=] of the [=relevant global object=].
<li data-tests="show-consume-activation.https.html">[=Consume user
activation=] of the [=relevant global object=].
</li>
<li>Let |document| be |request|'s [=relevant global object=]'s
[=associated `Document`=].
Expand Down Expand Up @@ -2315,7 +2282,7 @@ <h2>
This specification defines a [=policy-controlled feature=] identified
by the string <dfn class="permission">"payment"</dfn>
[[permissions-policy]]. Its [=policy-controlled feature/default
allowlist=] is '<code>self</code>'.
allowlist=] is [=default allowlist/'self'=].
</p>
<aside class="note">
<p>
Expand Down Expand Up @@ -3283,32 +3250,6 @@ <h2 id="canmakepayment-protections">
opening multiple windows (tabs or pop-ups).
</p>
</section>
<section>
<h2 id="user-activation-requirement">
User activation requirement
</h2>
<p>
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.
</p>
<p>
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.
</p>
<p>
Another relevant mitigation exists in step 6 of
{{PaymentRequest/show()}}, where the document must be visible in
order to initiate the user interaction.
</p>
</section>
</section>
<section class="informative">
<h2>
Expand Down
Loading