[csuwldcat]

It's a deliberate architectural decision that passkey authenticators not allow any retrieval or enumeration of key pairs - they don't even have internal APIs for it. This holds true for all known implementations, as it is a core principle of the system design.

[blibble]

> it's a deliberate architectural decision that passkey authenticators not allow any retrieval or enumeration of key pairs

there is no much thing as a "passkey authenticator"

there are "platform authenticator" and "roaming authenticators"

> they don't even have internal APIs for it.

CTAP has an enumerate credentials command, which returns, among other things:

> publicKey (0x08): public key of the credential in COSE_Key format

https://fidoalliance.org/specs/fido-v2.3-rd-20251023/fido-cl...

> This holds true for all known implementations, as it is a core principle of the system design.

oh dear

[csuwldcat]

The underlying CTAP implementations are only used by the platform to facilitate core activities, they are not used to expose key pairs to external parties. Please link to where any API offers up public keys to external userland actors, and any use of said APIs beyond core credential management. If this is assumed insecure/exposed, it would mean the system and its guarantees cannot be trusted as advertised, given both keys are supposed to be handled as a secure, opaque bundle, disclosed to no one beyond the bound origin at create time.

[csuwldcat]

No need for the "oh dear"-ing before you provide evidence. I'm not aware of any command for fetch or enumeration of public keys in CTAP (was rather confident it doesn't provide any such thing). Care to link to what you were referring to?