Sort of. Passwords themselves are just text, and they can always be copied and pasted no matter what. But you're right that the full vaults themselves aren't standardized, and a requirement in the spec that authenticators just generally support export would be enough for me I think, even if it didn't specify a specific format.
I do think specifying a specific format might be better though -- if we had standardized password vaults more, maybe the LastPass breach wouldn't have happened, and they wouldn't have assumed that encrypting site metadata/urls was optional. But I generally agree, supporting multiple export formats is fine as long as those export formats exist in some form.
> But more importantly, WebAuthn makes assumptions about the characteristics of an authenticator at registration time. (And establishes continuity of those signals with DPK). Exporting it would be contrary to that.
Well, that's the question though: should it make assumptions about the characteristics of an authenticator? Embedded in that statement is the idea that sites should have more insight into my device than they've ever had in the past. It's a huge expansion of the amount of information that a site has about where a user is logging in from. I don't know that I agree with that, and I think there needs to be more justification that having that information leads to practical increases in security.
There are a lot of advantages to WebAuthn that have nothing to do with verifying the device. The biggest security increase from WebAuthn is the site identifying itself to the authenticator. The site getting information about the hardware is kind of secondary, and I would argue of much more limited value for security (but of high value for DRM/platform restrictions).
Users can already get device-bound credentials without attestation -- they can get a Yubikey. So for users that want that extra security, options exist. But does it add tangible security for the site to be in charge of that? Enough security to justify enabling some really pervasive DRM methods and device lock-down?
> A user could more easily be tricked into trusting a malicious TPM that exfiltrates they passkeys, whereas single vendors like Apple can implement mitigations as long as all the devices are in their own ecosystem and they can use their own services for sync.
I don't think I agree with this either. Any restriction Apple puts in front of iCloud recovery can be put in front of an export button. Any information that Apple asks you before syncing to a new iPhone can be asked before providing you with a backup file. And from an attacker's point of view, if I can attack the iCloud export function, I can also buy an iPhone and attack its device recovery process. I'm not sure there is much of a security difference here.
I think that ship has kind of sailed as soon as we start talking about syncing passkeys between devices. I think this argument only makes sense if we get of sync entirely and say, "no, they'll be completely device-bound like a Yubikey." But if Apple is syncing keys between iOS and Mac, if it allows going even further and sharing them using AirDrop, we're well past the point of worrying about whether someone can trick you into exporting your passkeys.