Provide a method to get the count of the credentials of a rely party on client device on user permission

[bigradish]

The method asks the user to release the information and returns a Promise which is resolved with the count when the user permits, and is rejected with a deniedByUser exception when the user denies.
This method can help the website to limit the number of accounts a user can register on it, and at the same time respects users' privacy.

[emlun]

This will not work the way you want, it will be trivial to circumvent:

window.PublicKeyCredential.getNumberOfCredentialsWithUserPermission = async function (options) {
  return 0;
};

Sure, not all users will know to do this. But once it becomes commonly known that websites use this technique, it will be equally trivial to create a browser extension that does this, or share it as a scriptlet that you can just paste into the console to bypass such site restrictions. Which is in itself harmful too: normalizing the idea of running strangers' code will lead to all kinds of malicious abuse.

The problem is that you do not trust your users to obey your terms of service, so you're asking for the browser to enforce your ToS. But the browser is the user's agent, in the user's control, so you cannot trust the browser to do it either. The user can just choose a browser that doesn't enforce your demands. This approach can never work, because the premise contradicts itself.

Therefore I am against this. Even with a permission prompt, this would be a net loss for privacy since we don't even gain any benefit in exchange, given that it wouldn't serve its purpose anyway.

[emlun]

(See also previous discussion in #2222)

[yackermann]

@bigradish @emlun Not only that, but there are technical limitations as well.

1. Platforms are no longer monolith, but a plugin ecosystem, that allows third party providers, like Dashlane, 1Password, etc to provide passkeys. This means that they would have to have API, that allows non-authorized enumeration of the credentials, which is not only technically might not be possible (see encryption), but would be a gross privacy violation (see russian govt wanting to know where u have accounts).
2. Passkey providers might not even know how many credentials they have. If they do non-exportable non-discoverable credentials, that are stored in secure enclave, and they don't allow user manage them, like it works in FIDO2/U2F, then it might not even know that it has those credentials.
3. Security keys exist, and user can plug them in after you request authentication. And again, if they are non-discoverable, then security keys won't be able to enumerate them.

Passkeys are not meant to deal with T&C of the website. It's a tool to sign challenges, that happens to be useful as a part of authentication.

[bigradish]

@emlun @yackermann Thank you very much for your reasonable explanation.
I'm thinking this solution: In the CredentialsContainer.create() method, add an option to ask the user to let the authenticator return its GUID in the response. If the user denies or the auhenticator fails to do this, the create method fails with exceptions.
This requires that all authenticators have their GUIDs.
How do you think of this?

[Firstyear]

@bigradish What are you trying to achieve here? What's the end goal? I feel like your making technical suggestions to solve a problem you have, but without explaining what your problem is.

[bigradish]

@Firstyear Hi, I use pure webauthn to let users register accounts on my site and try to find a way to limit the number of accounts a user can register.
If authenticators have their GUIDs and provide them in the result of the create method, they can be identified on the server side, and then the goal can be achieved.

[nicksteele]

By GUID do you mean the AAGUID?

[nicksteele]

Assuming you mean the AAGUID, that is not actually a unique identifier of the specific authenticator that is being used. For instance, 1Password's AAGUID just identifies that the request was handled by an instance of 1Password

[Firstyear]

@Firstyear Hi, I use pure webauthn to let users register accounts on my site and try to find a way to limit the number of accounts a user can register. If authenticators have their GUIDs and provide them in the result of the create method, they can be identified on the server side, and then the goal can be achieved.

You can't achieve this with webauthn. There is no way to limit or track users based on the authenticator they register.

You need to find other ways to limit account sign ups.

[yackermann]

@bigradish

That would disclose privacy sensitive information, as well as wont solve anything else.

Use can have multiple passkey providers. Each would have to ask user consent, or you will have limited scope, one password manager. User can as well export credential, delete it, register, re-import.

Or user can custom credential provider. Or passkey manager decides to lie because of privacy.

And again, this does not solves issue of non-discoverable credentials, and security keys.

And lastly, what if the same laptop is used by both wife, and husband? In that case you would stop husband from registering?

So to summarise:

• Technically difficult (or impossible)
• Privacy horrible
• Easily bypassed
• Effectiveness little
• Value, little.

If you want to prevent users re-registering, aka ensure user uniqueness, aka personhood, KYC like iProve can solve it much better.

Again, webauthn is a tool for generating assertions, not account management and enforcement police.

[bigradish]

I just ask whether it is possible that each authenticator is given a GUID (not AAGUID), which can be returned in the result of the create method if the user permits.
Thank you very much.

[emlun]

That would be even worse for privacy (as others have already pointed out) and still have the same problem that it's trivial to bypass. Again: why would the user be honest about returning a genuine GUID (remember, the user can just choose a browser that returns a random GUID on every call) if you've already assumed they're not honest about only registering one account? Even if we assume the GUID feature was implemented and worked flawlessly with all authenticators in all browsers, why wouldn't the user just get a second authenticator to register a second account?

It would not solve your problem, would not respect user privacy, and would not be backwards compatible with existing hardware security keys. There are no benefits to this, only downsides.

[bigradish]

I think you may not get what I mean. I say 3 points: 1. About bypassing. I said the GUID is put in the result of CredentialsContainer: create method. If the browsers makers are willing, they can make the create method as "read-only" or "unconfigurable". This can prevent the create method from being replaced/bypassed in browser extensions or scriptlets. 2. About user privacy. I said: add an option in the create method, e.g., "requireAuthenticatorID". This optin is defaulted to "false", and if it is set to "true", the brower will ask the user to decide whether he/she permits the authenticator GUID to be returned when the create method is called. If the user denies, the GUID will not be provided, and the create method fails with an exception. 3. I never said one account per user. I said: "limit the number of accounts a user can register". A user can register two or more accounts with one authenticator, and can register even more with more authenticators, but this costs him/her money and time. This is the effect to reach.

…

________________________________ 发件人: Emil Lundberg ***@***.***> 发送时间: 2025年2月8日 9:58 收件人: w3c/webauthn ***@***.***> 抄送: bigradish ***@***.***>; Mention ***@***.***> 主题: Re: [w3c/webauthn] Provide a method to get the count of the credentials of a rely party on client device on user permission (Issue #2255) That would be even worse for privacy (as others have already pointed out) and still have the same problem that it's trivial to bypass. Again: why would the user be honest about returning a genuine GUID (remember, the user can just choose a browser that returns a random GUID on every call) if you've already assumed they're not honest about only registering one account? Even if we assume the GUID feature was implemented and worked flawlessly with all authenticators in all browsers, why wouldn't the user just get a second authenticator to register a second account? It would not solve your problem, would not respect user privacy, and would not be backwards compatible with existing hardware security keys. There are no benefits to this, only downsides. ― Reply to this email directly, view it on GitHub<#2255 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABBYBYJESTYOVTO2HH7I5KD2OVQDHAVCNFSM6AAAAABWTDGMK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBUGQZDIOBYHE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[yackermann]

1. Are you referring to excludeCredentials. Again this would only prevent user from re-registering the same device for the same account.
2. That would disclose that user does not want to share information.
3. Again WebAuthn API is not account management system lol. It's a key management API.

And lastly, as stated before, web security model is based on no trust to the user side. Server must at all times be aware of that nothing that comes from the browser can be trusted.

Making stuff read-only, etc, does not matter since extensions will just override your JS, and send you false information.

Most importantly, malicious actors won't care for the browser, specs, what ever. They will simply run broken version of the browser, with "fixed" api, and abuse your system to the end.

Best you can do is correctly build your threat model, use KYC techniques, like iProve, etc, register people by phone number, and many many other ways to limit attack vector.

OWASP is your friend https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html

[bigradish]

Thank you for your answers. 1. I'm not referring to excludeCredentials. I'm talking new account registration. 2. That is too trivial to be a user privacy. 3. Actually, AAGUID (Authenticator Attestation Globally Unique Identifier) is already present, whose authenticity is ensured by Attestation. But AAGUID only indicates the make and model of the authenticator. If each authenticator is given a GUID (AGUID), or just a shorter id string to identify it from the authenticators with the same make and model, it can be returned along with the AAGUID. For AAGUID, see https://w3c.github.io/webauthn/#aaguid For Attestation, see https://w3c.github.io/webauthn/#attestation For Attestation Certificate, see https://w3c.github.io/webauthn/#attestation-certificate

…

________________________________ 发件人: Ackermann Yuriy ***@***.***> 发送时间: 2025年2月11日 16:56 收件人: w3c/webauthn ***@***.***> 抄送: bigradish ***@***.***>; Mention ***@***.***> 主题: Re: [w3c/webauthn] Provide a method to get the count of the credentials of a rely party on client device on user permission (Issue #2255) 1. Are you referring to excludeCredentials<https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-excludecredentials>. Again this would only prevent user from re-registering. 2. That would disclose that user does not want to share information. 3. Again WebAuthn API is not account management system lol. It's a key management API. And lastly, as stated before, web security model is based on no trust to the user side. Server must at all times be aware of that nothing that comes from the browser can be trusted. Making stuff read-only, etc, does not matter since extensions will just override your JS, and send you false information. Most importantly, malicious actors won't care for the browser, specs, what ever. They will simply run broken version of the browser, with "fixed" api, and abuse your system to the end. Best you can do is correctly build your threat model, use KYC techniques, like iProve, etc, register people by phone number, and many many other ways to limit attack vector. OWASP is your friend https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html ― Reply to this email directly, view it on GitHub<#2255 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABBYBYKX7PQ3G6H3BAJ7XJT2PG3M5AVCNFSM6AAAAABWTDGMK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJQGE3TMNJUHA>. You are receiving this because you were mentioned.Message ID: ***@***.***>