With v4.10.0, StrongKey FIDO Server(SKFS) supports authenticating users with "discoverable credentials". This is a user experience where web applications authenticate users to the relying party's site without having the user provide their username - the browser and user's FIDO Authenticator negotiate the capability between them, and make the user experience seamless. [Note: You can see a demonstration of this in the StrongKey Discover demo here].

The premise of this authentication flow is that most users have a primary FIDO credential registered with an RP site, which they use frequently from the same platform. In such a situation, if the RPID on the site matches that of a credential within the FIDO Authenticator, the browser does not need to prompt the user for any text (unless a PIN has been enabled on the Authenticator) - without typing a username or password, the user is authenticated to the site. If the user has multiple FIDO Authenticators accessible/connected to the platform, the browser may display a "chooser" identifying the type of Authenticator the user must select to authenticate with. On the chosen Authenticator, if there is only a single credential for the user to the RP site, the user is authenticated with the "discoverable credential" flow.

If the user has multiple usernames and FIDO credentials registered to the same RP site on a single Authenticator, the browser will display a "chooser" to select a username to authenticate with [Note: While the authentication flow using "discoverable credentials" does not require typing in a username, the registration of such a credential does require specifying one - this is why the browser can display usernames associated with FIDO credentials when there is more than one username-credential associated with the RPID].

In this release, SKFS added support for "discoverable credentials" by making the "username" parameter optional for the preauthenticate web service - the parameter can be set to NULL, an empty value or eliminated from the input JSON data structure entirely. Such a preauthenticate request returns a response with the challenge and an empty "allowedCredentials" array - indicating that the Authenticator(s) available on the platform must discover any/all FIDO credentials registered for the specific RPID, and permit the user to choose the one they will authenticate with. If there is only one Authenticator available to the platform, and if such an RPID-scoped credential is available on it, the user is authenticated with just the user-presence/user-verification prompt without the need for the username. This is what makes "discoverable credentials" seamless.

It should be noted that due to mixed support for WebAuthn's "credential properties" aka "credProps" extension by browsers, SKFS' Policy Module cannot enforce a FIDO policy to mandate "residential keys" - which in StrongKey's traditional understanding implies that the key-pair is generated on the Authenticator and the private key never leaves the Authenticator in any circumstance. For now, suffice to know that if an RP requires that FIDO keys must be generated on a cryptographic hardware device and the private key must remain on the Authenticator, the RP should discuss this with Authenticator manufacturers for affirmation.

RP web applications must also specify "residentKey" in AuthenticatorSelectionCriteria to signal their intent for a "discoverable credential" by setting "authenticatorSelection.requireResidentKey" to 'true' and "authenticatorSelection.residentKey" to 'required'. Web applications should be prepared to receive an error from the Authenticator if such a resident key cannot be created. (WebAuthn L3 specification expects to change much of this; StrongKey will implement L3 when it is finalized by W3C and will explain its rationale for the implementation at that time).