- From: Matthew Miller via GitHub <noreply@w3.org>
- Date: Mon, 27 Oct 2025 21:44:44 +0000
- To: public-webauthn@w3.org
The explainer proposes [exposing user info support](https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-requestUserInfo#feature-detection) via some new capabilities:
> The availability of this functionality and list of attributes must be detectable by the relying party. We'll extend `ClientCapabilities` to reflect each attribute:
>
> - `userInfoIdentifierPhone`
> - `userInfoIdentifierEmail`
> - `userInfoAttributeName`
Could `requestUserInfo` feature become a reason to expand the definition of `ClientCapabilities` to allow more dynamic feature values than `boolean`? e.g.
```js
const capabilities = await getClientCapabilities();
// {
// ...,
// userInfoIdentifier: ["phone", "email"],
// userInfoAttribute: ["name"],
// }
```
Also @nsatragno it's still unclear to me from the explainer why, if `identifier` gets used for `user.name` and `user.displayname`, then why is `name` in a separate `attribute`? This just seems like a collection mechanism for getting the user's name when WebAuthn wouldn't normally need to know that to populate `user.name` and `user.displayname`. i.e. RPs are already expected to ask for this info out of band, so why are we adding a mechanism for requesting the user's name as well in the ceremony output? Right now I'd be inclined to suggest we **don't** allow requesting a name attribute and just focus on enabling the obviously useful User Agent-facilitated collection of the identifiers needed for populating `user.name` and `user.displayname` 🤔
--
GitHub Notification of comment by MasterKale
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2336#issuecomment-3453451562 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 27 October 2025 21:44:45 UTC