- 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>
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. thanx, Anders 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