NISTIR 7817

A Credential Reliability and 

Revocation Model for Federated 

Identities

Hildegard Ferraiolo

http://dx.doi.org/10.6028/NIST.IR.7817
NISTIR 7817

A Credential Reliability and 

Revocation Model for Federated 

Identities

Hildegard Ferraiolo

Computer Security Division

Information Technology Laboratory

http://dx.doi.org/10.6028/NIST.IR.7817

November 2012

U.S. Department of Commerce 

Rebecca Blank, Acting Secretary

National Institute of Standards and Technology 

Patrick D. Gallagher, Under Secretary of Commerce for Standards and Technology and Director 
i

Reports on Computer Systems Technology

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology 

(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s 

measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of 

concept implementations, and technical analyses to advance the development and productive use of 

information technology. ITL’s responsibilities include the development of management, administrative, 

technical, and physical standards and guidelines for the cost-effective security and privacy of other than 

national security-related information in Federal information systems.

Comments on this publication may be submitted to:

National Institute of Standards and Technology

Attn: Computer Security Division, Information Technology Laboratory

100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

National Institute of Standards and Technology Interagency Report 7817

22 pages (Nov. 2012)

Certain commercial entities, equipment, or materials may be identified in this document in order to 

describe an experimental procedure or concept adequately. Such identification is not intended to imply 

recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or 

equipment are necessarily the best available for the purpose. 

There may be references in this publication to other publications currently under development by NIST 

in accordance with its assigned statutory responsibilities. The information in this publication, including 

concepts and methodologies, may be used by Federal agencies even before the completion of such 

companion publications. Thus, until each publication is completed, current requirements, guidelines, 

and procedures, where they exist, remain operative. For planning and transition purposes, Federal 

agencies may wish to closely follow the development of these new publications by NIST. 

Organizations are encouraged to review all draft publications during public comment periods and 

provide feedback to NIST. All NIST publications, other than the ones noted above, are available at 

http://csrc.nist.gov/publications.
ii

Acknowledgement:

The author wishes to thank their colleagues who reviewed drafts of this document and contributed to its 

development. The author also gratefully acknowledges and appreciates contributions from the public and 

private sector for the interest and involvement in the development of this publication. The author would 

like to acknowledge the NIST Multi-Factor Authentication Program as sponsors of this work. 

Abstract

A large number of Identity Management Systems (IDMSs) are being deployed worldwide that use 

different technologies for the population of their users. With the diverse set of technologies, and the 

unique business requirements for organizations to federate, there is no uniform approach to the federation 

process. Similarly, there is no uniform method to revoke credentials or their associated attribute(s) in a 

federated community. In the absence of a uniform revocation method, this document seeks to investigate 

credential and attribute revocation with a particular focus on identifying missing requirements. This 

document first introduces and analyzes the different types of digital credentials and identifies missing 

revocation-related requirements for each model in a federated environment. As a second goal, and as a 

by-product of the analysis and recommendations, this paper suggests a credential reliability and 

revocation service that serves to address the missing requirements. 

Keywords

authentication; identity management; IDentity Management System (IDMS); information security

Disclaimer

This paper is intended for informational purposes only. Statements made are the opinions of the author 

and should not be interpreted as standards, guidelines, best practices, or recommendations for specific 

changes to any other NIST publications.
iii

Table of Contents

1. Introduction ......................................................................................................................... 1

2. Identity Provider Models and Recommendations................................................................. 2

2.1. The Two-Party Model (two legged) ..................................................................................... 2

2.1.1. Delegation .................................................................................................................. 2

2.2. The Three-Party Model (three legged)................................................................................ 3

2.2.1. Single Sign-On Schemes............................................................................................ 4

2.2.2. Privacy Enhancing Technologies................................................................................ 4

2.3. The Four-Party Model (four legged).................................................................................... 5

2.3.1. Single-Source Attribute Providers............................................................................... 5

2.3.2. Multi-Source Attribute Providers ................................................................................. 6

2.3.2.1. Attribute Aggregation .............................................................................................. 6

2.3.2.2. Service Provider as the Aggregation Agent............................................................. 6

2.3.2.3. External Aggregation Agent .................................................................................... 6

3. The Uniform Reliability and Revocation Service (URRS)..................................................... 7

3.1. URRS’s Role ...................................................................................................................... 8

3.2. The User’s Role.................................................................................................................. 9

3.3. The Service Provider’s Role................................................................................................ 9

3.4. SSO Systems ....................................................................................................................10

3.5. The Identity Provider and Attribute Provider’s Role............................................................10

3.6. Supplementary URRS Feature: Credential Media (Token) Revocations ............................10

3.7. Supplementary URRS Feature: Derived Credential Revocation.........................................11

Appendix A— Recommendations .............................................................................................13

Appendix B— Acronyms ...........................................................................................................15

Appendix C— References.........................................................................................................16
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

1

1. Introduction

Identity providers 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.

A federated community accommodates two or more identity providers along with the specific 

authentication solution. With the diverse set of identity providers and the unique business requirements 

for organizations to federate, there is no uniform approach in the federation process. Similarly, there is no 

uniform method to revoke credentials or their associated attribute(s). In the absence of a uniform method, 

this document investigates credential and attribute revocation with a particular focus on identifying 

missing requirements for revocation. As a by-product of the analysis and recommendations, this 

document also suggests a model for credential reliability and revocation services that serves to address

some of the missing requirements. 
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

2

2. Identity Provider Models and Recommendations

For the purpose of this document, the identity provider and associated authentication solutions can be 

categorized according to the number of parties involved in an authentication event. The two-party model, 

for example, involves only the service provider and the credential holder (user) in the authentication 

event. The four-party model, on the far end of the spectrum, involves the credential holder, an 

independent identity provider, the service provider, and one or more independent attribute providers that 

vouch for attributes requested by the service provider. These and other models are discussed in this 

section. Where applicable, recommendations are identified to improve credential revocation.

2.1. The Two-Party Model (two legged)

In the two-party model, the two parties in the authentication event are the user and the service provider.

The service provider also acts as the identity provider. The two-party model is the most frequently used 

scheme today. The user registers with each service provider separately, and receives a digital credential 

(usually username and password) after completing the registration process. These credentials are used for 

subsequent logins to the service providers. With a two-party model, the user is forced to remember (or 

carry) credentials for each service he/she subscribes to. The two-party model is generally not part of a 

federation, except by loose interpretation or by extension, where it is used in an enterprise’s Single SignOn (SSO) applications. 

Recommendation 1: In enterprise SSO solutions, service providers receive an assertion that 

asserts a successful prior authentication event by the enterprise’s SSO authentication server. In 

cases where the session has been tampered with by an attacker1 or in cases where the attackers 

compromised the credential (e.g., pharming or phishing attacks), a service provider or application 

may detect suspicious activities of the attacker. Based on this knowledge, the service provider 

may prevent further malicious activities with other service providers by reporting the incident to 

the enterprise’s SSO authentication server, resulting in a suspension of the credential. A reporting 

and revocation procedure, therefore, is beneficial to protecting the enterprise SSO environment in 

a two-party model.

2.1.1. Delegation

In some instances, a third-party application may provide services by accessing a user’s primary service.

For example, a third-party smartphone application may offer a message consolidation service by 

gathering and displaying email, text messages, and instant messaging in one place—its application. The 

consolidation service requires the username and password for each service it consolidates in order to 

access, retrieve, and display the messages in its consolidation application. 

By sharing a password and username (i.e., the credential and its secret) with a third-party service, the user 

gives the third-party application uncontrolled access to the user’s primary service. As much as possible, 

third-party services should not be used, as they give unlimited access to another party. In addition, should 

 1 A session could be subject to man-in-the-middle attack or session hijacking. Other attacks originating at the 

service provider may include Cross-Site Request Forgery (CSRF) or Cross-Site Scripting (XSS).
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

3

malicious activity occur that originated at the third party, the primary service is likely to revoke access 

privileges, and as a result, block the user out of the primary service.

To disable a third-party application, a user can simply change the primary service’s credential (username 

and/or password).

Recommendation 2: In federated communities, delegation technologies should be considered.

With delegation technologies, the service provider issues delegation credentials that are tailored 

for access to data and/or processes limited to third-party service, but exclude access rights to 

anything else, such as user settings and controls. With delegations, should malicious third party 

activities occur, the primary service revokes the delegated credential, while the user credential 

remains valid. At the same time, the user is protected from Denial of Service (DoS) attacks.

Delegations of a service should also be time constrained by limiting the access of a third-party

service to the time necessary to perform the delegated service.

Recommendation 3: A user or service provider in the federation should have the ability to 

terminate a delegated service through a delegation revocation procedure.

2.2. The Three-Party Model (three legged)

A three-party model involves a user, an independent identity provider, and a service provider. In general, 

the user authenticates to the identity provider. After successful authentication, the identity provider issues 

an assertion to the service provider indicating that the user has successfully authenticated to the identity 

provider. The service provider in this case outsources authentication to the identity provider and accepts 

the authentication assertion of the identity provider. 

A service provider accepts a user’s access requests to its service based on a successful authentication 

assertion from the identity provider. As is the case with the two-party model, the service provider needs to 

protect its resources from unauthorized and malicious access. It employs a variety of defense 

mechanisms2 to detect and guard against attacks such as phishing, cross-site scripting, and session 

hijacking as best as possible. 

Evidence of malicious activity at the service provider is not generally shared with the identity provider.

This situation is unfortunate, as the service provider is at the forefront of attacks. It has all audit trails and 

knowledge of suspicious or malicious account activities. A user could potentially be a victim of a 

phishing attack in which an attacker directs the user to a mock identity provider for authentication, and 

thereby learns the username and/or password. With the phished username and password, the attacker 

authenticates to the actual identity provider to acquire an assertion. The attacker subsequently tries several 

service providers to access the user’s federated services and accounts. Unaware of the attack, a service 

provider accepts the assertion and grants access. The service provider, however, may detect unusual or 

suspicious account activities and block the user. With the feedback from the affected service provider, the 

identity provider could suspend the user and prevent further attacks at other federated services. Service 

provider feedback is especially useful and indicative in the federation since the feedback is likely reported 

by several service providers in the federation, thus providing strong evidence of credential compromise. 

The user as well as the service is saved time, money, and damage because of the service provider’s 

feedback and the identity provider’s suspension actions.

 2 SP 800-63-1, Sections 9 and 10 describes specific threat mitigation techniques for authentication threats. 
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

4

Recommendation 4: In a three-party model, a reporting service for credential 

revocation/suspension is necessary in order for the service provider to provide feedback to the 

identity provider on malicious use of credentials.

2.2.1. Single Sign-On Schemes 

Service providers in the three-party model may be part of a federated SSO environment where an identity 

provider authenticates the user once on behalf of the service providers. All service providers accept the 

authentication assertions and give the user access to their services without the need for the user to reauthenticate for each service individually. The threats from assertion misuse are limited when identity 

providers issue short-term assertions for the service provider. While short-term assertions reduce benefits 

for attackers, they do not mitigate threats resulting from the user’s long-term credential that was used to 

authenticate to the identity provider. If the long-term credential has been compromised, an attacker could 

use the credential to authenticate to the identity provider and proceed undetected to exploit several service 

providers. A federated SSO environment therefore can benefit from service providers reporting suspicious 

or malicious account activities and for identity providers to suspend a credential based on the feedback.

Recommendation 5: The previously described phishing attack and other attacks against longterm user credentials is a concern in a federated SSO environment. Based on the service 

provider’s audit trail and risk mitigation techniques, the service provider may be able to prevent 

further malicious activities for other service providers by reporting incidents to the identity 

provider. A reporting service for credential revocation/suspension, therefore, is beneficial to 

protecting the federated SSO environment in a three-party model.

2.2.2. Privacy Enhancing Technologies 

Privacy enhancing models seek to minimize the exposure of user attributes and user information, thereby 

limiting attribute disclosure to service providers based on the “need-to-know” or “least privileged” 

security mantra. Privacy enhancing protocols also limit the identity provider and service provider’s ability 

to collect and link the user’s login habits. There is no transaction handle and the user can register and use 

pseudonyms with each service provider or even stay anonymous with a service provider. Most privacy 

enhancing authentication protocols are based on selective disclosure schemes where the user has more 

control to selectively present some attributes, while hiding (i.e., zero knowledge) other irrelevant 

attributes in the interaction with the service provider. Other schemes do not disclose an attribute value 

(say, date of birth) at all. Instead, these privacy enhancing technologies can dynamically calculate and 

prove a predicate/condition (above 21) for the service provider, instead of revealing the user attribute (the 

date of birth). 

Privacy enhancing protocols involve the identity provider only minimally. The identity provider signs the 

user’s attributes and issues zero-knowledge enabled credentials to the user. The user, in turn, establishes a 

login account with the service provider with a pseudonym or by establishing an anonymous login 

account. On subsequent logins, the user presents the credential with the service without further 

interaction/authentication with the identity provider. The identity provider therefore is out of the loop and 

cannot collect the user’s Internet footprint. Similarly, the service provider does not interact with the 

identity provider beyond simply verifying the identity provider’s signature on the credential. No 

transaction handle is involved. 

Recommendation 6: While privacy enhancing schemes offer enhancements to information 

disclosure, they suffer from the lack of identity provider involvement in the authentication event. 
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

5

Without the identity provider’s involvement, the status of a user’s credential cannot be 

determined by the service provider. Where the status of a credential/attribute is important to the 

federation, therefore, a service provider may benefit from a blacklist as part of a federated 

revocation mechanism. Blacklists are posted by the identity provider and constructed primarily 

based on feedback received from users or based on individuals reporting a lost, stolen, or 

compromised credential.

Recommendation 7: The blacklist mechanism is valuable, but seems to exclude service provider 

feedback. Service providers are the primary entities that have first-hand information about 

malicious account activities. With service provider feedback, malicious incidents could be 

reported by the service provider to the identity provider. As a result, the identity provider could 

suspend the credential and protect the user from further attacks. To implement this measure, a 

trusted third party (the revocation service of the federation) would have to perform the task of 

credential suspension/ revocation. 

2.3. The Four-Party Model (four legged)

In the four-party authentication model, an attribute provider is introduced in addition to the identity 

provider, service provider, and user. The need for attributes, in addition to user identification and 

authentication, stems from access control models such as Attribute-Based Access Control (ABAC) and

Role-Based Access Control (RBAC), where combinations of attributes (authorization attributes) are 

evaluated at the access decision point of the service to determine authorized access. The four-party model 

can be further sub-categorized in accordance with the source of the attributes: 1) single-source, where the 

