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

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
> >      >
> >
> >
>
>