User Intent Pattern

Design Pattern Metadata

Title

User Intent Design Pattern is meant as a composable object that can be included in any entity. In some ways this is similar to existing use case that discuss privacy enhancing technology, but the purpose is quite different.

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.

The UX committee intends to increase the type of information the user could select.

Design Pattern Category

Privacy, Trust/Assurance, Interoperability

Contributor

Tom Jones

Design Pattern Content

Problem Description (meme)

Do Not Track. For any case where the user wishes the communications partner (either RP or provider) to honor the user's desire to avoid linking their actions on the partner site to another site, this intention needs to be known by the site.

When to use this Pattern (Context)

• Any time user information is collected by a site on the internet. That would include behavior patterns like search terms.
• The user device will have sufficient display area and input capability to allow the user to chose to set their own tracking option, or to explain why they are not provided an option by the RP.
• When the web site advertises a DO NOT TRACK policy, it is required that the user "opt into" any tracking of their attributes or behaviors.
• When the web site has a privacy policy that explicitly permits "opt out" behavior, then the user will be provided with other means to do so in the normal course of any transaction with the site.
• 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 DO NOT TRACK 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 Choice Pattern is used to allow the user to select which attributes are released to a relying party.

Relationships with Use Cases

The Device Integrity is defined in the "Device Integrity supporting User Authentication use case"

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. 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 on which system or provider to provide identity.
4. This request for information is rendered by the user agent.
   1. Where appropriate the user will be given the choice to change their DO NOT TRACK policies.
   2. Where the RP needs the ability to track the user for regulatory or security reasons, those will be made clear to the user.

Error Conditions

1. User does not have credentials acceptable to the relying party.
   1. Mitigation: The ID ecosystem / trust framework 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.
2. User is unwilling to permit DO NOT TRACK to be disabled
   1. Where possible the RP will provide the user with an option to continue to avoid tracking, perhaps with limited functionality.
   2. Where the RP cannot continue service without tracking the user, the user will be informed of the reason.

Usability Considerations

One important part of any Design Pattern is the intelligibility of the use 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 that used.

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 intent pattern will give the RP proof of compliance with DO NOT TRACK regulations as well a presumed trust mark from the IDESG or its frameworks that provides some comfort to the site user that their privacy concerns are being addressed.

References and Citations

The Do Not Track (DNT) header is nicely described in the Wikipedia at the following link [[1]].

NSTIC Guiding Principles Considerations

Privacy Considerations

Privacy enhancement is the core of the purpose of this 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 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.

Interoperability Considerations

This design pattern is oriented toward a composable object that presents a user experience that results in a set of claims adequate for the RP.

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.