UXC Use Case Mapping

From IDESG Wiki
Jump to: navigation, search

About the User Experience and Use Cases

This page describes the categories and mappings of IDESG use cases (scenarios) into user experience (UX) patterns. It also maps the entity categories into UX patterns.

User experience standards applied to Use Cases

Standards for IDESG UX to compare the existing use cases so that gaps can be identified and mitigations proposed. Note that in all cases the use cases do not represent actual

  1. - User General (based on Nielsen’s principles from his Usability Engineering book)
    1. The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
    2. Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
    3. Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
    4. Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
    5. Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
    6. Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
  2. - User to IdP (or other) provider
    1. Terms and conditions can be expressed on a single mobile phone page.
    2. Attributes are not requested unless required to match authentication or authorization conditions. (Like LOA from NIST SP 800-63)
    3. User can completely delete all references to user that can be discovered without a court order.
    4. If the user losses access to the identity provided reasonable terms to regain access are provided.
  3. - User to Agent or intermediary (Arbitrarily assuming that all privacy-enhancing technology and caching of creds occurs by this role). The following list came from the PrimeLife prototypes described in the book listed in the reference section.
    1. Data management makes it easy to store and organize personal information.
    2. Credential management makes it easy to store an organize certificates and credentials.
    3. Privacy preferences makes it easy to set general data release policies and the level of reporting back to the user.
    4. Relying Party evaluation helps the user evaluate the credibility and trustworthiness of the RP.
    5. Data release makes it easy to understand what they are asked to agree too and whether the decision (and accompanying claims) will be cached.
      1. Cached decisions can be retrieved and modified (or at least deleted) by user.
      2. Decision are only cached per either (1) relying party or (2) members of a common IDESG framework
    6. History lets the user see what information has been disclosed to which RP.
  4. - User to Relying party
    1. User can understand what attributes are required and why they are required all within a single mobile phone page.implementations. As a result the use cases are not evaluated on what they directly provide to the user, but rather they are to be evaluated on the guidance that they provide to the designer and implementer of the user experience.
    1. No sharing of user identity or attributes are permitted without explicit permission.
    2. RP provides some protocol elements (such as EV certificates [[1]]) that the user agent can use to provide information about the RP to the user.

Categories used in User Experience Evaluations

The first step is to describe the categories of roles that will be mapped. Note that we emphasize roles rather then real-world objects because a real-world object in many cases will provide the functionality of more than one role. This section is structured as a taxonomy to enable a clear distinction between terms. This page follows the Taxonomy AHG Glossary from the IDESG standards and security committees where they were able to reach consensus.

  • Named Object: A thing that exists, e.g., a person, organization, device, software application or service. (Taxonomy) This is an object that is defined not by its attributes, but by a thread of continuity and identity. Any Named Object must have an identifier that persists for its lifetime.
    • User: For the purposes of the UXC, a “user” is a natural person, and generally singular. (aka individual, human being or carbon-based-life form)
    • Organization: A collection of humans or other organizations.
    • Device: A silicon-based life form that can form network connections. if the device has an identity in a piece of hardware, like a smart card or TPM chip, it is a Named Object.
    • Connection: An identified link between two or more entities. (This is the one Named Object not yet recognized by the taxonomy AHG)
      • Ephemeral Connection: An identified link with a short life time.
      • Persistent Connection: An identified link that may extend for an indefinite period of time.
      • Ceremony: A conversation between two entities that provides evidence of a good faith effort to achieve informed user consent.
  • Identifier: an effectively unique attribute that applies to an Named Object.
    • Anonym: an identifier that is intended not to be linked to any Named Object other than a ephemeral connection.
    • Pseudonym: an identifier that is intended not to be linked to any Named Object other than a persistent connection.
    • Entity: An Named Object that provides or uses Identities.
    • Software Application or Service: A virtual entity that exists on one or more devices.
  • Role: A function that exists within an entity. Entities may host several roles.
    • Relying Party: An entity role that requires identity and possibly attribute claims to permit user access to resources on their site.
    • Provider: Any other role besides relying parities.
      • Identity (IdP) - a source of identity claims, like Hotmail or Facebook (which also function as RPs of their own IdP).
      • User Attribute (UAP) - think members of the armed forces (ID.ME) - could also be an RA.
      • Device Attribute (DAP) - think Remote Attestation Service for TPM or TZ equipped devices
      • Biometric - all of the above are knowledge based attribute providers (KBA) this is everything else.
      • Privacy Enhancing Technology (PETP) - this role converts user or device claims into unlikable claims.
      • Identity Oracle as described by Bob Blakley [[2]] can be realized by placing a PETP in front of an IdP
      • Policy - think a smart card identity where the smart card protection policy is fixed as a part of the certificate template.
      • Proofing - think driver’s license or other in-person identity.
      • Authenticity Proofing - think EV certs and registration authorities (RA).
      • Certificate Service Provider (CSP) - a specific type of secure id provider with a strange set of formatting rules (X.509).
No Title + Description User -> Identity (etc.) Provider User -> User Agent User -> Relying Party

Mapping of Use Cases to UX categories

This paper takes the existing use cases and presents the contributor’s view of the UX challenges of each. The columns show how a user (person) interacts with each of the following: Identity (or other) Provider, User Agent and Relying Party. Comments and questions are from the UXC perspective, about how and what UX challenges may exist at each point where the user interacts with parties in the system.

Use Case No.s correspond to Sections in “Use Case 1.2 Commentary” Comments. The questions in this table are from the user experience committee to the use case ad hoc working group.

