- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Thu, 23 Jul 2020 11:33:05 +0200
- To: Adrian Hope-Bailie <adrian@coil.com>
- Cc: Danyao Wang <danyao@google.com>, Payments WG <public-payments-wg@w3.org>, Jeff Hodges <jdhodges@google.com>, Dirk Balfanz <balfanz@google.com>
Adrian, This is just a proposal, feel free ignoring it. It was intended as an alternative to adding new browser APIs like WebAuthn to Pay seems to require. I leave it there. Thanx, Anders On 2020-07-23 11:16, Adrian Hope-Bailie wrote: > You haven't explained how though, just high level things you claim will be possible with no description of the assumptions you're making (e.g. complex code vetting and signing ecosystem that doesn't exist for the Web today) or how this capability enables these features. > Shared PHs are already possible by hosting them at a single URL. > > IMO a payment handler that is hosted by an issuer or network on their own servers and rendered by the browser inside the payment handler window is much safer than client side code, even if that code is subject to some not-yet-existing vetting and signing process. > You are asking to change the whole security model of the web. > > On Thu, 23 Jul 2020 at 11:01, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote: > > On 2020-07-23 10:43, Adrian Hope-Bailie wrote: > > Hi Anders, > > > > Can you explain what value this will add? > > Why is signed code on the client better than standard browser APIs to interface with the FIDO hardware and the issuer code running on their own servers? > > Hi Adrian, > > Signed (and vetted) code could enable powerful features as I tried to outline below. Shared PaymentHandlers is one such feature. > > Anders > > > > > > On Thu, 23 Jul 2020 at 10:28, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>> wrote: > > > > 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> <mailto:btidor@stripe.com <mailto:btidor@stripe.com>> <mailto:btidor@stripe.com <mailto:btidor@stripe.com> <mailto:btidor@stripe.com <mailto:btidor@stripe.com>>>), and Adrian Hope-Bailie (adrian@coil.com <mailto:adrian@coil.com> <mailto:adrian@coil.com <mailto:adrian@coil.com>> <mailto:adrian@coil.com <mailto:adrian@coil.com> <mailto: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 09:33:21 UTC