3.3 Functions

The trust agreement that defines the terms for a federated transaction (see Sec. 3.5) can be directly established and managed by the parties involved, such as an RP and IdP making a pairwise agreement to connect with each other or a subscriber making a decision to share their identity from an IdP with an RP. In other situations, the trust agreement can be managed through a dedicated party known as a federation authority. The federation authority facilitates the onboarding and management of parties that fullfil different roles and functions within a trust agreement. The federation authority’s function provides a basis for parties in the agreement to trust each other without those parties needing to make pairwise trust decisions.

For example, an RP that joins a trust agreement managed by a federation authority can decide that any IdP approved by that federation authority is suitable for its purposes. Alternatively, the RP can select a subset of the IdPs approved by the federation authority based on the RP’s specific application needs. If a particular IdP was not part of the managed trust agreement when the RP joined, the RP can benefit from the federation authority’s ongoing management by trusting the newly added IdP. Federation authorities are used in multilateral trust agreements, as discussed in Sec. 3.5.2.

The authorized party in a trust agreement is the organization, person, or entity that is responsible for the specific release decisions covered by the trust agreement, including the release of subscriber attributes. The trust agreement stipulates who the expected authorized party is and the parameters under which a request could be automatically granted, be automatically denied, or require a runtime decision from an individual. For public-facing scenarios, the authorized party is expected to be the subscriber. The subscriber’s consent to release attributes is often gathered through an explicit consent process during the federation transaction (see Sec. 4.6.1.3).

For enterprise scenarios, the authorized party is expected to be the organization. Consent to release attributes is decided by the organization on behalf of all subscribers, and this consent is represented by an allowlist (see Sec. 4.6.1.1) to enable the disclosure of identity attributes without direct decisions and involvement by the subscriber.

Examples of different authorized parties are found in Sec. 9.10.

In some architectures, the IdP and RP do not communicate directly with each other. A federation proxy acts as an intermediary between the IdP and RP for all communication in the federation protocol. The proxy functions as an RP on the upstream side and an IdP on the downstream side, as shown in Fig. 1. When communicating through a proxy, the upstream IdP and downstream RP communicate with the proxy using a standard federation protocol, and the subscriber takes part in two separate federation transactions. As a consequence, all normative requirements that apply to IdPs and RPs SHALL apply to proxies in their respective roles on each side. Additionally, a proxy can act as an upstream IdP to a downstream proxy in a chaining scenario.

Fig. 1. Federation proxy

The role of the proxy is limited to the federation protocol. It is not involved in the establishment or facilitation of a trust agreement between the upstream IdP and downstream RP. The same party can operate a federation authority and a proxy to facilitate federation transactions, but the proxy function is separate from the federation authority’s role in managing the trust agreement. Just like other members of a federation system, the proxy can be involved in separate trust agreements with each of the upstream and downstream components, or a single trust agreement can apply to all parties, such as in a multilateral agreement.

The downstream RP receives and validates the assertion generated by the proxy, as it would an assertion from any other IdP. This assertion is based on the assertion that the proxy receives from the upstream IdP. The contents of the assertion from the upstream IdP can be handled in several ways, depending on the method used by the proxy:

The federated identifier (see Sec. 3.4) of an assertion from a proxy SHALL indicate the proxy as the issuer of the assertion.

A proxied federation model can provide several benefits. Federation proxies can simplify technical integration between the RP and IdP by providing a common interface for integration, as well as providing translation between federation protocols, formats, and schemas. Additionally, to the extent that a proxy effectively blinds the RP and IdP from each other, it can provide some business confidentiality for organizations that want to guard their subscriber lists from each other. Proxies can also mitigate some of the privacy risks described in Sec. 3.10, though other risks arise from their use since an additional party is now involved in handling subscriber information. For example, if an attacker is able to compromise the proxy, the attacker need not target the IdP or RP directly in order to gain access to subscriber attributes or activity since all of that information flows through the proxy. Additionally, the proxy can perform additional profiling (i.e., aggregating information on which identity the subscriber uses at which RPs) of the subscriber beyond what the IdP and RP can do, since the proxy brokers the federation transactions between the parties and binds the subscriber account to either side of the connection.

See Sec. 7.5 for further information on blinding techniques, their uses, and their limitations.

The FAL of the connection between the proxy and the downstream RP is considered to be the lowest FAL along the entire path, and the proxy SHALL accurately represent this to the downstream RP. For example, if the connection between the upstream IdP and the proxy is FAL1 and the connection between the proxy and the downstream RP otherwise meets the requirements of FAL2, the connection between the proxy and the downstream RP is still considered FAL1. Likewise, if the connection between the upstream IdP and the proxy is FAL2 and the connection between the proxy and the downstream RP is only FAL1, the overall connection through the proxy is considered FAL1.

A subscriber-controlled wallet could potentially function as a proxy. To do so, wallet software would need to act as an RP to an external IdP, just as any other proxy, and then provide those attributes to the downstream RP.

In some systems, the proxy is referred to as a broker.

The roles in a federation transaction can be connected in a variety of ways, but several common patterns are anticipated by these guidelines. The expected trust agreement structure and connection between components will vary based on which pattern is in use.

Different roles and functions can be fulfilled by separate parties that integrate with each other. For example, a CSP can provide attributes of the subscriber account to an IdP that is not operated by the same party or organization as the CSP.

It is also possible for a single party to fulfill multiple roles within a given federation agreement. For example, if the CSP provides the IdP as part of its identity services, the CSP can provision the subscriber accounts at the IdP as part of the subscriber account establishment process. Similarly, the RP can also be in the same security and administrative domain as the IdP but still use federation technology to connect for technical, deployment, and account management benefits.

The same is true for other functions in the overall federation system, such as a federation authority and proxy. While the roles may seem similar, they are fundamentally distinct and do not need to be connected. A federation authority facilitates the establishment of a trust agreement between parties, and a proxy facilitates the connection of the federation protocol. The same entity can fulfill both the federation authority and proxy functions in the system, providing a means of establishing both trust agreements and technical connections between IdPs and RPs.