No Title + Description User -> Identity (etc.) Provider User -> User Agent User -> Relying Party
3.1 DEVICE INTEGRITY SUPPORTING USER AUTHENTICATION – this case assumes a security component contained in the user device, but it could be a separate dongle in some implementations. Requires trusted interchange between user and Device Attribute provider. Someone needs to pay the DAP. Q: how does the user register their machine? Runs on user device with a hardware root of trust which can be linked to a user id – complex new ideas for user to comprehend. Runs on user device with a hardware root of trust which can be linked to a user id – complex new ideas for user to comprehend.
3.2 AUTHENTICATE PERSON – the user (an individual) gets to choose their IdP Fairly standard IdP: helps the user get to choose their IdP. There is a proviso that the IdP meets the RP’s LOA. Has the option to select “Do-not-track”. Q: How does the user understand the context and how the rules apply? Mediates authentication process. Privacy enabling technology (PET) interface definition needed. Typical token caching problems to be controlled in some way by user. Q: Will the user choose a cloaking or PET? User choice of IdP may not be acceptable to RP. But one process step says that RP directs user to IdP(s) they do accept. Q: is this too complicated for user?
3.3 IDENTITY PROOFING – for example: how a driver’s license bureau verifies a user address by mailing the user their driver’s license. Confusing terminology for the addition of an identity proofing step to the IdP registration. Q: how will this be made clear to user? n/a Addressed above.
3.4 CRYPTOGRAPHIC AUTHENTICATION FOR ACCESS TO ONLINE RESOURCES – all online authentications uses crypto. This use case discusses the more difficult ways to do it. User must have some token to create cryptographic signatures. Some tokens have really poor UX. Q: how will this be made clear to user? In some instances the cryptographic key is stored on the user device. The existing UX for this is also really poor. Q: how will user know what to find, and find it, especially in mobile instances? The RP must make its authentication needs known to user that doesn’t understand.
3.5 DELEGATED AUTHENTICATION FOR USER MANAGED ACCESS – increasingly important, but hard to get right. This use case assumes there is no new technology over currently available, and that some authz server must be able to access the content on some content server. Very complex. The content owner needs to be able to trust that only specific content has been released to a service acting as agent for user in this limited context. Maintenance of this continuing authz is required. Some service wants to act as user-agent to acquire user content on another site. The user needs to delegate to this service authz that is limited to the required content. The site that contains the user’s content needs to be assured that the user really did authz release to the agent.
3.6 CREDENTIAL ISSUANCE – describes one view of how existing credentials are handled. Since none of these work at all well, it might be better to try to start with a good UX and then build the use case from that. This is indistinguishable for 3.5. A credential service provider is described with others might call a certificate authority. Existing UX to these is super challenging. An optional registration authority is described to do identity proofing. Either normal user device or one that can handle cryptographic tokens. The UX for cryptography is traditionally very poor UX. Needs to be able to request the LOA in a manner that the user can comprehend and provide. In most cases this means a help desk.
3.7 ACCESS AGE RESTRICTED CONTENT – can go both ways, up and down. This is a normal IdP together with an attribute provider. Addressed above. Must be able to express requirement for age verification.
3.8 PRIVACY ENHANCED BY USER AGENT – in the case the PEP is include in the user device. It could be provisioned in the IdP or as an independent agent. Normal – unless the IdP hosts the Privacy Enhancing Technology Provider (PETP). See UC 3.12. The PETP needs to: get the RP requirements and display to the user on a single page on whatever device in use, gets the response and caches user decisions. The RP needs to express the need for user attributes in a way that the agent can display to the user.
3.9 TRUST ELEVATION – user can start a relationship with a pseudonym and move up to a fully proof ID as required. Normal – may need more than one IdP or attribute provider as the trust elevation progresses. The user agent needs to select appropriate credentials for the user based on user intent an RP needs. The RP can start as a normal web site and demand additional creds as needs dictate.
3.10 FOUR PARTY AUTHENTICATION AND AUTHORIZATION – same scenario as 3.3 and 3.6 with different names for the same function. Confusion between the ideas of attribute provider, registration authority and identity proofer make this seem different. Addressed above. Addressed above.
3.11 UN AND UNDERSERVED PEOPLE – help the unbanked perform money transactions on the internet It can be a real challenge to create a strong identity for homeless or otherwise disadvantaged people. Q: Does the user have to get a state ID card? What about undocumented people? Addressed above. Addressed above.
3.12 SELECTIVELY DISCLOSE ATTRIBUTES – in the case that the PETP role resides in the IdP. In addition to normal IdP functionality the IdP must track all of the sites to which a user release credentials to maintain user choice. This will be a difficult UX to be sure. User agent is part of IdP. How can the user know that is to be trusted? Addressed above.
3.13 REMOTE ELECTRONIC IDENTITY PROOFING – think electronic notary. Normal IdP functions, probably with identity proofing. Notaries require Gov't ID. Will the Gov't IdP be the same IdP functionally proving the Gov't ID? Notary verifies user and the signature of the user on a doc. Very specialized RP that needs notarized docs

References applied to Use Cases

  • NIST Special Publication 800-63 Electronic Authentication Guideline [[3]]
  • The Meta-Identity System (or Identity Oracle) as described by Bob Blakley [[4]]
  • A report of a user experience study on privacy enhancing technology (PET) is available in chapters 10 and ll of the book "Privacy and Identity Management for Life" Springer 2011 ISBN 978-3-642-20316-9.
  • A series of ISO 9241 [[5]] applies to Human System Interaction. ISO 9341-210 [[6]] provides guidance on human-system interaction throughout the life cycle of interactive systems. The first principle of human user-centered design is one based upon an explicit understanding of users, tasks and environments.
  • A functional requirements document is under discussion to show the relationship among the various levels of the IDESG model. It shows the scenarios as dependent on distinct identity frameworks. That is an item for current discussion on the discussion page attached to that page. Additional input from the UX community is specifically needed. Click on this link to read Functional Requirements