service provider relies on a single source to provide attributes in an authentication event, and 2) multi 

source, where the service provider relies on several independent attribute providers to provide attributes 

in an authentication and authorization event. Single-source and multi-source attribute providers are 

further discussed below.

2.3.1. Single-Source Attribute Providers

The most common single-source attribute provider is the identity provider. Single-source attribute 

providers in federated communities have generally pre-agreed authorization attributes. These attributes 

are maintained by the user’s identity provider (issuer) and sent to the service provider as part of an 

authentication event to provide authorization context in the form of assertions. An example of this model 

is the Backend Attribute Exchange (BAE), an interagency attribute exchange mechanism used in addition 

to PIV cardholder authentication, where a federal agency service provider can request additional attributes 

about a PIV cardholder from other agencies (e.g., the issuer/identity provider) to enhance authentication 

and determine access control privileges. Another example is the First/Emergency Response Official 

(F/ERO) system where attributes such as knowledge, skills, and abilities of first responders are verified at 

incident control sites. The arriving first responder presents his/her First Responder Access Card (FRAC) 

at the incident site, where he or she is authenticated using the digital credentials on the FRAC. The 

attributes are pre-loaded from the F/ERO Attribute Repository in the access control station and linked to

the FRAC credentials at the authentication event, so that these attributes can be used for informed 

