Trustmark Evolving Design Pattern

Design Pattern Metadata

Title

Trustmark Evolving Pattern shows how the trustmark can be included in web pages without breaking existing user patterns of behavior. It should evolve as users gain understanding about the benefits that are offered by IDESG compliant web services.

Status

Design Pattern Lifecycle Status

Contributed	Working Draft	Committee Review	Compilation	Approval	Publication
This Design Pattern is available for review by the User Experience 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

In UXC committee review.

Expect changes before this pattern is final.

Contributor

Tom Jones
Mary Hodder

Design Pattern Content

Problem Description (meme)

Users need to be able to make a trust decision from the information on the web site of a relying party which may not yet be fully trusted. This trust decision will be honored by all parties to the interchanged data.

The IDESG concepts need to be incorporated into an existing online displays to users without major disruption and then evolve in the following ways:

1. Existing successful web site will be reluctant to risk major changes that alienate users and the prominence of IDESG Trustmarks will grow as the user's understanding grows.
2. The terms of use of each Trustmark will evolve as user and regulatory understanding grows.
3. The ID ecosystem itself will evolve as new Trustmarks are added to accommodate user's growing expectations.

When to use this Pattern (Context)

• Any time a user is asked to provide identification or personal information to gain access to a web service. This pattern specifically focuses on the interaction with a relying party (RP).
• 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 restrictions on the attributes collected from users as well as the way those attributes are handled by the entities that have access to them.
• Some web sites can determine in advance which Trustmark applies to them by the nature of their business. They will be able to display one or more Trustmark that will apply to all interactions with the user.
• Most web sites will operate with the user under different levels of trust and assurance and so will have different trust contexts during different parts of the interchange. When more than one Trustmark can apply the user needs to have the ability to select the Trustmark, and hence the context, under which the reset of the interchange will be conducted.
• The Relying Party (RP) can voluntarily determine which Trustmark policies will provide it with the information it needs to allow access to its site.
• The RP will voluntarily chose to support one or more IDESG trust frameworks known to follow IDESG principles for the user to chose from. When the IDESG process is just starting it is expected that most RPs will continue to support other identity providers. Over time it is hoped that the IDESG process will become widely accepted so that many RPs will be able to support only IDESG trust frameworks.
• 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 Common to any Internet Identity Ecosystem design pattern. Other specific design patterns that relate to this one are:

• User Registration Ceremony with an Identity or Attribute Provider using one or more IDESG Trustmarks.
• User Intent Pattern is used to acquire the user's intent to allow linking to be passed to the Relying Party.
• User Choice Pattern is used to allow the user to select which attributes are released to a relying party.

Relationships with Use Cases

The Trust Elevation Use Case describes the case where one interaction between a user and a relying party could result in the application of different Trustmarks during a single web browser connection. This is the likely scenario for most retail sites where users are not asked to identify themselves until they are committed to the buying process.

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 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 attributes claims of some sort to continue to process the user request. That web site then transitions from an purely anonymous information site into a relying party.
3. The RP gives the user a choice from which IDESG framework (with its Trustmark) or legacy 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 the user agent, or any privacy-enhancing technology intermediary. (A complex step where user drop-out is likely.)
   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 or the required identity or attribute claims 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 (including the Trustmark) 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.
5. All parties need to ensure that the Trustmark is explicitly included in all interchanges with every party that is impacted by the Trustmark condition.
   1. All parties that receive a message that includes the Trustmark are bound by the restrictions contained in the Trustmark as well as those published by the IDESG.
6. Trustmark UX will consist of:
   1. An icon in one of three sizes: Large (nxm pixels), Medium (nxm pixels) and Small (nxm pixles)
   2. A meme that can be displayed on the web page or in a mouse-over of the icon in Large (560 English characters), Medium (280) or Small (140) that may not be altered by the web site except for localization.

The following images show one way (with some options) that an IDESG Trustmark might be combined with framework Trustmarks and existing IdP service marks at an RP.

Trustmark Anti-Patterns

This section describes some patterns of user experience that should be avoided when building a Trustmark of value for the ecosystem. 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 later solutions are those that violate accepted usability experience principles. All anti-patterns in the common design pattern[1] are explicitly included by reference.

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. An icon at the bottom of a page. Past attempts to inform users as to the security or privacy of a site were able to apply to one of the third party labs for permission to use an icon that demonstrated their compliance. Users did not understand what the icon meant and when the icons were relegated to the bottom of a page, often not displaying on user devices unless the user scrolled to the bottom, they became completely useless as a user experience.
2. Annual statements of compliance. Many of us receive those multi-page privacy statements that have proliferated since the Federal Government started to “enforce” privacy. Maybe the first one was read because of its novelty, but over time, individuals have become inured to them, and are often used as the basis now for class action suits, which don't help individuals before, during or after a problem occurs. Users don't read or understand how they apply and therefore these statements fail to help individuals decide whom to trust.
3. An unsubstantiated or generic claim. Amorphous and high-level statements of corporate intent are not specific, and often don't mean anything to individuals, but are common. They have no practical value to the user, and where corporate lawyers have become involved, it is usual that they have no legal meaning either.
4. Withholding context. Display of a Trustmark without giving context for which is applies or defining its boundaries could prompt individuals to infer a Trustmark should be trusted for more is correct, leading to unrealistic expectations for the value of the mark.
5. Too much detail. Identity and personal data management policies today suffer in part from an overload of information where an individual doesn't have the time or ability to understand the ramifications of these policies when applied. Trustmark language should not suffer from too much information so that they become useless.

