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.

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

CR Snapshot Update Request for Payment Request API #287

Closed
ianbjacobs opened this issue Nov 9, 2020 · 5 comments
Closed

CR Snapshot Update Request for Payment Request API #287

ianbjacobs opened this issue Nov 9, 2020 · 5 comments
Assignees
Labels
Updating CR Candidate Recommendation Snapshot wg:payments

Comments

@ianbjacobs
Copy link

ianbjacobs commented Nov 9, 2020

Document URLs

https://w3c.github.io/payment-request/
(GitHub commit 0d11184)

Link to group's decision to request transition

https://lists.w3.org/Archives/Public/public-payments-wg/2020Oct/0012.html

Link to previous Candidate Recommendation transition or update request

https://lists.w3.org/Archives/Member/chairs/2019AprJun/0035.html

Substantive changes

The following features are not supported interoperably and thus have been removed from Payment Request 1.0. They had not been identified as "at risk":

  • Merchant validation. Note: This was removed because it is only used in Apple Pay. It is now described in a new informative Note; we will send a separate transition request for this.
  • hasEnrolledInstrument. Note: This feature is shipping in Chromium-based browsers and for now has been moved to the living Editors' draft of Payment Request. That is: as of now it remains part of the API post version 1.0.
  • allowpaymentrequest. Note: This was simply deprecated in favor of the HTML "allow" attribute, which is supported interoperably. We had mentioned moving in that direction in our March 2019 transition request [5].

Other changes:

  • Remove recommendation to localize sheet based on body element
  • Give AddressInit members defaults
  • Disallow duplicate Payment Method Identifiers when creating request

For the full commit history, see:
https://github.com/w3c/payment-request/commits/gh-pages

[5] https://lists.w3.org/Archives/Member/chairs/2019JanMar/0154.html

Any changes in requirements?

None. However, some minor changes to dependencies:

  • "Fetch" moved from an informative to a normative reference.
  • The "Feature Policy" reference has been changed to "Permissions Policy"

Wide Review of substantive changes

  • Because changes largely involved removing unsupported features, we did not solicit additional wide review since the previous Candidate Recommendation publication.

  • We did alert horizontal review groups of our Call for Consensus to return to Candidate Recommendation.

Issues status

Formal Objections

We received no new Formal Objections through the October 2020 Call for Consensus [0] to the Web Payments Working Group.

Regarding the previous objection from Sam Weiler (addressed during the previous transition request) Ralph wrote:

"[T]he Working Group should continue to work with the community
during CR on issues #842 [2] and #72 [3] to identify means for
payment methods to specify those address fields required for the
transaction, confirm whether the specified PaymentMethodData data
attribute is sufficient for carrying that information in the
basic-card payment method, and recommend good privacy practice for
consideration in other payment methods."

Following the April 2019 publication, Working Group participants, in discussion with Sam Weiler, developed a proposal to allow incremental request of billing and shipping information [4]. However, as we wrote in the Call for Consensus:

"One year later, implementations in Chromium-based browsers and
 Webkit have remained essentially unchanged. There are no
 implementer plans in the near term to address issue 842. Browser
 vendors believe that there are sufficient privacy mitigations in
 place in the current API to allow it to ship as part of the Web
 platform (as it has been for a number of years). "

At this time we are proposing to return this specific to Candidate Recommendation (en route to Recommendation), without changes to address Sam Weiler's objection. We expect to revisit the topic as part of "post 1.0" discussions.

[0] https://lists.w3.org/Archives/Public/public-payments-wg/2020Oct/0006.html
[1] https://lists.w3.org/Archives/Member/chairs/2019AprJun/0003.html
[2] w3c/payment-request#842
[3] w3c/payment-method-basic-card#72
[4] w3c/payment-request#873

Any changes in implementation information?

Deadline for further comments

14 January 2021

Any changes in patent disclosures?

No.

See Requirements for updating a Candidate Recommendation Snapshot for further information.

@ianbjacobs ianbjacobs added [DO NOT USE] Awaiting Director Deprecated. Use Awaiting Team Verification. Updating CR Candidate Recommendation Snapshot labels Nov 9, 2020
@swickr
Copy link
Contributor

swickr commented Nov 13, 2020

hasEnrolledInstrument is not mentioned in "Changes since last publication"; I recommend you add it. The Transition Request says Basic Card is normative now, but the reference is still listed as Informative. It appears that Permissions Policy should be normative and referenced from Section 15 else that section 15 is ambiguous. The updateWith() method depends normatively on DOM; why was DOM dropped from Normative References? 3.1 needs a reference for "payment method identifier"; this was also dropped from the Normative References.

@swickr swickr assigned ianbjacobs and unassigned swickr Nov 13, 2020
@swickr swickr added Awaiting Editor and removed [DO NOT USE] Awaiting Director Deprecated. Use Awaiting Team Verification. labels Nov 13, 2020
@ianbjacobs
Copy link
Author

Hi @swickr,

You wrote:

"hasEnrolledInstrument is not mentioned in "Changes since last publication"; I recommend you add it. "

Under substantive changes I had written:

"hasEnrolledInstrument. Note: This feature is shipping in Chromium-based browsers and for now has been moved to the living Editors' draft of Payment Request. That is: as of now it remains part of the API post version 1.0."

Were you thinking I should say something else?

You wrote:

"The Transition Request says Basic Card is normative now, but the reference is still listed as Informative"

That's my error then. Apparently there's no change here and I was wrong. I will fix the transition request.

I will chat with the editors about the other references and get back to you.

Thanks!

@ianbjacobs
Copy link
Author

Hi @swickr,

  • hasEnrolledInstrument only appeared in the Editor's Draft (not a formally published TR document)
  • Basic Card is not normative (my transition request has been fixed)
  • The editor's draft has been updated so that there is a normative reference in section 15 to permissions policy; see edit:
    w3c/payment-request@2799b44
  • The DOM spec is there as a normative reference (but as "dom" lower case):
    https://w3c.github.io/payment-request/#normative-references
  • [payment-method-id] is a normative reference. There's a reference 3.1 (step 4.3.3).

Please let me know if there are any remaining issues. Thank you!
Ian

@swickr
Copy link
Contributor

swickr commented Nov 20, 2020

Transition approved.

Thanks for the clarifications.

@plehegar plehegar added Awaiting Publication Approved by the Director, waiting on publication and removed Awaiting Editor labels Nov 20, 2020
@ianbjacobs ianbjacobs removed the Awaiting Publication Approved by the Director, waiting on publication label Dec 7, 2020
@plehegar
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Updating CR Candidate Recommendation Snapshot wg:payments
Projects
None yet
Development

No branches or pull requests

4 participants