Design Pattern: Common to any Internet Identity Ecosystem

Design Pattern Metadata

DRAFT: September 2016

Title

This pattern is the progenitor of all IDESG UX design patterns for internet connected devices. It will be updated where needed to fit the needs of the dependent patterns.

Status

Design Pattern Lifecycle Status

Contributed	Working Draft	Committee Review	Compilation	Approval	Publication
Marked up since last review. See Identity Design Patterns for the current list of design patterns and their status.

Design Pattern Review Status

This Design Pattern has been reviewed by the Privacy Committee. An addition has been made since then to the Privacy Considerations.

Expect changes before this pattern is final.

Design Pattern Category

Privacy, Trust/Assurance, Interoperability

Contributor

Tom Jones
Edits:
Ellen Nadeau
Mary Hodder

Design Pattern Content

This pattern is designed to fit the broad needs of developers of user experiences for displays that are conformant to the IDESG principles. It should satisfy both web browsers displaying HTML as well as applications downloaded to a mobile device. No attempt has been made to show low level design elements as the range of applicability of this pattern is designed to span a large range of display sizes. The terms used in creating design patterns follows the taxonomy described in the UXC_Use_Case_Mapping#Categories_used_in_User_Experience_Evaluations

Problem Description (meme)

Users need to be able to understand when an IDESG set of criteria are involved and what that means to them. Dependent patterns can include all of the user experience conditions in the common pattern by reference. They do not then need to repeat any of these condition in those dependent patterns.

When to use this Pattern (Context)

• Any time a user is asked to provide identification or personal information.
• The relying party (RP) can voluntarily determine which policies will provide it with the information it needs to allow access to its site. If the IDESG Trustmark is on the web site the user can be assured that the web site has agreed to the broad IDESG requirements. {confirm with TFTM}
• The RP can voluntarily chose to support one or more IDESG trust frameworks known to follow IDESG principles for the user to choose from. Whenever more than one Trustmark is displayed on a web site, the user will have the opportunity to select which Trustmark will apply to the balance of the interaction until the user decides to switch to a different Trustmark.
• It is not anticipated at this time that more than one Trustmark would ever apply at any one time in an interaction.

The following illustration shows the primary actors and the data that they maintain. For the general case considered here, the specific category of entity required is not specified as it could be a relying parity, identity, attribute or authorization entity that interacts with the user. Connections that the entities have beyond the user connection are not indicated as all data sent to or received from the user by way of a user agent (or browser) will pass to one entity at a time. That does not imply that multiple entities are not part of a single user interchange, but only that the interchanges to the user deal with a single entity at a time.

Relationships with other Design Patterns

This pattern is the progenitor of all IDESG UX design patterns for internet connected devices. It will be updated where needed to fit the needs of the dependent patterns.

Since this design pattern operates at a level of abstraction above the description of actual UX elements, the designer will benefit from additional resources at the level of the design elements themselves. The following references supply that kind of support (for example the accordion pattern in the first reference shows one method to accommodate the additional information needed in the above image with dynamic UX elements):

• https://developer.yahoo.com/ypatterns/everything.html
• http://searchpatterns.org/library.php

Actors

The following roles are present in any IDESG compliant ecosystem. Note that some of the roles may be collocated in a single site on the Internet. This section uses the "Entity" definition of the IDESG Functional Requirements as any organization providing or using identity services. Before all of this can be defined there needs to be an Identity Ecosystem, an online environment where individuals and organizations will be able to trust each other because they follow agreed upon standards to obtain and authenticate their digital identities—and the digital identities of devices. The Identity Ecosystem is designed to securely support transactions that range from anonymous to fully-authenticated and from low- to high-value.

1. User: An individual human being This does not include machines, algorithms, or other non-human agents or actors.
2. User Agent: In this pattern an agent is any piece of operational code that displays a user experience and obtains responses from the user in order to satisfy the privacy concerns of the user and the need for identity and attribute claims by the relying party.
3. Entities The collection of all internet based services with which a user will interact to create, supply and consume identity and attribute claims as required to complete the task that they have undertaken.
   1. Identity or Attribute Provider (IAP): An entity that contains identities or attributes of users that will be provided on demand in claims that the user can forward to a RP.
   2. Relying Party (RP): An entity that needs a collection of claims to provide that service; the RP might rely on a collection of claims from different identity or attribute providers.

Solution

Description of the Solution

In the UXC design patterns, the user experience that is generated by a user agent from RP web sites might improve if RPs automate some requests for user's attributes. It is beyond the scope of any of these Design Pattern to determine policy questions like whether the RP actually has any justification in requesting any user attribute at all.

