Re: going though comments from 2.2.6 Accessible Authentication and new wording.

Hi Lisa,

> Some key points for the call today on accessible authentication for the wording draft  at

That’s a good improvement, but it still has the hole in the 1st exception: If authentication involves email (e.g. using your email as username), then the whole process is exempt. I don’t think that is the intention?

I suggest: “Re-authentication process only relies on basic personal identification information”

> 1.  we were concerned that web authentication specification which is a great standard way to meet this SC was not mature enough and did not have implementations. However this specification is now at wide review version and is on track for CR.

Which means 2nd Quarter 2018 according to their charter, is that in time to be useful?

> They have implementations in Microsoft Edge, the Google Chrome and the Mozilla Firefox browsers and working in different operating systems. (See

Their blog is not very clear, I’ve been searching for the implementation status on FF & Edge, the best I can find is: (not planned) (Worked on, but hard to determine progress).

When they say “implementations”, that does not mean they are publically available in browsers yet. The firefox one is behind a flag, I’m still not clear where to find the MS one.

Also, remember that webauth is useful when you are not using multiple factors, in the multi-factor scenario it replaces one factor, and you still need a username/password (or code to copy across).

> 2. the only type of multi-factor identification that is bared is on involving coping a code.

Without webauth, that is all (standardised) multifactor options available via the browser.

> This method is being activity depreciate by NIST as insecure.

No, that is just SMS. The popular Googe-auth/authy style 2FA still in wide use. (I have a dozen codes active in my app for google, Microsoft, amazon, dropbox, hosting companies etc.)

> 3. the use of a passport manager can be an allowed technique so long as specific conditions are met …

I assume you mean password manager here, and as I said 1st Dec:

I’d be happy to have an SC about not blocking password managers, it would fit nicely under guideline 4.1, something like:

“Assisted Authentication: User interface components which gather authentication credentials do not prevent automatic entry.”

NB: Not marking up an input as password properly could be failed under 1.3.1 and possibly 4.1.1 already.

However, we are a bit late in the 2.1 cycle for a new SC!

So the question is: Would you like to proceed with this (in my view) redundant SC requiring sites to provide a non-password method of re-authentication for single-factor auth?

The only other (useful) option I can see is that we assume people can use a password manager.

In which case, we could re-scope the SC to ensure that sites which do use 2 factor make it simpler for re-authentication:


Essential steps of a multi-factor re-authentication process which relies on recalling or transcribing information has alternative essential steps which do not rely upon recalling or transcribing information, unless there are legal requirements for a recall or transcribe method of authentication.


That basically says: You can use username/password, but for 2nd factor you have to provide a mechanism for re-authentication which doesn’t require typing things in.

The options for that are then:

  *   Save the person’s cookie, only re-auth after 30 days or with a new browser.
  *   WebAuth (later).
  *   ‘Magic’ link.

Having it apply to second-factor re-auth makes it more feasible.

> 4. we asked the web authentication group for feedback months ago, and we also performed and passed a security audit on this success criteria.

That is good, but that does not mean it is feasible to do across all web sites.

Kind regards,


Received on Tuesday, 19 December 2017 14:22:51 UTC