Fyrd / caniuse

Raw browser/feature support data from caniuse.com
https://caniuse.com
Creative Commons Attribution 4.0 International
5.65k stars 1.38k forks source link

Tracking various WebAuthn features #5649

Open lgarron opened 4 years ago

lgarron commented 4 years ago

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:

Feature Introduced to spec Supported in browsers Not supported
Basic security key support long ago see caniuse.com Chrome on iOS (cannot use WebKit implementation)
uvm Sep. 1, 2016 ???
requireResidentKey (boolean) authenticator selectionª Sep. 13, 2017 Chrome 70 on macOS (mid-2017)
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 iOS (cannot use WebKit implementation)
Chrome on Android (hopefully in 2021)
Firefox on macOS (stalled)
residentKey (enum) authenticator selection May 8, 2019 Chrome 87 (Nov. 17, 2020ᵇ) Safari 14
credProps extension May 8, 2019 Chrome 87 (Nov. 17, 2020ᵇ) Safari 14
appidExclude extension July 1, 2019 Chrome 78 (mid-2019)
largeBlob extension June 22, 2020 (main feature)
Sep. 30, 2020 (querying for support)
Chrome ?? (late 2020)
Creates resident keys even if not requested Currently outside the scope of the spec Safari 14 Chrome

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.

ptman commented 2 years ago

WebAuthn has Levels, L1, L2. Safari seems to have the best support currently, with chrome as runner up and firefox only supporting basic stuff.

lgarron commented 1 year ago

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?