Split the standard by focus driven use cases.

[Firstyear]

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 #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?

[dagnelies]

TL;DR: Too late... Is it not?

Longer version:

I totally agree with your point of view. My personal gripe with this specification is the extremely high complexity of it, probably due to the fact that everyone chimed in its part of this towering edifice. It's also very difficult to "use". Originally, when I first encountered the concept overview, I though "great, sounds simple and secure!". And in my naïve mind, I kind of expected a two pager which might describe something like this:

// creates a key pair
webauthn.createKeyPair()
=> {keyPairId:<string> , publicKey:<base64>}

// signs the challenge
webauthn.sign(challenge, allowedKeys) 
=> {keyPairId:<string>, signature: <JWT>}

These two minimalistic methods would indeed be enough to let most RP make an authentication system. Very easily and with a good feeling about its correctness.

But, well, this spec is quite the opposite. I already "complained" about this in #1709 so I won't dig into it again.

There is also the question of "What can be changed at this point?" ...webauthn is already out, it's there, it's implemented, it's used by a few, it kind of passed a point of no return. In order to keep compatibility, things can only be added to it. Yikes!

However, maybe it might make sense to split this into two RFCs. This complex one for all the fluff, and another one for the straightforward authentication case. Like for example a separate "simplewebauthn" two-pager spec without options and proper JSON responses. Ideally it would also reuse other RFCs like JWT for signed content, to obtain something that everybody could use out of the box, easily and safely. But well, I guess this is just wishful thinking.

If you want to foster adoption, making a simple spec for devs would be a great way.

[MasterKale]

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.

The WebAuthn Adoption Community Group would welcome efforts to help prepare guides highlighting how to achieve such discrete use cases. We've been wanting to for ages but alas life gets in the way 😂 😭

[Firstyear]

However, maybe it might make sense to split this into two RFCs. This complex one for all the fluff, and another one for the straightforward authentication case. Like for example a separate "simplewebauthn" two-pager spec without options and proper JSON responses. Ideally it would also reuse other RFCs like JWT for signed content, to obtain something that everybody could use out of the box, easily and safely. But well, I guess this is just wishful thinking.

If you want to foster adoption, making a simple spec for devs would be a great way.

Yes, I think this is a good idea. @MasterKale and I have spoken about this before. But I think the challenge is that even in the simple spec, webauthn today can't actually meet some RP use cases properly ....

Anyway, where would be the right place to bootstrap such an effort. I'd be more than happy to start.

[Firstyear]

@MasterKale ping, where would be the best place to start?

[MasterKale]

@MasterKale ping, where would be the best place to start?

The WACG will soon have an avenue for accepting submissions for guides/cookbooks/etc... to enable such "focus driven use cases" as what you've outlined above. Once @timcappalli and I finish getting the repo set up and the site online one of us can follow up here with links.

[Firstyear]

@MasterKale Awesome! Ping me once done, and I'll help out :)

[MasterKale]

It's been a while since this issue was opened, and we've come a long way since then especially now that we have a site like https://passkeys.dev to capture use of WebAuthn for the "best" discrete use case. Additional work to help others understand how best to use WebAuthn can continue to take place at the Community Group.

I'm going to close this out, please feel free to re-open if you believe there's still something to be done at the Working Group level.