Facility for an RP to indicate a change of displayName to a discoverable credential

[Firstyear]

I was talking about this previously with @nsatragno, that there should be a method for an RP to indicate to a device that it may need to update it's knowledge of the users displayname.

Let's consider I have a yubikey which contains a discoverable credentaila that I use in a "usernameless" flow (conditional ui).

I update my displayname from William to Steve on the RP's user management interface.

The next time I authenticate from my yubikey it would still prompt me to "login as William" (even though it will send the binary unique user id which correctly maps to my identity). Very few devices today publish administration tools allowing these to be updated which can be problematic for many types of person.

A possible method to address this could be an extra "ceremony" type that indicates to the browser that the credential ID indicated SHOULD update it's knowledge of the display name. For ctap2.1 this would use https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#updateUserInformation underneath. Other authenticators need to perform their own methods to update.

This would allow the RP to list the authenticators registered by the user, along with an "update name" option that would initiate this possible workflow.

There are plenty of possible other ideas that could resolve this, but I think at the least a way for an RP to indicate that a display name needs update would be really important and helpful!

[nuno0529]

I think possible approach from RP now is to send 2 make() commands continually with considering privacy and authroization.

• make() with the credentialId need to update displayName in excludeCredentials to identify the target authenticator to update . If it's the target device, it' will just ask UP as similar behavior like selecting device.
• then another make() with the same user.id to overwrite the credential with new displayName.

Although the 2 make() commands are stateless, there should be something client/browser can help in this part.

[emlun]

While we indeed don't currently have a way for RPs to do this - except overwriting the existing credential with a new one by setting the same user.id - CTAP2.1 does have a credential management command capable of updating user information, and at least the Chrome settings support it (see chrome://settings/securityKeys).

[Firstyear]

@emlun I'm thinking something like a third operation in https://www.w3.org/TR/webauthn-3/#sctn-rp-operations like "update credential metadata" or similar? And yes, it should rely on the management commands for updating info, rather than overwriting the credential.

[Firstyear]

Any ideas on how we could proceed here @emlun?

[emlun]

I'm not sure. We discussed this a bit on the 2022-07-27 meeting, and there's tentative support for "something" to support this. It gets complicated because external authenticators are intermittently connected, and because CTAP2.1 doesn't keep authorization state around long enough to follow up a getAssertion operation with a credential management operation without re-authenticating, but discussions have started in FIDO about perhaps doing something to support this in CTAP2.2. But the first step is for the platforms to implement support for credential management at all. Then if all else fails, the new "operation" might end up simply opening the credential management UI, perhaps with new values prefilled or something.

[nsatragno]

From TPAC: a possible, privacy-friendly design for this update would be to leverage a Reporting API (see relevant previous issue). After a successful sign-in, the RP can call an API that tells the user agent some state about the passkey:

• Whether the passkey was accepted or rejected
• The current displayName and name for the user.

The user agent can then decide to prompt the user to update the displayName and name on the credential.

This "reporting api" may need some updates on ctap 2.2 if we don't want to have the user tap their authenticator again to make this change, but since there's going to be a prompt anyway, perhaps we are okay with it.

[timcappalli]

closing to consolidate discussions on this topic. please continue discussions here: #1967