NIST SP 800-63C-4 Digital Identity Guidelines: Federation and Assertions

This section is informative.

Federation is the process of authenticating a subscriber to a relying party (RP) without the RP directly verifying the subscriber’s authenticators. An identity provider (IdP) makes the subscriber account defined in [SP800-63A] available to the RP through a federation protocol. The IdP sends an assertion triggered by an authentication event of the subscriber to the RP. An assertion is a verifiable statement about the subscriber account to the RP. The RP verifies the assertion provided by the IdP, creates an authenticated session with the subscriber, and grants the subscriber access to the RP’s functions.

The IdP works in one of two modes:

The federation process allows the subscriber to obtain services from multiple RPs without the need to hold or maintain separate authenticators at each RP. This process is sometimes known as single sign-on. The federation process is also generally the preferred approach to authentication when the RP and the subscriber account are not administered together under a common security domain, as it eliminates the need for the RP to issue an additional authenticator for the subscriber to manage. Even so, federation can be still applied within a single security domain for a variety of benefits, including centralized account management and technical integration.

The federation process can be facilitated by additional parties acting in other roles, such as a federation authority to facilitate the trust agreements in place and federation proxies to facilitate the protocol connections.

This section is normative.

This section defines federation assurance levels (FALs) and the requirements for securing federation transactions at each FAL. In order to fulfill the requirements for a given FAL, the federation transaction SHALL meet or exceed all requirements listed for that FAL.

Each FAL is characterized by a set of requirements that increase the security as the FAL increases. These requirements are listed here and expanded in other sections of this document:

Audience Restriction

The assertion presented in the federation protocol targets a specific RP, and the RP can confirm that it is the intended audience of the assertion.

Replay Protection

The assertion presented in the federation protocol is protected from being presented more than once.

Assertion Injection Protection

The RP is strongly protected from an attacker completing a federated transaction and initiating an authenticated session with a forged, captured, or modified assertion (see Sec. 3.11.1).

Trust Agreement Establishment

The rights and expectations of the parties in the federation transaction are established to support trust between those parties for the purposes of creating an authenticated session for the subscriber at the RP (see Sec. 3.5).

Identifier and Key Establishment

The IdP and RP have exchanged identifiers and cryptographic key material to allow for the verification of assertions and other artifacts during future federation transactions (see Sec. 3.6).

Presentation

The assertion can be presented to the RP either on its own (as a bearer assertion) or in concert with an authenticator presented by the subscriber.

Table 1 provides a non-normative summary of requirements for each FAL. Each successive level subsumes and fulfills all of the requirements of lower levels (e.g., a federation process at FAL3 can be accepted at FAL2 or FAL1 since FAL3 satisfies all of the requirements of these lower levels). Combinations not found in Table 1 are possible, and agencies can choose to implement stronger protections in one or more areas of requirements at a given FAL.

Table 1. Federation assurance levels

While many different federation implementation options are possible, the FAL is intended to provide clear guidance that represents increasingly secure deployment options. See [SP800-63] for details on how to choose the most appropriate FAL.

This section is normative.

A federation transaction allows the subscriber to establish an authenticated session with the RP based on a subscriber account known to the IdP. The federation transaction can also provide the RP with a set of identity attributes associated with the authenticated session. The authenticated session can then be used by the RP for activities to support use cases, such as the following:

A federation transaction requires relatively complex multi-party protocols that have subtle security and privacy characteristics. When evaluating a particular federation protocol, profile, or deployment structure, it is often instructive to break it down into its component relationships and evaluate the needs for each of them:

In addition, the subscriber often interacts with the CSP, IdP, and RP through a user agent (e.g., a web browser) that is, as a result, involved in the federation process. While the actions of the subscriber described throughout these guidelines can optionally be performed through a user agent, a user agent is not necessary for all types of applications and interactions (e.g., native applications). When necessary, requirements on the user agent are called out directly.

Each party in a federation protocol bears specific responsibilities and expectations that must be fulfilled in order for the federated system to function as intended.

Federation transactions are comprised of three separate but related elements:

Trust Agreements:

