Update name, displayname and icon for RP and user

[Kieun]

Depending on the scenarios or cases, RP or user may change their displayable contents like name, displayname or even icon. Since such information is supplied during the registration and used forever, if RP or user changes such information in the RP side, such information needs to be updated on the client or authenticator side. The best way is to support it is synchronization between RP and the authenticators. But it is almost impossible in case of roaming authenticator. It would be better if we provide the API or parameters at the time the authenticator is really used for authentication.

[akshayku]

Looks like a real use case to me.

But was wondering that if name (email) really changes?? In usernameless flows, this information cannot be provided in the authentication. In username flows, will RP provide different name in the API??

[Kieun]

@akshayku depending on the services, the name can be other attributes like phone number or even nickname such information can be altered. Unlike the traditional web services, such RPs (services) may not have such name almost like an identifier (email).

[emlun]

This is currently possible to do by replacing an existing credential, by performing a new registration ceremony with the same user.id but omitting the credential to be replaced from excludeCredentials. But I agree it could be done more smoothly if it didn't require an additional ceremony invocation just to replace the credential metadata. I guess one of the best options for how to do this would probably be an authentication extension?

On the other hand, though: would this risk users getting confused when credential names suddenly change with little or no warning? How big a deal would that be?

[Kieun]

In case of the name for user, the user has the consent for the modification since such name changes are requested by the user. For the RP case, RP may change their logo and it would be better to replace the old one with new one.

[emlun]

For RP logos I think it's much more likely that RPs will sett rp.icon to a dynamic https: URL rather than a static data: URL since you can't fit much of an icon in 128 bytes, let alone Base64 encoded.

I was more worried about rp.name, but on second thought that shouldn't matter much since the user doesn't need to choose the RP in a normal ceremony anyway. It could matter for (as-of-yet unstandardised) credential management interfaces, but I guess that should be fine.

[Kieun]

I agree. For the fetching URL from the remote source (https) happens at the time of registration once and then such fetched icon is stored in the authenticator. See following descriptions: https://w3c.github.io/webauthn/#ref-for-dom-publickeycredentialentity-icon

Authenticators MUST accept and store a 128-byte minimum length for an icon member’s value.

[emlun]

fetching URL from the remote source (https) happens at the time of registration once and then such fetched icon is stored in the authenticator

That behaviour is not mandated by the spec, in fact neither WebAuthn nor CTAP says anything about what the authenticator is supposed to do with rp.icon other than somehow "store" it. It's equally permissible for the authenticator to simply store the https: URL without resolving it.

[leshi]

From call on 06.12.19: we believe that no normative action is warranted. RPs can already overwrite credentials. Maybe eventually add that as a recommendation. punting to L3

[ptman]

This is currently possible to do by replacing an existing credential, by performing a new registration ceremony with the same user.id but omitting the credential to be replaced from excludeCredentials. But I agree it could be done more smoothly if it didn't require an additional ceremony invocation just to replace the credential metadata. I guess one of the best options for how to do this would probably be an authentication extension?

Has anyone done this in practise? I tried, and get a new credential identifier. So am I supposed to replace the old credential with this? Or should I be getting back the same ID that I left out from the exclusion list? Using the same user ID

[emlun]

@ptman If you create a new credential with the same rp.id and user.id it will overwrite the existing one in authenticator storage, but you'll get a new credential ID and would need to replace the credential ID, public key, signature counter and attestation statement (if stored).

This issue is probably superseded by #1779 now.

[emlun]

Closing as superseded by #1779, let's continue any further discussion there.