You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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:
uvm
requireResidentKey
(boolean) authenticator selectionªChrome 73 on Windows
Firefox 66 on Windows (early 2019)
Safari on iOS 14 (Sep. 16, 2020)
Safari 14 on macOS 11ᵇ (late 2020)
Chrome on Android (hopefully in 2021)
Firefox on macOS (stalled)
residentKey
(enum) authenticator selectioncredProps
extensionappidExclude
extensionlargeBlob
extensionSep. 30, 2020 (querying for support)
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?ª 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: