User Choice Pattern

Design Pattern Metadata

Title

User Choice Design Pattern is meant as a composable object that can be included in any IDESG entity. In some ways this is similar to the existing use case that discusses privacy enhancing technology, but the purpose of the pattern is limited to the attributes requested by the RP and the corresponding user experience. Note that a PET provider can be inserted between the RP and the user agent that renders the user experience.

Status

Design Pattern Lifecycle Status

Contributed	Working Draft	Committee Review	Compilation	Approval	Publication
This Design Pattern is available for review by the User Experice Committee (UXC) with the goal of refining and completing the Design Pattern, , see Identity Design Patterns for the current list of design patterns and their status.

Design Pattern Review Status

Initial posting.

Design Pattern Category

Privacy, Trust/Assurance, Interoperability

Contributor

Tom Jones

Design Pattern Content

Problem Description (meme)

Taxonomy of Requested Attributes User releases only that information to Relying Parties that they wish. User choices can be cached to avoid cognitive overload.

When to use this Pattern (Context)

• Any time a user is asked to provide any personal information. Personal information includes patterns of behavior that could be used narrow the population that contains the user, such as search terms.
• The user device consideration is that the device has a display at least 400 x 800 pixels with a live connection to the internet.
• The IDESG will create an identity ecosystem consisting of multiple trust frameworks that satisfy the needs of specific affinity groups. Since users need to communicate with different affinity groups from time to time, they will typically need to accommodate different trust frameworks during the normal course of daily computer use. Each affinity group can specify a Taxonomy of Requested Attributes default policy if it chooses.
• The RP has a relatively clear set of privacy compliance regulations to follow that can be satisfied by one or more IDESG trust frameworks.
• The RP will support one or more IDESG trust frameworks or providers known to follow IDESG principles for the user to chose from.
• It is expected that each trust framework will come with a set of rules and approved independent labs that can attest to the web site based on the trust frameworks that are supported by the site.

Relationships with other Design Patterns

This design pattern assumes the use of a device connected to internet service providers as described in the Design Pattern: Common to any Internet Identity Ecosystem design pattern.

• User Intent Pattern is used to acquire the user's intent to allow linking to be passed to the Relying Party.

Relationships with Use Cases

The Device Integrity is defined in the "Device Integrity supporting User Authentication Use Case" at [[1]]

Actors

1. User: In this case a human being that wants to access services on a web site and still retain privacy by requesting that the site not link the user's attributes to any other site or instance.
2. User Agent: in this case any piece of 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. Relying Party (RP): A service provider that needs a collection of claims to provide that service. The claims may relate to financial responsibility or other user attributes that are required by regulation to met legal responsibilities. The user experience for RP web sites should improve if they can automate some requests for user's attributes. It is beyond the scope of this Design Pattern to determine whether the RP actually has any justification in requesting any user attribute at all.
4. Identity or Attribute Provider (IAP): contains identities and attributes of users that will be provided on demand in claims that the user can forward to a RP.
5. Identity Ecosystem: a set of services that implement other trust services as required by the rules of that ecosystem. Note that all of the other actors are almost certainly required to function with multiple identity ecosystems; some, but not all, of these ecosystems are expected to be compliant with IDESG trust frameworks.

Solution

Description of the Solution

1. The user establishes an account with one or more IAPs. In this case there is no need to distinguish between identity providers and other attribute providers.
2. The user accesses a web site which requires identity and attributes claims of some sort to continue to process the user request. That web site then becomes a relying party.
3. The RP gives the user a choice from which IDESG framework or provider to provide identity.
   1. In general the identity provider will be a distinct role from the RP where a persistent identity across multiple interactions is desireable.
   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 privacy enhancing technology or directly by the user agent.
   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 to this RP.
   3. Display any remaining choices to the user to acquire more attributes or release those already available.
   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 identity has been proved to provide the request access.
   6. Repeat these steps till the RP is satisfied or one side gives up.

Taxonomy of an Attribute Request

It is important that the RP have a taxonomy of requested fields that can be presented to the user within the scope of a single device page. That implies that the taxonomy of requested fields needs to be limited to those items that the user can sensibly be expected to comprehend. It is expected that the language used will support name/value pairs with other attributes such as whether the attribute is mandatory. It is not likely that any list will be complete, the RP can always ask for other information, but this list is intended to be what is released by the user agent in claims. Permissions for release of this information to one RP is likely to be sticky; that is to be released on demand to the same RP, typically for a limited period.

