Make webauthn-rs tolerant to changes in the MDS schema

[sycamoreoak]

FIDO changes the MDS schema with some regularity and without adequate documentation, and this causes webauthn-rs to break (see #462 , #453 , #450 , #449 ). There is no repository of old MDS files, so if a system fetches the MDS file and it fails to parse due to a change in schema, the webauthn-rs library stops working. FIDO recommends updating the MDS blob once per month.

This issue is for tracking methods for mitigating this problem.

Methods of remediation might include:

1. A higher level of collaboration between FIDO alliance and webauthn-rs
2. A strict parser which enforces the webauthn-rs schema and non-strict fallback parser which allows new fields and making a best effort at parsing. It may be useful to see how other webauthn backend projects in other languages (e.g. javascript) handle MDS schema changes, and whether they also have been breaking.
3. Allowing a configuration file for webauthn-rs to exclude specific authenticators and providing more informative error reporting on which authenticators are failing to parse.

[Firstyear]

We tried 1. - fido refused to work with us as we are not a paying member. Simple as that, we don't matter in their eyes.

Option 2. has it's own issues, as enums like for cryptographic variants would need catch all's, and that gets tricky to handle.

Option 3 is "kind of" possible, as we need to then parse everything to generic json value, then parse one at a time to highlight the problem devices. This way we can alert on devices with new fields, but they'll be excluded from our output.

If we're going to go with any of these, I would say option 3, simply because we already have a precedent to exclude authenticators that don't parse or have invalid data, so what's a few more right?

[sycamoreoak]

SMS 2FA is really dead now, so webauthn needs to work reliably. Option 3 is nice if there can be more verbose error reporting so it's clear how to exclude failing chunks of the MDS.

[Firstyear]

Attestation is only useful in tightly controlled enterprise security environments, for most applications with general users it's not worth it. Most authenticators that consumers use are not - and can not - be attested.

[Be-ing]

We tried 1. - fido refused to work with us as we are not a paying member. Simple as that, we don't matter in their eyes.

Ugh, that sucks. @Firstyear IIUC SUSE sponsors your work on Kanidm, and I presume that includes webauthn-rs, correct? Is it out of the question for SUSE to pay the membership fees for the FIDO Alliance?

[sycamoreoak]

The MDS breakage was not discovered by webauthn-rs CI, because there is no webauthn-rs CI right?

Is webauthn-rs production-grade?

Another remediation might include:

4. webauthn-rs should include CI

[Firstyear]

The MDS breakage was not discovered by webauthn-rs CI, because there is no webauthn-rs CI right?

You do not need the MDS to use webauthn-rs.

The MDS is an optional tool to acquire certificate authorities that you can use for attestation. You don't need it! You can make your own attestation ca lists quite easily if you want.

And in most cases you don't need attestation. If you need attestation, you only need to update the MDS infrequently as even FIDO state they only publish it once a month. Again, this is about threat modelling and risk assessment.

Is webauthn-rs production-grade?

Yes.

Another remediation might include:

4. webauthn-rs should include CI

FIDO should stop breaking their MDS without telling people. But they are the authority we have, not the authority we want.

We also already have CI thanks.