I’ll address the second objection first regarding the phone or browser. You’re always going to rely on some technology for the solutions that use cryptography, you just can’t do those calculations long-hand realistically. That said, look up frameworks like CTAP that allow a potentially untrusted user terminal, like a browser, to interact with a trusted hardware token. Those hardware tokens can be made fairly tamper-proof, see FIPS authorized Yubikeys, such that the phone is pretty much removed from the attestation process. Yes these can still be stolen, but they make hardware keys that are fingerprint authenticated and the biometric stays on the device. Doesn’t get much more self-sovereign than that.

The existence of a trusted credential provider is a challenge. Fully self-sovereign credentials need to either be trust on first use or validated against a larger system everyone participates in. Even if we had some system of birth certificates tied to a distributed ledger, we would have to trust the third party recording that certificate in the first place, be it a hospital, doctor, or state entity. These trust and proof systems don’t create the trust, they just allow us to extend that trust from one claimant to a verifier. Whether you place that trust in the state, an individual, or an independent third party is up to you.

This is a fundamental misunderstanding of how the FIDO2 standard works. It is not designed to be vendor specific and as other people in this thread point out, plenty of open-source secrets managers and hardware implement passkeys.

What we’ve seen is the typical Silicon Valley model of “embrace, extend, extinguish” so you’re right to be wary of any implementation by Google or Microsoft.

Same goes for biometrics - how you unlock the passkey isn’t specified in the standard. It is left up to the implementation. If you don’t want to use biometrics, you don’t have to.