Re: [webauthn] Add a way to use webauthn without Javascript (#1255)

> The issues with basic auth and TLS client certs are browser UI issues [...]
>
> The basic auth and TLS client cert protocols definitely support logout (just don't send the basic auth HTTP header or TLS auth extensions), so lack of logout is again a browser UI issue that should get fixed.

I read somewhere that Edge allows TLS logout by clicking on the padlock icon in the URL. This is not discoverable, but more or less any place in the native Browser UI would be hard to discover. It is significantly easier if the website can place it in intuitive locations. And the browser cannot do that because it shall not inject something into the web page. One might think to make it a large button somewhere in the browser UI but that won't work for mobile browsers.

So the logout button should be under control of the website. This is also important for other scenarios e.g. banking applications which want to log the user out after some inactivity. Similarly you want to invalidate all sessions after e.g. a password change. There once was `window.crypto.logout()` though it was removed.

**But this is a completely different topic independent from the one discussed here.** Even if the UI provided by the browser was ideal there would still be reasons why this might be better off in the HTML standard and not HTTP or TLS...

> I was thinking that after a user logs in with the HTTP/TLS based WebAuthn protocol, the website would map their WebAuthn credential to the appropriate username/etc, or if none exists on the service, then the website would return the account registration flow including creating a user and registering their WebAuthn credential to that user. The website itself wouldn't have any logout functionality, that would be provided solely by the browser UI.

For all but very simple scenarios, I do not think HTTP Auth and TLS client-certs are not flexible enough even though I would like them to be. Login might be the simplest case but even then there are many inflexibilities: E.g. services which also allow login through OpenID Connect providers. You cannot give them a choice to choose if you require authentication before the website is loaded. But for registration this becomes even worse: No way to convey username guidelines, no way to request other information like birthdate, no way to provide legal disclaimers. Obviously this could all be embedded by some options but that is waaay out of scope of WebAuthn. This flexibility can only be provided if the website itself can provide the UI of the login/registration process.

Also in case of HTTP which is stateless what do you want to transmit after the first request? You would have to request and sign a new challenge each time and asymmetric crypto is slow. It gets even worse if you want to use post-quantum secure algos. And implementing this on the TLS layer seems way to complex given that client-certs already cover a lot of the same grounds.

If you want support for WebAuthn in these other layers you should create corresponding issues for that but I doubt they will get much support. WebAuthn is simply too complex for and incompatible with these layers.

Even if WebAuthn support were to be added to these lower layers, it would still be part of the HTML/JS stack. And for this case we STILL want a way to use it in noscript mode. Just because it offers so much more control to the website authors.

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


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

Received on Sunday, 20 November 2022 00:44:22 UTC