decision-making (for example, whether the first responder should be allowed access to a particular area 

during an emergency) .

Recommendation 8: The types of attributes accepted by the federation are usually defined by 

the service providers of the federation. Attributes can be assigned by the identity provider to its 

users as either self-asserted or verified attributes. Where attributes serve a critical part in the roles 
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

6

or the functions a user is permitted to perform, it is important for attributes to be verified and upto-date. The identity provider, therefore, should check the authoritative source(s) for attribute 

updates (e.g., changes in the attribute qualification, revocation, suspension).

2.3.2. Multi-Source Attribute Providers

There are situations where the identity provider is not the attribute provider. Other authoritative sources 

are consulted independently. These sources may include credit bureaus or background investigation

services. With multi-source attribute providers, therefore, the service provider aggregates attributes from 

several sources or receives aggregated attributes from an aggregation service to make an access decision.

The multi-source attribute provider model is less common because of the added complexity and extended 

trust model required and the lack of a standards-based approach to multi-source attribute aggregation. The 

complexity, in part, is due to the lack of a standards-based aggregation technique that correlates the 

different sources to the same user.

2.3.2.1. Attribute Aggregation

An aggregation service collects all service provider-requested attributes. The collection of attributes is 

subsequently used by the service provider to determine access privileges. Attribute aggregator services 