1. Identity of the RP must be supplied to the user agent in a secure message, such as an EV certificate. This is needed, not only to be sure that the user is sure who is getting the information, but also to allows the future release of the same information to the same RP.
2. There is always a tendency for each relying party to determine that their requirement for information is unique and therefore they cannot use a predetermined set of user attributes. This tendency is destructive of user comprehension. The only way to assure that users will understand the options display is to make the basic set of options common for all users. Then a few extension on a web site will at least be in the context of the choice already known and understood by the user.
3. To keep the number of choice for the user small it is likely that aggregations of attributes will be required. One example would be the user's street address which is an aggregation of several attribute elements.
4. It is also likely that some attribute aggregations can be specified in more or less detail as the user is more or less comfortable in sharing information with the web site. For example the physical location of the user may be limited to a radius of miles, or feet, depending on the requirements of the app. Similarly the home address may be precise, or limited to just the postal (zip) code.
5. Message formatted by the RP in a language agreed by the identity framework (the following is just an example)
   1. Location
      1. Gross/Fine
   2. Age
      1. over/under {13, 18, 21, etc.}
      2. Birthdate - Highly likely to ID the user with only a little bit more information - very bad for privacy
   3. User Identity
      1. email {and what it can be used for: messages required by transaction, adds, share with others}
      2. address {just zip code, or full street address - very bad for privacy}
      3. phone number {for various access types, home, cell, fax, business, etc.}
   4. Device Identity - and perhaps device health

Error Conditions

1. User does not have credentials acceptable to the relying party.
   1. Mitigation: The ID ecosystem redirects the user to one or more sources of appropriate credentials that do meet the criteria.
   2. Mitigation: 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 change the PET to meet those particular requirements.

Usability Considerations

One important part of any Design Pattern is the intelligibility of the design to the user. Here it is very important that the user be give only some decisions to address as can easily and comprehensibly be display on the device used. Specifically the amount of explanatory text and the number of choices must be limited by the display capabilities of the smallest devices to be used in the ecosystem as specified above in the "where used" section. See the references section below for the experiences of operating systems that work on smart phones for an example of a real usable solution. The example of smart phone applications very germane in a internet environment where most web pages download active content into the user's browser (which functions as the user agent in the simplest cases.) The following link provides an image of the application download experience in a smart phone [[2]].

A good review of the complexity that users can face when trying to control the release of data is shown in the following article: "On Facebook, Deciding Who Knows You’re a Dog" http://www.nytimes.com/2014/01/30/technology/personaltech/on-facebook-deciding-who-knows-youre-a-dog.html?ref=technology&_r=0

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

Value Proposition

The most difficult acceptance barrier for most new protocols is the web site of the relying party. If any part of the implementation hinders use of the web site, the feature will not be implemented. If there is no business value to the relying party, it is unlikely that broad adoption will happen. The only way to ensure that any IDESG feature is accepted if for the relying party to see a better user acceptance, or at least a better user experience after adopting the feature. The user choice pattern with the taxonomy of requests provides the opportunity for the RP to include many requests for user private data in an user experience that is shared by many web sites and so will become more familiar and less scary to the user. It will also enable returning users to update their information with no additional user experience elements at all.

References and Citations

The Android operating system enforces a system of permissions on the applications loaded into the smart phone to give the user control of the capabilities of the application. Since the deployment of HTML 5 [[3]] most web pages download applications into user's browsers today, so the example of the Android experience might be very helpful in forming a list of user attributes to be requested in an standard user choice design. Specifically in August 2014 the number of detailed permissions permitted an application in Android was 146 [[4]] which as been aggregated into 31 [[5]] groups of permissions.

NSTIC Guiding Principles Considerations

Privacy Considerations

Privacy enhancement is the core of the purpose of this design pattern. One particularly challenging problem is the case of minors under the age of 13 that are covered by COPPA. Those challenges are left for another Design Pattern.

It is known that search terms alone are sufficient in many cases to allow identification of the user. In any service that collects attributes or behaviors of the user over time, only policy enforcement within each entity that handles user information will offer any hope of blocking discovery of the user's 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. This use case presumes the existence of a set of requirements from the RP for user attributes that it requires. Those requirements must have a common meaning within an identity ecosystem or at least within one framework by all parties to the exchange of user information.

Framework Specific Considerations

Aerospace and Defense

• The specific example is employees, contractors and vendors which are under contract to one of the recognized employers in the A&D industry complying with DoD regulations for protection of secret information.
• Currently most employers assume that their employment contract allows then to provide employee attributes to any site that the employee voluntarily visits. The assumption is likely to need to be make more explicit in the years to come.

Health Care

• Two specific examples are of interest:
  • Users of the healthcare sytem.
  • Providers of health care.