View this document as: a single page | multiple pages.

Introduction

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.

Notations

This guideline uses the following typographical conventions in text:

Cryptographic Terminology

In these guidelines, assertions, attribute bundles, and other elements of the federation protocol are verified by an asymmetric digital signature or a symmetric message authentication code (MAC). When either asymmetric or symmetric cryptography is specifically required, the terms sign and signature will be qualified as appropriate to indicate the requirement, such as symmetric signature or asymmetric signature. When either option is possible, the terms sign and signature are used without a qualifier.

For both symmetric and asymmetric signatures, the key used to create a signature is known as the signing key. With asymmetric cryptography, the signing key refers to the private key of the cryptographic key pair. Likewise, the key used to verify the signature is known as the verification key. For asymmetric cryptography, the verification key refers to the public key of the cryptographic key pair. With symmetric cryptography, the symmetric key is both the signing key and verification key.

For both symmetric and asymmetric encryption, the key used to encrypt a payload is known as the encryption key. With asymmetric cryptography, the encryption key refers to the public key of the cryptographic key pair, which is used to encapsulate a symmetric key that encrypts the payload. Likewise, the key used to decrypt the encrypted payload is known as the decryption key. With asymmetric cryptography, the decryption key refers to the private key of the cryptographic key pair. With symmetric cryptography, the symmetric key is both the encryption key and the decryption key.

Some cryptographic processes use multiple keys in combination, such as using a public-private key pair to derive a shared key for actual use. Unless otherwise specified, these guidelines focus on the initial key material that is known or transferred by the parties taking part in the federation protocol and not the cryptographic material derived from those keys.

\clearpage

Document Structure

This document is organized as follows. Each section is labeled as either normative (i.e., mandatory for compliance) or informative (i.e., not mandatory).