The establishment of a policy decision that allows the CSP, IdP, and RP to connect for the purposes of federation. This policy is governed by a set of terms that establish the permission to connect.

Identifier and Key Establishment:

The association of cryptographic keys and identifiers for the CSP, IdP, and RP that take part in the federation transaction. This process enables the parties to identify each other securely for future exchanges.

Federation Protocol:

The verification of the subscriber’s identity by the IdP and subsequent issuance of an assertion to the RP. This results in the passing of subscriber attributes to the RP and establishing an authenticated session for the subscriber at the RP.

These elements all need to be fulfilled for a federation process to be complete. The exact order in which that happens and which parties are involved in which steps can vary depending on the deployment model, protocol choices, and other factors.

This section is normative.

A general-purpose IdP is an IdP that the CSP uses to make the subscriber account available through a process of provisioning the IdP, as described in Sec. 4.1. The subscriber provides an authentication event to the IdP using one or more authenticators that are bound to the subscriber account, as described in Sec. 4.5. Usually, a general-purpose IdP is hosted on a remote service and not on the subscriber’s device. Often, a general-purpose IdP supports multiple subscribers.

This section is normative.

A subscriber-controlled wallet is an IdP for which the CSP makes the attributes of the subscriber account available through the issuance of attribute bundles, as described in Sec. 5.1. The subscriber activates the wallet using an activation factor or authenticator, as described in Sec. 5.4. Usually, the subscriber-controlled wallet runs on a device that is controlled by the subscriber and represents only a single subscriber. However, wallets can also be hosted on remote systems in a deployment pattern that is sometimes known as a cloud wallet.

This section is informative.

Since the federated authentication process involves coordination between multiple components, including the CSP, IdP, and RP, there are additional opportunities for attackers to compromise federated identity transactions and additional ramifications for successful attacks. This section summarizes many of the attacks and mitigations that are applicable to federation.

This section is informative.

This section is informative.

To align with the standard terminology of user-centered design, customer experience, and usability, the term “user” is used throughout this section to refer to the human party. In most cases, the user in question will be the subject in the role of applicant, claimant, or subscriber, as described elsewhere in these guidelines. Customer experience sits at the nexus of usability, accessibility, and optionality. Considering user needs allows organizations to provide responsive and secure identity solutions while minimizing unnecessary friction and frustration.

This section is informative.

This section provides several example scenarios of federation used in conjunction with the requirements in these guidelines. These scenarios are for illustrative purposes and do not convey additional requirements beyond those imposed by these guidelines.

AAL

Authentication Assurance Level

ABAC

Attribute-Based Access Control

API

Application Programming Interface

CN

Common Name

CSP

Credential Service Provider

CSRF

Cross-Site Request Forgery

FAL

Federation Assurance Level

FEDRAMP

Federal Risk and Authorization Management Program

FIPS

Federal Information Processing Standards

IAL

Identity Assurance Level

IdP

Identity Provider

JWT

JSON Web Token

MAC

Message Authentication Code

OIDC

OpenID Connect

PIA

Privacy Impact Assessment

PIN

Personal Identification Number

PKI

Public-Key Infrastructure

PPI

Pairwise Pseudonymous Identifier

RP

Relying Party

SAML

Security Assertion Markup Language

SAOP

Senior Agency Official for Privacy

SCIM

System for Cross-Domain Identity Management

SORN

System of Records Notice

TLS

Transport Layer Security

XSS

Cross-Site Scripting

This section is informative.

A wide variety of terms are used in the realm of digital identity. While many definitions are consistent with earlier versions of SP 800-63, some have changed in this revision. Many of these terms lack a single, consistent definition, warranting careful attention to how the terms are defined here.

account linking

The association of multiple federated identifiers with a single RP subscriber account or the management of those associations.

account resolution

The association of an RP subscriber account with information that is already held by the RP prior to the federation transaction and outside of a trust agreement.

activation factor

An additional authentication factor that is used to enable successful authentication with a multi-factor authenticator.

allowlist

