Re: [webauthn] Privacy risk from revealing allowed credentials (#1246)

Look mate - I hate that passkeys are resident keys as much as the next bloke. The history isn't great for a bunch of reasons. 

But passkeys means *resident keys*. Even if you don't like it - I certainly don't. But either way you have to stop calling them passkeys. They aren't. Passkeys is such an overloaded term in general. 

Within webauthn everything you are talking about are *credentials*. Passwordless is an umbrella for non-resident credentials. Passkeys are the umbrella term for *resident keys*.  Device bound are "not synced" and synced is ... well synced. But resident and sync aren't related. 

If you're gonna talk about this stuff, specificity of language *matters* so that everyone is on the same page. And I think this is only serving to confuse yourself about this. 

At the least just say "I need non-resident credentials" or "I need a device-bound credential" or whatever.

So when you keep saying "I need non-resident device bound passkeys" it's like saying "I need dry water". Because you're saying "I need a non-resident device bound resident key". See the issue?  It doesn't exist mate. You actually want a "non-resident device bound _CREDENTIAL_".  

Now, more over I get it you want device bound keys, but the reality is you're fighting a losing battle. Devices mfrs and browsers are working against you. They *want* synced, resident keys. I have tried to advocate for device bound keys as an option and was shut down. 

You need to accept that webauthn has largely fallen into one of two broad use cases today. 

You either get a synced, residentkey, that could be in iCloud, GPM, A password manager, or even a cereal box. You have zero control at all about what's enrolled, it's a passkey. You have no idea where or how it's stored, but you know that it's somewhere since it's resident/discoverable. 

Or you use *attestation* and cryptographically limit what devices can enroll so that you know the precise characteristics of those devices and then you can choose *precisely* to only use devices that are non-resident (passwordless) or resident (passkeys). Many devices *refuse* to enroll a key if you demand attestation, which further limits your hardware choices. Realistically if you demand attestation, you're an enterprise using yubikeys or something that you provide to your employees. 

But the reality is, phone mfrs don't want device bound keys. So you're barking up the wrong tree man. The *only way to guarantee you get a device bound key is attestation*. There are plenty of devices that will "pretend" to give you a device bound key, and send you a credential ID, but it's actually synced, and the device just uses the credential ID as a "nice to have" look up identifier. 

You're trying to walk in this line between the two, where development of the standard and the tooling around it doesn't want you to walk.

And at the end of the day, if you want to minimise the privacy risks, resident keys are better here because they don't need any credential ID's transmitted. But this means you have to accept the keys are also *synced*. 

So you have to choose:

* Do you want resident keys to guarantee privacy but it means there might be synced credentials?
* Or do you absolutely want device bound keys, and accept that means you need attestation and strict limits on the devices that can participate? 

That's your choice. Sorry to have to be so direct, but I think you aren't getting it otherwise. 

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


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

Received on Tuesday, 23 December 2025 05:31:17 UTC