Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add a method to get the count of the credentials for a rely party on the client device to support the rely party (website) to limit the number of accounts a user can register #2222

Closed
bigradish opened this issue Dec 27, 2024 · 20 comments
Closed

Add a method to get the count of the credentials for a rely party on the client device to support the rely party (website) to limit the number of accounts a user can register #2222

bigradish opened this issue Dec 27, 2024 · 20 comments
Labels
stat:Discuss subtype:FeatureProposal

Comments

@bigradish
Copy link

bigradish commented Dec 27, 2024 •
edited
Loading

It is very easy for a user to register many accounts on a website which using webauthn, but it seems that there is no an easy way to limit this capability of the user, for it is not easy to identify the user or the authenticator (many platforms do not return its AAGUID even if the "enterprise" conveyance option is used.) using javascript in browsers when the user is registering.
If there is a method that can get all the credentials for a rely party on the client device, the rely party (website) can easily limit the number of accounts a user can register using the client device.
Thank you very much.
@MasterKale
Copy link
Contributor

It is very easy for a user to register many accounts on a website which using webauthn, but it seems that there is no an easy way to limit this capability of the user, for it is not easy to identify the user or the authenticator...when the user is registering.

I don't entirely understand what is being requested here. Limiting new account creation to dissuade one user from registering multiple accounts is a problem for the RP whether it uses passwords+2FA or passkeys. Passkeys aren't really a good means for achieving this.

If there is a method that can get all the credentials for a rely party on the client device, the rely party (website) can easily limit the number of accounts a user can register using the client device.

This sounds like credential enumeration, which is frowned upon in the WebAuthn space for how easily it can be abused by bad actors.

@bigradish
Copy link
Author

bigradish commented Dec 27, 2024 via email

@sbweeden
Copy link
Contributor

sbweeden commented Dec 27, 2024 •
edited
Loading

Hi, thank you for your answers. I use pure passkeys to let users register on my site, and hope passkeys can be good at limiting the number of the accounts a user can register. Yes, I mean credential enumeration. I think as a rely party can only get its own credentials, this will not cause bad problems. Do you think so?

This is very much a problem since the RP could now tell that the same human or device owner was in control of those multiple accounts.

@bigradish
Copy link
Author

bigradish commented Dec 27, 2024 via email

@sbweeden
Copy link
Contributor

This type of behaviour is called account linking, or account tracking, and is an anti-pattern with respect to end user privacy, whether it be across domains on the internet, or between separate accounts on the same RP/website. I am highly confident the WebAuthn WG will not support any notion to introduce a capability like this. By way of example, if I have 5 google accounts, Google doesn't need to know, nor should they, that they are all mine. They are completely separate personas that I (as an end user) want distinct for privacy reasons.

If as an RP you're trying to bind an account to a human, then use a 3rd party identity proofing solution (not an authentication technology like WebAuthn) to do that. Real humans will find it difficult to provide the burdens of proof required to satisfy different human identities for many accounts at the same RP.

@bigradish
Copy link
Author

bigradish commented Dec 27, 2024 via email

@sbweeden
Copy link
Contributor

I'm sure it will come up as a topic at the next WG call, and will let that process take its course, but I'm almost certain the answer will be against. There isn't even a discovery API to figure out if any credential exists at all, let alone provide a number. This is why the "autofill UI" (also known as conditional mediation) version of WebAuthn behaves the way it does. The notion of whether or not a credential exists on the client device and is shown in autofill dropdown to the user is not discoverable to the RP until the user decides to use it. The RP is not entitled to know this - again for privacy reasons.

@bigradish
Copy link
Author

bigradish commented Dec 27, 2024 via email •
edited
Loading

@agl
Copy link
Contributor

agl commented Jan 8, 2025

The WG has pondered this several times and remains of the opinion that browsers should not silently release credential metadata for privacy reasons. There is a possibility that an API similar to one that exists on several mobile platforms could be provided on the web, where a UI appears if (and only if) credentials exist. But this also effectively discloses whether some credential exists, and thus is not trivial.

But, if such a thing happened, we would track any such proposal in a more specific issue/PR. So we'll close this one since we don't think that the suggestion in the title is suitable.