1. The user establishes an account with one or more IAPs that are accredited with one or more IDESG Trustmarks. In this case there is no need to distinguish between identity providers and other attribute providers.
2. The user accesses a web site which at some point requires identity and attribute claims of some sort to continue to process the user request. That web site then transitions from providing purely anonymous access into a relying party.
3. The RP gives the user a choice of which IDESG framework (with its Trustmark) or legacy provider to provide identity claims.
   1. In general the identity provider will be a distinct role from the RP where a persistent identity across multiple interactions is desirable. In some cases the RP may also include a local identity provider option.
   2. The option of ephemeral connection ID may be provided at the RP's options where anonymous interactions are permitted.
4. This request for information is intercepted by the user agent, or any privacy-enhancing technology intermediary (a step where user drop-out may occur).
   1. Determine if the information is available based on the specific requested attributes from the RP.
   2. Determine if the user has already authorized release of claims to this RP.
   3. Display any remaining choices to the user to acquire more attributes or transmit those already available in the agent.
   4. Format the set of requested claims into a response in a way the RP can evaluate the claims.
   5. Send the response to the RP who has sole responsibility to determine if sufficient claims have been proved to authorize the request access.
   6. Repeat these steps till the RP is satisfied or one side gives up.

Anti-patterns

This section describes some patterns of user experience that should be avoided when building any user display. These particular patterns are incorporated by reference in every other IDESG UXC design pattern. The patterns are ordered from specific to the more general. The first items are those solutions that have been tried, but failed, to deliver on a promise of better security for privacy in the past. The latter items are those that violate accepted user experience principles.

Note that this section does not make any judgement about whether such user elements need to be shown for legal reasons. It only addresses issues of usability and user experience.

1. Too much detail. Identity and personal data management policies today suffer in part from an overload of information where a user doesn't have the time or ability to understand the ramifications of these policies when applied. Cognitive overload [[1]] will cause users to miss or misinterpret the message. (See also the reference in item 3 below.) Even when Microsoft tried to be brief these 880 words, including links to two legal documents is the best that they could do. Clearly some better solution is needed for users who do not have the patience for this.
2. Too little attention. If the user does not see and evaluate the IDESG trust mark, it has no impact on their experience. Prominence-Interpretation Theory [[2]] teaches that two things need to happen for people to assess creditability online:
   1. The user notices something (our Trustmark)
   2. The user makes a judgment about it (forms a favorable opinion about the internet site).
3. The Trustmark is not recognized for what it is or what it means. A study in 2013 evaluated Which site seals do people trust the most? It showed that seals promoted by profit making companies, and simpler seals, were the most trusted.
4. The user is encouraged to enter a unique user name and password for each relying party. One goal of the IDESG is for user credentials to be shared across multiple sites so relying parties should encourage the user of a federated identity rather than ask the user to create yet another user ID password pair.

Error Conditions

USABLE-3 states that “Information presented to USERS in digital identity management functions MUST be in plain language that is clear and easy for a general audience or the transaction's identified target audience to understand.” This applies to error messages, which should be expressed in plain language, clearly indicating the problem and constructively suggesting a solution.

Any error condition that requires user action should create the following user experience elements

1. As much detail about the cause of the error that would help the user understand while not significantly impacting the user flow or security.
2. A way for the user to mitigate the error. The response "Please contact your administrator" does not qualify as a mitigation step.

The following are specific errors that the user might see.

1. User does not have credentials that can generate claims acceptable to the relying party.
   1. Mitigation option: The provider redirects the user to one or more sources of appropriate credentials that do meet the criteria for authorization at the RP.
   2. Mitigation option: The relying party redirects the user to one or more Identity Providers or trust frameworks that are acceptable. If a new framework is chosen, that may involve user acceptance or change to some Privacy Enhancing Technology (PET) to meet those particular authorization requirements.
   3. Mitigation option: The user is allowed to back-out of the current path to one where they can succeed.

Usability Considerations

This section further refines the user experience defined in the User Experience Overview.

• User Control and Freedom

• Match between system and the real world
  • All IDESG logoed web sites are expected to participate in establishing a trusted identity ecosystem. This design pattern will be combined with other design patterns to help design and build web sites that align with the IDEF requirements.
  • Related requirement from IDEF v1: USABLE-5, accesibility, indicates that: “All digital identity management functions MUST make reasonable accommodations to be accessible to as many USERS as is feasible, and MUST comply with all applicable laws and regulations on accessibility.”
• Consistency and Standards
  • One important part of any Design Pattern is the intelligibility of the design to the user. Here it is very important that the user understand the meaning of the IDESG mark sufficiently well to understand the benefits from it. Related requirements from IDEF v1:
    • USABLE-3, plain language, states that: “Information presented to USERS in digital identity management functions MUST be in plain language that is clear and easy for a general audience or the transaction's identified target audience to understand.”
    • USABLE-4, navigation, states that: “All choices, pathways, interfaces, and offerings provided to USERS in digital identity management functions MUST be clearly identifiable by the USER.”

