Meeting minutes
<Chuck> lost audio, working the issue
Accessible Authentication Note 3
Using Google Doc https://
We have various proposals for Note 3
Note 3 Option 1: Original proposal NOTE 3: Device passwords, used to unlock a device, are out of scope for this requirement as these are not up to the author.
Looks like most preferred 4 or 7 (votes in the doc)
Note 3 Option 4: Mary Jo - An additional adjustment to the proposal from the 1 Feb. meeting NOTE 3: Passwords used to unlock the underlying platform or system are out of scope for this requirement when the authentication process is not up to the author of the software application.
Note 3 option 7 This requirement applies to any software that implements or includes an authentication process. Note: it does not apply to authentication processes that occur to platform layers below the software in question.
Note 3 option 7 - minor editorial This requirement applies to any software that implements or includes an authentication process. Note: it does not apply to authentication processes that occur in platform layers below the software in question.
Some of these options for note 3 have not been discussed yet - they were added after meetings from last week.
Note 3 option 7 - further editorial This requirement applies to any software that implements or includes an authentication process. Note: it does not apply to authentication processes that occur in platform layers underlying the software in question.
Sam: Option 5 is simpler to read. Option 7 has a nested note that is confusing
Note 3 option 7 - Mary Jo's latest edit, with below swapped for underlying This requirement applies to any software that implements or includes an authentication process. It does not apply to authentication processes that occur in the underlying platform software underlying the software in question.
Mary Jo: Note 3, option 5, was trying to avoid using the language "out of scope"
Sam: Doesn't necessarily exclude platform software - just about whether the author has control.
mitch11: Now happy with option 5 as well
<maryjom> Poll: Which option do you prefer for Note 3?
<Sam> 5
<Chuck> 5
4, 5, or 7. I do agree with Mitch that all are rather similar
Looks like option 5 may be the winner...
maryjom: Just worry about the language "out of scope"
maryjom: We've previously only used out of scope in context of hardware
"does not apply" instead of "out of scope"?
Note 3 Option 5: Sam’s edit of option 1, removing out of scope: Passwords used to unlock platform software may be unable to apply to this requirement as these are not up to a software application’s author.
Note 3 Option 5: Sam’s edit of option 1, removing out of scope: Passwords used to unlock platform software may be unable to apply this requirement as these are not up to a software application’s author.
<maryjom> Software applications are not responsible for the authentication process of the underlying platform.
Passwords used to unlock platform software may be unable to apply this requirement when these are not up to a software application’s author.
<Sam> +1 to Phil last one
Sam & Mitch : like not up to, or not under the control of... author
mitch11: Understanding text uses similar language
"Evaluating whether or not the code can be seamlessly transferred from the secondary device to the primary device is outside of the scope for this Success Criterion. ..."
mitch11: So we could take a similar approach if we wanted
<maryjom> Poll: Which is your preferred option?
Note 3 Option 9: Edit of Sam’s option 5 Passwords used to unlock platform software may be unable to apply this requirement when these are not up to a software application’s author.
Note 3 Option 9: Edit of Sam’s option 5: Passwords used to unlock platform software may be unable to apply this requirement when the authentication process is not up to a software application’s author.
<Sam> Option 5 then Option 9
<mitch11> prefer 5, accept 9
9, but also happy with 5
Chuck: Also prefers 5, as 9 reads like the password applies the requirement. 5 reads better, but understand the sentiment of 9
<mitch11> prefer 5 with addition of "underlying", accept 9
Note 3 Option 9: Edit of Sam’s option 5: Software authors may be unable to apply this success criterion to underlying platform software when the authentication process is outside their control.
Note 3 Option 10: Edit of Sam’s option 5: Software authors may be unable to apply this success criterion to underlying platform software when the authentication process is outside their control.
<LauraBMiller> Prefer 5
5 is clearer - go with this, and take it to the full task force
Consensus from this small sub group is 5 is the least bad
Latest version: Note 3 Option 5: Sam’s edit of option 1: Passwords used to unlock the underlying platform software are out of scope for this requirement as these are not up to a software application’s author.
Note 5
Note 4
Note 4 Option 3: Mary Jo’s take (Move the note to Closed Functionality, and change it to the following) NOTE 4: Systems that are designed for shared use (such as in a public library) might block mechanisms typically used to assist the user, such as copying authentication information from a password manager. Instead, an alternative authentication method might be necessary, such as an identity card scanner.
<maryjom> Poll: Do you prefer option 3 or 4?
Note 4 Option 4: Phil’s modification (Move the note to Closed Functionality, and change it to the following) NOTE 4: Systems that are designed for shared use (such as in a public library) or have closed functionality might block mechanisms typically used to assist the user, such as copying authentication information from a password manager. Instead, an alternative authentication method might be helpful, such as an identity card scanner.
<mitch11> 4
4, but happy with 3
<Sam> 4
<LauraBMiller> 4
<maryjom> 4
Sam: Are we agreed to move this to closed functionality section?
<maryjom> Poll: Should Note 4 be moved to the closed functionality section?
<Sam> +1
+1
<LauraBMiller> +1
<maryjom> +1
Consensus from this sub group - go with option 4, and move to SC problematic for Closed functionality
mitch11: Noticed Gregg had an editorial - change 'mechanism' to 'method'. May speed things up prior to survey
maryjom: mechanism is used as the language in the SC
Note 4 Option 4b: Phil’s modification - method instead of mechanism (Move the note to Closed Functionality, and change it to the following) NOTE 4: Systems that are designed for shared use (such as in a public library) or have closed functionality might block method typically used to assist the user, such as copying authentication information from a password manager. Instead, an alternative authentication method might be helpful, such as an[CUT]
Note 5
<maryjom> Poll: Which option do you prefer?
3, but it might make sense to move to SC problematic for closed
<Sam> 3
<Chuck> Where standards for banking or security have authentication requirements that are regulated or strictly enforced, those requirements may supersede the 3.3.8 Accessible Authentication (Minimum). For example, some [software applications | systems with closed functionality], particularly those that handle financial transactions, have a requirement for a personal identification number (PIN) for authentication.
LauraBMiller: Like removal of the problematic. There are methods to help people to enter PIN on glass.
Chuck: Would like to subtract a portion from note 5
Chuck: Was using option 3 of note 5
LauraBMiller: Agree that simplifying option 3 improves it
Note 5 Option 3: A variation of Option 2 calling out conflicting standards/regulations, removing “problematic” [Use both in the general section and in closed functionality, saying “software applications” for the former or “systems with closed functionality” for the latter (in bold).] NOTE 5: Where standards for banking or security have authentication requirements that are regulated or strictly enforced, those requirements may sup[CUT]
…
… Authentication (Minimum). For example, some [software applications | systems with closed functionality], particularly those that handle financial transactions, have a requirement for a personal identification number (PIN) for authentication.
<Chuck> +1
<LauraBMiller> +1
NOTE 5: Where standards for banking or security have authentication requirements that are regulated or strictly enforced, those requirements may supersede the 3.3.8 Accessible Authentication (Minimum). For example, some [software applications | systems with closed functionality], particularly those that handle financial transactions, have a requirement for a personal identification number (PIN) for authentication.
<maryjom> Poll: Can we use Option 3 and delete the last two sentences?
<LauraBMiller> +1
+1
<mitch11> +1 with one edit: change "supersede" to "legally supersede"
with Mitch's tweak: NOTE 5: Where standards for banking or security have authentication requirements that are regulated or strictly enforced, those requirements may legally supersede the 3.3.8 Accessible Authentication (Minimum). For example, some [software applications | systems with closed functionality], particularly those that handle financial transactions, have a requirement for a personal identification number (PIN) for authentication.
+0.75
<LauraBMiller> +1
<maryjom> Poll: agree with above language, and propose to the TF it be added to the SC problematic for closed functionality
<mitch11> +1
<Sam> +1
+1
<Chuck> +1.25
<LauraBMiller> +1
mitch11: happy for it to not be in general SC - and only apply to closed.
maryjom: Could add an editor's note: are there any non-closed systems that this might apply to as well?
Next Friday we will return to adjustments to Reflow. We were working on public comments that touch on this
If there any items from problematic for closed that you have been working on and want to bring to the Friday meeting - let Mary Jo know