alt Hacker NewsIt'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.
> 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.
the point of the authenticator is that you don't need need to trust the platform, the operating system the browser or anything other than the authenticator
the authenticators job is to secure the private key, but it will happily serve up the public key to "random callers"
the browser/webauthn are not special, it's just another untrusted "random caller" from the authenticator's perspective
webauthn will not allow the public key out, but the authenticator will
> 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 nothing cryptographically sensitive about the public key
hence the name: PUBLIC key