Trustmark Evolving Design Pattern

From IDESG Wiki
Revision as of 18:22, 13 December 2014 by Mary Hodder (talk | contribs) (→‎Error Conditions)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Design Pattern Metadata

Title

Trustmark Evolving Pattern shows how the trustmark can be included in web pages without breaking existing user patterns of behavior and then 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 committee review.

Expect changes before this pattern is final.

Contributor

Tom Jones

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 world wide web 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:

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. TrustmarkUX2.png

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

TK

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 consumers of health care can be accommodated with an IDESG compatible solution.

Retrieved from "https://wiki.idesg.org/index.php?title=Trustmark_Evolving_Design_Pattern&oldid=8553"