are discussed below.

2.3.2.2. Service Provider as the Aggregation Agent

When the service provider aggregates attributes, it accumulates the attributes from the attribute providers 

at the authentication event in order to determine access privileges to its services. Ideally, the user consents 

to the release of attributes by authenticating to each attribute provider individually and authorizing the 

release to the service provider. A mechanism to correlate and aggregate the different attribute assertions

received for a user has to exist in this model in order for the service provider to link the attribute to the 

same person. A simple method to correlate attributes is to use the same credential throughout the 

authentication event—including authentication to the identity provider as well to all attribute providers.

Recommendation 9: As a benefit of using the same credential, and taking into account service 

provider feedback mechanisms, the authentication decisions by the attribute provider and identity 

provider should be based on the same status of the credential. 

2.3.2.3. External Aggregation Agent

In this model, either the identity provider or an independent service acts as the aggregation agent by 

collecting the attributes on behalf of the service provider from various identity provider or attribute 

provider sources. The collection of attributes is subsequently provided to the service provider in a single

transaction. A federation service (e.g., URRS, Section 3) can accumulate or correlate the credentials used 

for authentication of all parties.
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

7

3. The Uniform Reliability and Revocation Service (URRS)

In federations, service providers relinquish control of maintaining their own population of user credentials 

by accepting credentials managed by a third-party identity provider. These third-party credentials are not 

