NIST SP 800‑63C‑4 Federation & Assertions

Document Background

SP 800‑63C is the “C” volume of the four‑part SP 800‑63 suite. While the A volume handles identity proofing (establishing who someone is) and the B volume covers authentication (verifying identity on each visit), the C volume addresses a different question: How does one system tell another system that a user has already been authenticated? (NIST, 2025a).

This question matters because modern organizations rarely operate in isolation. A university student might authenticate once with Northgate’s identity system and then access Canvas, library databases, Microsoft 365, and research computing resources without logging in again. Each of those services is a relying party that trusts an identity provider (the university’s authentication system) to vouch for the student’s identity. SP 800‑63C defines the rules for that trust relationship.

What Is Federation?

Federation is a trust arrangement in which one organization (the identity provider, or IdP) authenticates a user and then communicates the result of that authentication to another organization (the relying party, or RP). The relying party accepts the identity provider’s assertion and grants access without requiring the user to authenticate again (NIST, 2025a, Section 4).

The Key Players

Identity Provider (IdP): The system that authenticates the user and creates assertions about their identity. In a university context, this is typically the campus single sign‑on (SSO) system. In a consumer context, it might be Google, Microsoft, or Apple.

Relying Party (RP): The application or service that needs to know who the user is but delegates the actual authentication to the IdP. Canvas, Brightspace, Zoom, and thousands of SaaS applications act as relying parties.

Subscriber (the user): The individual whose identity is being asserted. The subscriber authenticates at the IdP and is then seamlessly redirected to the relying party with proof of that authentication.

Why Federate?

1. Reduced credential sprawl

   Without federation, every application needs its own username and password. Users end up managing dozens of credentials, which leads to password reuse, weak passwords, and forgotten accounts. Federation lets users authenticate once and access many services.

2. Centralized security policy

   When authentication is centralized at the IdP, security policies (MFA requirements, password standards, session timeouts) are enforced in one place. Upgrading from single‑factor to multi‑factor authentication at the IdP immediately benefits every relying party.

3. Faster deprovisioning

   When an employee leaves the organization or a student graduates, disabling their account at the IdP immediately revokes access to all federated services. Without federation, each application must be deprovisioned individually, and missed accounts become orphaned access points.

4. Better user experience

   Single sign‑on eliminates repeated login prompts. Users authenticate once per session and move between services seamlessly. This reduces friction, support tickets, and the temptation to use weak passwords for convenience.

Assertions Explained

An assertion is a digitally signed statement made by an identity provider about a subscriber. It typically contains the subscriber’s identifier, the authentication method used, the time of authentication, and optionally, attributes like name, email address, or role. The relying party receives this assertion and uses it to make access control decisions (NIST, 2025a, Section 5).

Assertion Properties

SP 800‑63C identifies several critical properties that assertions must have to be trustworthy (NIST, 2025a, Section 5.1):

Integrity: The assertion must be protected against tampering. If an attacker can modify an assertion in transit (for example, changing the user’s role from “student” to “admin”), the entire federation model breaks down. Digital signatures provide integrity protection.

Confidentiality: Assertions often contain personally identifiable information (PII). They should be encrypted in transit and, in higher‑assurance scenarios, encrypted such that only the intended relying party can decrypt them.

Audience restriction: An assertion should specify which relying party it is intended for. This prevents a malicious relying party from capturing an assertion and replaying it at a different service. If an assertion meant for Canvas is presented to a banking application, the banking application should reject it.

Freshness: Assertions include timestamps and have limited validity periods. A stale assertion (one that was issued hours or days ago) should be rejected because the subscriber’s authentication state may have changed since the assertion was issued.

Bearer vs. Holder‑of‑Key Assertions

SP 800‑63C distinguishes between two assertion binding models (NIST, 2025a, Section 5.2):

Bearer assertions can be used by anyone who possesses them, much like a movie ticket. If an attacker intercepts a bearer assertion, they can present it to the relying party and gain access. Bearer assertions are simpler to implement but rely entirely on transport‑layer security (TLS) to prevent interception.

