- From: Kyle Simpson via GitHub <noreply@w3.org>
- Date: Sat, 20 Dec 2025 05:46:23 +0000
- To: public-webauthn@w3.org
Thank you for your clarifications/perspectives. Specifically, my first question was in regards to this comment from 2019:
> Thanks for pointing this out, we're aware of the issue but it hasn't been a high priority since we're not aware of much interest in using non-resident keys for 1st factor authentication.
So I should have been more specific about the *non-resident* part of that assertion.
Anyway, without having previously seen the code you just linked to, I arrived at a very similar approach in my app (in JS, not rust). I didn't do any market distribution variability, but I do have variability of the "shape" of the credential returned based deterministically on the account identifier (emails, in my case).
QUESTION: how did you arrive at the "max" of 3? did you just observe that valid users basically never had 4+ credentials? My pick of 3 was quite arbitrary/subjective, not based on any real world data.
----
That said, here are some key differences on my side:
1. My system is passkey-only, so all valid accounts have to have at least one credential. So I vary 1-3 returned credentials rather than your 0-3 variation. That is, I never return 0 credentials, regardless of real or unknown/fake accounts.
2. My credential IDs were previously fixed at 32 long, but I've now taken your varying lengths idea and adapted it for my own approach, varying lengths between 16, 20, and 32 byte IDs. Thanks for that!
3. In addition to the credential ID, my endpoint's return values also include variability on the `transports` (from the set of "internal", "hybrid", "usb", "nfc", and "ble" values).
Also, my endpoint returns two additional flags -- normally collected from the credential at registration time (and faked for these credentials, of course) -- which are: *discoverable* and *backupEligibility* (cloud backed up vs device-bound). Those flags aren't included in the `allowCredentials` list that's passed into the `webauthn.get()` call of course, but they ARE used on my login page for determining certain UX, like whether to try a conditional mediation prompt on the email input box, etc.
--
GitHub Notification of comment by getify
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1246#issuecomment-3677416404 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 20 December 2025 05:46:23 UTC