The WebAuthn spec editor's draft is very much a living document, with features being added or removed features every few months. There is an old "level 1" spec (dated Mar. 4, 2019) and an in-progress "level 2" spec, but there is little correlation between these levels and the the way browsers have introduced features. Therefore, https://caniuse.com/?search=webauthn is missing a lot of useful details for website authors. For example:
Note that this table is far from complete, but it makes clear that implementation timelines vary wildly depending on the feature.
I'd like to ask: does it make sense for caniuse to keep track of support for individual features like this?
If so, how do I best contribute them?
If not, how would you recommend keeping track of them?
ª I'm assuming that browsers supported this boolean when they initially introduced resident key support. This... might not exactly be the case, in which case there should probably be a separate row for "supports resident keys in some other way".
ᵇ Has not reached a "stable" release.
The text was updated successfully, but these errors were encountered:
I'd love to see more guidance on how to contribute various WebAuthn features.
Although the WebAuthn spec has "levels", browsers are implementing different "fine-grained" features of the different levels at different times. It can be hard or impossible to feature detect support for each individual such feature, due to the nature of the API.
I'm tracking six such fine-grained features of the WebAuthn spec at the moment, one of which could potentially be broken down into 4 independently implementable methods: https://github.com/github/webauthn-json/blob/main/compat.md
There have been other such fine-grained features in the past, and there will undoubtedly be more in the future.
Would it be appropriate to create a caniuse entry for each individual one, or is there another recommended way to handle a situation like this?