DRAFT: WebAuthn recovery credentials extension

README.md

This document has moved; its new address is: https://github.com/Yubico/webauthn-recovery-extension

It doesn't back up the main credential directly, but instead creates a dedicated single-use backup credential that can later be used to authenticate creation of a new replacement credential. This works even if the main credential is a resident credential, because the backup credential can always be a non-resident credential.

Thanks for taking the time to explain. However, one thing is still unclear to me: since username is not involved (that's the whole point of resident credentials), a user handle, which identifies the user, is stored on the main authenticator. So when using the backup authenticator, how does RP know which user account to recover credentials for?

If you can import your own key into a YubiKey, then your bank can't trust that your keys are safe just because you're using a YubiKey, because the YubiKey can't attest to the origin of your keys.

I'm not so much into banks and other financial institutions, so unfortunately I'm unable to argue because I don't know. But if it's actually the case and users are considered so silly so they don't have the right to set proper keys to ensure their own security, then it makes me really sad. Also it sounds a little ironic given that these days banks tend to trust SMS, which is anything but secure.

A bit of a side topic: which banks or other financial institutions do you know which support U2F? I'm personally not aware of any bank supporting it, and even paypal doesn't. So would love to learn about banks which do support U2F.

I mean if you have a pair A, B, with B as backup for A, and you can't set up a new key C to back up B once you've lost A and taken out B to replace it. In that case you'd have to get a whole new pair C, D if you don't want to be without a backup for B.

Yes I agree that some users might not like it, but what I'm saying is that it'd be unfair only if the user doesn't have an option to not use the backup at all. If there is an option to buy a single token and live without a backup (basically that's how everyone lives right now), then it's fine.

It's all about tradeoffs, and for someone having to order C+D if either A or B is lost is justified (e.g. for me), for someone it isn't. If there is an option to order just A without a backup (or with a backup implemented as per your proposal, when it goes live, is adopted by PRs, etc), then I don't see any unfairness. Actually I see unfairness in not having an option to order A+B.

However, one thing is still unclear to me: since username is not involved (that's the whole point of resident credentials), a user handle, which identifies the user, is stored on the main authenticator. So when using the backup authenticator, how does RP know which user account to recover credentials for?

Right, good point. Our proposal does not cover accounts that are identified solely by a user handle, i.e., that don't have a username at all. That's not the entire point of resident credentials, though - it's one use case enabled by them, but I expect the most common use case for them will be to ease day-to-day login flows but still have a username to fall back to.

which banks or other financial institutions do you know which support U2F?

I know Coinbase does, although they don't seem to place requirements on the what authenticator you can use. Either way, with regulations such as PSD2 in the EU, attestation will be important if WebAuthn is to be even evaluated for some use cases.

Note to watchers:

This document has moved; its new address is: https://github.com/Yubico/webauthn-recovery-extension