A documented list of specific elements that are allowed, per policy decision. In federation contexts, this is most commonly used to refer to the list of RPs that are allowed to connect to an IdP without subscriber intervention. This concept has historically been known as a whitelist.

approved cryptography

An encryption algorithm, hash function, random bit generator, or similar technique that is Federal Information Processing Standards (FIPS)-approved or NIST-recommended. Approved algorithms and techniques are either specified or adopted in a FIPS or NIST recommendation.

assertion

A statement from an IdP to an RP that contains information about an authentication event for a subscriber. Assertions can also contain identity attributes for the subscriber in the form of attribute values, derived attribute values, and attribute bundles.

assertion injection attack

In the context of a federated protocol, consists of an attacker attempting to force an RP to accept or process an assertion or assertion reference in order to gain access to the RP or deny a legitimate subscriber access to the RP. The attacker does this by taking an assertion or assertion reference and injecting it into a vulnerable RP.

assertion reference

A data object that is created in conjunction with an assertion and used by the RP to retrieve an assertion over an authenticated protected channel.

assertion presentation

The method by which an assertion is transmitted to the RP.

asymmetric keys

Two related cryptographic keys comprised of a public key and a private key that are used to perform complementary operations, such as encryption and decryption or signature verification and generation.

attribute

A quality or characteristic ascribed to someone or something. An identity attribute is an attribute about the identity of a subscriber (e.g., name, date of birth, address).

attribute bundle

A package of attribute values and derived attribute values from a CSP. The package has the necessary cryptographic protection to allow for the validation of the bundle independent from interaction with the CSP or IdP. Attribute bundles are often used with subscriber-controlled wallets.

attribute provider

The provider of an identity API that provides access to a subscriber’s attributes without necessarily asserting that the subscriber is present to the RP.

attribute value

A complete statement that asserts an identity attribute of a subscriber, independent of format. For example, for the attribute “birthday,” a value could be “12/1/1980” or “December 1, 1980.”

audience restriction

The restriction of a message to a specific target audience to prevent a receiver from unknowingly processing a message that is intended for another recipient. In federation protocols, assertions are audience-restricted to specific RPs to prevent an RP from accepting an assertion that was generated for a different RP.

authenticate

See authentication.

\clearpage

authenticated protected channel

An encrypted communication channel that uses approved cryptography in which the connection initiator (client) has authenticated the recipient (server). Authenticated protected channels are encrypted to provide confidentiality and protection against active intermediaries and are frequently used in the user authentication process. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [RFC9325] are examples of authenticated protected channels in which the certificate presented by the recipient is verified by the initiator. Unless otherwise specified, authenticated protected channels do not require the server to authenticate the client. Authentication of the server is often accomplished through a certificate chain that leads to a trusted root rather than individually with each server.

authenticated session

See protected session.

authentication

The process by which a claimant proves possession and control of one or more authenticators bound to a subscriber account to demonstrate that they are the subscriber associated with that account.

authentication assurance level (AAL)

A category that describes the strength of the authentication process.

authentication key

A private or symmetric key used by an authenticator to generate the authenticator output.

authenticator

Something that the subscriber possesses and controls (e.g., a cryptographic module or password) and that is used to authenticate a claimant’s identity. See authenticator type and multi-factor authenticator.

authenticator binding

The establishment of an association between a specific authenticator and a subscriber account that allows the authenticator to authenticate the subscriber associated with the account, possibly in conjunction with other authenticators.

authorize

A decision to grant access, typically automated by evaluating a subject’s attributes.

\clearpage

authorized party

In federation, the organization, person, or entity that is responsible for making decisions regarding the release of information within the federation transaction, most notably subscriber attributes. This is often the subscriber (when runtime decisions are used) or the party operating the IdP (when allowlists are used).

back-channel communication

Communication between two systems that relies on a direct connection without using redirects through an intermediary, such as a browser.

bearer assertion

An assertion that can be presented on its own as proof of the identity of the presenter.

blocklist

A documented list of specific elements that are blocked, per policy decision. This concept has historically been known as a “blacklist.”

bound authenticator

An authenticator verified by the RP in addition to an assertion at FAL3. The bound authenticator is bound to the RP subscriber account.

