[Navigation Timing] Client authentication

Hi All,

According to the connectEnd attribute definition<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html>, it includes the time interval to establish the transport connection as well as SSL and SOCKS authentication, however what about the time spent for client authentication where the user has been prompted for credentials, but has not committed/dismissed the dialog yet?

Consider the following scenario:
1.      Connection is already established
2.      Client requests a page that requires authentication, but doesn't give the credentials.  This is probably the most common as this will occur when the user just navigates to www.foo.com<http://www.foo.com>
3.      Server responds with HTTP 401 (Unauthorized) status code with the expected authentication scheme and realm.
4.      The browser prompts the user for the credentials.
5.      The user can cancel if they want to or give the username/password.
6.      If user gives credentials, then the client adds an Authorization header with value base64encode(username+":"+password) to the original request and resends it.
7.      Server either accepts the credentials and returns the page, or responds with another status code...perhaps another 401 to prompt the user again.

It isn't clear from the definition, whether client authentication should be part of the connect phase or part of the response phase.  In any case, at step #6 if the user lets the dialog remain open for a considerable amount of time, the timing data for the respective phase will become inflated.

Some options to consider:
1.      Do nothing - probably not the best plan if it's not clear
2.      Do not add a new phase (clientAuthenticationStart/End) and update the connect or response phase definitions to call out that this time should be omitted...specifically the time between prompting the user and the user either supplying data or cancelling the prompt.  The phase would still capture the time of the 401 response and the server round trip of the credentials.
3.      Add a new phase (perhaps named clientAuthentication) which captures this time.  If you don't eliminate the time spent in the dialog, then the valuable information regarding the authentication process itself is lost.
4.      Other suggestions?

My vote is for #2.  We made a similar decision with the unload phase.  It only includes the time spent in the onunload event as the onbeforeunload event can contain blocking UI and is cancelable.  The same is true here.

Thoughts?  Shall we discuss this at next week's call?

Thanks,
Karen