Re: [webauthn] Add clearer definition of API use cases to the spec

Let me also add some thoughts on user journeys as we're approaching the AMS plenary (where I'm hoping we can chat more about all of this):

**_Re-Authentication_**
**a) Strict built-in, gesture-based (biometric) re-auth (post bootstrap)**
This use case typically applies to financial services companies who want to give their mass market audience a way to re-authenticate on the same device using a fingerprint. It is critical that these users should not be confused with any messaging about external authenticators (during re-auth, especially since they might very well have required an external authenticator during bootstrapping) and, if there’s any doubt whether the fingerprint scan will work, users should fall back to whatever method for authentication is required during bootstrapping (mostly password).

During credential creation, the RP will explicitly ask for a UV=true, X-Plat=false authenticator, but note that the platform may, at its discretion, return an authenticator which is built-in, but also accessible from other devices.

For this use case to work properly, RPs should tag the specific session on this device with the credentialId, so that only the valid, local credentialId is passed in on subsequent get requests.

**_Bootstrapping_**
**b) Using platform authenticator (passwordless bootstrap)**
This user journey builds on (a): When an RP creates a credential, and gets a list of transports that indicate that the credential can be reached remotely (USB/NFC/BLE), the RP can remember this.
The next time a user tries to bootstrap their account from a new device, the RP can, after username entry:
**Cross-Platform**
Send all credentialIds it has on file for a specific user to the user-agent. This will either result in a local match (if the user cleared their cookies, or is trying to sign in from another app type, but a credential is available in a local authenticator), or, it will result in a dialog box asking the user to use one of their roaming authenticators to solve the challenge. The user can also dismiss the dialog in order to bootstrap normally.


**Strictly non-Cross-Platform**
Only send credentialIds that have “internal” in their transport type to the user-agent. If the credential has more than one transport, other transports should be cleared prior to sending it to the user-agent. This use case is specific to RPs who don’t want to deal with roaming authenticators and only wants the user to be able to sign in using credentials that was previously registered on this machine. This use case applies to a user clearing their cookies, or, signing in with a different browser, or, moving from the browser to an app or vice versa.

**c) Using removable authenticator cross-platform (bootstrap)**
This is the standard “U2F” use case where a user uses their security key as a second factor. Technically, (b) can also satisfy this use case if the credential was created using a phishing-resistant challenge.
To create a key that will only be used for this use case, X-Plat=true and UV=false should be set when creating the credential.

Note that when creating this credential as X-Plat=true, it might still be physically built in to a platform. It should just also be accessible remotely and will be indicated as such in the transports.

**d) Typeless bootstrapping**
This use case is the only one that requires resident credentials and is meant to allow a user to bootstrap an account onto a new device without the need for a username or password. The user would typically arrive at the login page of the RP, insert their security key, authenticate (locally) to the key (using a PIN or fingerprint), and then a list of all available credentials for that RP will be rendered by their browser. Once they select the credential they’d like to sign in with, the signature is released to the RP.

To create this type of credential, X-Plat=true and UV=true is sent during credential creation. 

This flow today is restricted to wired authenticators: we’re not sure how to do this yet for wireless (without requiring system pairing).
Token Exfiltration Protection
This use case is very similar to (c), but instead of registering a removable security key, this is about registering a security key that’s built into the platform, and it doesn’t need to identify the user. This is what Googlers are using on a daily basis to prove that long lived credentials (cookies, OAUTH tokens, etc) is still being sent from a “trusted” machine. To create this type of credential, X-Plat=false and UV=false is sent.

**_Summary_**
**Improving UX**
It is my belief that by far the most prominent use for FIDO2 will be around use case (a): built-in, gesture based re-authentication. As this should also, relatively easily, enable (b): passwordless bootstrap, I think that RPs will start moving here fairly soon too. Depending on how (a) was bootstrapped, (b) might provide a security benefit, but this is mostly about improving UX.

**Improving security**
In order to improve security, we need users to bootstrap their devices with an unphishable challenge. To register one of these credentials, an RP could either re-use a key they created in (a) if that session was bootstrapped unphishably, but RPs could also, independent of the re-auth key, create a specific keypair that’ll be used during bootstrapping, in conjunction with a username and password, on a roaming authenticator by setting X-Plat=true and UV=false. If such a call is made on Android, we should give the user the choice to use a built-in authenticator (Citadel+physical button on Pixel3), or a discrete authenticator.
If this call is made on a desktop device I think we can only reliably offer the user a discrete authenticator right now as we don’t plan (as far as I know) to make Android act as a “paired” BLE authenticator.


-- 
GitHub Notification of comment by christiaanbrand
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/334#issuecomment-388989355 using your GitHub account

Received on Monday, 14 May 2018 23:00:17 UTC