@agl agl closed this as completed Jan 8, 2025
@emlun
Copy link
Member

emlun commented Jan 13, 2025

I'd just like to add for the record:

I think we should not emphasize the user privacy too much.

This sentiment is directly contradicted by W3C Ethical Web Principles §2.5. The web is secure and respects people's privacy:

When we add features to the web platform, we are making decisions that impact people's ability to control their personal data. This data includes their conversations, their financial transactions and how they live their lives. We will start by creating web technologies that create as few potential threats to web users as possible, and mitigate the threats that we cannot avoid. We will make sure people understand what risks they are taking when they use the web.

Which is why this W3C working group prioritizes user privacy over RP convenience.

@bigradish bigradish changed the title Add a method to get all the credentials for a rely party on the client device to support the rely party (website) to limit the number of accounts a user can register Add a method to get the number of the credentials for a rely party on the client device to support the rely party (website) to limit the number of accounts a user can register Jan 30, 2025
@bigradish bigradish changed the title Add a method to get the number of the credentials for a rely party on the client device to support the rely party (website) to limit the number of accounts a user can register Add a method to get the count of the credentials for a rely party on the client device to support the rely party (website) to limit the number of accounts a user can register Jan 30, 2025
@bigradish
Copy link
Author

@emlun Thank you for your explanation, but I can not agree with you. I don't think my request is contradicted by the W3C Ethical Web Principles, whose motivation is making the web better.
If a user can register unlimited number of accounts on a website easily, he/she can violate the rules of the website, and register a new account after his/her account was closed by the website. Please notice that if the user destroy the website, he/she also hurt other users on this website.
If we protect users' privacy excessively and do not think of RP(website), the benefits of the users will eventually be hurt, and thus the motivation of the W3C Ethical Web Principles is betrayed.

@timcappalli
Copy link
Member

Restricting who can create an account on a website (or providing the means to restrict) is not in scope for the Web Authentication API. WebAuthn itself doesn't deal with accounts at all. It is an API for creating and asserting credentials.

You can accomplish this via other means if it is required for your business needs/policies.

@bigradish
Copy link
Author

@timcappalli Sorry, I have to say you have not got the meaning of this issue.

@timcappalli
Copy link
Member

You said:

If a user can register unlimited number of accounts on a website easily, he/she can violate the rules of the website, and register a new account after his/her account was closed by the website

to which I responded.

@james-d-elliott
Copy link

If a user can register unlimited number of accounts on a website easily

This can be done irrespective of if this kind of API addition exists or not. The user simply makes the credentials unavailable to the browser itself. The goal of WebAuth is not to solve identity management, but rather to facilitate the creation of cryptographical keys and later verify via mathematical proof that someone has access to them (likely the person who created them).

Registration concerns including but not limited to: multiple registration, rate limiting, etc; are in scope for business logic, and definitionally out of scope of this standard. You can solve this in many ways such as endpoint rate limits, requiring some form of additional validation that takes time, accounts to be created prior to registering a WebAuthn credential, using information already available to you such as their IP or long-lived session cookies , etc.

For malicious spam creation which is likely to be done via bots or automation it's completely trivial to circumvent any specification addition in this area. There is quite literally no way to keep track of mildly sophisticated malicious parties and how many accounts they truly have created credentials for.

@bigradish
Copy link
Author

@james-d-elliott You said: "The goal of WebAuth is to facilitate the creation of cryptographical keys and later verify via mathematical proof that someone has access to them"
Please show the source of your statement for the goal of WebAuthn. Thank you.

@timcappalli
Copy link
Member

First sentence of the specification....

This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users.

@bigradish
Copy link
Author

This proves nothing.

@bigradish
Copy link
Author

Do you think the goal of WebAuthn is just this?

@timcappalli
Copy link
Member

I'm going to assume you're either a bot or a troll and won't be engaging on this closed issue any further.

@w3c w3c deleted a comment from bigradish Feb 2, 2025
@emlun emlun mentioned this issue Feb 6, 2025
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
stat:Discuss subtype:FeatureProposal
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@agl @emlun @james-d-elliott @bigradish @MasterKale @timcappalli @sbweeden