Talk:UX Usability Requirements and Guidelines Working Document

Noreen Comments

Looks like some of my comments under HL 1 should actually be placed under HL 2 these have to do with look/feel and system changes rather than language issues. Also HL 6 addresses language and perhaps could be incorporated in HL 2 instead of under its own guideline. The example given re NSTIC guiding principle 32 that is used as basis for HL 6 seems to be addressing the same natural language issues that HL 2 addresses.

Bev Corwin's Comments

FYI: My biggest concerns about this discussion:

1. That we do not effectively legislate any small businesses, particularly mom and pop shops, out of business with all these ideas around increasing demands on them that IDESG seems to be going.

2. Seem to be forgetting the "voluntary" guiding principle. Far too rigid thinking. (It's not "our - IDESG's" ecosystem - we do not "own" the ecosystem)

3. Multidirectional, multimodal thinking is missing.

4. Costs of implementation is no discussed at all, and it will be a huge defining factor.

UXC meeting minutes discussion: terminology and feedback from Privacy on UXC Reqs, added 6/23/2015

1. UXC Requirement: Information presented to users, provided by participants in the identity ecosystem, shall be in plain language, i.e. language that is clear and easy to understand by a general audience.

— Input from Privacy: Some new terminology may be necessary to effectively communicate new concepts or processes accurately to users. It will be important to provide guidelines on how to articulately and briefly define these terms. There are few (if any) standard definitions of anonymous, psuedonymous, and verified identity states and few are concise -­‐ it may be difficult for organizations to deliver on this guidance. Therefore, the IDESG may need to provide definitions or remove this piece of guidance.

UXC discussion: Even if we are looking to have common terms, we may need additional links. We may need to share definitions as the best way process. If we have a domain specific definition, it is up to the owners of the domain to do so. UXC Requirement: All choices, pathways and solutions provided by participants in the identity ecosystem shall be available and clearly identifiable by the user.

— Input from Privacy: The requirement may create an overwhelming amount of IDP discovery options to users or contradict some privacy or security requirements of the system (such as in sensitive systems). May want to provide guidance on how to balance the provision of pathways. Some options might be used by vulnerable populations and highlighting those may open the door to attack/violation of privacy.

UXC discussion: It may not be feasible for them to change what they have been doing so it would put them into noncompliance. This may just a point of further investigation and reconciliation for us. This requirement needs further clarification. It should be up to Privacy to walk us through this input. Where is this amount of IDP coming from? What is driving this and what is the core of the problem? What is the exposure? We need a better understanding of their comments, so we can better understanding of what they are saying. The use of “pathways” is of concern. They may be thinking of exposing security or privacy things that would constitute a violation. Mary will respond back to them to get more clarification.

The UXC Requirement: All systems provided as part of the identity ecosystem shall provide opportunity for redress: an easy way for users to report errors, complaints, etc. while preserving user privacy. Input from Privacy: There is a privacy requirement on redress as well, but the requirement covers a slightly different aspect of redress. Maybe an element of overlap, but redress design will need to be informed by both privacy and UX expectations. UXC discussion: That is probably true on a lot of requirements at some level. We will need to make sure we cover both group’s interest on redress.

The UXC requirement: Where interactions with users exist or are expected, and user requirements standards exist, users shall have structured opportunities to document and express their requirements early on in interacting with Service Providers in online transactions. The use shall receive a response to their requirement from the provider early on in the interaction.

Input from Privacy: It seems these standards are still in development – should this requirement be informative? Or, should it reference best practices for entities that do not have standards that are applicable to their services? FMO may want to provide some clarity regarding the use of “standards” and the example of Do Not Track. User requirements will need to be recorded in a privacy enhancing fashion.

UXC discussion: We discussed this when we created the requirement. There is a question about the do not track “standard” because the W3C has not yet created a standard yet – they are still in process, but there are places where the “do not track” concept in codified in the law. What constitutes a standard? Is it because it is used? How long has W3C been working on this and what is the goal? Spring, 2010 or 2011 W3C held conference in the industry as kickoff event. Trying to please too many people and questionable as to how much headway they are making. Do not track is a law in California. What is a user? Relying parties? System to system interaction, so the system is the user? We have been thinking of the user as a human being. The UXC charter, the user is a human. Some standards work, a certain number of standards were created with the system in mind. There is a disconnect as to who is the user and maybe this will come out during the harmonization process. Could the UXC have a role in reviewing some of the standards review to see if the UXC perspective is adequately addressed? Why aren’t there more UXC standards? Maybe UXC could provide some help in this area. Mary looked at UXC charter.