issued for the sole purpose of one service; they serve other service providers within the federation as well.

To accept third-party credentials, therefore, involves some risks, even if a trust framework is established.

There are threats from other service providers, the third-party identity provider, and the users. For 

example, service providers may be vulnerable to cross-site scripting, while users may be tricked into 

phishing schemes or subject to pharming. As a result (and because these credentials are accepted by many 

service providers), attacks geared at one service and its user are a threat to all other federated services.

The Uniform Reliability and Revocation Service (URRS) strives to mitigate some of the threats identified 

in Section 2 by providing a collaborative tool for all parties of the federated community to contribute to 

and participate in the credential reliability and revocation service, including the user and the service 

provider. Involving all parties will enhance acceptance and trust in the credentials by giving the 

stakeholders with the most risk (e.g., financial loss) the ability to monitor and report credentials. 

Participation by the user and service provider will lead to closely surveyed credentials and eventually to 

more trusted credentials. Attackers, on the other hand, will have limited success in repeat misuse of a 

credential because of the monitoring, reporting, and revocation features of the URRS.

The URRS provides revocation status information to and from identity providers, service providers, 

attribute providers, and users. Revocation services include traditional revocation checks such as 

Certificate Revocation Lists (CRL) or Online Certificate Status Protocol (OCSP) checks for PKI-based 

credentials. The URRS also includes credential revocation services that incorporate some of the missing 

requirements identified in Section 2 as a federation service. Inclusion of missing requirements in an 

URRS will depend on the type of model of the federated community. For example, a federated 

community without federated privacy enhancing technology would not include recommended features in 

Section 2.2.2. 

The service provider feedback to the URRS results in a credential’s reliability score that shows decreased

reliability with each negative feedback, and that may cause the URRS to lower the credential status to 

‘suspended’ should the score reach a pre-established low score. Suspension actions can be initiated by the 

identity provider or by the user regardless of the reliability score. The reliability score also serves as a tool 

for service providers to determine the suitability of a presented credential in an authentication event. The 

service provider may decline the credential if the reliability score is low. The reliability mechanism will 

limit, as a result, attackers’ success in repeat attack of a credential.

In addition to the credential reliability and revocation service, the URRS also attempts to address 

revocation to a credential medium where the user has several credentials in one medium – e.g., smart card 

and revocation of derived credentials. 

The URRS is designed to serve a federated system with a diverse set of federated identity types. The 

entities of the URRS are depicted in Figure 1 and their roles in universal revocation are described in more 

detail in Sections 3.1 through 3.7. 
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

8

Figure 1 - Universal Reliability and Revocation Service (URRS)

The URRS in Figure 1 includes all possible entities in the federation. However, depending on the 

federation, only a few entities may be involved. For example, a federated community without federated 

privacy enhancing identities would not include the Privacy Enhancing Technology (PET) blacklist.

3.1. URRS’s Role

The URRS is the central information collection and distribution point of credential status information and 

its reliability. The role of the URRS is to:

• Maintain credential status (ACTIVE, SUSPENDED, REVOKED).

• Communicate credential status and reliability scores to service providers in order for the service 

provider to make a risk based decision to accept or decline the proposed credential for 

authentication.

