User name and displayName change for existing passkey

The publicKeyCredentialCreationOptions contains a user object with an id, name, and displayName.

I understand the id is unique and not visible to end users, so it will never change.

However, what about name and displayName? On many platforms, users can change their name, username, and email. How would these fields be updated on the passkey? I do not seem to find a way to do it.

The short answer:

• Usernames (username and displayName) in the pass manager entry are in the control of the user and hence it is actually not your responsibility to maintain such labels as a domain service provider (relying party).
• These fields are logically decoupled from authentication but there is a serious design problem in the webauthn specs that makes these fields "required" (the fields could be deleted, but at least should be made not required).
• The thinking should be that normally there is only one account per user per domain, and if not, it is the responsibility of the user to maintain labels to entries in his pass manager. (It is actually not an opinion, it follows from decoupling logic!)
• No wonder people are confused and you get hacky answers even from people who are involved and knowledgable (like create a totally new passkey and then you gain some power to manipulate these labels in the pass manager though they have nothing to do with actual authentication).
• There is no good solution thanks to this design horror, one solution that is logically correct that you use blank fields for both usernames and realize it is not your responsibility to manage labels for the user. Currently it is bad pass manager UX by all three (Apple, Google, Microsoft) even if there is only one account per domain and more so by multiple accounts (default could be readable creation date instead of blanks)

The long answer with some background:

• You create as domain service provider (relying party) the random user id / handle which I will just call PID (passkey id) since the user identity is tied to holding the private key or passkey.
• On the device, a key pair is created where the passkey (private key) is stored like xyz.com -> PID -> passkey whereas you get and store the verification key (public key) on the server after creation.
• By verification, you send a random challenge to the device which looks up the PID and passkey to your domain, signs over your challenge with passkey and sends you PID & signature (where now PID is called user handle not user id but it is the same).
• In the current pass manager UX (I checked mostly an android phone with google pass manager) users can even freely change both username fields themselves. There is even a reminder that you can freely edit these fields and your account will not change.
• usernames and emails as user ids without real function (and user opt-in) are a bad habit with a privacy smell... at least from the dawn of pass managers your identity can securely be just a long random string that is username and password in one... why is it not so then?
• at the beginning, there was this naive I am "joe22" and my password is "nobodywouldguessthis" but then web became somewhat more serious... passwords were weak and emails were unique, then emails were handy for tracking and for ad spam and direct marketing, then misused for account recovery
• the passkey concept now mixed up the old world with the new: in the registration and verification flows and on your server you must use the random PID (or if there are different apple-google-microsoft-linux passkeys, all 4 PID with 4 different verification keys)
• however, for authentication, you must(!) give username and displayName by the registration too... despite the fact that they have actually no meaning in the authentication process more than labeling the credential per domain in case there are more accounts per domain or for whatever reasons (it is actually legacy thinking: the transition from: the user is "username" (and the proof is the password) DID happen with passkeys towards "the user is the passkey holder" but the current specs and UX just cannot or dare not let go of usernames)
• I think this horror show began when webauthn wanted 2 actually contradicting things: decouple authentication from usernames for privacy (hence the existence of user id/handle or how I just call it: PID) and act as if it was just swapping bad passwords to good passkeys and everything else stays the same and hey people, come and please impement me, I am familiar to you arent I!
• the only problem is that this design is fundamentally wrong and problems and confusion pop up until the actual real problem is solved at the roots: dare explicitly eliminating usernames from authentication, not just logically
• you see the problem and that is why you asked the question: you feel that you have total control over usernames on the server but not on the client in the pass manager and you feel the urge/pressure to maintain the user's pass manager labels instead of letting the user take care of it
• this confusion emerges because the responsibility space is not explicitly clearly defined: who is responsible for what... even the answer from a spec contributor suggests you do have to care and update the usernames on client side, moreover, you should do so by making a totally new(!) credential for it because that is the only way to gain some control over the pass manager entry (what you actually should not do, because it is simply not your responsibility and in the normal case of one account/domain it makes absolutely no sense, either...)
• if you decouple the usernames from authentication, well, it is decoupled... a relying party has NO real control over pass manager username entries, which can be changed anytime by the user to anything, not affecting authentication, since authentication happens with domain->PID->passkey and any labels like the usernames are just hanging if there is only one account per domain...
• yes, it would and should be so simple as: create your passkey for xyz.com and use your passkey for xyz.com

More about multiple accounts per domain:

• it is possible for users to create multiple accounts for any web domain that will not enforce real identity checks (even if it makes actually no sense)
• why people in fact use multiple accounts is probably because usernames and emails reveal an identity in the first place (or they cheat with free credits)
• so in the open web people may(!) end up with their pass manager having 2-3 entries for the same domain (in a pass manager more entries are shown even if blank usernames are used, since PID is used in the background as identifier)
• only(!) if that happens, should a domain account chooser in the pass manager UX come up (where if nobody used usernames or display names, and the user did not maintain the labels, you see two blank rows now... there could be a readable creation date instead)
• but is it a problem? or rather: whose problem and whose responsibility is it?
• it all boils down to the basic design decision: if we decouple usernames logically then they cannot and should not be managed from the server, and only the PID will be coupled to the passkey, not the usernames
• I would also discourage to use usernames as labels in the pass manager since if they decoupled, they may change, and if they change, it seems to be too complicatd for the user to sync changes in the pass manager (even better, if there is more than one passkey and more than one pass manager like pixel-ipad-surface-linuxpc combination without centralized pass manager, you change your email adress that was the username of your password on one of the devices and you have to maintain all 4 pass managers which will never happen, at least in the real world with real users, but labelling chaos starts to unfold)
• the solution is actually straightforward from the decoupling design decision: it is the users responsibility to label its pass manager entries (if he has more than one per domain) and the default should be one account per domain without any labels for simplicity
• the pass manager ux should provide some note field where the special case of more accounts per domain can be handled, by the user, but thats it

Until redesign, there is no real good solution. You can just leave these required username fields blank, just dont care and hope that they will not be required in the future and that Apple/Google/Microsoft registration and verification UX flows will not be awkward showing unnecessary text and blank username fields like now... At least not until a user decides to create multiple accounts on your domain for whatever reason. But then he also has to maintain the labels in his pass manager!

With correct rethink, the solution to your problem would be that you just do not have to do anything: change uid->email or uid->username internally on the server and thats it! The uid->pid->verification key can stay on your server as it was. The user just authenticates to your site as before with "use your passkey" on xyz.com. No new passkeys, no maintaining and micromanaging the pass manager labels of the user is needed.