PING summary - 16 February 2017

Dear PING colleagues,

Sincere apologies for the late summary.

Many kind thanks to Ian Jacobs for joining our February PING teleconference to introduce the Payments Requests API and discuss its privacy considerations.

Here is a link to the draft specification: https://w3c.github.io/browser-payment-api/


And, a link to Ian’s slides: https://www.w3.org/2017/Talks/ij_ping_201702/payments.pdf


The Web Payments WG will be having a face-to-face meeting in Chicago (23-24 March 2016), where they will be discussing whether to take the draft specification to candidate recommendation. The WG has sought wide review, and would like PING’s review of the privacy aspects. They would also like our help with the text for the privacy considerations - https://www.w3.org/TR/payment-request/#privacy-considerations. 

(There is also a place for developer guidance, see https://github.com/w3c/payment-request-info.)

The specification describes an API that allows user agents (e.g. browsers) to act as an intermediary between three parties in a transaction:
- the payee: the merchant that runs an online store, or other party that requests to be paid.
- the payer: the party that makes a purchase at that online store, and who authenticates and authorizes payment as required.
- the payment method provider: the party that provides the means (e.g.,credit card) that the payer uses to pay, and that is accepted by the payee.

Ian’s slides give a very nice overview. 

Note: the API is extensible by design and payment data storage is not in scope. The WG considered a registry of payment methods but decided against this approach.

Re: API design: The API is designed so that only the information necessary for a given party to fulfill its role is available to that party. The API may increase user privacy because it is more likely that only necessary information will be sent to the merchant, rather than the merchant collecting additional information via a traditional payment form. (It’s a balance between making Web payments easy and not returning data to the merchant.)

Also, users must consent to:
- Make a payment
- Allow the user agent to share information about the user with the merchant Web page.
- Provide credentials to a payment app
- Register a payment app
- Permit a payment app to return information to the merchant

Some of the privacy and/or security topics:
- There some rate-limiting to counter fishing by merchants, but this is one area where the WG would appreciate PING guidance. 
- What if a site has been hacked? Not within the Web Payments WG purview, more within Web Applications Security WG
- But, see https://www.w3.org/TR/payment-request/#paymentrequest-and-iframe-elements (re iframes)
- Uses the Canmakepayment method enabling the merchant to fine-tune the user experience; seeking a balance with user privacy 
- What if the payment app doesn’t want to be used for a known bad site - the question is how can the payment app reject that site? The WG is currently proposing that rejection should only occur after the user selects because they do not want to send data about transactions to all payment apps.
- paymentrequestid - unique identifer per transaction for reconciliation - e.g. for push payments if there is a network failure - raising in case there are any concerns

Please also see Payment Method Identifiers - https://w3c.github.io/webpayments-method-identifiers/


The Payment Request API requires that merchants supply a list of identifiers for supported payment methods. This specification defines those identifier strings and how they are created.

Finally, a link to the Web Payments WG wiki: https://github.com/w3c/webpayments/wiki


Next call on 23 March 2017.

Christine and Tara

Received on Wednesday, 22 March 2017 23:28:32 UTC