3.4 Federated Identifiers

Before · SP 800-63C

After · SP 800-63C-4

Federated Identifiers

Before · SP 800-63C

After · SP 800-63C-4

The subscriber is identified in the federation transaction by information in the assertion, which allows the RP to associate the assertion with an RP subscriber account. This identification can happen through an account resolution process (see Sec. 3.8.2 ) or through a federated identifier .

For general purpose IdPs, a federated identifier is the logical combination of a subject identifier that represents a subscriber account and an issuer identifier that represents the IdP. The subject identifier is assigned by the IdP, and the issuer identifier is usually assigned to the IdP through configuration.

For subscriber-controlled wallets, a federated identifier is the logical combination of a subscriber identifier that represents the subscriber account and an issuer identifier that represents the CSP that issued the attribute bundle. The subject identifier is assigned by the CSP, and the issuer identifier is usually assigned to the CSP through configuration. However, these will not always be available, for example in the case of mobile driver’s licenses where the account resolution is typically done through the use of the driver’s license number and the issuer of the driver’s license. Such a pattern is addressed in Sec. 3.8.2 .

The multi-part federated identifier pattern is required because different IdPs manage their subject identifiers independently, and could, therefore, potentially collide in their choices of subject identifiers for different subjects. Therefore, it is imperative that an RP never process the subject identifier without accounting for the IdP that issued the subject identifier. For most use cases, the federated identifier is stable for the subscriber across multiple sessions and independent of the authenticator used, allowing the RP to reliably identify the subscriber across multiple authenticated sessions and account changes. However, it is also possible for the federated identifier and its associated use at the RP to be ephemeral to provide some privacy enhancement. Federated identifiers and their constituent parts are intended to be machine-readable and not managed by or exposed to the subscriber, unlike a username or other human-facing identifier.

When federated identifiers are used, the federated identifier SHALL be unique to that subscriber. Federated identifiers SHALL be associated with a single subscriber at the RP.

It is recommended that federated identifiers contain no plaintext personal information, such as usernames, email addresses, employee numbers. This restriction is a requirement at FAL2 and above. When a federation process uses account resolution (see Sec. 3.8.2 ), the RP subscriber account can be resolved by the RP without the use of a federated identifier. Federated identifiers are a logical concept and will typically not be an explicit value distinct from the subject identifier and issuer identifier. Instead, federated identifiers comprise the information needed to ensure that a subscriber is uniquely distinguished and there are no collisions between subject identifiers provided by different IdPs.