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

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?


On Thu, 23 Jul 2020 at 10:28, Anders Rundgren <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>), 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
> >
>
>
>