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 all 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
89 changes: 40 additions & 49 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 Down Expand Up @@ -143,13 +143,36 @@ <h3>
Changes since last publication
</h3>
<p>
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 <a href=
"https://github.com/w3c/payment-request/commits/gh-pages">commit
history</a>. Key set of changes are viewable in the <a href=
"#changelog">Changelog</a>.
In September 2022 the Web Payments Working Group published a <a href=
"https://www.w3.org/TR/2022/REC-payment-request-20220908/">Payment
Request Recommendation</a>. Following privacy and
internationalization reviews, the Recommendation excluded <a href=
"https://lists.w3.org/Archives/Public/public-payments-wg/2021Jun/0000.html">
capabilities</a> 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.
</p>
<p>
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.
</p>
<p>
In adding back support for addresses, the group plans to refer to the
address components defined in the <a href=
"https://w3c.github.io/contact-picker/">Contact Picker API</a> 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.
</p>
<p>
The Working Group would engage in discussion and follow the usual
review process before advancing the specification to Proposed
Recommendation status.
</p>
</section>
</section>
Expand Down Expand Up @@ -419,7 +442,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 +482,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 +846,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 +2332,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 +3300,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