- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Thu, 23 Jul 2020 19:04:32 +0200
- To: Tom Jones <thomasclinganjones@gmail.com>
- Cc: Danyao Wang <danyao@google.com>, Payments WG <public-payments-wg@w3.org>, Jeff Hodges <jdhodges@google.com>, Dirk Balfanz <balfanz@google.com>
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 > > > >
Received on Thursday, 23 July 2020 17:04:48 UTC