Design Pattern: Dual use user agent

From IDESG Wiki
Revision as of 03:52, 28 June 2018 by Omaerz (talk | contribs) (12 revisions imported: Initial Upload of old pages from IDESG Wiki)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Design Pattern Metadata

DRAFT: July 2016

Title

This pattern shows how a single user agent running in a user's personal device can accommodate users operating in more than one role while protecting both the interests of the user and of an enterprise that has a contractual relationship to the user.

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

Contributed.

Expect changes before this pattern is final.

Design Pattern Category

Privacy, Trust/Assurance, Interoperability

Contributor

Tom Jones

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)

There can be users with an authenticating agent running in their own personal device that need to access sites on their own behalf as well as on behalf of some organization that they contract to supply services.

When to use this Pattern (Context)

Any time a single user agent needs to be constructed to provide users with an authenticated experience that can span a range of needs from a loose, short-lived interaction to an on-going contractual relationship. Typical uses are when a user needs to access sites as an individual and as a member of an enterprise with some contractual relationship with that enterprise, for example as an employee of that enterprise. This design pattern should also work for a user agent that works with different ecosystems with different rule sets.


Relationships with other Design Patterns

This pattern is specific to access of internet sites from common user devices typically in a location that is not under the control of the site.

Actors

The following roles are present in any IDESG compliant ecosystem. 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, an online environment where individuals and organizations will be able to trust each other because they follow agreed upon standards to obtain and authenticate their digital identities—and the digital identities of devices. For this pattern the RP must be able to access sufficient attributes to determine the role that the user will fulfil. Any user that accesses the site will be able to understand the purpose of the site and its acceptance of IDESG principles while remaining anonymous.

  1. User: An individual human being This does not include machines, algorithms, or other non-human agents or actors. We will specifically categorize the users in this pattern in the following way. Note that is a matter of convenience to help understand the specifics discussed, and is should not limit the applicability of this pattern to other categories of users:
    1. Consumer An individual accessing the internet site in a casual manner that still requires some level of authentication.
    2. Employee An individual accessing the site under the conditions described in a contract, such as an employment or contractor contract.
    3. Participant An individual accessing the site under the conditions describe in various ecosystems.
  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. It will typically serve other purposes as well beyond the scope of this pattern.
    1. Browser is a web based browser that runs scripts and displays content supplied by the web site of the RP. The user experience is provided mostly by the web site.
    2. Application is a piece of code that has been added to the user device that takes full control of the user experience.
  3. 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.
    1. Identity or Attribute Provider (IAP): An entity that contains identities or attributes of users that will be provided on demand in claims that the user can forward to a RP.
    2. Relying Party (RP): An entity that needs a collection of claims to provide that service; the RP will be using the attributes from one or more provider to determine the role that the user is performing and present a UX appropriate to that role.

Solution

Description of the Solution

In this design pattern, the user may be able to access some pages on the site anonymously, but this pattern only addresses the user experience when the user wants to perform a specific role with specific privileges.

  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 attribute claims of some sort to determine what set of user experiences the user may access. That web site then transitions from providing purely anonymous access into a relying party.
  3. The RP displays a request to the user for an identity.
  4. The user selects an identity to use that will enable the role that needs to be performed.
  5. Any request from the RP for user attributes to satisfy that role is intercepted by the user agent, or any privacy-enhancing technology intermediary.
    1. The user agent has or acquires the claims necessary to meet the site expectation.
    2. Format the set of requested claims into a response in a way the RP can evaluate the claims.
    3. Send the response to the RP who has sole responsibility to determine if sufficient claims have been proved to authorize the requested role access.
  6. The RP displays the user experience appropriate to the role selected by the user and authorized by the RP.

Anti-patterns

The following are patterns that have been used in existing sites that is not in accordance with the IDESG principles.

  1. The code or web site uses bait and switch methods. This can take many form, but always involves the RP allowing the user easy access revealing little private information and then asks for increasing personal information as the user gets more involved in the web site. This anti-pattern can be avoided by telling the user up front about all of the information that will be required to be fully functional on the RP site.

Error Conditions

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 for the role that they want to use.
    1. 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.
    2. 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.
    3. Mitigation option: The user is allowed to back-out of the current path to one where they can succeed.
  2. User cannot access the role that they want.
    1. It is often the case that the RP will not ask the user what their role is, but use the identifier presented to look up their attributes and assign a role based on that set of attributes.
    2. The user at least has the possibility that the RP can change their registration to accommodate their designed role.
    3. The user can change their attributes that are linked to the identifier that they used.
    4. The user can select a different identifier to use with that RP.

Usability Considerations

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

TK

Read the report of the IDESG experience committee on use case usability at UXC Use Case Mapping

Value Proposition

This pattern allows the RP to create a single web site for all users where the role of users directs them to the appropriate user experience.

References and Citations

TK

NSTIC Guiding Principles Considerations

User Experience Considerations

Whichever role the user is granted by the web site, it is necessary that the user understand the role and what the impact that role will have on the data they see on the site and the data that they provide to the site.

Privacy Considerations

It is always the responsibility of an IDESG compliant web side to provide information only to users who are authorized to see it. In this pattern the web site supports roles that have different levels of access to user data.

  1. Having a single site RP with multiple roles may expose information to some users that are not appropriate to their role.
  2. Evaluation of a site with multiple roles will be a challenge for the following reasons:
    1. The RP/site assessment tool is designed to ask questions of the assessor that will not have a single answer.
    2. The RP could create a different assessment form for each role on the site.
  3. The site might chose to only assess for some roles, which would imply that only compliant roles would see the IDESG TrustMark.

Security Considerations

Security is more difficult on a web site that contains multiple roles. That disadvantage should be carefully weighed against the advantage of having a single site for multiple roles.

Interoperability Considerations

No special consideration was identified.

Specific Industry Examples

Health Care

  • Several specific examples within the health care communities that have different levels of access based on their role:
    • Users of the healthcare system that is open to any person seeking healthcare. It is an open system.
    • Patients that want to access personal health information.
    • Guardians of others that are authorized to handle the patient's health choices typically with specific choices of the patient documented.
    • Providers of the health care system that is open only to persons with credentials appropriate to the care provided. It is a closed system.
    • Providers that are authorized to prescribe drugs or courses of treatment for patients.

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.

Education

  • student
  • teachers
  • School Administration
  • Parents or guardians (may have multiple sub roles depending on student's choice)
  • Affinity groups like school clubs
Retrieved from "https://wiki.idesg.org/index.php?title=Design_Pattern:_Dual_use_user_agent&oldid=1653"