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

To clarify, the manifest mentioned here:
https://w3c.github.io/payment-handler/#authorized-payment-apps is published
by the payment method owner, not the app publisher (unless these are the
same entity).
This indirection is intentional, allowing something like a scheme or
network to define a standard for the interactions between the website and
payment handler but for there to be many payment handler implementations.

On Thu, 23 Jul 2020 at 19:19, Tom Jones <thomasclinganjones@gmail.com>
wrote:

> We have been focused on native code due to the lack of functionality in
> the "pure Web" (which I take to mean PWA apps written in javascript and run
> as a worker). I suspect that when gRPC is enabled in the browser we can
> look at PWA, but only if it can be tested to be secure., (that will most
> likely take years to accomplish.) Kantara already writes "Service
> Assessment Criteria" for NIst SP 800-63-3 assurance levels for web
> sites and so is well positioned to extend that to the device in the user's
> hands.
> Peace ..tom
>
>
> On Thu, Jul 23, 2020 at 10:04 AM Anders Rundgren <
> anders.rundgren.net@gmail.com> wrote:
>
>> On 2020-07-23 18:40, Tom Jones wrote:
>> > Anders, etal.
>> Hi Tom,
>>
>> > By manifest are you talking about the Android manifest?
>>
>> "Almost".  In this case I was referring to PaymentHandlers based on pure
>> Web code/Service Worker.  They also require manifests:
>> https://w3c.github.io/payment-handler/#authorized-payment-apps
>>
>> However, payment applications based on pure Web code are (IMO) quite
>> behind in functionality compared to native apps.  My proposal was intended
>> to change this.  An updated manifest could in addition to a signature and
>> pointer to ZIP achieve, also hold permissions.
>>
>> This is an alternative to build more specific payment support inside of
>> the browser itself.  It is a non-trivial update.
>>
>> Anders
>>
>> > 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 <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>>), and Adrian Hope-Bailie (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
>> >      >
>> >
>> >
>>
>>