Clarify examples: 1.1.1. Registration / 1.1.2. Authentication

[binaryanomaly]

I got the impression that the provided examples could be understood in a wrong way as they lack an important detail:

As far as I understood W3C Web Authentication / CTAP supported transports are USB, BLE, NFC.
That would mean that in order to be able to authenticate as proposed in 1.1.2 I'd have to pair the phone with a desktop/laptop device or connect it via USB in the "on a laptop/desktop" scenario?
If my understanding is correct then I'd propose to mention that important detail explicitly for readers to not get the impression that this will just work out of the box (and not remotely) after the initial registration just on the phone.

If I got something wrong here feel welcome to enlighten me.

[equalsJeffH]

As far as I understood W3C Web Authentication / CTAP supported transports are USB, BLE, NFC.
That would mean that in order to be able to authenticate as proposed in 1.1.2 I'd have to pair the phone with a desktop/laptop device or connect it via USB in the "on a laptop/desktop" scenario?

Yes, for the BLE and USB cases, and not for NFC (AFAIK).

I'd propose to mention that important detail explicitly for readers to not get the impression that this will just work out of the box

I'm ok with clarifying this aspect of the use cases.

[binaryanomaly]

Thanks.

The reason why I propose this clarification is that because when I read the examples initially, I got the impression that this would work in a similar manner like "Google 2-Step Verification phone prompts" https://support.google.com/accounts/answer/7026266 but with Secure enclave / PKI technology protected by biometrics - which would be nice. This seems not to be the case though with the current version because we have "only" NFC, BLE and USB available.

I could imagine though that from an end-user perspective it could be an advantage to have the protocol also available via a combination of TCP/IP backchannel and (push) notifications? as a trigger since not every device has NFC, BLE and plugging in USB is also a bit tedious/physically constrained.
Webauthentication and CTAP seem to be generic enough that this extension could be possible on top of it. Having this standardized could leverage adoption since as of today you would have to do this custom for every OS where as a standard would scale better for implementation.

I realize the last part is maybe a bit OT. It could be a possible extension for a future version or an Extension as in Chapter 9 though?

[Kieun]

In order to send push notification to the user's device, the platform should have some knowledges of connection info. Such use cases can be provided by RP with some implementations. Indeed, some RPs have been providing such use cases by leveraging push technology.

[binaryanomaly]

Thanks @Kieun for the additional comment. That is broadly also my understanding.

In addition there is also the device/authenticator side where afaik no standards are available. Means in order to achieve that, one needs to have a native application for each device OS, it cannot yet be done by the OSes themselves even if the functionality is quite generic.

• For end-users this means they have to install an application for each website/service provider that wants to use that kind of authentication.
• For the service providers to provide and maintain an application for each device OS.

Having a standard functionality that is part of the OS would solve this. It would not have to do much more than receiving push messages, verify their authenticity, display a dialog, unlock the authenticator when biometric authentication is ok, sign payload and send to agreed destination. Mostly it's just another transport protocol with some extensions.
This would enable n services to use PKI based biometrically supported 2-step verification without the need to install an application for each one and without the physical constraints of NFC, BLE, USB.

[emlun]

I agree it would be good to clarify this explicitly.

---

Regarding push notifications: I don't think one app and protocol per RP would be necessary to do that "today" - there just needs to be a way for the browser to locate the smartphone. So it should be possible for Mozilla, for example, to provide a "Firefox Authenticator" phone app that would receive push notifications from Mozilla servers, and allow using the phone as an authenticator with any RP in Firefox. The RP wouldn't know to prompt the user to look at their phone, but the browser could.

It wouldn't be portable between browsers, of course, but I think that kind of thing should be possible to do within the spec as currently written. A standardised protocol to enable this without centralised relay servers would be nice of course, but that's way out of scope for a first version of WebAuthn.

[binaryanomaly]

A standardised protocol to enable this without centralised relay servers would be nice of course, but that's way out of scope for a first version of WebAuthn.

Understand we are not there, yet - but this is the future imho 😃