Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking various WebAuthn features #5649

Open
lgarron opened this issue Oct 13, 2020 · 2 comments
Open

Tracking various WebAuthn features #5649

lgarron opened this issue Oct 13, 2020 · 2 comments

Comments

@lgarron
Copy link

lgarron commented Oct 13, 2020

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?

  • 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.

@ptman
Copy link

ptman commented Sep 14, 2022

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
Copy link
Author

lgarron commented Jan 17, 2023

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants