View source for Trustmark Evolving Design Pattern

= Design Pattern Metadata =
Draft: February 2016

==Title== 
[[Trustmark Evolving Pattern]] shows how the [[Trustmark]] can be included in web pages without breaking existing user patterns of behavior. It’s most effective when it evolves as users gain an understanding of the benefits that are offered by Identity Ecosystem Framework (IDEF) compliant web services providers.

==Status==
===Design Pattern Lifecycle Status===
{|  border="1" padding="2" width="600px"
|Contributed || Working Draft || bgcolor="SteelBlue"|'''Committee Review''' || Compilation || Approval || Publication 
|-
|colspan=6|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===
This draft is current as of February 2016. In UXC committee review and out for other committee informal review. 

Expect changes before this pattern is final.

==Contributor== 
Tom Jones <br>
Mary Hodder <br>
Edits: <br>
Ellen Nadeau <br>
Mary Hodder

= Design Pattern Content =
==Problem Description (meme)==
[https://wiki.idesg.org/wiki/index.php?title=Trustmark_Evolving_Design_Pattern#Actors Users] need to be able to make a trust decision from the information on a publicly accessible internet site with an IDESG Trustmark. The user may not have a fully formed trust opinion when first navigating to the site. 

The IDESG concepts need to be incorporated into an existing online displays to users without major disruption and then evolve in the following ways:
# Existing successful web sites may be reluctant to risk major changes that alienate users and the prominence of IDESG Trustmarks will grow as the user's understanding grows.
# The terms of use of each Trustmark will evolve as user and regulatory understanding grows.
# The identity Ecosystem itself will evolve as new Trustmarks are added to accommodate user's growing expectations.

While there may be sites that are not publicly accessible that have an IDESG Trustmark, they are outside the scope of this committee.

==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 is contributing to the development of the Identity Ecosystem, which consists 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 may 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, as long as these entities adhere to the same trust frameworks.
* 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 Trustmarks that will apply to all interactions with the user.
* Web sites may 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 may 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 choose to support one or more IDESG trust frameworks known to follow IDESG principles for the user to choose 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 is a specific internet pattern that derives from the pattern described in the [[Design Pattern: Common to any Internet Identity Ecosystem]]. 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 one possible scenario for retail sites where users are not asked to identify themselves until they are committed to the buying process.

===Actors===

The following roles are the ones most likely to be involved in the deployment of Trustmarks. 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 that defines the use of Trustmarks. The Identity Ecosystem is designed to securely support transactions that range from anonymous to fully-authenticated and from low- to high-value.

# '''User:''' An individual human being This does not include machines, algorithms, or other non-human agents or actors.
# '''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.
# '''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.
##'''Identity or Attribute Provider (IAP):'''  An entity that contains identities and of users that will be provided on demand in claims that the user can forward to a RP.
##'''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===
# 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.
# 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 a purely anonymous information site into a relying party.
# The RP gives the user a choice of which IDESG framework (with its Trustmark) or legacy provider provides identity.
## In general the identity provider will be a distinct role from the RP where a persistent identity across multiple interactions is desireable.
##The option of ephemeral connection ID may be provided at the RP's options where anonymous interactions are permitted.
# This request for information is intercepted by the user agent, or any privacy-enhancing technology intermediary—complex step where user drop-out is likely.
## Determine if the information is available based on the specific requested attributes from the RP.
## Determine if the user has already authorized release or the required identity or attribute claims to this RP.
## Display any remaining choices to the user to acquire more attributes or release those already available.
## Format the set of requested claims into a response in a way the RP can evaluate the claims.
## 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.
## Repeat these steps till the RP is satisfied or one side gives up.
# All parties should ensure that the Trustmark is explicitly included in all interchanges with every party that adhered to the Trustmark's conditions.
## 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.
# Trustmark UX should consist of:
## An icon in one of three sizes: Large (nxm pixels), Medium (nxm pixels) and Small (nxm pixles)
## 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.
[[File:TrustmarkUX2.png]]

===Trustmark Anti-Patterns===
This section describes some patterns of user experience that should be avoided when displaying 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 latter items are those that violate accepted usability experience principles. All anti-patterns in the common design pattern[https://wiki.idesg.org/wiki/index.php?title=Common_to_any_Internet_Identity_Ecosystem#Anti-patterns] 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 offers suggestions related to usability and user experience.

#	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. [[citation needed]]
# 	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, users have become inured to them, and are often used as the basis now for class action suits, which don't help users before, during or after a problem occurs. Users don't read or understand how they apply and therefore these statements fail to help users decide whom to trust. [[citation needed]]
#	An unsubstantiated or generic claim. Amorphous and high-level statements of corporate intent are not specific, and often don't mean anything to users, but are common. They have no practical value to the user, and where corporate lawyers have become involved, it sometimes is the case that they have no legal meaning either. [[citation needed]]
#	Withholding context. Display of a Trustmark without giving context for which is applies or defining its boundaries could prompt users to infer a Trustmark should be trusted for more than is correct, leading to unrealistic expectations for the value of the mark. [[citation needed]]
#	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. Trustmark language should not suffer from too much information so that it becomes useless. [[citation needed]]

===Context 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 element, 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===
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:
# As much detail about the cause of the error that would help the user understand, while not significantly impacting the user flow or security.
# 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.
# User does not have credentials that can generate claims acceptable to the relying party.
## 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.
## 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 the PET to meet those particular authorization requirements.
## Mitigation: The user is allowed to back-out of the current path to one where they can succeed.

Related requirements from IDEF v1:
•	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.” 
•	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.
•	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.”

===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 service provider that the interaction will be treated as anonymous and no user data will be collected until the user selects some action which explicitly requires 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. IDEF v1 requirement USABLE-3, plain language, states: “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 is applicable to trustmarks; users should understand the meaning of the Trustmark sufficiently well to make an informed consent decision.

When displaying trustmarks, providers should also comply with IDEF accessibility requirement USABLE-5: “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.” 

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 should 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 inquirer. 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===
One of the most difficult acceptance barriers 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 may 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.

===User and Web Site Acceptance===

Back in 2000 the FTC had the following to say.[https://www.ftc.gov/sites/default/files/documents/reports/privacy-online-fair-information-practices-electronic-marketplace-federal-trade-commission-report/privacy2000text.pdf FTC ''PRIVACY ONLINE: FAIR INFORMATION PRACTICES IN THE ELECTRONIC MARKETPLACE A REPORT TO CONGRESS'' May 2000] There is little evidence to-date that things have changed.

The 2000 Survey also examined the extent to which industry's primary self-regulatory
enforcement initiatives  online privacy seal programs  have been adopted. These programs,
which require companies to implement certain fair information practices and monitor their
compliance, promise an efficient way to implement privacy protection. However, the 2000
Survey revealed that although the number of sites enrolled in these programs has increased over
the past year, the seal programs have yet to establish a significant presence on the Web. The
Survey found that less than one-tenth, or approximately 8%, of sites in the Random Sample,
and 45% of sites in the Most Popular Group, display a privacy seal.

= NSTIC Guiding Principles Considerations =
==Privacy Considerations==
There are three sources of leaks to user private information that are considered by this pattern:
# The user agent provides more information to the RP than the user intended.
# The user interacts with the RP over an extended period allowing the RP to determine the user ID from their behavior.
# 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.
More details of the IDESG v1 privacy concerns can be viewed [https://wiki.idesg.org/wiki/index.php?title=Design_Pattern%3A_Common_to_any_Internet_Identity_Ecosystem#Privacy_Considerations here].

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, employers may assume that their employment contract allows them to provide employee attributes to any site that the employee voluntarily visits. In the coming years, this assumption might need to be more explicit.

== Health Care ==
* Two specific examples within the health care communities have Identity Ecosystem interest:
** Users of the healthcare system that is open to any person seeking healthcare. It is an open system.
** Providers of the health care system that is open only 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 should 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 should 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.

==References and Citations==
* link to Cranor study on length of time needed to read TOUs / PPs


[[Category:Authentication Design Pattern]]
[[Category:User Experience]]
[[Category:Design Pattern]]
[[Category:Consent]]
[[Category:Profile]]