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

Anders, etal.
By manifest are you talking about the Android manifest?
In Kantara we are working on a Mobile Assurance statement to allow apps to
declare who and what they are. Our immediate goal is healthcare, but
finance needs should be similar.  Would welcome feedback or participation.
https://github.com/KantaraInitiative/DistributedAssurance/blob/master/OpenID%20Self%20Issued%20Identifier.md

Peace ..tom


On Thu, Jul 23, 2020 at 1:29 AM 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
> >
>
>
>