alt Hacker News> Given both keys are supposed to be handled as a secure, opaque bundle, disclosed to no one beyond the bound origin at create time.
yes, there is no way to enumerate the public key in the webauthn api, but this is a property of the webauthn api only
the passkey cryptosystem consists of more than the webauthn api
there's the platform and roaming authenticators too
and you can't ignore them because they are the part of the passkeys cryptosystem that actually store the key material
and I have shown you, it is common for the layer below webauthn to support enumeration of the resident public keys
because... it's useful!
million dollar HSMs let you enumerate & see public keys, protected Java keystores let you enumerate & see the public keys, the windows certificate manager lets you enumerate & see public keys
(because surely no-one would be daft enough to try to build a secret key scheme out of the public keys of a pair?)
Replies
It's not just about the WebAuthn API, you're talking about passkeys as if their key bundles are freely accessible to random userland actors, which is absurd. If that were the case, many assurances the platform makes would be out the window. The reality is that you are obviously already trusting the platform, hardware, its software/firmware, and the implementation's use of core key management APIs, which it doesn't just offer up to random callers. If you think any of those components/actors are not adhering to fundamental boundaries/limitations, like exposure of sensitive credential material to random callers on the device, it's a more far reaching indictment of passkeys in general.
There's also the specific case of synced passkeys, which aren't exposed to CTAP management APIs for external parties, only to the OS/platform itself. You seem tied to a narrative where a user can install a native app that gets permission to call core OS/platform APIs that let the app get all the public keys of passkeys on the device, but no such permissions/APIs exist for apps, and providing them would be in explicit violation of the fundamental security model. In reality, only the platform/OS and highly trusted actors/components that are already within the existing trust model have such access for internal purposes, and if that's not a safe assumption, it would have broader implications beyond this concern.