UXC Meeting Agenda

AGENDA for UXC, 9am PT, 12 noon ET, June 23, 2015:
https://idesg.webex.com/idesg/j.php?MTID=m15e3edf756a99940ac7b515ce79e4dc6
1. Call to order (1-6: 3 minutes)
2. Recording question: Yes; Recording policy: https://www.idecosystem.org/page/recording-policy-conduct-meetings
3. Note taking: Ann
a. Attendance
4. Review and approval of agenda
5. IPR Rules: https://www.idecosystem.org/iprpolicy
6. Review and approval of minutes from prior meetings

• March 10, 2015 https://www.idecosystem.org/filedepot/folder/23?fid=1796
• March 17, 2015 https://www.idecosystem.org/filedepot/folder/23?fid=1797
• April 7, 2015 https://www.idecosystem.org/filedepot/folder/23?fid=1798
• April 21, 2015 https://www.idecosystem.org/filedepot/folder/23?fid=1799
• May 5, 2015 https://www.idecosystem.org/filedepot/folder/23?fid=1800
• May 12, 2015 https://www.idecosystem.org/filedepot/folder/23?fid=1801

7. Current Work and Activities Discussion: (50 minutes)

A. Review of UXC Requirements, and Supplemental information, Guidelines and Metrics: https://www.idecosystem.org/wiki/User_Experience_Guidelines_Metrics

• Metrics document for UX Benchmarks: http://www.measuringusability.com/blog/ux-benchmarks.php
  • reference materials: UXC requirements and guidelines
    
    • Note: Word documents sent via our email list last FRIDAY
    • Reqs sent to FMO in March, 2015 can be found here at the https://www.idecosystem.org/wiki/UX_Usability_Requirements_and_Guidelines_Working_Document

B. SCC review of KAB starting 7/1/15 ??

C. UXC other docs:

• Design Pattern Work located here:
  
  • Common Design Pattern and fit with Reqs / Guidelines: https://www.idecosystem.org/wiki/Common_to_any_Internet_Identity_Ecosystem
    
  • Trustmark Evolving Pattern: https://www.idecosystem.org/wiki/Trustmark_Evolving_Pattern
    

D. Information Ethics Discussion: anything else?

8. Chairs Report
9. Liasons report
10. Other business?

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. 11. Ongoing Action Items (3 minutes)

1. ARR and Mary to discuss Human Centered Possibility (HCP) driven options in general and a focused response to "How are UX Metrics obtained."
2. ARR mentioned that UX to consider insertions of the word "transparency" in requirements and supplemental.
3. Mary to write up proposal for review of terms
   
4. Metrics document for UX Benchmarks: http://www.measuringusability.com/blog/ux-­‐ benchmarks.php
5. Ellen suggests possible standard for SCC: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=58625
6. Review other Committee’s requirements for UX guidance.
7. Clarify Listing/ Advertising on UX Wiki…Some ideas about how to ha
8. Mary to ask for MA for ISO Standard Review copy
9. Create another page(s) for UX review of other committees’ requirements, ARR will be happy to help create these.
10. A brief paragraph about how to approach the UX wiki may be helpful for new participants…”start with the Agenda…”
11. UX has an opportunity to weigh in on “Anonymous” term in healthcare.

12. Adjourn