Design Pattern: Selecting an Identity

Design Pattern Metadata

DRAFT: Sept 2016

Title

This pattern shows how a user can select an Identity Provider and identity options that meet their need for both privacy and access.

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, Registration

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)

Users face a large number of choices in selecting an identity provider (IdP). This pattern addresses the pull on the user to protect their private data while still gaining access to a class of resources available on the Internet. In order to authorize access a relying party (RP) will need to have the authenticated claims from the user to meet their criteria for the authorization.

When to use this Pattern (Context)

Any time a single user needs to register an identifier with an IdP and select either the level of assurance or the characteristics of the use of the identifier.

Relationships with other Design Patterns

This pattern is specific to selecting and registering an identifier with an IdP.

Value Proposition

Most RPs want to acquire qualified users. But users are put off by complex steps that they need to follow to be authorized to access resources on the RP web site. Following this pattern should reduce the frustration and drop-off of users seeking authorized access.

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.
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.
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. Those of particular interest to this pattern are those that require access to user personal information.
   1. Identity Provider (IdP): An entity that assigns identities and enable authentication.
   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 that the user has the claims necessary to authorize access to the desired resource.
   3. Other Third Parties that are required to get the user the claims that they need for the RP to authorize access to the desired resource.

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 access a specific class of resources controlled by a Relying Party.

1. The user establishes an account with one or more IdPs 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 RP 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 access requested by the user.
   1. If the RP is unable to grant access, it is important that the user be given actionable advice on how to rectify the situation. This criterion is not meant to imply that the user should be give information that might allow circumvention of the security of the authentication or authorization process.

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 and Failure 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 authorization to the resource they want to access.
   1. Mitigation option: The RP or third party redirects the user to one or more sources of appropriate credentials that do meet the criteria for authorization at the RP. It is important that the user receives actionable advice to overcome the authorization failure.
   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

References and Citations

FIPS Publication 200 --Minimum Security Requirements for Federal Information and Information

NIST SP 800-53 Revision 4 --Security and Privacy Controls for Federal Information Systems and Organizations [[1]]

NIST SP 800-63 Revision 3 --Digital Authentication Guideline [[2]] still a draft on Sept 1 2016

Executive Order 13681 --Improving the Security of Consumer Financial Transactions [[3]]

Relationship to NIST 800-63 Digital Authentication Guideline (Levels of Assurance)

NIST Special Publication SP 800-63 revision 3 is still in draft form when this section was composed. Previously there were four levels of assurance, Levels 1 to 4, in terms of the consequences of authentication errors and misuse of credentials. Level 1 is the lowest assurance level, and Level 4 is the highest. With revision 3 there are now (for non-federated systems) two individual components, referred to as Identity Assurance Level (IAL) and Authenticator Assurance Level (AAL). For federated systems, a third component, Federation Assurance Level (FAL), is required. A mapping from the old assurance levels to the new assurance levels is provided in the publication. It is these levels of assurance that create a challenge for any RP that uses them, especially when different levels apply to different resources on the same RP web site. As the RP tightens down security, identities that were generated by a federated IdP may be producing authentication claim tokens that do not meet the required level of authentication, especially with regard to multiple authentication factors as described below. Note that the user is a claimant before authentication and a subscriber after registration with the IdP.

IAL, AAL, and FAL summary restated in the terms used in the IDESG.

IAL 1 – only suggests self-assert attributes provided in conjunction with the authentication process.

IAL 2 – specifies the need for either remote or in-person identity proofing and requires identifying attributes to have been verified in person or remotely.

IAL 3 – requires in-person identity proofing. Identifying attributes must be verified by an authorized representative of the IdP through examination of physical documentation. This criterion is typically used by state driver's license agencies.

AAl 1 - requires single factor digital authentication, giving some assurance that the same claimant who participated in previous transactions is accessing the protected transaction or data. A wide range of available authentication technologies may be employed and requires only a single authentication factor to be used. It also permits the use of any of the authentication methods of higher authenticator assurance levels. Successful authentication requires that the claimant prove possession and control of the authenticator using a secure authentication protocol with the user agent.