Environment for a Trusted Interchange

• Trust is expected to survive for the duration of the interchange, from the time that the user clicks on the trust mark, till the time that the interchange is complete and all user claims have expired. This means that every party to the interchange receives notification of the applicable Trustmark and implicitly agrees to be bound the by terms of the Trustmark.
• An interchange that has occurred under the terms of one specific Trustmark should continue to be recognized as meeting the restrictions of the IDESG and the specific Trustmark, which should be attached to the interchange in a secure manner.

Error Conditions

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: The ID ecosystem redirects the user to one or more sources of appropriate credentials that do meet the criteria for authorization at the RP.
   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 involve user acceptance or change the PET to meet those particular authorization requirements.
   3. Mitigation: The user is allowed to back-out of the current path to one where they can succeed.

Usability Considerations

Other considerations for this section of this document have been collected in the Common_to_any_Internet_Identity_Ecosystem#Usability_Considerations since they apply equally well to any design pattern for display devices attached to the internet.

It is expected that when a user first navigates to a server provider that the interaction will be treated as anonymous and no user data would be collected until the user selected some action which explicitly was acknowledged to require user information, such as clicking a logon or framework logo. The user cannot be expected to have made any trust decision just because they have landed on a web location. As an example the user should not expect that whitehouse.com was trustworthy. Note that it is only after the web site renders that the user can see if the URL is trusted (e.g. if it has a trusted EV-certificate.)

All IDESG logoed web sites are expected to participate in setting a trustworthy context. This design pattern will be combined with other design patterns, including IDESG general patterns to help design and build web sites that meet IDESG UX goals. For example each web site needs to allow users to stop, cancel or back out of decisions when they change their mind.

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 Trustmark sufficiently well to make an informed consent decision.

All providers will be assessable and localized in English, Spanish and any other language expected to be encountered by a significant number of users.

The reader is also encouraged to read the report of the IDESG experience committee on use case usability at UXC Use Case Mapping

Evolution of a Trustmark

Users must be made aware of the status of a Trustmark, especially when it has been revoked. It is important that there be a central location where all of the IDESG certified Trustmark status be available to any enquirer. It is incumbent on the Trustmark itself to publish notification of facts about its evolving status to any organization that subscribes to it and to the individuals and organizations that are members of its programs. In the event that members have reason to believe that a Trustmark is failing to live up to the representations it has made public, or that it has ceased operations, it should bring these concerns to the Trustmark itself and to the mailing list maintained by the Trustmark.

• Proposed with a proposed version number of 1.0.
• Accepted and a version number is assigned with a certificate from the IDESG.
• Revision Proposed with a proposed version number indicating if a major or minor revision.
• End of Life is indicated when a Trustmark is no longer being maintained. This can also be used to indicate that the sponsoring organization has ceased to exist, but the certification is still valid.
• Revocation indicates that a Trustmark has lost its certification.

Value Proposition

The most difficult acceptance barrier for most new design choices 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. The Trustmark evolution depends on increasing the value of the web site at every stage of the evolution. For early adoption by web sites that means that users or partners will prefer dealing with a web site that shows the Trustmark and delivers on the promise that is contained in the terms of use for that Trustmark. That implies that some organization has taken the responsibility to validate the web site before and during operation.

References and Citations

• link to Cranor study on length of time needed to read TOUs / PPs

NSTIC Guiding Principles Considerations

Privacy Considerations

There are three sources of leaks to user private information that are considered by this 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.

Other privacy considerations, such as an expressed user intent, have been separated out to other design patterns. For an example see the User Intent Pattern.

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 Trustmark selected by the user that provide the promised interoperability and protections for user private data.

Framework Specific Considerations

In this use case it is assumed that each identity framework comes with its own Trustmark that the user can understand in terms of the care given to protection of user private data.

Aerospace and Defense

• For this affinity group the user basis is limited to people or services who are well know to the enterprise that issues them with credentials. Those credentials will likely include access authorizations based on the trustworthiness of the user. It is a closed community.
• 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 within the Health Care communities have ID ecosystem interest:
  • Users of the healthcare system that are open to any person seeking healthcare. It is an open system.
  • Providers of health care that is closed to persons with credentials appropriate to the care provided. It is a closed system.

The specific interest of the User eXperience Committee is the open enrollment of any person looking for health care. This involves every range of user involvement and must be able to accommodate all comers, but may need to send the user to some other location for verification of some attribute as a part of authorizing health care. A user must have the capability to anonymously browse health care provider web sites to determine their qualifications and cost before providing private information. On the other hand the user should expect that health care information will not be released to them until they provide strong proof of identity.

No specific affinity group has been identified for health care users at this point, but there are several NSTIC pilot projects that show ways that users of health care can be accommodated with an IDESG compatible solution.