Add authenticatorDisplayName to credProps

[emlun]

In today's WG meeting, there was a desire expressed for some way for the RP to receive a user-friendly name for the new credential. For example, in order to instruct the user to "use your passkey saved in Password Manager X". To that end, this would add a new credential property to the credProps extension, possibly configurable by the user and with the possibility of a fallback value set by the authenticator vendor.

---

Preview | Diff

[emlun]

(And just to be abundantly clear: this is a proposal for discussion. "Let's not do this, close with no further action" is a perfectly acceptable conclusion.)

[ndpar]

I like the idea to give a user a mean to name the credential during the registration ceremony, and store it in the credential record. But I don't fully understand the envisioned UX. Will the browser show an input field and pass the value in the extension output? Typically, RP has a custom UI to choose the name.

[emlun]

Additional feedback during today's WG meeting was that we should return a single value to the RP, so I've merged both properties and renamed it to authenticatorDisplayName.

[emlun]

@ndpar My envisioned UX is that the browser may have configuration settings for the default nickname for new credentials. Perhaps one for the platform authenticator, if any, and one per external security key. Similarly, passkey providers and external security keys could have such a configuration setting as well, which the browser can check if the user hasn't configured the browser setting(s).

If the user hasn't configured any such setting, the browser may choose to prompt the user to set it, or simply omit the credential nickname. Once set, the user shouldn't need to be prompted again for that authenticator.

RPs would still have custom UI to set credential nicknames, but could set the initial value to this extension output when available.

[Kieun]

It seems that the authenticator, client or both are responsible to store such displayName for the credential.
If the client stores such information and overwrites the default one provided by the platform, the credentials' displayName would be different each other.
E.g., if I set the displayName as "A" with Browser X for the authenticator and I set the displayName as "B" with Browser Y for the same authenticator; I would get "A" and "B" for the credential generated by the same authenticator with different browsers.

[MasterKale]

E.g., if I set the displayName as "A" with Browser X for the authenticator and I set the displayName as "B" with Browser Y for the same authenticator; I would get "A" and "B" for the credential generated by the same authenticator with different browsers.

The flow that we imagined didn't involve the browser storing this string, rather it would flow through to the RP so that the RP had something it could nickname the credential. The client displaying this new value would strictly be for the user to optionally change the name that makes it back to the RP, and if the client handled the "enter a name" step of credential naming as part of the tail end of the registration ceremony then it would mean RP's wouldn't all have to implement similar functionality in their sites.

And to be clear I don't think anyone suggested that the client or authenticator store whatever value the user ended up setting for the credential. The authenticator display name would be a default suggested name for the credential that the user could change one way, as it propagates through to the RP.

[Firstyear]

Might be good @emlun to list a string length limit here.

[hpsin]

As an RP currently testing passkeys internally, this would solve significant pain points our testers reported. Namely, they didn't really "get" where their passkeys would be usable, and we are reluctant to use heuristics to attempt to brand the passkey ourself. What we end up with eventually is "Touch ID on iPhone" being syncable to one of Chrome or Mac (or maybe both, but you don't know how). Users indicated they had no way of predicting if their passkey would work elsewhere.

Providing a reliable, understandable name and vendor to start would give users confidence in the usability and restrictions on their passkey.

[emlun]

@Firstyear I don't think a length limit is appropriate at this layer, since the data flow is directed from authenticator to RP and the RP is already recommended to allow the user to modify the value - so if the authenticator were to return a 2 kB long string the RP is not willing to store, the RP can just tell the user to shorten it before saving it. I wouldn't be against pointing that case out as a recommendation to RPs, though.

A length limit would be appropriate for a new API for configuring this value on the client-to-authenticator layer, but that is not currently part of the extension definition.

[Firstyear]

I think we should recommend it then.

[Kieun]

Please correct me if I'm wrong.

What I'm understanding is that browsers may offer the way for the user to configure the authenticator name.
This configuration process by the user is not performed during the registration ceremony. If user sets certain name for the authenticator, the browser should have an ability to store such information so that such configuration keep surviving.
If anything isn't configured, the browsers might return default name for the authenticator.
If this is the case, as I've mentioned, such configured information is stored in the browser side and which causes the inconsistency between the names from the different browsers with same authenticator.

As a RP, we would like to get meaningful consistent authenticator display name if the user creates credentials with the same authenticator regardless of browsers which the user runs.

[emlun]