• Maintain reliability score for each ACTIVE credential and 

o Lower the reliability score in cases where the pre-established reliability threshold has not 

been reached. The credential status in this case remains ACTIVE.

o Update the credential status to SUSPENDED in cases where the pre-established reliability 

threshold has been reached or as requested by the user.

o Update the credential status to REVOKED as requested by the identity provider.

Identity Provider

Credential Holder

Service Provider

request revocation

Attribute Provider

SCVP 2-Party

Credentials with

•Reliability score

•Credential status

•Attribute status

•List of accounts 

(optional)

•Media (optional)

3-Party

4-Party

PET - Black List 

SSO 

Service 

Provider

SSO 

Service 

Provider

Single Sign on System report status and score request status and score

Universal Reliability and Revocation Service
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

9

• Communicate feedback from the service provider to the identity provider and the user, including 

the resulting actions (credential status and/or reliability score update).

• Accept immediate SUSPENSION requests from the user for credentials that have not reached the 

pre-established reliability threshold.

• Accept immediate REVOCATION requests from the identity provider for credentials that have 

not reached the pre-established reliability threshold. 

The URRS automatically updates the reliability score with each feedback from the service provider.

These updates are communicated to the identity provider and the user. The URRS automatically suspends 

the credential if a feedback causes the score to fall below the reliability score threshold. The threshold 

value is established and agreed upon by the identity providers and service providers when the URRS is set

up.

3.2. The User’s Role

A user (credential holder) can benefit by monitoring his/her own credential. Monitoring services are a 

critical function for the user as his/her digital reputation is at stake. He/she can actively monitor the 

credential status and take actions to suspend the credential should the reliability score of the credential be 

unacceptable. Involving the credential holder will add an extra layer of surveillance and promote early 

detection of credential misuse, effectively mitigating further attacks as a result of early detection. 

The user’s responsibility is to:

• Monitor his/her profile of credentials through the user interface of the URRS.

• React to alerts sent by the URRS as necessary and request the URRS to suspend a credential as 

needed.

• Immediately report lost, stolen, or compromised credentials to the identity provider and URRS 

for suspension or revocation action at the URRS and identity provider. 

The user can suspend a credential at any point, even if the reliability threshold has not been reached. 

Reasons for immediate suspension may be necessary if the user’s credential has been lost. A user may 

also need to request immediate suspension upon detecting an attacker’s use of a stolen or compromised 

credential at a service provider.3 The attacker may trigger an URRS alert, enabling the user to discover 

unauthorized use of the credential. In some circumstances, suspended credentials can be reactivated. A 

lost credential, for example may be recovered by the user, but if no activity has been reported by the 

URRS for the credential during the suspension period, the credential may be reactivated at the discretion 

of the identity provider.

3.3. The Service Provider’s Role

As recommended in Section 2, service provider feedback in the two to four party models should be part of 

a revocation service. With a service provider feedback procedure, malicious use of a credential is

effectively reported to the URRS. Other service providers are prevented from using the credential because 

1) the credential has been flagged as revoked/suspended by the URRS or 2) the reliability score has been 

 3 The user may receive an unexpected out-of-band authentication request from the service or detect changes to the 

service’s user setting/activities. 
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

10

lowered to an unacceptable level. Thus, other service providers save time, money, and damage because of 

the URRS’s reliability score system and/or suspension/revocation action.

The service provider’s role is to:

• Report suspicious account activities to the URRS so that the URRS can either 

o Lower the reliability score or 

o Update the credential status to SUSPENDED or REVOKED 

• Consult the URRS at authentication events for the credential status and reliability score in order 

to make a risk based decision to accept or decline the credential for authentication and subsequent 

login 

3.4. SSO Systems

With SSO systems, an authentication server or identity provider authenticates the user on behalf of the 

service providers. The service providers accept the authentication assertion and give the user access to 

their services without the need to reauthenticate.

The service providers unified under the SSO environment should: 

• Report suspicious account activities to the URRS so that the URRS can either

o Lower the reliability score or 

o Update the long term credential status to SUSPENDED or REVOKED 

The authentication server/identity provider’s role is to:

• Consult the URRS at each authentication event and retrieve the credential status and reliability 

score in order to make a risk based decision to accept or decline the proposed credential for 

authentication and subsequent assertion provisioning for the unified service provider under the 

SSO environment. 

3.5. The Identity Provider and Attribute Provider’s Role

In order for the URRS to be effective, the identity provider and attribute provider will interface with the 

