Re: [External] RE: Timeouts and WebauthN

OK, that’s great, and makes a lot more sense to me than trying to force it into the essential exception bullet.

I think that we should make sure to explain this clearly as an option in the Understanding document, but can almost hear the question being typed for a comment to ask “how far in advance of a timeout can the warning be provided?” We are saying that 5 minutes is not too long from getting the message on page load to the timeout occurring and users will be appropriately notified, but what about 20 minutes? I assume that there is a point where the advance notice is too distant from the event, and we may be asked what that is.

Also, we should have a technique for this scenario.

Thanks,
AWK

Andrew Kirkpatrick
Director, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk



From: Alastair Campbell <acampbell@nomensa.com>
Date: Wednesday, July 14, 2021 at 11:50 AM
To: David MacDonald <david@can-adapt.com>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: [External] RE: Timeouts and WebauthN
Resent-From: WCAG <w3c-wai-gl@w3.org>
Resent-Date: Wednesday, July 14, 2021 at 11:50 AM

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