There is the case where Web Authentication will be used as the second factor, case for AWS SIGV2 where the user has logged in with SIGV2 and this SIGV2 authentication token needs to be bound to the second factor FIDO authentication, this is much like how PKI may be bound to Web Authentication

Terminology.

At this time positively identify user and device doesn't need to be positively identifyable are both used.
a) The device must be able to positively identify the user
b) The device doesn’t need to be positively identifiable

I think we should always use a) as the authenticator positively identifies the user (or positively identifying authenticator). It is not that the device is not positively identifiable in some cases (so b is misleading IMHO).

further terminology issues:

We already have a term, roaming authenticator, for "portable" authnr.

We already have a term, user verification, for what the above is terming (in @rlin1's parlance) "the authenticator positively identifies the user", i.e., we should say "the authenticator performs user verification".

It seems to be: The RP can call getAssertion without CredentialID, but in makeCredential the RP cannot filter the authenticators to the ones suporting it.
So some form of authenticator selection policy.

Seems to be 3 canonical characteristics:

1. Positively Identify the user
2. Roaming vs Bound authenticator
3. Being able to produce an assertion without receiving a credentialID from the RP

for 1 only a limited memory space is required (e.g. store a PIN). For 3 the authenticator needs such.

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 aka "X-Plat" in cbrand-lingo
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.

@christiaanbrand Please review, if no longer needed we will close

see also pr #956

Just to be clear: I don't quite care whether this goes into the main spec, or into an accompanying "implementation considerations" (editorial) doc. I actually think the latter might be better, as it could evolve more rapidly.

see also the closed PR #1300
this is a nice-to-have and puntable to a later spec version -- doing this properly is not "hard", but will take effort. I envison something like revamping along the lines of pr#1300, but also citing https://github.com/fido-alliance/how-to-fido/blob/master/HowToFIDO.md for "the full details"

this is superseded by issue #1389 and (closed) PR #1300.