> I'm sure you can come up with a protocol where you can fan out access to the secret in a way that requires fanning back messages to you. But I don't see any clear way to do so that doesn't increase the communication burden on everyone.
the spec actually supports this, it's called caBLE
Right, that flow seems somewhat straight forward and is roughly what I had in mind with my sentence. It doesn't really break you out of vendor involvement, though? You both still have to be fully in on the whole flow. Right?
Asked differently, how does this get a vendor out of the picture?
caBLE is not a specification for transferring secrets, but for mediating (temporary) access to them.
But the FIDO alliance is apparently working on that: https://fidoalliance.org/fido-alliance-publishes-new-specifi...
I actually thought it was more for mediating confirmation of access to them. You don't share the secret with the new party, but you and the vendor both do a flow with them to confirm that someone claiming to be an identity can support that claim.
Do not use a vendor for managing passkeys. Use a self hosted password manager like vaultwarden. Or spin up an OIDC provider with pocket-id. Using a vendor is just pointless and should be avoided at all costs
Effectively you have a secret that you are using to authenticate yourself. With pass keys managed by a vendor, you are trusting that vendor to manage your secret. If they are able to give your secret to someone else, then they can no longer confirm who all knows your secret.
I'm sure you can come up with a protocol where you can fan out access to the secret in a way that requires fanning back messages to you. But I don't see any clear way to do so that doesn't increase the communication burden on everyone.
I'm also sure smarter people than me can surprise me with something, here. But secrets that can be shared historically tend to not be secrets for long.