W3C home > Mailing lists > Public > public-payments-wg@w3.org > July 2020

Signed PaymentHandler? Re: Seeking feedback: WebAuthn to Pay proposed flows

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Thu, 23 Jul 2020 10:28:12 +0200
To: Danyao Wang <danyao@google.com>
Cc: Payments WG <public-payments-wg@w3.org>, Jeff Hodges <jdhodges@google.com>, Dirk Balfanz <balfanz@google.com>
Message-ID: <c3d289d0-1cd5-ef27-e08b-f2d49102576e@gmail.com>
I have one more item on my list...

Rather than standardizing new and pretty specific browser APIs, I believe signed PaymentHandlers would be more useful both in the short- and long-term perspective.  Such a scheme would:
- Support central distribution like native wallets
- Eliminate fuzzy questions to users about 1P or 3P access or other permissions
- Put FIDO in a less constrained mode
- Enable trusted UIs

Last but not least, it would enable innovation!

If we stick to Web payments this could make PaymentHandler-based systems fully comparable to native wallets including support for independent issuers and payment system specific UIs.

This should be be a good fit for SRC as well.

Since the installation is a one-time event, the entire PaymentHandler application could be packaged in a ZIP file, while the signature would be provided by the manifest.


On 2020-07-23 07:39, Anders Rundgren wrote:
> Hi Danyao & Payment WG,
> It is of course not my problem but 3DS made its debut 1998 and initially used passwords for "step-up" authentication.  Nowadays SMS callbacks are more or less the norm.
> However, if you have a strong key like FIDO in the client device you don't really need 3DS; you just sign the transaction request like EMV does.
> If you then combine signed transaction requests with encryption and on top of that add an URL to the issuer, there is not even a need for maintaining external issuer registries.
> Then you get a system that potentially can cope with *any account-based payment scheme*: https://youtu.be/OWn8sg7Oy3I?t=297
> BTW, encrypting signed assertions could be a possibly *generic way dealing with FIDO privacy and domain constraints* since only the proper domain (presumably) have the decryption key.  This is an alternative to "tweaking" the FIDO domain concept like your current proposal requires(?).
> thanx,
> Anders
> On 2020-07-22 01:14, Danyao Wang wrote:
>> Hi Payments WG,
>> I'd like to get your feedback on the proposed WebAuthn to Pay (aka Secure Payment Confirmation) pilot [1]. The goal of this pilot is to prototype an enhancement of the 3DS step-up flow (direct user authentication with the issuer during checkout using WebAuthn without redirect) and evaluate the user friction and conversion impact of such a flow.
>> The finalized UX mocks [2] were discussed at today's WebAuthn/WPWG Joint Task Force call [3].
>> For the WPWG call this coming Thursday, July 23rd, I'll do a walk-through of the sequence diagrams [4][5]. I look forward to your feedback.
>> If you have any questions, please reach out to myself and my collaborators on this proposal: Benjamin Tidor (btidor@stripe.com <mailto:btidor@stripe.com>), and Adrian Hope-Bailie (adrian@coil.com <mailto:adrian@coil.com>).
>> Thanks!
>> Danyao, on behalf of the WebAuthn to Pay collaborators
>> [1] WebAuthn to Pay pilot overview: https://bit.ly/webauthn-to-pay-2020h2-pilot
>> [2] WebAuthn to Pay UX mocks: https://bit.ly/webauthn-to-pay-2020h2-pilot-ux
>> [3] July 21 WebAuthn / WPWG Joint Task Force minutes: https://www.w3.org/2020/07/21-webauthn-pay-minutes
>> [4] Enrollment sequence diagram: https://bit.ly/webauthn-to-pay-2020h2-pilot-enrollment
>> [5] Checkout sequence diagram: https://bit.ly/webauthn-to-pay-2020h2-pilot-checkout
Received on Thursday, 23 July 2020 08:28:28 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 23 July 2020 08:28:29 UTC