Deprecate rp.name - Githubissues

w3c / webauthn

Web Authentication: An API for accessing Public Key Credentials

https://w3c.github.io/webauthn/

Other

1.19k stars 172 forks source link

Deprecate rp.name #2121

Closed nsatragno closed 1 month ago

nsatragno commented 3 months ago

Proposed Change

Remove, deprecate, or ignore PublicKeyCredentialRPEntity.name. It's not used by any credential provider that I know about.

This might be tricky because it's inherited from PublicKeyCredentialEntity.name.

emlun commented 3 months ago

Summary of the discussion on the 2024-08-14 WG call:

https://github.com/w3c/webauthn/pull/2093#issuecomment-2282813017 currently doesn't have a field for updating rp.name, and it seems inconsistent to allow updating some otherUI fields but not others.
No known client implementation actually uses rp.name in any meaningful way.
rp.name is arguably the "most phishable part" of WebAuthn, as unlike rp.id it's not subject to any security checks.
For these reasons, we don't really want to include an update signal for rp.name.
Another way to resolve the inconsistency is to deprecate/remove rp.name instead.

emlun commented 3 months ago

As also mentioned in the discussion, we probably can't actually remove rp.name, or make it optional, since it's required in L1 and L2. Both of those changes would create a trap where RPs don't include rp.name, since it's not required, but when that code happens to run in an L1 or L2 client it would raise a TypeError since the attribute is required in that version.

Instead, there was consensus on the call in favour of simply changing the definition and description of rp.name to "unused and meaningless, but still required for backwards compatibility, so just set it to empty string".

zacknewman commented 3 months ago

Instead, there was consensus on the call in favour of simply changing the definition and description of rp.name to "unused and meaningless, but still required for backwards compatibility, so just set it to empty string".

Setting it to an empty string will not be backwards compatible for clients that enforce the Nickname profile as recommended by the L2 spec since empty strings are not valid Nicknames; however enforcing Nicknames is “only” a recommendation and is likely not enforced by many clients.

nicksteele commented 2 months ago

General sentiment from the 2024-9-11 call seemed to be in favor of deprecation

emlun commented 2 months ago

2024-09-11 WG call: Hearing consensus in favour of deprecating rp.name. @emlun to write a PR.

@zacknewman has a fair point that empty string may not be an entirely safe fallback value. We don't know of any clients that actually enforce the nickname profile, but still.

timcappalli commented 2 months ago

2024-09-18 call: instead of deprecating or making optional, add some text stating many clients will not display the value and to pass either the RP ID again, or an empty string. Also update passkeys.dev guidance.