RE: Timeouts and WebauthN

An extension of time means you do not lose any data.  Restarting the auth process may require that you re-enter your user name or authentication details again.  Generally speaking authentication processes in general are likely to have this challenge unless as in Peter’s example pressing some key extends the time without loss of what you have entered.   It seems to make sense to allow for a reasonable time limit here given that we want this to be adopted and the data that may need to be re-entered is only the authentication information.  I could understand that if you had to re-authenticate during a process that would be different as you might lose your place – but we do have a AAA criteria for that situation.

Jonathan

From: Alastair Campbell <acampbell@nomensa.com>
Sent: Wednesday, July 14, 2021 11:50 AM
To: David MacDonald <david@can-adapt.com>
Cc: WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: RE: Timeouts and WebauthN

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi David,

> Strictly speaking in the bullets for the SC there doesn't seem to be a passing provision where the user is timed out but can easily restart the timer.

I might be squinting hard at this, what if you’ve got a form like this:

[heading] Login

[p] Selecting the button below starts the device authentication, if you don’t manage to do that within 5 minutes then press the button again.

[button] Login with webauth

That seems to fit extend: “The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times”

The user is warned, they have more than 20 seconds (infinity), and at least 10 goes (infinity).

Obviously most implementations don’t have the warning, but that at least fits the letter of the SC as well as the spirit.

> It appears the author can set the timeout. I'm not sure where this code lives.

Yes, that’s set by the content, it isn’t an external server/service.


> If WebAuth defaults to 5 minutes (or 6 minutes) one way to pass would be to extend that to 50 minutes or 60 minutes in this code.

I don’t think so, the extension is for the default of the content. If you set the default (for this site) to 50 minutes, that because the new default. It isn’t comparing to a spec.


>  Perhaps there is a way to link a button to that bit of code to extend it.

That seems a bit pointless when you can just re-open the authentication.


> Not proposing a solution here, just trying to look at options for approaches. Here's what I see as our options:

  1.  Change the text of timing adjustable for 2.2
I’m not sure that’s possible with our ratchet approach to backwards compatibility, i.e. where passing 2.2 means you pass 2.1. If you relax a requirement then you could pass 2.2 but fail 2.1.


  1.  Provide two techniques for meeting the current language (1) extend it in the code (2) link a button to that code to extend it on a button press
I don’t think either would work for the security factors here, (I think) the time-out is to prevent interception hacks, or people putting the device down and someone else picking it up at a critical time.


  1.  Fudge with the understanding to say that an "easy" restart of the process is close enough to an extension of the time out that we will accept it as a pass (a little risky to take that approach)
Where the outcome is the same as one of the exceptions, I think that might be possible.
-Alastair