Holder‑of‑key assertions are bound to a specific cryptographic key held by the subscriber. Even if an attacker intercepts the assertion, they cannot use it without also possessing the subscriber’s private key. This provides stronger protection but requires more complex implementation.

The Three FALs

SP 800‑63C defines three Federation Assurance Levels (FALs) that describe the strength of the federation transaction. Higher FALs require stronger protections against assertion interception, modification, and misuse (NIST, 2025a, Section 3).

The progression from FAL1 to FAL3 reflects increasing defense‑in‑depth. At FAL1, you trust the transport layer to protect the assertion. At FAL2, you add encryption so the assertion is protected even if the transport is compromised. At FAL3, you bind the assertion to the subscriber so that even a stolen, decrypted assertion is useless without the subscriber’s key.

SAML vs. OpenID Connect

SP 800‑63C is protocol‑neutral: it describes requirements that any federation protocol must meet, rather than mandating a specific technology. However, two protocols dominate the federation landscape, and understanding them at a conceptual level is essential for applying SP 800‑63C in practice (NIST, 2025a, Section 7).

SAML 2.0 (Security Assertion Markup Language)

SAML is an XML‑based standard that emerged in the early 2000s and became the backbone of enterprise SSO. In a SAML flow, the identity provider generates an XML document called a SAML assertion, digitally signs it, and delivers it to the relying party (called a “service provider” in SAML terminology) via the user’s browser. SAML is mature, widely deployed in higher education (through InCommon and eduGAIN federations) and government, and well‑understood by enterprise security teams.

OpenID Connect (OIDC)

OpenID Connect is a modern identity layer built on top of OAuth 2.0. Instead of XML, it uses JSON Web Tokens (JWTs) as assertions (called “ID tokens” in OIDC terminology). OIDC was designed for the web and mobile era: it is simpler to implement than SAML, works naturally with REST APIs and single‑page applications, and is the protocol behind every “Sign in with Google/Apple/Microsoft” button you encounter online.

Both protocols can meet the requirements of any FAL when properly implemented. SAML’s XML signatures naturally provide assertion integrity, and SAML supports encrypted assertions for FAL2. OpenID Connect achieves the same through signed and encrypted JWTs. The choice between them is typically driven by the existing infrastructure and the type of applications being integrated, not by the FAL requirements themselves.

Relationship to 63A and 63B

The three volumes of SP 800‑63 form a complete identity system. Each volume addresses a different stage, and the assurance levels from each volume combine to define the overall trust posture of the system (NIST, 2025a; NIST, 2025b; NIST, 2025c).

How the Levels Work Together

An organization selects an IAL (from 63A), an AAL (from 63B), and a FAL (from 63C) based on its risk assessment. The selected levels do not have to be the same, but they must be coherent. A system that requires IAL3 proofing and AAL3 authentication but uses FAL1 federation would have a weak link in the chain: all the rigor of identity proofing and authentication could be undermined by a poorly protected assertion.

The Trust Chain Revisited

Federation adds a critical dimension to the identity trust chain. When a relying party accepts an assertion from an identity provider, it is trusting not only that the IdP authenticated the user correctly (AAL) but also that the IdP proofed the user correctly (IAL) and that the assertion itself was transmitted securely (FAL). A compromise at any point in this chain can propagate across the entire federation.

This is why SP 800‑63C requires relying parties to establish trust agreements with identity providers, verify that the IdP meets the required IAL and AAL, and monitor for signs of compromise. Federation is not just a technical plumbing problem; it is a trust management problem that requires ongoing governance.

Citing This Document (APA 7)

SP 800‑63C‑4 follows the same APA 7 citation pattern as the other volumes in the suite. When citing multiple volumes in the same paper, use letter suffixes in the year to disambiguate (e.g., 2025a, 2025b, 2025c).

When all three volumes appear in the same reference list, assign year suffixes alphabetically by title. For example: 63A as 2025a (authentication comes after assertions alphabetically, but assign based on your reference list order). Always check your reference list to ensure each entry is uniquely identifiable.