Four Party Authentication and Authorization Use Case

Use Case Metadata

Title

Four Party Authentication and Authorization

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 Category

Authentication, Access Control, Identity

Contributor

Use Case AHG

Use Case Content

Use Case Description

NIST Interagency Report 7817, titled A Credential Reliability and Revocation Model for Federated Identities, is a document that provides a model for tracking the revocation status and overall reliability of credentials by having various participants report misuse or other risk factors to a service that can track the reliability of the credential. In the course of the discussion, this document introduces a clear model of different ways for a service party or relying party to perform authentication and access control based on interactions with identity and attribute providers. The most robust example in the document is referred to as the Four Party model due to the number of actors involved in the process. It describes a case in which a Service Provider obtains information about a User sufficient to make an access control decision based on identity and attribute information gathered from the Identity Provider and Attribute Provider.

Attributes upon which access control decisions might be made may include age, location (address of residence or current geo-location), biographical information including employment current or history (e.g. military or veteran status, access granted to employees of member companies, etc.), professional skills (e.g. medical or first responder status), law enforcement status, health plan membership, organization membership.

This use case does not incorporate the credential reliability and revocation features proposed in NISTIR 7817, but we recognize that revocation is an important topic.

Actors

• Identity Provider - establish and manage their user community’s digital identities. These identities (in the form of digital credentials) are employed by users to authenticate to service providers. The digital identity technology deployed by an Identity Provider for the population of its users varies and often dictates a specific authentication solution in order for the service provider to authenticate the user.
• Attribute Provider - that vouch for attributes requested by the Relying Party. The need for attributes, in addition to user identification and authentication, stems from access control models in which combinations of attributes (authorization attributes) are evaluated at the access decision point of the service to determine authorized access. This includes two models - single-source, where the service provider relies on a single source to provide attributes in an authentication event, and multi-source, where the Relying Party uses several independent attribute providers to provide attributes in an authentication and authorization event.
• Relying Party - a Service Provider that relies on identity and attribute information to make a decision to grant access to resources. In federations, service providers relinquish control of maintaining their own population of user credentials by accepting credentials managed by a third-party identity provider.
• User - Individuals that wish to obtain access to Relying Party's resources.

Goals / User Stories

From the User’s point of view, the goal of the use case is to obtain access to Relying Party's resource. From the Relying Party's point of view, the goal is to identify the User and obtain sufficient attributes to deny or grant access. From the Identity Provider’s point of view, the goal is to issue credentials to Users and support the subsequent authentication of those credentials. From the Attribute Provider’s point of view, the goal is to provide attribute information for uniquely identified individuals.

Assumptions

• User has been identity proofed and obtained credentials from an Identity Provider that uniquely identify the user. Depending on how this is implemented, the result may be a unique identifier or a collection of attributes sufficient to identify the user (e.g. “Clark Kent from Smallville”). The users unique identifiers may be verified by an Attribute Provider. If unique identifiers or a collection of attributes are linked to a user, Relying Party may also verify unique identifiers or user attributes via Attribute Provider.

Process Flow

1. User accesses Relying Party to obtain access to resources
2. Relying Party communicates with User and Identity Provider (as necessary) to authenticate the User. This mechanism will be credential dependent.
3. Relying Party communicates with Attribute Provider to obtain attributes for the User based on the User’s identifier obtained from the authentication.
4. Relying Party makes an access control decision based on the attribute information received.

Success Scenario

• User authenticates successfully.
• Attribute Provider delivers verified attributes to the Relying Party.
• Relying Party makes an access decision based on the User’s attributes.

Error Conditions

• Attribute Provider cannot identify User based on identifier or identifying information provided by Identity Provider. RP cannot communicate with AP or vice versa. AP provides inaccurate information. User provides inaccurate information to AP. User provides inaccurate information to Identity Provider.

Relationships

• Extended by:
  • Authenticate Person is a step in this process
  • Credential Issuance is a prior step in the process
  • Identity Proofing is a prior step during Credential Issuance

• Variations: Single Source Four Party Authentication and Authorization, Multi Source Four Party Authentication and Authorization

• Extends:

References and Citations

• NISTIR 7817

NSTIC Guiding Principles Considerations

Privacy Considerations

•Tracking policy determinations across different services a concern could provide substantial information about user behavior, and could be significantly identifying.

•Depending on the variance in the types of actors, other considerations like user consent would be an issue.

•Services can also lock out users with strict policies creating incentives for disclosure. One particularly challenging problem is the case of minors under the age of 13 that are covered by COPPA.

•Attributes are potentially highly identifying, even without PII. Example: service member of specific age range, in a specific geographic area, could be enough to ID user. Will require work with RPs to ensure that collection of validated attributes is protected in order to be successful.