Emphasize use of user.name for RP's to help users distinguish credentials

[MasterKale]

Context

RP's, like us at Cisco, use WebAuthn with a broad RP ID scoped in a way to allow for credential reuse across multiple "applications" on unique subdomains. Unfortunately, we've discovered that current, nascent passkeys management UIs emphasize displaying a credential's RP ID and username, which are often

Chrome:

1Password:

Safari (macOS):

Proposed Change

What if we added a "note" property somewhere in PublicKeyCredentialCreationOptions to allow RP's to annotate a credential for the management interfaces to then expose to users for the user's ease of management?

Here are examples of places that "note" could go:

1Password ("notes"):

Safari ("Notes"):

This feels beneficial to both RP's and end users.

[Firstyear]

Would the note be embedded in the resident key itself though? How will this work for yubikeys?

Feels a lot more like this is a specific notes field for passkeys that are managed by platforms.

[MasterKale]

Would the note be embedded in the resident key itself though?

Perhaps it's more of a "client note", and leave it up to clients to handle maintaining a note for a given credential ID? The spec could add the value and suggest how clients might benefit from it, then leave the synchronization up to the clients like how we do with passkeys backup.

How will this work for yubikeys?

A "client note" model would potentially work for Yubikeys too.

[ve7jtb]

We have two fields now, and from the looks of it only one is being displayed.

We should try to get some consistency with what RP are sending and User agents are displaying before adding another field that won't be displayed.

If what is currently displayed is displayname then having the name be "mmiler@beta_environment" would be what was originally intended. The name field is the name of the account to display to the user in whatever format the RP wants.

I suspect this is an education problem along with the platforms not showing the info.

[james-d-elliott]

Yeah by my reading of the following section this is the intent of the displayName: https://www.w3.org/TR/webauthn-2/#dom-publickeycredentialuserentity-displayname

A human-palatable name for the user account, intended only for display. For example, "Alex Müller" or "田中倫". The Relying Party SHOULD let the user choose this, and SHOULD NOT restrict the choice more than necessary.

[MasterKale]

If what is currently displayed is displayname then having the name be "mmiler@beta_environment" would be what was originally intended.

displayName doesn't read like the kind of value that'd look like "mmiller@beta_environment". The name examples in the spec constrains thoughts of what are appropriate values for this field to "full name" representations of the user. Perhaps there's a chance here to expand the examples to denote this could be used for my "Beta Environment" example.

A human-palatable name for the user account, intended only for display. For example, "Alex Müller" or "田中倫". The Relying Party SHOULD let the user choose this, and SHOULD NOT restrict the choice more than necessary.

PublicKeyCredentialUserEntity's name property seems similar, too - this field seems like it'd be where the user's email address might go:

The name field is the name of the account to display to the user in whatever format the RP wants.

So if we wanted to encourage full use of PublicKeyCredentialUserEntity, perhaps we can clarify these two further with example use cases to satisfy my proposal.

[MasterKale]

It turns out both Chrome and Safari use user.name when displaying passkeys:

Chrome:

Safari:

Windows:

Android (uses user.displayName too):

[emlun]

I would be in favour of adding a few examples showing these use cases for user.displayName and/or user.name. There's no reason user.name would have to be the account's primary email address (if any), it could easily accommodate something like mmiller (FooBank via AcmeIAM) if the RP has several distinct namespaces (like some IAM services do). I guess we just hadn't considered that use case much, so the examples are a bit lacking.

Maybe we should also add a symmetric mention of "determining the difference" to displayName - the name description currently reads:

[...] It is intended only for display, i.e., aiding the user in determining the difference between user accounts with similar displayNames. [...]

but displayName does not have a similar mention of disambiguating similar names. There's really not much reason either should be more or less likely to be similar between credentials.

[james-d-elliott]

I think clarifying several of these parameters and their use cases may be helpful. For example another similar attribute that may be used is the PublicKeyCredentialEntity's name value: https://w3c.github.io/webauthn/#dom-publickeycredentialentity-name

It also is meant to be human-palatable and may be chosen by the end user. In the context of this issue maybe this one mentioned is more applicable as it's more closely related to the actual credential itself?

[MasterKale]

I think clarifying several of these parameters and their use cases may be helpful. For example another similar attribute that may be used is the PublicKeyCredentialEntity's name value: https://w3c.github.io/webauthn/#dom-publickeycredentialentity-name

In the screenshots above this is what I meant by "user.name", it's this property that is currently used to help convey information about who a credential belongs to.

[james-d-elliott]

Yeah I've completely misunderstood the spec in this area, both user.name and user.displayName are specific to the WebAuthn User Account, not the individual credential itself. It actually makes quite a lot of sense that a specific WebAuthn User Account may have multiple credentials and that something exists to clearly differentiate them in those circumstances.

[MasterKale]

There's been clarification that user.name can be arbitrary strings, not necessarily only email or user name. user.displayName may be supported in certain clients and OS's, but by and large RP's should only count on user.name being regularly shown to users.