Common to any Internet Identity Ecosystem ARR

From IDESG Wiki
Jump to navigation Jump to search

Design Pattern Metadata

Title

This is the common pattern from which all other Internet Identity patterns should depend. It will be updated where needed to fit the needs of the dependent patterns.

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

Contributed.

Expect changes before this pattern is final.

Design Pattern Category

Privacy, Trust/Assurance, Interoperability

Contributor

Tom Jones, Annotation in Progress by Ann Racuya-Robbins

Design Pattern Content

The terms used in creating design patterns follows the taxonomy described in the UXC_Use_Case_Mapping#Categories_used_in_User_Experience_Evaluations

Problem Description (meme)

Users need to be able to understand when an IDESG set of criteria are involved and what that means to them. Dependent patterns can include all of the user experience conditions in the common pattern by reference. They do not then need to repeat any of these condition in those dependent patterns.

When to use this Pattern (Context)

  • Any time a user is asked to provide identification or personal information. In general the user will be able to assume that an interaction on an IDESG logoed web site will be anonymous until the user elects to provide personal information. (UXC has discussed that anonymity is not technically possible to date. The best we can offer to date is blinding and that needs to be defined for the user and agreed upon by the user.ARR)
  • The RP can voluntarily determine which policies will provide it with the information it needs to allow access to its site. (What is meant by policies?ARR)(Harmonized with User Requirements recorded in natural language. ARR) If the IDESG logo is on the web site the user can be assured that the web site has agreed to the broad IDESG requirements. (By broad do you mean baseline? ARR) (Because the IDESG will/may be organized around communities of interest which do not share semantics this will be aspirational for some time. May need to have an initial baseline trust mark that is harmonized across frameworks and communities of interest so that the user can understand the meaning of the mark.ARR)
  • The RP can voluntarily chose to support one or more IDESG trust frameworks known to follow IDESG principles for the user to chose from.(Again because the Trustmarks are not comparable semantically this remain aspirational see comment above.ARR This is not currently possible for the user to determine. ARR) Whenever more than one Trustmark is displayed on a web site, the user will have the opportunity to select which Trustmark will apply to the balance of the interaction until the user decides to switch to a different Trustmark.
  • It is not anticipated at this time that more than one Trustmark would ever apply at any one time in an interaction. The potential interactions of patterns is far too complex for human users to be expected to understand.(If it is too complex for human users to understand how can the user find transparency and accountability in these interactions and transactions? ARR)

The following illustration shows the primary actors and the data that they maintain. For the general case considered here, the actual service provider is not specified as it could be an identity or attribute provider, a relying party or any of a variety of other service providers that interact with the user. Connections that the service providers have beyond the user connection are not indicated as all data sent to or received from the user by way of a user agent (or browser) will pass to one provider at a time. That does not imply that multiple providers are not part of a single user interchange, but only that the interchanges deals with a single provider at a time. (There are many unresolved privacy considerations here. In addition it should be clear that if a Service Provider is made up many servers and each server wears a different identity management hat even though a server interacts with the user through the user agent one provider at time each the user may be passing between trustmarks and trustframeworks without the knowledge of the user. ARR)

File:General Design.png

Relationships with other Design Patterns

This pattern is the progenitor of all IDESG UX design patters for internet connected devices.

Actors

The following roles are present in any IDESG compliant ecosystem. Note that some of the roles may be collocated in a single Entity on the Internet.

  1. User: For any user experience internet identity pattern, the user can be assumed to be a human being who (may, under the right circumstances ARR)want to access services on a web site (and once the right circumstances are in place ARR) 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 (interaction under the right circumstances ARR) 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.(Needs more work...ARR)
  3. Service Providers The collection of all internet based services with which a user (in accordance with the user's requirement may ARR) will interact with to create and supply identity and attribute claims as (harmonized with the user's and relying parties requirements ARR) required to complete the task that they are working to complete.
    1. Relying Party (RP): A service provider that needs a collection of claims (harmonized with user requirments ARR)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 (interaction with) experience for (the ARR) RP web sites (may ARR) should improve if (an RP ARR) can automate some requests for user's attributes (such automation must be privacy enhancing, transparent and accountable to the user ARR). 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. (Nothing that involve the user's attributes is beyond the scope of user experience work. A variance from this principle needs to be explained and or justified.ARR) It is required that the relying party have secure identity to present to the user in a manner visible in the user agent, for example the RP could have an EV-certificate to prove its identity and existence in the real world.
    2. Identity or Attribute Provider (IAP): contains identities and (appropriate to user attributes aligned with user requirements ARR) of users that will be provided on demand in claims that the user can forward to a RP.
    3. Identity Ecosystem: a set of services that implement other trust services as required by the rules of that ecosystem. Note that all of the actors are almost certainly required to function with multiple identity systems; some, but not all, of these identity systems 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 desirable.
    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 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.

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

This section further refines the user experience defined in the User Experience Overview.

  • User Control and Freedom
    • 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.)
    • The user will have the ability to back out of a process at any time before it is committed.
  • Match between system and the real world
    • It is expected that when a user first navigates to a web site 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.
    • All IDESG logoed web sites are expected to participate in setting a trustworthy context. This design pattern will be combined with other design 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.
    • All providers will be localized in English, Spanish and any other language expected to be encountered by a significant number of users.
  • Consistency and Standards
    • 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 IDESG mark sufficiently well to understand the benefits from it.
  • Recognition and Recall
    • If the user has made a decision to release information to an RP, the decision may be cached, but remains always under the user's control so that it can easily be revoked.
    • TK


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 design choices is the web site of the relying party. If any part of the implementation hinders use of the web site, or exploits the user the feature will not be implemented. The meaning of a trust decision for the user's well being and capability needs to be made clear and understandable. It should be clear to the user if a trustmark or trust framework allows the monetization of the users attributes and how the revenue from that monetization is distributed and owned. It should be clear to the user if a trustmark allows the tracking of the user. ARR

References and Citations

TK

NSTIC Guiding Principles Considerations

Privacy Considerations

There are a number of sources of leaks to user private information that are considered by any ID 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.

Some privacy considerations, such as an expressed user intent, have been separated out to specific design patterns.

Other privacy consideration include identifying and locating persons, and personal information through aggregation, analysis and inference of human attributes are systemic issues applying to any identity ecosystem.

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.

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