core attributes

The set of identity attributes that the CSP has determined and documented to be required for identity proofing and to provide services.

credential service provider (CSP)

A trusted entity whose functions include identity proofing applicants to the identity service and registering authenticators to subscriber accounts. A CSP may be an independent third party.

cross-site request forgery (CSRF)

An attack in which a subscriber who is currently authenticated to an RP and connected through a secure session browses an attacker’s website, causing the subscriber to unknowingly invoke unwanted actions at the RP. For example, if a bank website is vulnerable to a CSRF attack, it may be possible for a subscriber to unintentionally authorize a large money transfer by clicking on a malicious link in an email while a connection to the bank is open in another browser window.

cross-site scripting (XSS)

A vulnerability that allows attackers to inject malicious code into an otherwise benign website. These scripts acquire the permissions of scripts that are generated by the target website to compromise the confidentiality and integrity of data transfers between the website and clients. Websites are vulnerable if they display user-supplied data from requests or forms without sanitizing the data so that it is not executable.

cryptographic key

A value used to control cryptographic operations, such as decryption, encryption, signature generation, or signature verification. For the purposes of these guidelines, key requirements shall meet the minimum requirements stated in Table 2 of [SP800-57Part1]. See asymmetric keys or symmetric keys.

decryption key

The cryptographic key used to decrypt the encrypted payload. In asymmetric cryptography, the decryption key refers to the private key of the cryptographic key pair. In symmetric cryptography, the decryption key is the symmetric key.

derived attribute value

A statement that asserts a limited identity attribute of a subscriber without containing the attribute value from which it is derived, independent of format. For example, instead of requesting the attribute “birthday,” a derived value could be “older than 18.” Instead of requesting the attribute for “physical address,” a derived value could be “currently residing in this district.” Previous versions of these guidelines referred to this construct as an “attribute reference.”

digital identity

An attribute or set of attributes that uniquely describes a subject within a given context.

digital signature

An asymmetric key operation in which the private key is used to digitally sign data, and the public key is used to verify the signature. Digital signatures provide authenticity protection, integrity protection, and non-repudiation support but not confidentiality or replay attack protection.

disassociability

Enabling the processing of personal information or events without association to individuals or devices beyond the operational requirements of the system. [NISTIR8062]

encryption key

The cryptographic key used to encrypt a payload. In asymmetric cryptography, the encryption key refers to the public key of the cryptographic key pair. In symmetric cryptography, the encryption key is the symmetric key.

\clearpage

entropy

The amount of uncertainty that an attacker faces to determine the value of a secret. Entropy is usually stated in bits. A value with n bits of entropy has the same degree of uncertainty as a uniformly distributed n-bit random value.

Federal Information Processing Standards (FIPS)

Standards for adoption and use by federal departments and agencies that are developed by NIST, a part of the U.S. Department of Commerce. FIPS address topics in information technology to achieve common levels of quality, security, and interoperability. FIPS documents are available online on the FIPS home page: https://www.nist.gov/itl/fips.cfm.

federated identifier

The combination of a subject identifier within an assertion and an identifier for the IdP that issued that assertion. When combined, these pieces of information uniquely identify the subscriber in the context of a federation transaction.

federation

A process that allows for the conveyance of identity and authentication information across a set of networked systems.

federation assurance level (FAL)

A category that describes the process used in a federation transaction to communicate authentication events and subscriber attributes to an RP.

federation authority

A party that facilitates the establishment and management of one or more trust agreements between federated parties. The federation authority can also provide other services, such as a federation proxy, discovery and registration support, and conformance evaluation.

federation protocol

A technical protocol that is used in a federation transaction between networked systems.

federation proxy

A component that acts as a logical RP to a set of IdPs and a logical IdP to a set of RPs, bridging the two systems with a single component. These are sometimes referred to as “brokers.”

federation transaction

A specific instance of processing an authentication using a federation process for a specific subscriber by conveying an assertion from an IdP to an RP.

front-channel communication

Communication between two systems that relies on passing messages through an intermediary, such as using redirects through the subscriber’s browser.

