ID Ecosystem Root

Title: The ID Ecosystem root use case is designed to encompass all use cases envisioned by the NSTIC principles
Use Case Description: Enables users to seamlessly move between relying party web sites with the greatest of ease with full control of all information release to each site.

Use Case Category: Authentication
Contributor: Tom Jones

Use Case Details

Actors:

• User - typically the digital representation of human being or group of human beings. Can also be a pseudonym controlled by a user.
• Identity Provider (IdP) - a digital process that can provide a claim verifying the continuing identity of a user together with a statement as to the level of assurance known about that user. The generic identity provider encompasses the full collection of: simple identity providers, Certificate Providers, Registration Authorities, Attribute Providers and Verifiers.
• Relying Party (RP) - typically a web site (or service) that needs to know something about that user.
• Identity Ecosystem - a set of consistent rules about the interactions between the entities that voluntary agree to them.

Goals: This use case is designed to serve as a template for all other use cases for IDESG.
Assumptions:

• The user has full control of their identity and other attributes which are only released by permission.
• All entities that chose to voluntarily participate in IDESG transactions will be able to prove their compliance with the rules of the ID Ecosystem of their choice and so display an ICON representing that compliance.
• Existing ID system will exist side by side with IDESG Ecosystem for the foreseeable future.

Requirements: A common way for the Relying Party to request claims from the user in a manner that the user can understand and respond to. Typically there will be a user agent to interpret the request to the user and package the response to the relying party.

Process Flow:

1. The user acquires an identifier and a credential from an identity provider. The identifier is typically a URI that is unique on the internet.
2. When the user navigates to an RP that requires some identity or attribute claims, the RP will send a request for to the user.
3. There will be some sort of user agent can process the request from the RP into a set of claims to return to it.
4. If the user does not have the claims locally it will contract one or more IdP's to acquire them.
5. If the user has not previously released these claims to the RP, the user will be required to authorize release of them.
6. The RP will receive the claims and determine if they satisfy its need to authorize access.
7. The RP will either grant access to the site or request additional claims from the user.

Success Scenario:

Error Conditions:

• The user cannot acquire claims sufficient to satisfy the RP.
• The user cannot supply the credentials to release the claims from the IdP.
• The RP cannot properly validate the claims supplied by the user.

Relationships

• Extended by:
• Extension of: