[webauthn] Split the standard by focus driven use cases. (#1751)

Firstyear has just created a new issue for https://github.com/w3c/webauthn:

== Split the standard by focus driven use cases. ==
This is probably going to be a hot-take, but I think it needs to be written and shared. Right now, there are a bunch of issues in this standard related to the wide-variety of use cases that can and might exist, and as a WG we are trying to jam all of these through a single specification and trying to make them all work. By making one specification, that is *super broad* and general, we end up in a way, doing nothing well (especially in the eyes of an RP). 

For example:

* we have passkeys as a single factor authentication (since no attestation) that can really come from any device type and we want to allow users to have near full control over that experience.
* we have security keys as a "second factor" to a password, that should only be touched and not have it's own UV, and maybe it's attested, maybe its resident etc.
* We have enterprises that want security keys and want strict control over the list of devices that can be used and guarantees of the hardware bound nature of the credential
* We have enterprises that was passwordless, and further control over attestation and features and more.

All of these requirements all have their own subtle edge cases that webauthn today mucks up. From resident keys being pretty well impossible to verify (but dpk might kinda fix it), to being able to pre-indicate the type of token we want a user to use, to then the intent of passkeys to just be "any possible cryptograhphic authenticator" (but accidentally blocking the ability to use attested creds).

All of these use cases have their own subtleties, edge cases, and verification requirements. Some of these features collide - for example, transport selection for enterprises as a feature, might hurt passkeys if people use that feature in that section.

This ties in a lot to the  issue about use cases https://github.com/w3c/webauthn/issues/1720 

Rather than one-super broad generalised spec, I think it could be interesting and a net positive to see well defined use cases. They may not be "perfect" for everyone, but they'll be a lot closer than what we have today. And then from those use cases we have subsections of say "passkey registration and authentication" vs "security token registration and authentication". Within these, rather than a lot of generalised options, we have defaults that match the use cases within definitions. 

Now there are many ways you could do this. It could be a breaking change, or we could even "pre-define" use cases with examples of what exactly the webauthn options would be. It could even be like the current base64 encode/decode work where it's a function on navigator.credentials which just translates and "fills in the blanks" to the generalised version. But I think that a focus on use cases, so that there is a defined, RP centric view of what various RP's and Users *might* want, will help us to guide not only our decisions and discussions, but will help and enable RP's to better implement webauthn. Today webauthn has a ton of complex options, and not all of them are always needed. By having focused smaller use cases with associated standard ways to use them, would really help RP's, especially for the passkey push that is currently on going. 

Thoughts? 

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1751 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 20 June 2022 23:52:58 UTC