general-purpose IdP

An IdP that is housed and executed separately from a subscriber’s device (e.g., a remote service). Often, a general-purpose IdP will be capable of representing multiple subscribers.

hash function

A function that maps a bit string of arbitrary length to a fixed-length bit string. Approved hash functions satisfy the following properties:

One-way — It is computationally infeasible to find any input that maps to any pre-specified output.

Collision-resistant — It is computationally infeasible to find any two distinct inputs that map to the same output.

identifier

A data object that is associated with a single, unique entity (e.g., individual, device, or session) within a given context and is never assigned to any other entity within that context.

identity

See digital identity.

identity API

A protected API that is accessed by an RP to retrieve the attributes of a specific subscriber.

identity assurance level (IAL)

A category that conveys the degree of confidence that the subject’s claimed identity is their real identity.

identity provider (IdP)

The party in a federation transaction that creates an assertion for the subscriber and transmits the assertion to the RP.

login

The establishment of an authenticated session between a person and a system. Also known as “sign in,” “log on,” or “sign on.”

message authentication code (MAC)

A cryptographic checksum on data that uses a symmetric key to detect both accidental and intentional modifications of the data. MACs provide authenticity and integrity protection but not non-repudiation protection.

network

An open communications medium, typically the internet, used to transport messages between the claimant and other parties. Unless otherwise stated, networks are assumed to be open and subject to active (e.g., impersonation, session hijacking) and passive (e.g., eavesdropping) attacks at any point between the parties (e.g., claimant, verifier, CSP, RP).

nonce

A value used in security protocols that is never repeated with the same key. For example, nonces used as challenges in challenge-response authentication protocols must not be repeated until authentication keys are changed. Otherwise, there is a possibility of a replay attack. Using a nonce as a challenge is a different requirement than a random challenge because a nonce is not necessarily unpredictable.

pairwise pseudonymous identifier

A pseudonymous identifier generated by an IdP for use at a specific RP.

personal information

Information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual.

predictability

Enabling reliable assumptions by individuals, owners, and operators about personal information and its processing by an information system. [NISTIR8062]

private key

A cryptographic key used with a public-key cryptographic algorithm that is uniquely associated with an entity and is not made public. In an asymmetric-key (public-key) cryptosystem, the private key has a corresponding public key. Depending on the algorithm, the private key may be used to:

Compute the corresponding public key,

Compute a digital signature that may be verified by the corresponding public key,

Decrypt keys that were encrypted by the corresponding public key, or

Compute a shared secret during a key-agreement transaction.

processing

An operation or set of operations performed on personal information that can include, but is not limited to, the collection, retention, logging, generation, transformation, use, disclosure, transfer, or disposal of personal information. [NISTIR8062]

protected session

A session in which messages between two participants are encrypted and integrity is protected using a set of shared secrets called “session keys.” A protected session is said to be authenticated if one participant proves possession of one or more authenticators in addition to the session keys and if the other party can verify the identity associated with the authenticators during the session. If both participants are authenticated, the protected session is said to be mutually authenticated.

provisioning API

A protected API that allows an RP to access identity attributes for multiple subscribers for the purposes of provisioning and managing RP subscriber accounts.

pseudonymous identifier

A meaningless but unique identifier that does not allow the RP to infer anything regarding the subscriber but that does permit the RP to associate multiple interactions with a single subscriber.

public key

A cryptographic key used with a public-key cryptographic algorithm that is uniquely associated with an entity and that may be made public. In an asymmetric-key (public-key) cryptosystem, the public key has a corresponding private key. The public key may be known by anyone and, depending on the algorithm, may be used to:

Verify a digital signature that was generated using the corresponding private key,

Encrypt keys that can be decrypted using the corresponding private key, or

Compute a shared secret during a key-agreement transaction.

public-key certificate

A digital document issued and digitally signed by the private key of a certificate authority that binds an identifier to a subscriber’s public key. The certificate indicates that the subscriber identified in the certificate has sole control of and access to the private key. See also [RFC5280].

public-key infrastructure (PKI)

