3.6 Identifiers and Cryptographic Key Management for CSPs, IdPs, and RPs

Before · SP 800-63C

After · SP 800-63C-4

Identifiers and Cryptographic Key Management for CSPs, IdPs, and RPs

Before · SP 800-63C

After · SP 800-63C-4

While a trust agreement establishes permission to federate, it does not facilitate the secure connection of parties in the federation. In order to communicate over a federation protocol, the CSP, IdP, and RP need to be able to identify each other in a secure fashion with the ability to associate identifiers with cryptographic keys and related security artifacts. In this way, an RP can ensure that an assertion is coming from the intended IdP or that an attribute bundle is coming from the intended CSP. Likewise, an IdP can ensure that it is sending an assertion to the intended RP.

The process of an RP establishing identifiers and cryptographic keys for an IdP or CSP is known as discovery . The process of an IdP establishing identifiers and cryptographic keys for the RP is known as registration . Both the discovery and registration processes can happen prior to any federation transaction or inline as part of the transaction itself. Additionally, both the discovery and registration processes can happen directly between parties or be facilitated through the use of a third-party service, as defined in the trust agreement. These processes can use a combination of manual distribution of keys and identifiers between the IdP, CSP, and RP or associate these entities with sources in which cryptographic key material and metadata can be fetched through automated processes. Different federation protocols and processes have different processes for establishing these identifiers and cryptographic keys, but the end result is that each party can properly identify others as necessary within the protocol.

The discovery and registration processes SHALL be established in a secure fashion, as defined by the trust agreement that governs the federation transaction. In many cases, the identifier is associated with a trusted source of cryptographic key material and not the key material itself. For example, a URL hosted by an IdP can serve the public signing keys for that IdP. Even if the RP is manually configured with this association, the RP can fetch the actual cryptographic key material at runtime. Protocols that require the transfer of cryptographic key information SHALL use an authenticated protected channel to exchange the cryptographic key information needed to operate the federated relationship, including any shared secrets or public keys. Any symmetric keys used in this relationship SHALL be unique to a pair of federation participants.

CSPs, IdPs (including subscriber-controlled wallets), and RPs MAY have multiple identifiers and cryptographic keys to serve different purposes within a trust agreement or different trust agreements. For example, an IdP could use one set of assertion signing keys for all FAL1 and FAL2 transactions and use a separately managed set of signing keys for FAL3 transactions that are stored in a higher security container.

When domain names, URIs, or other structured identifiers are used to identify parties, wildcards SHALL NOT be used. For example, if an RP is deployed at “www.example.com”, “service.example.com”, and “gateway.example.com”, then each of these identifiers would have to be registered for the RP. A wildcard of “*.example.com” cannot be used, as it would unintentionally allow access to “user.example.com” and “unknown.example.com” under the same RP identifier.