General IDESG Use Case

Use Case Metadata

Title

A general use case which all other use cases can depend (unless they chose not to.)

Status

Use Case Lifecycle Status

Contributed	Working Draft	Committee Review	Compilation	Approval	Publication
This use case has been sent to the IDESG Committees for their review. When committee comments are resolved and all individual use case criteria are met, this use case will be a candidate for compilation. The IDESG Standards Coordinating Committee may select this use case for including in the Compilation phase.

Use Case AHG Review Status

• Contributed *

Use Case Category

Trust, Assurance, Authentication, Interoperability, Privacy

Contributor

Tom Jones, Editor

Use Case Content

Use Case Description

Establish a user’s identity with an Identity Provider (IdP) role and a Relying Party (RP) role. This case is specifically designed to include general security, privacy and user experience criteria that will apply by default to all other user cases so that they do not need to duplicate those criteria in each new use case. Use case can specifically opt out of this general case in total or in part.

Actors

These are the base set of actors that should be found in all use cases.

• User - a human being or organization acting through a user agent that needs to access resources of service providers (RPs).
• Relying parties (RP) - a provider of services to the user.
• Identity providers (IdP) which will include attribute providers in the most general case.

Glossary

The base glossary is that produced by the Taxonomy AHG Glossary.

Beyond the actors describe above, the following definitions are used throughout the use cases for consistency and may have expanded uses in other contexts.

• Credential = any authoritative collection of information used by or about a user to prove identity or attribute claims.
• Credential Service Provider = any service that provides credentials to a user. Credentials in the digital world are susceptible to endless cloning and so need to be protected at the highest level of security and should not be transported without special security precautions.
• Claim = an assertion made by a Claimant based on its identity or attributes that is yet to be verified.
• Claimant = a user that has made a claim that has not yet been verified.

Goals / User Stories

• Provide all the restrictions on privacy that meet the evolving criteria of the IDESG.

Assumptions

• The User has a device with internet access.
• The User Agent is trusted by the user to collect claims from providers for a limited validity period and provide them to the relying party using a policy provided by the user.
• Relying Party has a list of providers and frameworks that it trusts which are displayed for the user to chose.
• Closed frameworks may limit the list of trusted providers to those that accept the terms and conditions of the framework.

Process Flow

1. User navigates to a site on the internet.
2. The site requests claims from the user.
3. The user acquires claims and transmits them to the site.
4. The site validates the claims and thereby becomes a relying party.

Success Scenario

All use cases are designed to allow the user to make claims that are verified by a relying parting in order to authorize access to a resource.

Error Conditions

1. User does not have the credentials required by the relying party. Mitigation: the relying party redirections the user to one or more sources of appropriate credentials.
2. User cannot acquire the requisite credentials. Mitigation, the user needs to find the proof needed to satisfy one of the identity providers acceptable to the relying party.

Relationships

• Extended by:
  • TK
• Extension of:
  • TK

References and Citations

• NIST Electronic Authentication Guideline with Levels of Assurance information http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf

NSTIC Guiding Principles Considerations

Privacy Considerations

• There is no reason for validation of attributes until the user decides to ask for specific resources. Anonymity is the default behavior of any IDESG logoed site until the user takes specific action that requires identity.

• Cookies containing identity information are known to create privacy problems, but they are critical to some relying parties to allow an interaction to survive for some specified period.

Security Considerations

TK

User Experience/Usability Considerations

TK.

Interoperability Considerations

To be accepted into a real-world environment use case will need to accommodate existing practices.

Domain Expert Working Group Considerations

Financial

TK

Health Care

Where the benefit requested by the user is for health care, the terms of HIPPA might begin to apply at some point in the information interchange. As described in the security section, any site that has any expectation of potential HIPPA applications should begin all interchanges as though it applied from the start even during an anonymous first stage interchange.

Derived Requirements

Most derived requirements only apply to the implementation of any use case.