Support for PWA authenticators

[jcayzac]

Following the approach of the Payment Handler API, there could a way for a web application to get "installed" inside the user agent as an authenticator that end-users could then use to authenticate on other web properties using the Web Authentication API.

While most-certainly out of scope for the Web Authentication API, this could be provided as a separate document by our working group. That document would describe the registration mechanism, and provide web bindings for the Authenticator API available in a worker context.

Any suggestion as to why this would be a very bad idea or any advice/guidance as to how to proceed to kick this off would be greatly appreciated. We've been working with a separate, native authenticator for a while but going PWA makes much more sense IMHO, for a number of reasons I can go into if interested.

[nadalin]

@jcayzac Can you propose a draft specification so we can discuss ?

[ve7jtb]

It would be good if we could understand the reasons.

Most platforms intend to have a platform level authenticator.

If the credentials in the PWA are not globally available to other browsers and native apps I would see this potentially causing fragmentation and user confusion.

Also while I have nothing against PWA a native platform authenticator can use HW backed key protection and may have other security advantages, on the other hand, A PWA would be better than a password.

So it is hard to say how much effort should go into this without fully understanding the use case.

Also Duo is separately proposing a HTTPS based CTAP transport that would allow a native app to be paired with the platform as an authenticator, even across platforms.

John B.

[jcayzac]

@nadalin Yes, I can make a draft if you think that's the best way to go about it. I have a small bandwidth though so it might take some time.

@ve7jtb Native app ↔︎ browser pairing using CTAP over HTTPS is good for opening the platform to third-party authenticators, but requiring native apps has a lot of drawbacks. To cite just the main ones:

• It requires end-users install the native app. An authenticator app, by itself, has very little appeal to most end-users.
• Updates require pushing to app stores as well as being pulled by the end-users, with no guarantee of the latter ever happening at all, so you have as many versions of your app in the wild as you've ever released.
• It adds an unnecessary step, as applinks already require a web property anyway.
• It breaks user experience with a switch to another native application, which involves long transitions and some loading latency.

Enabling PWA authenticators solve all these problems: no install is required, updates are available instantly, the web property directly serves the authenticator (instead of managing app links and falling back to offering app downloads), and users stay in the browser.

As for key storage and access to HW, I think that's a wrong argument to be had, as keys from websites using the PWA authenticator do not need to be stored on the device in the first place: they can live on the backend of the PWA authenticator, the same way all my passwords resides on LastPass servers right now. The PWA authenticator could also use webauthn itself or any other method to manage registration/login into the authenticator service, at its own discretion --I think keeping the exact mechanism behind this unspecified and service-dependent is fine, and that all that's needed is a registration API and WebIDL CTAP bindings.