Re: [webauthn] Why not make things simple? (#1709)

> I appreciate the frustration, and I invite you and everyone else to hurt our feelings as much as is needed to make the spec the best it can be. I agree with @Firstyear that if the spec fails to communicate clearly to its audience, that is primarily the fault of the spec. However, as a spec intended for wide interoperability we may need to prioritize impartial generality over concrete examples, or sacrifice brevity to avoid ambiguity, or on the flip side sacrifice detailed descriptions for conciseness. Where the spec is vague it is often intentional so as not to restrict implementations or use cases too much.

An example at the moment is over in the "backup" bit thread, that if it's a ux hint, it should have "hint" in the name. We choose language in the spec that implies absolutes and strict states, but when we mean "this is a hint and a guide or similar" but we don't choose to express that. 

Another good example is that the structs in webauthn don't delineate what is signed and what is not, which gives people a false sense of "security" unless they really know the internals of webauthn inside and out (and even then, it seems many of these issues were missed ...).  

Finally, things like authenticator selection criteria really focuses webauthn that an authentication challenge is targeted by an RP to a single or very narrow band of credential classes, but the spec isn't clear that this kind of mix-match can create security issues related to UV bypass, and generally pushes a lot of burden to the RP that doesn't really need to be there. 

I'm glad for the json base64 changes, but I also did previously raise it and it was closed sadly too. 


Anyway, sadly, the ship has probably sailed on most of these unless we are willing to do a fully breaking change for a level 4 version of the spec. 

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


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

Received on Wednesday, 23 March 2022 21:56:40 UTC