AAL 2 – provides higher assurance that the same claimant who participated in previous transactions is accessing the protected transaction or data. Two different authentication factors are required. Various types of authenticators, including multi-factor Software Cryptographic Authenticators, may be used as described in SP 800-63B. AAL 2 also permits any of the authentication methods of AAL 3. This requires cryptographic protection of the primary authenticator against compromise by the protocol threats of AAL 1 plus verifier impersonation attacks.

AAL 3 – intended to provide the highest practical digital authentication assurance. Two different authentication factors are required. Authentication at AAL 3 is based on proof of possession of a key through a cryptographic protocol. This is similar to AAL 2 except that only “hard” authenticators are acceptable. The authenticator is required to be a hardware cryptographic module or multi-factor OTP device validated at FIPS 140 Level 2 or higher. Authenticator requirements can be met by using the PIV authentication private key of a FIPS 201 compliant PIV Card.

FAL 1 - allows for the subscriber to retrieve and present a claim directly to the RP. The claim must be asymmetrically signed. (This level does not require protection for privacy or replay attacks.)

FAL 2 - requires the subscriber to retrieve a claim to present to the RP, which the RP then presents to the IdP to fetch the claim in manner only accessible to the RP. The claim must be asymmetrically signed.

FAL 3 - adds the requirement that the claim be encrypted such that the RP is the only party that can decrypt it. (This encryption presumably adds privacy as well as replay protection. The lower levels (particularly level 1) do not provide privacy from snooping attacks.)

FAL 4 - requires the subscriber to present proof of possession of a cryptographic key referenced in the claim in addition to the claim itself. The claim must be asymmetrically signed and encrypted to the RP.

NSTIC Guiding Principles Considerations

User Experience Considerations

The user is very unlikely to know the technical details of the claim tokens required by the RP to authorize access to the resource. Therefore it is incumbent of the RP and any other entity involved in the authorization process to actively assist the user in acquiring the claims that they need in language that they understand.

Privacy Considerations

All of the privacy considerations contained in Design_Pattern:_Common_to_any_Internet_Identity_Ecosystem#Privacy_Considerations apply to this section. Please look at that information in addition to the pattern specific information below.

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 users with different levels of authentication which could mean different levels of access to user data.

1. Having a single site RP with multiple levels of assurance may expose information to some users that are not appropriate to their level of assurance.
2. Federation Assurance Level 1 of NIST SP 800-63 does not require privacy at the level implied in the IDESG principles and so should not be used without some additional protections.

Security Considerations

Security is one of the primary concerns for RP wet sites that wish to keep their resources private for authorized users only.

Interoperability Considerations

Where an RP web site refers a user to a third party provider of identity or attribute claims, it should be to a web page on that third party that will clearly describe the registration opens that result in claim tokens that meet the desire user access to resources.

Specific Industry Examples

One of the major concepts of the IDESG is that multiple identity ecosystems exist with their own set of requirements. This section explores some potential ecosystems that may develop their own requirements, typically as a result of regulatory reasons like those in the NIST LOA documents described above.

Multifactor Authentication (MFA)

Often presented in the two common factions of authentication, something the user knows and something the user has, this category spans many possible industries, but has common issues across all of them and so is presented separately. In the past the most common form of second factor was a smart card with a X.509 certificate. This solution offered a secure location to store the private key used in authentication and very good prevention of replay and cloning attacks. Biometrics has been offered as a solution for many years. Both of these second factors have suffered from difficult user experiences for registration as well a leaking the user's personal information. More recently alternate methods using cell phones or other user controlled devices to hold the private authentication information have gained traction. The recent adoption in the US of chip card technology from the Payment Card Industry (PCI) standard and new open authentication standards like the Fast ID Online (FIDO) Alliance specifications [[4]] have created an ecosystem where multifactor authentication is rapidly increasing. Given the desire of some RP web sites for security more of them are requiring MFA. Since the IdPs may continue to offer simple password choices along with MFA, the number of failed authentication requests at RPs using existing credentials is likely to create very poor user experiences. This will be further complicated by RP web sites that allow some user access with a limited authentication credential and then require a stronger credential to access high-value resources. The following are current thoughts on the best practices to mitigate authentication failures caused by different levels of assurance available from the same, or similar, IdPs at the user experience of signing into an RP web site at an initial sign-in, or later when high value resources are accessed by the user.

