Controlling the Name Displayed During WebAuthn Registration (and Authentication)- 3 minute read
WebAuthn defines two possible values that Relying Parties can set to help users understand for which account they’re registering a credential and using in subsequent authentications:
It was unclear to me from reading the spec how exactly I was supposed to use either value:
When inherited by
PublicKeyCredentialUserEntity, it is a human-palatable identifier for a user account. It is intended only for display, i.e., aiding the user in determining the difference between user accounts with similar
displayNames. For example, “alexm”, “[email protected]” or “+14255551234”.
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.
Practically speaking, it seemed easy for an RP to misconfigure these values and get users into a state in which it’s difficult to know, for example, which environment/deployment/etc… a particular passkey was good for:
Which credentials are still valid? Which can I delete? From these real-world examples it seems impossible to tell.
I decided to attempt registration across the most common platforms and browsers and record which of these two values made it into UI that users actually see. I was also curious to see which of the values appeared in credential management UI. In the end I hoped to understand how I might better leverage these values to help users manage their passkey collections.
## Chrome M109 (macOS 13.2)
user.name for both registration and passkey management.
## Safari 16.3 (macOS 13.2)
Safari also used only
user.name for registration and passkey management.
## Windows Hello (Windows 11 21H2)
Windows Hello solely used
NOTE: I couldn’t find passkeys management in Chrome on Windows, but I’ve been informed I need to be on Windows 11 22H2 to see it. I’m updating now and will update this section when I can grab a screenshot (it’ll probably look like macOS Chrome above)
## iOS 16.3
iOS too limited itself to using
user.name for registration and management.
## Android 13
Android was the only platform that leveraged both
Based on what I observed today it appears that
user.name is an RP’s best option for differentiating credentials that use the same username but only work for specific environments/deployments/etc…
(BTW I submitted a GitHub issue to the WebAuthn spec related to differentiating credentials via a new “
note” value in registration options. Based on what I’m seeing above, though, I can agree with Yubico’s John Bradley that there’s an opportunity for clients and platforms to also leverage
user.displayName instead of adding anything new.)