W3C home > Mailing lists > Public > public-cognitive-a11y-tf@w3.org > September 2016

RE: Re: what is the consensus? was RE: Argument to revert my "User authentication methods" success criteria to the pre-5th Sept COGA call version (with a small mod)

From: Thad C <inclusivethinking@gmail.com>
Date: Sat, 17 Sep 2016 06:37:27 -0700
Message-ID: <CAOh2y+-Y25O+vf93n_eM=9Xf6Kur6vas-=QeJ=EzMJtuss4HOQ@mail.gmail.com>
To: Michael Pluke <Mike.Pluke@castle-consult.com>
Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
Hi Mike,

I will add other into the template for yo8.

Best
Thaddeus
On Sep 17, 2016 2:00 AM, "Michael Pluke" <Mike.Pluke@castle-consult.com>
wrote:

> Hi
>
> I realise that I omitted an important paragraph that should have preceded
> the last paragraph of the "Description" section. This is:
>
> "An alternative user authentication method is required to cope with users
> who are temporarily or permanently unable to use the primary
> user-authentication methods. One important situation where a user will be
> unable to user the primary user authentication methods is if they do not
> have a suitable trusted device or are not subscribed to or unable to access
> the third-party services that are frequently part of user authentication
> methods that meet the criteria for primary user-authentication methods."
>
> If there is a possibility to add this it would enhance the understanding
> of why an alternative user-authentication method is required.
>
> Best regards
>
> Mike
>
> Sent using CloudMagic Email
> <https://cloudmagic.com/k/d/mailapp?ct=ti&cv=7.9.8&pv=9.3.1&source=email_footer_2>
>
> On Fri, Sep 16, 2016 at 6:37 pm, Thad C <inclusivethinking@gmail.com>
> wrote:
>
> Hi Mike,
>
> Yes, not a problem. Glad to help.
>
> Best,
> Thaddeus
> On Sep 16, 2016 10:02 AM, "Michael Pluke" <Mike.Pluke@castle-consult.com>
> wrote:
>
>> Hi Thad
>>
>>
>>
>> Thank you for your kind offer to put my SC proposal into the template.
>>
>>
>>
>> The attached Word document is the best I have been able to do whilst in
>> the conference with a badly depleting battery!
>>
>>
>>
>> I hope that you are able to handle it so that we can get to the WCAG WG.
>>
>>
>>
>> Best regards
>>
>>
>>
>> Mike
>>
>> New SC v2 <https://1drv.ms/w/s!AonHhdlMwzu_zFziFK13W1io4NZ8>
>>
>> OneDrive
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* lisa.seeman [mailto:lisa.seeman@zoho.com]
>> *Sent:* 15 September 2016 19:51
>> *To:* Michael Pluke <Mike.Pluke@castle-consult.com>
>> *Cc:* Thad C <inclusivethinking@gmail.com>; public-cognitive-a11y-tf <
>> public-cognitive-a11y-tf@w3.org>
>> *Subject:* Re: Re: what is the consensus? was RE: Argument to revert my
>> "User authentication methods" success criteria to the pre-5th Sept COGA
>> call version (with a small mod)
>>
>>
>>
>> Mike, could you put this in the draft template and I  show it to wcag at
>> tpac? They might have some interesting feedback
>>
>> All the best
>>
>> Lisa Seeman
>>
>> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
>> <https://twitter.com/SeemanLisa>
>>
>>
>>
>>
>> ---- On Thu, 15 Sep 2016 20:52:43 +0300 *<**lisa.seeman@zoho.com*
>> <lisa.seeman@zoho.com>*>* wrote ----
>>
>> I think that could work but wonder if the second provision will not be
>> come outdated soon after  it gets to CR
>>
>>
>>
>> In which case maybe we want the following:
>>
>>
>>
>>
>>
>> If there maybe  users who are unable to use the primary user
>> authentication method  an alternative method should be offered that
>> ...(conforms to Option 2).
>>
>>
>>
>> That way the extra burned of an additional login expires as soon as the
>> easy sign in becomes ubiquitous. we can explain it in the description
>> section
>>
>>
>>
>>
>>
>> All the best
>>
>> Lisa Seeman
>>
>> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
>> <https://twitter.com/SeemanLisa>
>>
>>
>>
>>
>> ---- On Thu, 15 Sep 2016 15:35:24 +0300 *Michael Pluke
>> <Mike.Pluke@castle-consult.com <Mike.Pluke@castle-consult.com>>* wrote
>> ----
>>
>> Hi Thad and Lisa
>>
>>
>>
>> Lack of good technology is not really my primary concern regarding Option
>> 1. I think that quite good technology already exists to support user
>> authentication methods that pose few problems for users with cognitive
>> disabilities e.g. web services that support automatic login of Apple
>> TouchID authenticated users as well as login via Facebook, Google, AppleID
>> etc. I expect that these will increasingly become the PRIMARY method
>> offered to users - leading to the apparent death of the password. All of
>> these methods meet the rigorous Option 1 requirements - which I think can
>> be more succinctly summarised as not requiring the user to memorise, recall
>> or mentally process information.
>>
>>
>>
>> However all of these methods require some pre-conditions before a user
>> can use them. The user approaching the service must have specific
>> proprietary hardware configurations or be signed up to and logged in to a
>> service recognised by the web service's user authentication method. A web
>> service can, and several do, support multiple of these proprietary methods
>> but there will always be people who are permanently (don't own the hardware
>> or are not subscribed to the offered service(s)) or temporarily unable
>> (dead battery on a key authentication device) to use the offered methods..
>>
>>
>>
>> I think that this contrast between what would be best for users with
>> cognitive disabilities (Option 1) and what a last-resort fallback solution
>> (Option 2) should look like when the Option 1 solution won't work for a
>> user (which is inevitable) is the cause of the strong Option 1/Option 2
>> divergence.
>>
>>
>>
>> Option 1 is the ideal form of user authentication to maximise the
>> usability for all - the problem is there will be situations where users
>> will be unable to use such a biometric/SSO/token solution. Option 2
>> describes the minimum requirements for a fallback method that those unable
>> to use the Option 1 method should expect.  I think that it is these
>> completely different perspectives that is the cause of the strongly felt
>> Option 1/Option 2 divergence. I believe that both perspectives are valid in
>> their own context and that neither is sufficient to fully describe the
>> requirement.
>>
>>
>>
>> Here is a suggestion of how I think that we can define a very robust and
>> comprehensive success criterion that says (in terms of ideas rather than
>> exact words):
>>
>>
>>
>> 1) The primary user authentication method offered to users should not
>> require the user to  memorise, recall or mentally process information.
>>
>>
>>
>> 2) For users who are unable to use the primary user authentication method
>> an alternative method should be offered that ...(conforms to Option 2).
>>
>>
>>
>> Whereas I was not prepared to draft a simple Option 1 as I thought it had
>> serious limitations, I would be happy to try to modify the success
>> criterion to reflect this more sophisticated and realistic model.
>>
>>
>>
>> Does this option look OK to others?
>>
>>
>>
>> Best regards
>>
>>
>>
>> Mike
>>
>>
>>
>>
>>
>> Sent using CloudMagic Email
>> <https://cloudmagic.com/k/d/mailapp?ct=ti&cv=7.9.8&pv=9.3.1&source=email_footer_2>
>>
>>
>>
>> On Wed, Sep 14, 2016 at 6:50 pm, Thad C <inclusivethinking@gmail.com>
>> wrote:
>>
>> I vote for option #1 as it reflects the most collaborative effort of the
>> purposed information. Sorry Mike I dont mean to dismiss your POV, expertise
>> or hard work. I do think we need:
>>
>> "rewording to make it widely applicable, if the technology has not moved
>> forward in the next 3 years such as another exception"
>>
>> That was my intention in providing the links that referenced articles on
>> the future landscape of authentication models.
>>
>> On Sep 14, 2016 10:40 AM, "lisa.seeman" <lisa.seeman@zoho.com> wrote:
>>
>> Hi folks
>>
>>
>>
>> there have been arguments on both sides, and unfortunately I do not think
>> we have the time to spend on this now.
>>
>>
>>
>> can we see what the consensus is
>>
>>
>>
>> *option 1:* go with the wording from the call three weeks ago. We can
>> put some notes in the bottom of the proposal saying it may need some
>> rewording to make it widely applicable, if the technology has not moved
>> forward in the next 3 years such as another exception
>>
>>
>>
>> *option 2:* go with Mikes original wording ( the concern was that some
>> mechanism for authentication  were allowed that some coga users will not be
>> able to use)
>>
>>
>>
>> *option 3:* continue the discussion
>>
>>
>>
>> Please write back with you preference
>>
>>
>>
>> (Mine is option 1)
>>
>>
>>
>> All the best
>>
>> Lisa Seeman
>>
>> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
>> <https://twitter.com/SeemanLisa>
>>
>>
>>
>>
>> ---- On Wed, 14 Sep 2016 16:16:00 +0300 *<lisa.seeman@zoho.com
>> <lisa.seeman@zoho.com>>* wrote ----
>>
>> "they might accept an automatic login from an iPhone 5s or later to which
>> the owner has authenticated themselves with Touch ID. But this option would
>> still not help people who are trying to access the website from their PC.."
>>
>>
>>
>> Lisa comments - The idea was bluetooth tokens. By the time the this
>> becomes a standard (in 3 years)  it is very likely that this
>> is common place and can be used by people who are trying to access the
>> website from their PC.
>>
>> There is a concept of the user burden. They may need to have a the common
>> accounts for third part sign in or an assistive technology - in this case
>> that might be a phone that uses Bluetooth.
>>
>>
>>
>> Remembering in image is not an option for many users with an impaired
>> visual memory and/or short term memory.  It is a limited solution for a a
>> subset of our users.
>>
>>
>>
>>
>>
>> All the best
>>
>> Lisa Seeman
>>
>> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
>> <https://twitter.com/SeemanLisa>
>>
>>
>>
>>
>> ---- On Wed, 14 Sep 2016 16:06:02 +0300 *Michael
>> Pluke<Mike.Pluke@castle-consult.com <Mike.Pluke@castle-consult.com>>*
>> wrote ----
>>
>> Hi Lisa
>>
>>
>>
>> The issue paper may have been looking at things from a user perspective
>> *only*. If, as a user, biometric identification is available to me then
>> that is very convenient – but to the majority of users in many contexts
>> that is not an option (i.e. those that don’t own a top-end smartphone or
>> that are accessing a web service via a computer that does not have
>> biometric identification support (most)). If I am lucky and also if the web
>> service will trust the secure chip in the device to which I authenticated
>> myself I have avoided all cognitive barriers. This is an ideal available to
>> a minority of people in a minority of contexts.
>>
>>
>>
>> The success criterion has to consider what a web service can actually
>> offer. A web service* cannot*, of itself, *offer biometric
>> identification* as an option for its users. If, say, the British Airways
>> website declared that it offered biometric user authentication as its
>> alternative to its username and password option what would that actually
>> mean? How could someone evaluating the website begin to understand or test
>> that assertion? What feature would the evaluator look for on the British
>> Airways site?
>>
>>
>>
>> A web service could, justifiably, claim to offer login from a trusted
>> device as an alternative i.e. they might accept an automatic login from an
>> iPhone 5s or later to which the owner has authenticated themselves with
>> Touch ID. But this option would still not help people who are trying to
>> access the website from their PC. Even when hybrid solutions like being
>> able to use a trusted mobile device to authenticate to a service being
>> accessed from a PC become more common, these will still be options that
>> will not be available to the majority of users – and hence not a viable
>> alternative to methods that persons with cognitive disabilities are unable
>> to use.
>>
>>
>>
>> Where an alternative to potentially inaccessible methods is proposed it
>> MUST be available to anyone accessing the service (not just to those owning
>> suitable devices). An alternative that asks the user to identify their
>> security image from a page containing a number of images will be usable by
>> many people who find it impossible to remember usernames and awkward
>> passwords. Such a method would be acceptable according to my original
>> proposal but unacceptable according to Lisa’s revision.
>>
>>
>>
>> Such a method could still prove impossible for some people with, for
>> example, advanced dementia whose ability to recognise or recall images had
>> been seriously impaired.  Providing an alternative cannot always be a
>> guarantee that everyone who makes use of it can access the service.
>> Attempting to ensure that the SC covers all severities of all cognitive
>> disabilities has resulted in an SC that no service provider could say that
>> they have met.
>>
>>
>>
>> Best regards
>>
>>
>>
>> Mike
>>
>>
>>
>> *From:* lisa.seeman [mailto:lisa.seeman@zoho.com]
>> *Sent:* 14 September 2016 10:57
>> *To:* Michael Pluke <Mike.Pluke@castle-consult.com>
>> *Cc:* public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
>> *Subject:* RE: Argument to revert my "User authentication methods"
>> success criteria to the pre-5th Sept COGA call version (with a small mod)
>>
>>
>>
>> From the issue paper it seemed that the group consensus is to recommend
>> two authentication mechanism, one of which should be biometric or a token
>> or other such suggestion. Until such time as  a widely usable
>> authentication method is available, no one is suggesting having only one
>> alternative.
>>
>>
>>
>> Right now for capture, the visual user has one option, the non visual
>> user  has another option (audio). It is ok if one option meets some  needs
>> of some users,  and the other option meets the needs of other users. It is
>> the best we can do for now.
>>
>>
>>
>> To me that was clear from the language, but we can also make a  language
>> tweak to clarify that ideals like tokens or biometric is an acceptable
>> alternative,  although it does not need to be the only alternative to
>> conform and sometimes having two access methods may be necessary  to
>> address issues you brought up. Hopefully at some point there will be a
>> universal sign in, but until then more then one method is recommended.
>> (This can go in the description)
>>
>>
>>
>> But perhaps I still do not understand.
>>
>>
>>
>> What scenarios would you see as acceptable ?
>>
>>
>>
>>
>>
>>
>>
>> All the best
>>
>> Lisa Seeman
>>
>> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
>> <https://twitter.com/SeemanLisa>
>>
>>
>>
>>
>> ---- On Wed, 14 Sep 2016 11:41:40 +0300 *Michael
>> Pluke<Mike.Pluke@castle-consult.com <Mike.Pluke@castle-consult.com>>*
>> wrote ----
>>
>> Hi Lisa
>>
>>
>>
>> The fundamental reason that biometrics cannot be the (potential single)
>> alternative method are, off the top of my head:
>>
>>
>>
>> -          a person providing a web-based service is not in a position
>> to offer this as an alternative. Biometric sensing is always something
>> performed on a device and this will only ever be available on devices that
>> have the necessary sensing devices (e.g. finger sensors, infrared “depth
>> cameras”, etc.).
>>
>> -          for security reasons matching the biometric measure to a
>> template is (almost?) never done by a remote service, it is performed on
>> the device – but only on a few high-end devices;
>>
>> -          having a (potentially) single alternative method that is
>> biometric will break the universally accepted rule that there should always
>> be a non-biometric alternative (but I have already argued that all known
>> alternatives except SSO will fail the SC – which leads into a circular
>> logic that the SC demands and alternative – if that is biometric it also
>> demands an alternative – all alternatives break the SC.
>>
>>
>>
>> It can be argued that it is a user choice not to use a commercial service
>> to facilitate login to a service whose default login method is not
>> accessible to the user. However, I am sure that this argument is totally
>> against the spirit (and law?) of what constitutes an acceptable success
>> criterion. Here are a few reasons:
>>
>>
>>
>> -          many users may not have made a conscious decision to avoid
>> Facebook as I have. When they encounter an inaccessible user authentication
>> method they will be presented with an option to use a service to which they
>> are not subscribed and which they maybe know nothing about. They will
>> either be totally unable to use this alternative method or forced to
>> sign-up to a service which they know too little about and had no previous
>> need to use. This latter option is pretty unacceptable for all users and
>> even more so for many people with cognitive disabilities who will be
>> panicked by sudden surprises and uncertainty.
>>
>> -          If it is acceptable that not owning a device or subscribing
>> to a service can be dismissed as a “user choice”, then it might be possible
>> to remove many WCAG success criteria because, say, an iPhone meets those
>> criteria and it is a “user choice” not to own an iPhone.
>>
>> -          Even if a “standardized third party sign in” can be
>> universally agreed *and* *universally adopted* (a big IF that might be
>> against the interests of Facebook and Google), it is still very doubtful
>> that it would be acceptable to have a success criterion that only works
>> properly if you assume that everyone is signed up to this service.
>>
>>
>>
>> As I tried to argue before, both of the above sets of arguments amount to
>> the same thing:
>>
>>
>>
>> -          I do not believe that it is acceptable to say you must
>> provide an alternative unless you can be sure that this alternative will be
>> available to everyone in all contexts. I believe that this is a quite
>> fundamental aim of WCAG SCs and, as argued above, biometrics and SSO/social
>> logins fail that criterion very badly!
>>
>>
>>
>> I believe that the your attempt to significantly broaden the scope of my
>> restricted scope draft “User authentication methods” success criterion has
>> broken it. One thing that characterises many WCAG Success Criteria is that
>> they are short, simple and of quite limited scope. Broadening the scope (or
>> reducing the scope to remove exceptions) almost inevitably reduces the
>> universality of the success criterion and reduces its conformance level e.g.
>>
>> -          1.2.5 Audio Description (Prerecorded) [AA] - 1.2.7 Extended
>> Audio Description (Prerecorded) [AAA]
>>
>> -          1.4.3 Contrast (Minimum) [AA] - 1.4.6 Contrast (Enhanced)
>> [AAA]
>>
>> -          2.1.1 Keyboard [A] - 2.1.3 Keyboard (No Exception) [AAA]
>>
>> -          2.2.1 Timing Adjustable [A] - 2.2.3 No Timing [AAA]
>>
>> -          2.4.4 Link Purpose (In Context) [A] - 2.4.9 Link Purpose
>> (Link Only) [AAA]
>>
>> -          2.4.6 Headings and Labels [A] - 2.4.10 Section Headings [AAA]
>>
>> -          3.3.4 Error Prevention (Legal, Financial, Data) [AA] - 3.3.6
>> Error Prevention (All) [AAA]
>>
>>
>>
>> I was not involved in the development of WCAG 2.0 but I wouldn’t be
>> surprised to learn that there were very many success criterion candidates
>> that didn’t make it to AAA because of an over-ambitious scope. In my view
>> extending beyond my original idea, plus the proposed improvement of my 2
>> nd bullet to “processing presented or memorised information" is the only
>> way to get an SC that can definitely reach level AA and maybe level A.
>>
>>
>>
>> Best regards
>>
>>
>>
>> Mike
>>
>>
>>
>>
>>
>> *From:* lisa.seeman [mailto:lisa.seeman@zoho.com]
>> *Sent:* 14 September 2016 02:25
>> *To:* Michael Pluke <Mike.Pluke@castle-consult.com>
>> *Cc:* public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
>> *Subject:* Re: Argument to revert my "User authentication methods"
>> success criteria to the pre-5th Sept COGA call version (with a small mod)
>>
>>
>>
>> Hi Mike
>>
>>
>>
>> The wording (before the bullets) are "*At least one user authentication
>> method is offered that does not rely on a user's ability to:*"
>>
>>
>>
>> In other words we are asking people to offer an alternative -  Such as a
>> standard long complex password and Biometrics, or the long password AND a
>> facebook or other  sign in.  Now you might not like the alternative
>> (Biometrics or facebook) but it is  available and hence the content is
>> available, even to people who can not use long passwords.
>>
>> you wrote
>>
>>
>>
>> *"Biometrics fails at the first hurdle as it is widely accepted that
>> there should always be a non-biometric alternative to biometric user
>> authentication mechanisms"*
>>
>>
>>
>> Why would the combination of an hard password option and biometrics be an
>> issue?
>>
>>
>>
>> Another option, for example was the third party sign in (facebook gmail
>> etc)
>>
>> The user may not like the options being given because they can not use
>> the long passwords and "  avoid facebook with a passion" But the avoiding
>> facebook , while understandable is a user choice, so the author of the
>> content had provided an accessible option even if the user prefers not to
>> use it. I have a gmail account that I only use for sign in's.
>>
>>
>>
>> Further, we can hope and encourage a  standardized third party sign in
>>  that is only that - and helps the user long on anywhere.
>>
>>
>>
>>
>>
>> The other alternative Mike is to go back to the drawing board with the
>> wording.
>>
>>
>>
>>
>>
>> All the best
>>
>> Lisa Seeman
>>
>> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
>> <https://twitter.com/SeemanLisa>
>>
>>
>>
>>
>> ---- On Wed, 14 Sep 2016 02:27:06 +0300 *Michael Pluke
>> <Mike.Pluke@castle-consult.com <Mike.Pluke@castle-consult.com>>* wrote
>> ----
>>
>> During the 5th September COGA call Lisa, Steve Lee and myself considered
>> my draft SC on "User authentication methods" (below) and discussed and
>> agreed some changes. At the time I was persuaded, but on reflection I
>> believe that, with the exception of the item mentioned at the very end of
>> this (long) email, the changes we agreed wreck the SC and, in my opinion,
>> make it unacceptable (probably even for AAA)!
>>
>>
>>
>> Original SC (with rationalizations for each bullet in square brackets
>> following the bullet):
>>
>> TITLE: User authentication methods
>>
>>
>>
>> At least one user authentication method is offered that does not rely on
>> a user's ability to:
>>
>> - memorize character strings or; [a frequently used mechanism i.e.
>> usernames and passwords. - the ability to perform this is something that
>> will diminish with even the mildest cognitive decline due to ageing]
>>
>> - correctly identify and enter numbered characters from a character
>> string or; [this was probably not well worded, but was aimed at the very
>> common and complex method that says "enter the third, seventh and ninth
>> characters of your passphrase" - such a task involves multiple cognitive
>> skills - memory, recall from long-term memory, sequential counting, holding
>> the result of each sub-task in short term memory, retrieving the multiple
>> sub-task results from short term memory and accurately entering them into
>> the system!!!]
>>
>> - perform calculations or; [self-explanatory]
>>
>> - speak or; [aimed at speech recognition based authentication that will
>> fail if the user is unable to speak the required word in a consistent way -
>> i.e. where the current state of their cognitive disability has a
>> significant impact on the quality of their speech - or could result in an
>> inability to speak]
>>
>> - reliably produce gestures or; [this involves a mixture of cognitive and
>> physical skills i.e. drawing a pattern (e.g. on a touchpad) that acts as
>> the person's unique security pattern, memorizing what the pattern was,
>> recalling what the pattern was with sufficient accuracy, accurately
>> reproducing that pattern in a drawing gesture]
>>
>> - recognise characters presented on screen and then enter them into an
>> input field. [e.g .CAPTCHA - this involves, at least, a level of reading
>> skill to correctly recognise the characters so that they can be entered]..
>>
>>
>>
>> Exception: A user identification method that relies on one of the above
>> abilities can be the only method if that ability is essential to make
>> effective use of the content accessed via the user authentication method..
>>
>>
>>
>> Lisa's suggested that the bullets should be changed to (with critiques of
>> each bullet in square brackets following the bullet):
>>
>> -memorize information such as characters, words, numbers or gestures or;
>> [In the chat we also added pictures. This bullet rules out all mechanisms
>> that rely on ANY memorization]
>>
>> -correctly identify information such as characters, words, numbers or
>> gestures or; [this rules out all methods that expects the user to
>> comprehend ANY type of content]
>>
>> -correctly copy information such as characters, words, numbers or
>> gestures or; [this rules out all methods involving copying ANY type of
>> presented information (correctly)]
>>
>> -reliably produce information from memory [this rules all methods that
>> rely on memory recall of ANY type of information]
>>
>> -perform calculations or complex cognitive function [this rules out all
>> methods that expects the user to process information in ANY way (depending
>> on the interpretation of "complex cognitive function" i.e. it rules out the
>> use of executive functions including working memory]
>>
>> -speak [as above]
>>
>>
>>
>> Taken as a set, the above bullets manage to exclude pretty much every
>> type of cognitive functioning e.g. no memorizing, no recall, no
>> comprehension, no executive functions. In the call we agreed that the only
>> methods that would meet the criteria were biometric methods or methods that
>> permitted access from a trusted device (that would still require a
>> device-level user authentication). Subsequently Steve Lee (who was on the
>> call) suggested that single sign on solutions and social logins such as via
>> Facebook.
>>
>>
>>
>> The problem is that none of these can be the "at least one other method"..
>>
>>
>>
>> Biometrics fails at the first hurdle as it is widely accepted that there
>> should always be a non-biometric alternative to biometric user
>> authentication mechanisms (as biometric methods will not work for some
>> users because they have a disability that prevents them from using the
>> method e.g. no hands, damaged iris, etc.), because the user has not setup
>> the biometric functions, or because the device does not support the
>> relevant biometric method.
>>
>>
>>
>> The other two methods (and biometrics) badly fail one of the key factors
>> that SCs (at least those at levels A or AA) would be expected to conform to:
>>
>>
>>
>> " whether it is possible to satisfy the Success Criterion for all Web
>> sites and types of content that the Success Criteria would apply to (e.g..,
>> different topics, types of content, types of Web technology)"
>>
>>
>>
>> It is not acceptable to have a trusted device as the "at least one other
>> method" as even users that have a suitable device will sometimes need to
>> authenticate from other devices. SSO and social logins would not be
>> acceptable as being the "at least one other method" as whichever method was
>> offered as this alternative method would not be usable by anyone except
>> those that were using the correct SSO solution (i.e. offering Facebook
>> would not work for me as I avoid it with a passion).
>>
>>
>>
>> CONCLUSION
>>
>> So I propose that I leave the SC with my original wording with the
>> exception of the 2nd bullet. Here, the suggestion during the call of
>> "processing presented or memorised information" instead of my poorly worded
>> 2nd bullet works OK for me.
>>
>>
>>
>> Best regards
>>
>>
>>
>> Mike
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>



image001.jpg
(image/jpeg attachment: image001.jpg)

Received on Saturday, 17 September 2016 13:38:35 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 17 September 2016 13:38:36 UTC