Authenticate Person Use Case

Use Case Metadata

Title

Authenticate Person

Status

Use Case Lifecycle Status

Contributed	Working Draft	Committee Review	Compilation	Approval	Publication
This use case has been approved in version 1.2. This page may have been updated since the 1.2 document was approved.

Use Case AHG Review Status

The Use Case AHG reviewed this use case on 2013-07-10. Comments are available on the Discussion Page.

Use Case Category

Authentication Related

Contributor

Standards Committee Use Cases Ad Hoc Group

Use Case Content

Use Case Description

A user is seeking to gain access to an online resource that requires authentication - that user becomes the Claimant actor. The online resource provides the Claimant the ability to authenticate their identity using an Identity Service Provider of the Claimant’s choice through the use of privacy enabling and standards based protocols.

Actors

• Claimant – wants to obtain access to a web resource
• Identity Service Provider – performs primary authentication of the Claimant's credentials
• Relying Party – requires a level of assurance about the identity of the Claimant
• User Agent – accepts user input from the Claimant and mediates the authentication process

Goals / User Stories

The Claimant is able to gain authenticated access to the Relying Party online resource without having to provide the Relying Party with a primary credential. The Claimant is able to perform a single authentication with an Identity Service Provider of their choice and the manner in which the Identity Service Provider is identified is an intuitive process. An example of an intuitive process (but not a requirement) would be to identify the Identity Service Provider via the Claimant's email address. If the Claimant has previously established a trusted relationship with the Identity Service Provider then a session management design should enable the authentication to take place without requiring an additional prompt for the primary credential.

Assumptions

It is assumed that the Claimant has already been identity proofed to some LOA and has already received credentials binding their identity to one or more tokens.

Requirements:

• The Claimant must be capable of selecting an Identity Service Provider of their choice (provided that the Identity Service Provider meets the LOA requirements of the Relying Party)
• The Identity Service Provider must present the Claimant with privacy protection choices that minimally include the ability to not disclose their true identity (e.g. use a pseudonym)
• The Identity Service Provider must present the Claimant with an option to not track the Relying Party

Process Flow

1. The user attempts to access a resource and the site requires an authenticated identity in order to proceed.
2. The Claimant is able to intuitively indicate to the Relying Party their preferred Identity Service Provider
3. The Relying Party directs the Claimant to their Identity Service Provider, via a User Agent, for example a web browser
4. The Identity Service Provider authenticates the Claimant. The Identity Service Provider may accomplish this authentication either via performing primary authentication of the Claimant, or via the Claimant’s possession of a bearer token showing that authentication has already taken place, e.g. via the presentation of a session or persistent cookie. Note that some Relying Parties might have differing requirements that dictate whether or not cookies (or other session tokens) may be used, and if so what lifetime is acceptable.
5. Upon successful authentication of the Claimant, the Identity Service Provider generates an Identity Token which contains the claimed identity of the Claimant and possibly other personally identifiable information. The Claimant must be able to indicate what personally identifiable information is included in the Identity Token, including the usage of real name vs. pseudonym or other personally identifiable information such as email address, street address, or birthday. The Identity Token is sent back to the Relying Party via the Claimant’s User Agent.
6. The Relying Party validates the Identity Token from the the Identity Service Provider and extracts the claimed identity and possibly other personally identifiable information. The Relying Party may optionally query a third party attribute provider for additional attributes bound to the claimed identity or may map the claimed identity to local attributes.
7. The Relying Party makes authorization decisions based on the claimed identity, attributes of the identity, or both and returns resource (as applicable) to the Claimant’s User Agent.

Success Scenario

The Relying Party returns the requested resource to the Claimant’s User Agent

Error Conditions

• Relying Party cannot validate assertion
• Identity Service Provider cannot authenticate the Claimant
• The Relying Party rejects the LOA of the Identity Token
• The Relying Party is unable to authorize the Claimant, even after validating the claimed identity
• The Claimant is not authorized to access the requested application, resource or service

Relationships

Extended by: Authenticate Using Pseudonymous Identity Use Case

References and Citations

• NIST_SP_800-63-1

NSTIC Guiding Principles Considerations

Privacy Considerations

As currently constructed, this use case adopts the NIST SP 800-63 model of identity providers rather than the separate Identity Provider/Attribute Provider described in the NSTIC strategy. Accordingly, it uses the concept of Level of Assurance (LOA) that includes both the strength of authentication and the confidence in certain identifying attributes such as name. It does not therefore support strong authentication in the absence of identifying attributes, such as the ability to assert one's age without identifying oneself in an attributable way (see NSTIC strategy, page 11). Identity proofing relates to the binding of certain attributes to the identity, and therefore is maintained by an attribute provider, and is related to attribute release, not authentication per se.

Authentication of a person can release as little as an identifier, which may or may not be persistent from one session to the next.Accordingly, the use case does not address authentication for anonymous or pseudonymous interactions, which are considered important capabilities in the NSTIC. In both cases, trustable assertions from an attribute provider might be provided following authentication, even in the absence of a persistent identifier (in the anonymous case) or attributes that are intended to allow inference of the entity associated with those attributes.