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

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.

-- 
GitHub Notification of comment by dagnelies
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1751#issuecomment-1162356865 using your GitHub account


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

Received on Tuesday, 21 June 2022 21:01:18 UTC