- From: Anders Rundgren via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Jul 2021 04:56:56 +0000
- To: public-webauthn@w3.org
@arshadnoor Your proposed workflow doesn't work because the creation of a credential at the bank presumes (if we stick to payments) that you get something back comparable to a virtual payment card. This is not what Google & Co plan to ship later this year: consumers still have to manually type in card data and hand it over to merchants which in turn through certified and pretty complex software and services can deduct the origin of (in order to carry out an authentication through the actual issuer). Fortunately Chrome and other browsers support "deep-links", permitting banks to deploy native applications that make on-line payments comparable to current PoS payments. These solutions also work (using the same virtual payment cards) for PoS payments making this one-time registration + download of app much more acceptable. In fact, the very same app is typically also used for login as well. But it doesn't stop there. In some more developed parts of the world, banks want to use their already existing account-to-account payment networks such as SEPA. This is incompatible with Google's take on the matter since there are no cards to input account data from. The mentioned native apps therefore build on a "wallet" concept, like Apple: https://vipps.io/about-us/news/mobilepay-pivo-and-vipps-join-forces-to-create-one-strong-mobile-wallet/ -- GitHub Notification of comment by cyberphone Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1656#issuecomment-888009946 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 July 2021 04:56:57 UTC