W3C home > Mailing lists > Public > public-webauthn@w3.org > July 2019

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

From: Garnac via GitHub <sysbot+gh@w3.org>
Date: Mon, 15 Jul 2019 22:53:44 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-511599189-1563231223-sysbot+gh@w3.org>
@ignaloidas You make some good points.

I think that a declarative HTML API should not be limited to webauthn, (i.e. To a specific version of the Credential Management Level 1, etc.) The API should be made more general than that. It should cover all the general use cases that a browser may need. This is to allow innovation in the future. (i.e. In what ways can the browser benefit the user when doing a user login?)

(1) Login should be done via a form.

I disagree. Requiring an HTML form in order to use webauthn is too limiting. What should the login system of the future look like? (in 10 years, etc.) The entire point of the new login system (webauthn, etc.) is to eliminate the user having to perform manual data entry. So why continue to use an HTML form and *prompt* people to perform data entry? What is the point of requiring websites to keep using old style HTML login forms, when 90 percent of the time, data entry will not be used. (people will not type anything into the form.)

If you really don't want to have an anchor send a POST, then a new HTML element could be created. (Create a "login" tag, etc. instead of using the "a" tag.) Or the anchor could perform a GET instead of a POST. etc. etc.

As a thought experiment, if it could be done, would it be better to have the "login/logout" button as a standard part of the browser chrome, and not as a visible element in the HTML page at all? (The HTML page would contain hidden attributes for the browser to interact with.) Instead of an anchor tag, how about using a "meta" tag, or a "link" tag in the header. (It might take years to train users how to do things that way, but special browsers or browser extensions could be created that do it. How about accessibility for blind users, etc. etc.)

(2) Webauthn does not have a logout.

OK. So webauthn lacks that use case or feature. I don't think it matters that much.

A declarative HTML API should provide a "logout" option. As using it gives the browser more abilities. It allows the browser to perform pre and post processing (before and after the logout) and figure out the current login state at the RP.

Most RP websites *currently* have a "logout" option. (As an anchor in the HTML page.) The proposed change is that the RP should use an API that *explicitly* informs the browser of the RP's intent to perform a logout. (i.e. The browser gets to perform pre and post processing.)

Also, the "action" property allows other actions besides "logout". For example, "prove-user-presence", "change-credentials", etc. 

(3) The API should inform the browser of the success/fail of the login request.
The resulting RP login state should be maintained by the browser.

(This allows browsers to provide a "logoutAll" button and other features like that.)

OK. Webauthn does not inform the Authenticators if the login action succeeded or not. navigator.credentials.store does not work for PublicKeyCredentials. (It always returns an error.) However, this may not matter that much.

Some sort of response is still required from the RP to the browser. I think that: (1) The response should be caught by the user authentication code in the browser. So that the browser can perform post-processing after a successful login.  (Even if webauthn does not do post-processing, the browser needs to provide the hook for it.  For browser UI updating, browser extensions, etc.) (2) The browser should be able to tell if the response signals a login success or failure. The browser should keep track of the login status at the RP. (3) The response can also contain a redirect_uri. (Or the response can be a regular HTTP redirect response, as long as the other two criteria are met.)

Webauthn may not require a success/fail response or post-processing, but these traits are desirable for other use cases. The browser may want to do post-processing for some other reason (accessibility, visual cues in browser chrome, etc.), or other protocols may require post-processing. (Using a "password" Credential Management Level 1. etc. Also, by using new properties in the JSON, the browser can declare support for some other standard, and the browser can choose to use that standard.)

The idea is to give browsers the information about the RP login status, so as to allow browsers to innovate and automate as much as possible and provide more features for their users. Browsers are user agents, they act for the benefit of the user. They should be provided basic login information so as to allow them to do more for their user. (Such as to remember the login/logout status of RPs.)

For example, it would probably be a useful thing for browsers to have an easy way for the user to "logout from the browser". To close (or at least hide) all the current tabs that are logged in and may display sensitive information. Closing the browser will work, but should that be the only option? Would it not be convenient for the user to be able to close (or temporarily hide) all sensitive information in their browser in some situations? (If the user goes to the bathroom, if the browser is not used for an hour, etc.) Advanced users could use a browser setting to choose what they want to happen, etc.

I think it would a bad thing to not provide browsers with the explicit login status of the RP. This would limit browsers, so that when they innovate, they have to guess as to the RP login status.

(4) Using the JSON document for other applications.

Sounds good, a separate JSON document may not be needed for these cases at all. OK.

As a thought, if the URL for JSON document was moved to a "meta" or "link" element in the header, maybe that would allow HTTP/2 to deliver it along with all the other documents as part of the page load. That would cut out the additional HTTP request.



-- 
GitHub Notification of comment by Garnac
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1255#issuecomment-511599189 using your GitHub account
Received on Monday, 15 July 2019 22:53:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:59:06 UTC