URRS to:

• Provide credential/attribute updates (revoked, suspended) to the URRS in cases where the identity 

provider received reports of lost, stolen, or compromised credentials 

• Receive reliability score updates from the URRS in order to alert the user and take revocation 

actions as needed

• Issue new credential(s) or attributes after revocation and register the new credential at the URRS

The revocation procedure for the credential is initiated by the identity provider and communicated to the 

URRS. At the same time, the identity provider will issue a new credential to the user and register the 

credential at the URRS.

3.6. Supplementary URRS Feature: Credential Media (Token) Revocations
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

11

Credential media, such as smart cards and smartphones hold a user’s credentials and associated credential 

secret. Some credential media contain several credentials for multi factor authentication used for 

graduated authentication to access IT resources. An example is a smart card that holds PKI credentials as 

well as PIN and biometric credentials of the user. The management of the medium entails updating 

credentials in the medium, possibly at different times. Updates are necessary, for example, if one 

credential has been compromised, while other credentials remain secure and valid. The management of 

the medium also becomes more complex if there are several credential issuers sharing a medium. For 

example, an enterprise may have issued smart cards to its employees containing credentials that 

authenticate employees to the enterprise’s IT system. These cards also contain credentials for the cafeteria 

payment system and credentials to authenticate and pay for fares for the local transit agency. A lost or 

stolen card, in this situation, needs to be coordinated to the three entities or systems. The URRS can 

provide revocation services for lost, stolen, or compromised mediums and their credentials as follows: 

• Lost/stolen medium: Immediate update of all credential statuses hosted by the medium to 

SUSPENDED or REVOKED state as requested by identity provider or medium holder.

• Communicate lost/stolen medium to all identity providers that issued a credential for the medium.

• Replace or update one or more credential states in cases where the credentials have been replaced 

due to credential compromise. 

3.7. Supplementary URRS Feature: Derived Credential Revocation

User mobility enables employees to stay connected with the office while away from the office desktop 

computing environment. The laptop has been the medium of mobility, but it is slowly being taken over by 

smartphones, tablets, and other smaller portable devices. With hard and soft tokens, each of the mobile 

devices may need to be provisioned with secondary credentials to enable the user’s seamless connectivity 

to the office and its resources regardless of the medium currently in use (smartphone, tablet, etc.) These 

secondary credentials are called derived credentials4 for the purpose of this document. A revocation or 

suspension of the primary credential may affect the derived credential as well.

A derived credential may be tightly coupled with the primary credential. This will enable federated 

services to map the set of access control rules/roles to the same user regardless of whether the user used 

his/her primary or derived credential in the authentication event. Derived credentials also have their own 

token/credential secrets. Therefore, a compromised primary credential should not affect the derived 

credential because it has its own secret that is different (and in a different device) than the compromised 

primary credential. However, the derived credential’s association needs to be updated to the replacement 

primary credential, once the compromised credential is replaced. Similarly, reissuance and renewal of the 

primary credential triggers the same type of association update for the derived credentials.

Termination of the primary credential, on the other hand, should lead to the derived credential’s 

termination. Unlike re-issuance and renewal, termination ends the user’s privileges to the primary 

credential and by inference leads to termination of all other derived credentials embedded in the mobility 

devices and used for the same application/services as the primary credential. 

The URRS can help maintain the derived credential’s association with the primary credential:

• Maintain association of the primary credential and derived credential for renewal and reissuance.

 4 See SP 800-63-1 for a detailed definition of a derived credential.
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

12

• Update derived credential identifier at each renewal or reissuance of the primary credential as 

indicated by the identity provider.

• Mark all derived credentials as REVOKED in case the primary credential has been terminated.
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

13

Appendix A—Recommendations

Section 2.1 The Two-Party Model – Enterprise SSO

Recommendation 1: In enterprise SSO solutions, service providers receive an assertion that 

asserts a successful prior authentication event by the enterprise’s SSO authentication server. In 

cases where the session has been tampered with by an attacker5 or in cases where the attackers 

compromised the credential (e.g., pharming or phishing attacks), a service provider or application 

may detect suspicious activities of the attacker. Based on this knowledge, the service provider 

may prevent further malicious activities with other service providers by reporting the incident to 

the enterprise’s SSO authentication server, resulting in a suspension of the credential. A reporting 

and revocation procedure, therefore, is beneficial to protecting the enterprise SSO environment in 

a two-party model.