Read the report of the IDESG experience committee on use case usability at UXC Use Case Mapping

Value Proposition

The value of the IDESG Trustmarks is directly proportional to the number of successful sites that use the marks to help users find sites that meet their requirements. There is a good evaluation of the value of such marks (called judgment devices) in an article on How Ratings and Awards Do (and Don’t) Benefit Companies that appeared in the Harvard Business Review. This implies that for the mark to be successful on any web site it must be prominently a part of the user elements where a user makes a choice about providing personal information to the site.

One difficult acceptance barrier for new design choices is the web site of the relying party. If any part of the implementation hinders use of the web site, or exploits the user, there may be hesitation around implementing the feature.

References and Citations

TK

NSTIC Guiding Principles Considerations

Privacy Considerations

There are a number of sources of leaks to user private information that are considered by any ID pattern:

1. The user agent provides more information to the RP than the user intended.
2. The user interacts with the RP over an extended period allowing the RP to determine the user ID from their behavior.
3. The RP has privacy policies that are obscure or not followed. A multipage privacy policy is ipso facto obscure. Often leaks of user private data are allowed by insufficient security at the RP or other parties that have access to the data.

Some privacy considerations, such as an expressed user intent, have been separated out to specific design patterns.

Other privacy consideration include identifying and locating persons, and personal information through aggregation, analysis and inference of human attributes are systemic issues applying to any identity ecosystem.

Related requirements from IDEF v1:

1. PRIVACY-7, user data control, states: “Entities MUST provide appropriate mechanisms to enable USERS to access, correct, and delete personal information.”
2. PRIVACY-10, user option to decline, indicates that: “users must have the opportunity to decline registration; decline credential provisioning; decline presentation of their credentials; and decline release of their attributes or claims.”
3. PRIVACY-BP-C, recommended consequences of declining, states in part: “if information collection or attribute value release is designated as mandatory, that designation should include a short and clear description of the consequences of declining to provide that information or allowing that release.
4. PRIVACY-11, optional information, states: “Entities must clearly indicate to users what personal information is mandatory and what information is optional prior to the transaction.”
5. PRIVACY-12, anonymity, states in part that, “Wherever feasible, entities MUST utilize identity systems and processes that enable transactions that are anonymous, anonymous with validated attributes, pseudonymous, or where appropriate, uniquely identified.”

Anonymity

Based on the above requirements, the user of a IDESG logoed web site should be able to assume that no information is collected about them until their intent to allow collection has been positively recorded by the entity hosting the web site. Some sites may need to know some attribute of the ultimate user such as location and age in order to provide specific quotes of service. The design of the data collection needs to be extremely limited to avoid inadvertently acquiring sufficient information to enable the lookup of the user's identity since it is known that 87% of the U.S. population is uniquely identified by {date of birth, gender, postal code} [[3]]. Any site that collects that much information would be in violation of the IDESG description of anonymous.

Pseudonymity

Where the user needs access without allowing linkage back to their true identity, some trusted IdP would be required to have a policy to prevent linkage despite the capability of the information to allow identification of the user. This type of pseudonymity is not possible with sites that allow third party access for any purpose such as linkage to advertising content on the third party site. The definition of pseudonymous (following) shows the necessity for some sort of entity with privacy enhancing technology when the above three attributes are known.

Definitions from the IDESG Glossary

Anonymous "An INTERACTION designed such that the data collected is not sufficient to infer the identity of the USER involved nor is such data sufficient to permit an ENTITY to associate multiple INTERACTIONs with a USER or to determine patterns of behavior of a USER."

Pseudonymous "An INTERACTION designed such that the data collected is not sufficient to allow the ENTITY to infer the USER involved but which does permit an ENTITY to associate multiple INTERACTIONs with the USER’s claimed identity."

The bolded words could be modified to show their aspirational value by replacing them with is never to be used by the ENTITY to determine or something similar. But the goal of the definitions was to avoid using them to create requirements, which that change still does. Perhaps the definition could be something less prescriptive like" --- "When the user intends to allow linkage from one INTERACTION to another at a different time or device, but does not wish to allow linkage from the current identifier to their real world identity."

Security Considerations

In general security is not considered in this Design Pattern as security will be provided by the same type of credentials, token and claims as used in any secure implementation. One additional wrinkle that is inserted by a PET provider is that the PET provider must have a sufficient level of trust by the user and the relying party to perform the desired function.

Interoperability Considerations

User choice depends critically on each relying party making their request in a manner that can be consistently rendered by the user agent in a form that the user can comprehend that can then be matched to information available from the identity, attribute or privacy-enhancing technology provider.