Re: [webauthn] username and display name should not be mandatory (rp, challange either) and OS UX should be simplified if not present (#1915)

hey,
thanks for the reply, I am not looking for anything else than a great way to provide my users a simple and secure authentication solution: trusted device + biometrics (device code)

of course webauthn can be implemented great, I enter my google account on a windows machine with my fingerprint, vow (on my linux pc hmmm...)

the question is the broader design and whether it will be (should be) widespread, will 50%+ web domains implement it?

of course not, because it has the flaws I discussed... the biggest problem is that a ruling solution requires the secret to be backupable (like bitcoin BIP39 or something)... or else the whole thing is federated again (apple, google, pass manager) and nobody wants to (and nobody should want to) be dependent of the pass manager completely... the secrets must be exportable... that is my opinion and if only 10% of people think so, no web domain or service will implement only passkeys in this form... and what is actually the big advantage of passkeys IF there is a backupable secret key anyways? you should have understood that there always be some backupable secret key because why should I add passkeys if I can just use a recovery key (if the user wants it, on paper, if the user wants it easy in pass manager with some local disk encrypted backup etc...)

the trade off is you DO have a readable backup but you hopefully rarely or never really use it... if you create passkeys this way, there will be other solutions and why would I complicate my life with passkeys? I can do it in the browser (now without biometrics because webauthn has monopoly)

but my REAL SMALL problem is that you do not even consider minimal changes like making username fields NOT required... you do not even discuss what is right what is not right... you do not even seem to understan that the whole webauthn logic is usernameless, you did it this way and than required 2 username fields... come on!

I do not want to circumvent it, I do not want to hack it, I want to write 5-10 lines in js with the really important fields, I want to know from the interface and specs which fields are really important... and that is it... the UX cannot improve on BAD LOGIC! what should a UX writer do if a fied is REQUIRED? then they have to do something with the string inside, even if it is ""... the fact that people want to put "" is a proof that something is smelly (should not be required field.... if the field is not required, the UX implementer HAS to create an if-else... if it is not there, vow, then no field... then they think about it, vow, if it is not there, one account, no multiple account, we do not need 80% of UX stuff here... just sign in to xyz.com with your passkey, that is it!

id a second account is created with a different id, then we prompt the user to manage the username labels because logically it is NOT authentication logic by passkeys but pass manager multi-account labeling logic... I can change this label on android now and I can sign in... 

PS: I do not have the time but at one point challenge is crucial (the random server challenge that is signed over) at another point there is some challenge we never do anything with, as far as I can remember it has something to do with attestation that is not happening 99,9999% so we have to generate a random something that has no use... it may only be bad if an RP gives a non-random something... if we do not need it, we should not be made to create it, it is obvious... again, if someone needs it, it can be optional and if there is no challenge, the party that actually does something with it and has more security knowledge than an average RP creates a random something...

-- 
GitHub Notification of comment by r-jo
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1915#issuecomment-1835674237 using your GitHub account


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

Received on Friday, 1 December 2023 08:25:45 UTC