The following are specific practices for IDESG logo web sites which should help with the UX and should not be considered prescriptive.

1. require unauthenticated access to give users the requirements and rationale for requesting user private data before authentication begins.
2. present a trusted ID to users accessing the site. One example of this is a TLS (SSL) session established with an EV cert.
3. present a user one or more sign-in options with clear information about the privacy trade-off or independent attestation of each.
4. describe the user personal information (include the identifier) that will be retained after sign-out.
5. present a clear sign-out affordance near the user information/option affordance, in the upper left area of the site.
6. provide user actionable advice on how to acquire appropriate access tokens when a user sign-in fails.
   1. ensure that when failure remediation redirects to a third party that it provides user actionable advice.

Health Care

Of interest to the User Experience Committee (UXC) is the annual open enrollment process conducted by registered health insurance payer’s and government entities (covered entities) that try to accommodate all users or refer applicants to designated payers. The enrollment process varies between carriers but most all capture personally identifiable information (PII) with user’s consent with documents that support their PII. As a result of breaches, identity theft, fraud and increased financial exposure, payers are randomly identity proofing applicants so when their customer is issued an insurance card, payers have a level of confidence as to who that customer is. Concurrently, as healthcare digitally automates and becomes web-based, digital identities will become the norm In the same vein, as patients seek, on-line, copies of their medical records or want to browse a hospital or medical office site anonymously for pricing or medical complaint information, they will need a digital ID, acquired by being ‘identity proofed’ by a licensed ID provider.

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is oriented to Protected Health Information (PHI) which does not include most of what the identity industry classifies as PII. For example common user attributes like height, weight and eye color are PII but not PHI. The challenge for health care as well as identity providers is that once the data is considered PHI, the full weight of HIPAA is applicable. Specifically if an application transmits covered data to a covered provider, the application must be HIPAA compliant.

• Privacy considerations:
  • In the private healthcare sector regulatory and liability consideration will require that patients electing to protect their real world identity must be able to present a claim from a third party that is trusted by the health care data repository.
  • In the government sector a private citizen’s digital ID will also be accepted with the understanding of the following quote from NIST SP 800-63, "Since agencies should limit the collection of personal data in order to provide services and allow for strong pseudonymity, a specific [assurance level is] not explicitly required”. For example, an agency may establish a “health tracker” application. In line with the terms of Executive Order 13681 requiring “…that all agencies making personal data accessible to citizens through digital applications require the use of multiple factors of authentication and an effective identity proofing process, as appropriate.”, the agency could select LOA3 such that an AAL2 authenticator is required. However, in this example, there may be no need for the agency system to know the true identity of the user. In the past, the LOA3 assessment of data sensitivity would also require the agency to identity proof the user. This is no longer necessary and the agency is encouraged in this case to not perform any identity proofing and allow the user of the health tracker system to be pseudonymous at IAL1. The MFA authenticator at AAL2 or AAL3 will not leak any personal information because it is bound to an IAL 1 identity." The assumption implicit in this description is that the pseudonymous identifier is not used in some other context as linkage will then be possible.

• 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.
  • User Devices that collect health information like Microsoft Band or Apple Health are in a grey area. If the data is used by a covered health profession HIPAA demands that the application is HIPAA compliant. This is not the case with commonly available user devices connected to the internet today.

Aerospace and Defense (A&D)

This is an industry with a well know set of access criteria. In many cases the accountability requirements result in very specific identification of the human user of the system. In these case were federation is common among different organization, the primary concern is for privacy of user data that must be supplied by federal law.

Education

As a result of regulations on the release of personal information of minors, there are special requirements on web site that access student information. Some of the roles that users of such an ecosystem must accommodate are:

• Student
• Teachers
• School Nurse (may have to follow health care ecosystem restrictions as well as education)
• School Administration
• Parents or guardians (may have multiple sub roles depending on student's choice)
• Affinity groups like school clubs