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

> > I would rather the browser providing all of the user interface for the login flow, that way every single website doesn't have to reinvent the wheel and users get much more consistency. [...]
> 
> I understand your point, but let me remind few points why websites would prefer style-able HTML over something fully controllable by browser:
> 
> 1. Today all auth UI shown by browser looks so "unfinished" and "unbranded", that between using something like Basic auth over https, or even certificate based auth with certificate from auth card, and something with styled HTML UI with username and password boxes, sites automatically pick the later in favor of UI branding consistency.

I think a few things get mixed up here. Basic auth and client certificates are something which the browser must show as the connection to the website requires this. So for these things there is a fairly barebones UI and I agree with you that the developer has little control over what is shown and how it is used. Therefore these mechanism are also mostly used in communication between servers or scenarios where this is automatically resolved like kerberos tickets.

For WebAuthn, however, I think that letting the browser provide the UI is in the best interest of the devs. For one, they still control most aspects of the auth flow, like when it is initiated and can provide instructions beforehand. Second, there are so many different methods how WebAuthn can be achieved that is is infeasible to provide a UI for each way. There are hardware keys, fingerprint, face ID, Windows Hello, nearby bluetooth devices etc. Even providing the dev with information about which methods the platform supports could leak private information.

Furthermore on many platforms having the UI be provided by the browsers leads to more consistency. E.g. windows has a consistent Windows Hello prompt to my knowledge and all mobile devices have their own UI for biometrics which are consistent across the platform so we don't want to intercept them here. Also not every browser provided UI is bad. Think for example about file selectors, or date selectors on mobiles. Most versions to implement them inside HTML would result in a catastrophical leak of information or result in worse UX.

> 2. there is no a clear way to logout from such authentications with browser UI, e. g. Basic auth over https.

This is true for basic auth and TLS client certificates but not for WebAuthn. Here the session is completely in control of the website. Reading this I think you might also be referring to the comment from @pabs3 before the one you quoted in which case I am definitely on your side. So I will also respond to that:

> I think it would be better at the HTTP or TLS layer, so that API clients and similar non-browser clients can also use WebAuthn.

I do not think WebAuthn belongs in the HTTP or TLS layer. We already have mechanisms to authenticate there but these are mostly used for server to server communications. You already said that this mostly applies to server-to-server communication. A situation in which many of the possible WebAuthn advantages over traditional alternatives do not exist or cannot be utilized. You would not want to have your backend service require any kind of popup to request you biometrics or a hardware key. Instead you would usually use a strong token. If one requires an asymmetric auth flow one can still use TLS client certificates. And should those be too cumbersome you can still set up a mechanism similar to WebAuthn. Still, you are probably better of to just not do it.

> 3. Each website have own understanding of various aspects. One site have separated username and email, other websites use email as username, third use email OR username (you can type both). One website offer remember username only (remember me), others offer to remember user sign in for a while (keep me signed in), others do not show these  checkboxes and assume users want be signed in for a while by default. Site authors want anything within website look within same style, as other UI. This is one of corner stones of success of Stripe Elements which are literally provide a way to visually "embed" sensitive data inputs into website with proper styling, while still the CC numbers and such not exposed to website JavaScript or not sent in plain text to website backend.

I do not see why this would be incompatible with the browser providing WebAuthn UI. They can still control the input of username and other information and would simply invoke the browser UI upon submitting the information. Also there is another issue about providing an intent like "Register", "Signin", "Authenticate transaction" or others which I really like (#1823).

Regardless: This issue is about performing WebAuthn without JS and not about the UI provided by browsers which are independent issues.

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


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

Received on Saturday, 19 November 2022 18:24:33 UTC