Yes, the proposal as currently written would allow that. But presumably, browser implementers would probably agree that it's a bad idea to configure and store a nickname for an external authenticator unless you can store it on that authenticator, for the reasons you describe. Perhaps that is enough, perhaps we'll add an explicit recommendation against it, perhaps there are reasons to do it anyway. But this proposal will also apply to platform authenticators and rich third party passkey provider apps, where that concern doesn't apply, at least not in the same way.

None of this is final, though. I expect the details of the proposal will change as people take some more time to think about it and sketch out some implementation scenarios. In particular we'll have to consider how this should work, if at all, for multi-device passkeys.

[emlun]

By the way, to help illustrate the imagined UX flow, see for example https://demo.yubico.com/playground . After you create an account and register a WebAuthn credential (called "security key" or "internal authenticator" in this app; we're working on updated terminology), the app asks you to set a nickname for the credential. The nickname field is prefilled with a default value derived from attestation if available, or otherwise user agent sniffing in the case of platform credentials.

Google and GitHub, and probably many others, also have similar nickname prompts during registration, but don't attempt to prefill the nickname field.

The UX flow with this extension would most likely be the same in all those scenarios, except one could prefill the nickname field with this extension output if available instead of having to fall back on less reliable heuristics.

[irew]

Sounds good! We've already seen a few deployments fallback to unreliable means of naming the item in the UI.

[hpsin]

Google and GitHub, and probably many others, also have similar nickname prompts during registration, but don't attempt to prefill the nickname field.

Speaking for GitHub.com, we do attempt to propose a nickname, based on browser and OS, for all security keys today. However, for passkeys we will drop this behavior since e.g. "Chrome on MacOS" is an actively bad nickname for your Dashlane passkey, and will be quite a poor UX when it comes to lifecycle management as the user attempts to understand what passkey they are unregistering. I don't believe users will come up with a better nickname on their own though, since they are unlikely to understand the source of their passkey provider.

[Firstyear]

Google and GitHub, and probably many others, also have similar nickname prompts during registration, but don't attempt to prefill the nickname field.

Speaking for GitHub.com, we do attempt to propose a nickname, based on browser and OS, for all security keys today. However, for passkeys we will drop this behavior since e.g. "Chrome on MacOS" is an actively bad nickname for your Dashlane passkey, and will be quite a poor UX when it comes to lifecycle management as the user attempts to understand what passkey they are unregistering. I don't believe users will come up with a better nickname on their own though, since they are unlikely to understand the source of their passkey provider.

There is also a strong likelihood that users will be confused by the UI/UX presented by chrome that may mislead them to misname the key itself. About the best an RP could do here with this nickname field is to fill it in with a nice display name of the site itself.

Has any user testing or research actually been done on this feature with real humans to see how they will use / misuse this feature proposition?

[sbweeden]

If authenticators returned an AAGUID with the credential during registration, even without attestation, wouldn't that also address this same use case? I believe that's what some RP's (including Google) have been asking for.

[MasterKale]

If authenticators returned an AAGUID with the credential during registration, even without attestation, wouldn't that also address this same use case? I believe that's what some RP's (including Google) have been asking for.

Unattested AAGUID came up at the F2F as an acceptable way to solve this problem too, but at the time I don't think many of us thought AAGUIDs without attestation would catch on...

I agree that if we could get authenticator vendors to buy into the idea of returning a valid AAGUID under more circumstances (i.e. no attestation) it would solve this problem and a couple other "UX optimization" problems that RP's can have when trying to communicate passkey identity to users. The kind of problems that can be solved without needing a signature over the values because it's metadata that presents a low risk of weakening RP security posture if someone "spoofs" authenticator identity.

[sbweeden]

I am fine with these changes. It would provide a more standardized way of communicating back a nickname to the RP, which might be pre-populated by the client or authenticator, or when they do not provide a value, the RP might prompt for it.

[emlun]

or when they do not provide a value, the RP might prompt for it.

This got me thinking - could it make sense to define an autofill detail token like webauthn-authenticator-nickname to go with this? I'm thinking perhaps that could be a way to both get the value into an input field easily and also unobtrusively offer the user to save the value to the authenticator configuration after the fact.

Though I can see one complication already: in case there's not exactly one authenticator present, how does the client decide which one's nickname to autofill and optionally update? Intuitively it should of course be "the one that was just used", but that's not so easily defined when the user may wait an indefinite length of time before submitting the nickname, may have performed subsequent WebAuthn ceremonies in other tabs, etc. Perhaps you could associate by credential ID somehow, but I've a feeling this gets much too complicated for such a minor feature.

[ndpar]

Looks good to me

[arnar]

(I won't be able to review until mid September. Feel free to sub me with someone if needed earlier.)