Section 2.1.1 The Two-Party Model – Delegation

Recommendation 2: In federated communities, delegation technologies should be considered.

With delegation technologies, the service provider issues delegation credentials that are tailored 

for access to data and/or processes limited to third-party service, but exclude access rights to 

anything else, such as user settings and controls. With delegations, should malicious third party 

activities occur, the primary service revokes the delegated credential, while the user credential 

remains valid. At the same time, the user is protected from Denial of Service (DoS) attacks.

Delegations of a service should also be time constrained by limiting the access of a third-party

service to the time necessary to perform the delegated service.

Recommendation 3: A user or service provider in the federation should have the ability to 

terminate a delegated service through a delegation revocation procedure.

Section 2.2 The Three-Party Model

Recommendation 4: In a three-party model, a reporting service for credential 

revocation/suspension is necessary in order for the service provider to provide feedback to the 

identity provider on malicious use of credentials.

Recommendation 5: The previously described phishing attack and other attacks against longterm user credentials is a concern in a federated SSO environment. Based on the service 

provider’s audit trail and risk mitigation techniques, the service provider may be able to prevent 

further malicious activities for other service providers by reporting incidents to the identity 

provider. A reporting service for credential revocation/suspension, therefore, is beneficial to 

protecting the federated SSO environment in a three-party model.

Recommendation 6: While privacy enhancing schemes offer enhancements to information 

disclosure, they suffer from the lack of identity provider involvement in the authentication event. 

Without the identity provider’s involvement, the status of a user’s credential cannot be 

determined by the service provider. Where the status of a credential/attribute is important to the 

federation, therefore, a service provider may benefit from a blacklist as part of a federated 

 5 A session could be subject to man-in-the-middle attack or session hijacking. Other attacks originating at the 

service provider may include Cross-Site Request Forgery (CSRF) or Cross-Site Scripting (XSS).
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

14

revocation mechanism. Blacklists are posted by the identity provider and constructed primarily 

based on feedback received from users or based on individuals reporting a lost, stolen, or 

compromised credential.

Recommendation 7: The blacklist mechanism is valuable, but seems to exclude service provider 

feedback. Service providers are the primary entities that have first-hand information about 

malicious account activities. With service provider feedback, malicious incidents could be 

reported by the service provider to the identity provider. As a result, the identity provider could 

suspend the credential and protect the user from further attacks. To implement this measure, a 

trusted third party (the revocation service of the federation) would have to perform the task of 

credential suspension/ revocation. 

Section 2.3 The Four-Party Model

Recommendation 8: The types of attributes accepted by the federation are usually defined by 

the service providers of the federation. Attributes can be assigned by the identity provider to its 

users as either self-asserted or verified attributes. Where attributes serve a critical part in the roles 

or the functions a user is permitted to perform, it is important for attributes to be verified and upto-date. The identity provider, therefore, should check the authoritative source(s) for attribute 

updates (e.g., changes in the attribute qualification, revocation, suspension).

Recommendation 9: As a benefit of using the same credential, and taking into account service 

provider feedback mechanisms, the authentication decisions by the attribute provider and identity 

provider should be based on the same status of the credential.
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

15

Appendix B—Acronyms

ABAC Attribute Based Access Control

AP Attribute Provider

BAE Backend Attribute Exchange

CRL Certificate Revocation List

CSRF Cross-Site Request Forgery

DoS Denial of Service

F/ERO First/Emergency Response Official

FIPS Federal Information Processing Standard

FRAC First Responder Access Card

IdMS Identity Management System

ITL Information Technology Laboratory

NIST National Institute of Standards and Technology

NISTIR National Institute of Standards and Technology Interagency Report

OCSP Online Certificate Status Protocol

PET Privacy Enhancing Technology

PIV Personal Identity Verification

PKI Public Key Infrastructure

RBAC Role Based Access Control

SCVP Server-Based Certificate Validation Protocol

SP Special Publication

SSO Single Sign-On

URRS Uniform Reliability and Revocation Service

XSS Cross-Site Scripting
NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities

16

Appendix C—References

[FIPS201] Federal Information Processing Standard 201-1, Change Notice 1, Personal Identity 

Verification (PIV) of Federal Employees and Contractors, March 2006. Or as amended

(See http://csrc.nist.gov)

[SP800-63] NIST Special Publication 800-63-1, Electronic Authentication Guideline, December 2011

or as amended (See http://csrc.nist.gov)