A set of policies, processes, server platforms, software, and workstations used to administer certificates and public-private key pairs, including the ability to issue, maintain, and revoke public-key certificates.

reauthentication

The process of confirming the subscriber’s continued presence and intent to be authenticated during an extended usage session.

relying party (RP)

An entity that relies on a verifier’s assertion of a subscriber’s identity, typically to process a transaction or grant access to information or a system.

replay attack

An attack in which the attacker is able to replay previously captured messages between a legitimate claimant and a verifier to masquerade as that claimant to the verifier or vice versa.

risk assessment

The process of identifying, estimating, and prioritizing risks to organizational operations (i.e., mission, functions, image, reputation), organizational assets, individuals, and other organizations that result from the operation of a system. A risk assessment is part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls that are planned or in place. It is synonymous with “risk analysis.”

risk management

The program and supporting processes that manage information security risk to organizational operations (i.e., mission, functions, image, reputation), organizational assets, individuals, and other organizations and that include (i) establishing the context for risk-related activities, (ii) assessing risk, (iii) responding to risk once determined, and (iv) monitoring risk over time.

RP subscriber account

An account established and managed by the RP in a federated system based on the RP’s view of the subscriber account from the IdP. An RP subscriber account is associated with one or more federated identifiers and allows the subscriber to access the account through a federation transaction with the IdP.

security domain

A set of systems under common administrative and access control.

session

A persistent interaction between a subscriber and an endpoint, either an RP or a CSP. A session begins with an authentication event and ends with a session termination event. A session is bound by the use of a session secret that the subscriber’s software (e.g., browser, application, OS) can present to the RP to prove association of the session with the authentication event.

session hijack attack

An attack in which the attacker is able to insert themselves between a claimant and a verifier after a successful authentication exchange between the latter two parties. The attacker is able to pose as a subscriber to the verifier or vice versa to control session data exchange. Sessions between the claimant and the RP can be similarly compromised.

signing key

The cryptographic key used to create a signature. In asymmetric cryptography, the signing key refers to the private key of the cryptographic key pair. In symmetric cryptography, the signing key is the symmetric key.

single sign-on (SSO)

An authentication process by which one account and its authenticators are used to access multiple applications in a seamless manner, generally implemented with a federation protocol.

subject

A person, organization, device, hardware, network, software, or service. In these guidelines, a subject is a natural person.

subscriber

An individual enrolled in the CSP identity service.

subscriber account

An account established by the CSP for each subscriber enrolled in its identity service that contains information about the subscriber and a record of any authenticators registered to the subscriber.

subscriber-controlled wallet

A type of IdP that is issued attribute bundles by the CSP. The subscriber-controlled wallet that is either housed on a subscriber-controlled device (sometimes known as a digital wallet) or as a remote service (sometimes known as a cloud wallet).

symmetric key

A cryptographic key used to perform both the cryptographic operation and its inverse (e.g., to encrypt and decrypt or to create a message authentication code and verify the code).

technical profile

A fully conformant subset of functionality of a protocol or standard. Technical profiles are used to enhance interoperability.

Transport Layer Security (TLS)

An authentication and security protocol that is widely implemented in browsers and web servers. TLS provides confidentiality, certificate-based authentication of the receiving (server) endpoint, and certificate-based authentication of the originating (client) endpoint. TLS is specified in [RFC8446] and [SP800-52].

trust agreement

A set of conditions under which a CSP, IdP, and RP are allowed to participate in a federation transaction to establish an authentication session between the subscriber and the RP.

usability

The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use. [ISO/IEC9241-11]

verification key

The cryptographic key used to verify a signature. In asymmetric cryptography, the verification key refers to the public key of the cryptographic key pair. In symmetric cryptography, the verification key is the symmetric key.

verifier

An entity that confirms the claimant’s identity by verifying the claimant’s possession and control of one or more authenticators using an authentication protocol. To do this, the verifier needs to confirm the binding of the authenticators with the subscriber account and check that the subscriber account is active.

This appendix is informative.

This appendix provides an overview of the changes made to SP 800-63C since its initial release.