Re: [webauthn] Provide a method to get the count of the credentials of a rely party on client device on user permission (#2255)

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<https://github.com/w3c/webauthn/issues/2255#issuecomment-2644424889>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABBYBYJESTYOVTO2HH7I5KD2OVQDHAVCNFSM6AAAAABWTDGMK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBUGQZDIOBYHE>.
You are receiving this because you were mentioned.Message ID: ***@***.***>


-- 
GitHub Notification of comment by bigradish
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2255#issuecomment-2649746580 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 11 February 2025 03:53:21 UTC