Observations on HowToFIDO

[sbweeden]

Hmm - some might not consider this an issue with this spec, however I'd like to bring up an observation having been one of the first independent RP developers to try and actually implement it.

Unquestionably there are significant differences in behaviour of platform authenticator implementations across operating system and browser vendors. For example Windows Hello (and from beta testing Apple/Safari) always provision a discoverable resident key credential regardless of flags that the RP sets in options to create. Android does not support resident key credentials. These differences are mentioned in passing in other issues as well (such as #7).

My take on this is that for RP adoption to become widespread and uniform, and for any deployment pattern such as the one described in this repository to aid toward that goal, it is imperative to drive more consistent and prescriptive behaviour in how platform authenticators work by way of the WebAuthn and CTAP specifications themselves.

Without such consistency, the losers are the RP developers and the consumers. RP developers end up needing to branch behaviour based on browser/platform detection, which has been the bane of HTML/browser standards for a very long time.

With that in mind, and as I have presented at the CDWG over the last two months, these are some of the consistency issues I would like to see discussed and subsequent recommendations made back to the spec communities:

• Credentials specifically created with rk=false should have no limit per user.id per rp.id (https://github.com/fido-alliance/fido-2-specs/issues/866).

• Credentials specifically created with rk=false should prescriptively be "not discoverable". Said another way, they should not be usable or part of a UX when navigator.credentials.get is called without those credentials in an allowCredentials list (no spec issue opened for this yet, but discussed in UVRA for bootstrap sign-in UX is undesirable sbweeden/howtofido_site_feedback#5). Whether they are key-wrapped or stored locally with the authenticator is not important; their discoverability is what matters.

• Being able to prescriptively required authentication specifying either a platform or roaming authenticator (e.g. via an authenticatorAttachment-like directive). This would help with UX when performing bootstrap sign-in where an expectation has been set that a roaming authenticator would be used. This becomes of debatable value if phone-based UVRAs become mainstream, and it's also debatable when using something like the caBLE transport whether the authenticator you are interacting with is really platform or roaming. In context you may well be using what is considered a platform authenticator, but in a roaming sense since it is being used to authenticate on a platform other than the one where it is running. I think this particular idea becomes less important if the first two are addressed.

[christiaanbrand]

I like option 1 & 2, but I'm not so sure I agree with 3.

caBLE is certainly coming and I don't want to do anything that breaks the experiences we have in mind for that. Allowing RPs to specify this has all the downsides of breaking some of the future user journeys, while adding a marginal UX improvement. Happy to discuss this more.

[Kieun]

I just add the issue related to option 3.