Allow backup eligibility to change

[Firstyear]

Fixes #510

• cargo test has been run and passes
• documentation has been updated with relevant examples (if relevant)

[BlackDex]

@Firstyear Would this PR mean my Voodoo checks in the commit dani-garcia/vaultwarden@df783fc would be no longer needed?

[tessus]

I also tried, but I also ran into the same issue that it doesn't compile.

[Firstyear]

That will teach me for submitting a PR in a hurry on a busy day :)

[tessus]

We've all been there... I certainly more than once.

[Firstyear]

@BlackDex Yeah, I think I need to just clean this up a bit:

We have all your V3 -> V5 credentials moving to backup_eligible == true.

This means during authentication you have:

• cred.BE = true, auth_data.BE = true (valid)
• cred.BE = true, auth_data.BE = false (currently this FAILS)
• cred.BE = false, auth_data.BE = true (valid, covered by allow_backup_eligible_upgrade)
• cred.BE = false, auth_data.BE = false (valid)

So I think that's the corner case I missed. I'll update the PR to accept this.

[yaleman]

Rebase and fmt while you're there 😸

[Firstyear]

Done

[Firstyear]

@Firstyear Would this PR mean my Voodoo checks in the commit dani-garcia/vaultwarden@df783fc would be no longer needed?

Hopefully yes :)

[Firstyear]

@BlackDex Can you confirm if this updated PR resolves your issue without the need for all your checks? If it does, I'll do a release so you can use the updated version.

[BlackDex]

Sure, I'll see if i can do this today somewhere

[BlackDex]

I quickly tried this today, but doesn't seem to work.

[2025-08-24 16:21:51.064][request][INFO] POST /identity/connect/token
[2025-08-24 16:21:52.180][webauthn_rs_core::core][DEBUG] Credential backup eligibility has changed! false -> true
[2025-08-24 16:21:52.180][webauthn_rs_core::core][ERROR] Credential indicates it is backed up, but has not declared valid backup eligibility
[2025-08-24 16:21:52.180][error][ERROR] Webauthn.
[CAUSE] CredentialMayNotBeHardwareBound
[2025-08-24 16:21:52.180][response][INFO] (login) POST /identity/connect/token => 400 Bad Request

[Firstyear]

That sucks :( I see you have merged a separate PR so in this case, do you want me to just close this one since you have a work around?

I'm so sorry this has been such a pain for you, it is a pretty big mistake on our part.

[BlackDex]

That sucks :( I see you have merged a separate PR so in this case, do you want me to just close this one since you have a work around?

I'm so sorry this has been such a pain for you, it is a pretty big mistake on our part.

Ow, no problem. It was fun to figure it out. And i see it more as our own fault for not having updated it more quickly.

If this could help others or future implementations, then it might be useful to continue this PR. I know Proxmox had a similar issue as Vaultwarden. But there implementation is a bit different then ours.

Also, it shouldn't lower or demote security of course.

[Firstyear]

Correct, in this case it doesn't really affect your security stance. Realistically, given how the passkey ecosystem has moved, flags like backup eligibility and such dont matter, as the only way to truly guarantee properties about authenticators is to attest them. If you don't do attestation, the assumption is "anything goes" given how passkey providers operate.

So I think there is even an argument that we remove this field and flag.