Re: Request for review of substantive changes to Payment Request API -- by 19 February 2019

> On Feb 6, 2019, at 4:26 PM, Sarangdhar, Nitin V <nitin.v.sarangdhar@intel.com> wrote:
> 
> Ian
> 
> I am currently as a member of FIDO/WebAuthn Security group and an observer of the security interest WG, while the group is getting reconstituted. One of the roles that security interest WG can play is to harmonize the security activities going on in other WGs that yur WG may not be aware of. 

Hi Nitin,

Thank you for responding to the request for review. Some notes inline.

> I had following questions/comments on the Payment Request API proposal.
> 
> From FIDO perspective we have identified following two significant security events from the Payment Request API.
> -  User Authentication: A valid user is making the request.
> -  Transaction Confirmation: The user is confirming the final transactions.
> 
> From Verifiable Claims WG perspective I see following significant security events from the Payment Request API
> - User verifiable claim: The user is authorized to perform the proposed payment.
> 
> 
> From your WG have you done any classification of any specific security events? Or do you treat all actions to have equivalent security properties.

The Web Payments Working Group is building an architecture where merchants request payment, users return stored credentials through “payment handlers”, and the browser mediates the connection between the two parties. Payment Request API thus establishes a “pipe” for payment data, but the pipe is agnostic
to the data that flows through it. Our intention is that the Payment Request experience will be available for card payments, bank transfers, cryptocurrency payments,
real-time payments, and payment methods not yet invented. 

The Web Payments Working Group considers user authentication a topic that is orthogonal to the scope of Payment Request API. In a payment system, risk assessment may be handled in a variety of ways and may depend on the nature of the transaction, the payment method rules, regulatory requirements, and other factors. For that reason, the Web Payments Working Group leaves the question of “how to authenticate the user” to the payment handler itself. Payment handlers decide when and how to authentication the user. We envision, for example, that Web-based payment handlers will leverage WebAuthn increasingly now that it has advanced to Proposed Recommendation. 

For example, here is a demo built by Worldline that shows a Web-based payment handler that authenticates the user with WebAuthn: 
 https://www.w3.org/2018/06/worldline.html

Verifiable claims could also be used to enable some payments use cases (e.g., verification of customer eligibility). Verifiable claims would be part of the Web technology stack available to a payment handler to distinguish itself in the market. Again, that would be orthogonal to the base functionality offered through Payment Request API.

Transaction confirmation requirements also depend on context, including regulatory requirements and user expectations. We anticipate for common E-Commerce transactions that the user will push an “ok” button that is part of how browsers implement Payment Request API. This should suffice generally to reflect user confirmation of the transaction amount displayed by the browser (in new secure chrome that is part of a Payment Request implementation). However, we have also discussed, for example, streamlining the user experience for micropayments. The user expectation about transaction confirmation might differ in that use case. That use cases is “on our radar” but has not been a driving use case of version 1 of Payment Request API.

Let me know if the above helps. Thanks again for the questions/comments,

Ian

> 
> I would be interested in understanding that perspective.
> 
> If it would help for me to clarify my questions by attending one of your meetings please let me know.
> 
> Nitin Sarangdhar
> Sr. Principal Engineer
> (503)-264-6140

--
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447

Received on Wednesday, 6 February 2019 23:12:17 UTC