A passkey with a name of its own

When cross-device player accounts arrived, a passkey could be registered without linking Google. But every new passkey had the same name in a password manager: player. The registration flow now gives each new credential a recognizable device label, making the account usable without asking players to remember which identical entry belongs to which device.

The name was not the display name#

The server already supplied a user name, so the first assumption was that authenticators would show it. A test against the installed WebAuthn library exposed the gap: its displayName defaults to an empty string. Password managers and sign-in pickers often show that field, leaving the carefully supplied name invisible. The fix passes the same value into both fields.

generateRegistrationOptions({
	userName,
	userDisplayName: userName
});

Label new registrations at the source#

The label comes from the request’s browser and operating-system information, derived on the server for both signed-out account creation and adding a passkey to an existing account. If the request does not provide a recognizable device, the name falls back to Player. That keeps the credential label useful without introducing another form field or trusting a name typed by the player.

This change applies to passkeys created from now on. Authenticators keep the old name on credentials that already exist, and the server has no way to rename them after registration. Updating those would require a separate client-side flow, so the fix leaves existing credentials alone unless their labels become a real source of confusion.

The account now has a clearer path for new passkeys, whether or not a Google identity is attached. The remaining question is whether the older, identical names are confusing enough to justify a client-side update.