RE: Accessible Authentication

If the Understanding page is supposed to provide clarity, it's not doing a very good job! It's actually muddying the waters. For instance, it says "Goal: Make logins possible with less mental effort." and "Intent: The purpose of this Success Criterion is to ensure there is an accessible, easy-to-use, and secure method to log in." Sounds pretty unambiguous to me - it's all about login.

It doesn't explicitly exclude other uses of authentication, but it doesn't include them either - they are not even mentioned. Does that mean they are allowed? Perhaps our misunderstandings are due to the difference between Napoleonic law (you can't do anything unless it is explicitly permitted) and common law (you can do anything unless it is explicitly prohibited). Which one prevails in this context?

The Understanding page could have referred to "authentication processes, such as login". But it didn't, and we have to assume there is a reason for that. I don't believe that the authors couldn't think of any use of authentication other than login.

Steve


-----Original Message-----
From: Patrick H. Lauke <redux@splintered.co.uk> 
Sent: Tuesday, November 14, 2023 11:31 PM
To: w3c-wai-ig@w3.org
Subject: Re: Accessible Authentication

Getting back to authentication, I'd note that it's not accurate I think to say that the understanding document explicitly says that if something is NOT a login, then the SC is not applicable. Rather, it only provides prose around the login scenario. If there is another case of authentication (however, in the sense that it was intended - i.e. 
proving WHO you are, which is more restrictive than 'proving you're a human' which is the scenario for non-login uses of CAPTCHAs, or registering an account, where you're not *proving* who you are but telling a system who you claim to be), the understanding document doesn't mention it, but also - I don't think anyway - precludes it?

If there are other non-login authentication scenarios, I'd suggest that the understanding document can of course be expanded to name-check/explain them, as long as it doesn't change the intended normative meaning.

And yes, the core problem here is that WCAG did not explicitly define the term "authentication process", instead leaning just on referencing "process", which is problematic. All through the drafting of the SCs, it seemed there was a common understanding in AGWG about what "authentication" actually meant and that it didn't need defining as it was self-evident ... but clearly that's not the case.

Incidentally, there's already a parallel discussion here
https://github.com/w3c/wcag/issues/3264


(and a side note that this problem earned the SCs a little appearance in my recent presentation, on slide 68
https://patrickhlauke.github.io/wcag-interpretation/#68)

P
-- 
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke

https://flickr.com/photos/redux/ | https://www.deviantart.com/redux

https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke

Received on Wednesday, 15 November 2023 01:10:38 UTC