Overview#

Federation Models are Trust Model under which the Federation operates.

Federation Models Manual Registration[1]#

In the manual registration model, the Identity Provider (IDP) and Relying Party manually provision configuration information about parties with which they expect to interoperate. Identity Provider (IDP)s MAY configure RPs using an explicit white-list, allowing services to transfer information as part of the authentication transaction. In such cases where an RP is not white-listed, the Identity Provider (IDP) SHALL require appropriate runtime decisions to be made by an authorized party, such as the subscriber, before releasing Digital Identity.

IDPs and RPs MAY act as their own authorities of who to federate with or MAY externalize those authority decisions to an external party as in Section 4.1.3.

Protocols requiring the transfer of keying information SHALL use a secure method to establish such keying information needed to operate the federated relationship during the registration process, including any shared secrets or Public Keys. Any Symmetric Keys used in this relationship SHALL be unique to a pair of federation participants.

Federation relationships SHALL establish parameters regarding expected and acceptable Identity Assurance Level (IAL) and Authentication Assurance Level (AAL) in connection with the federated relationship.

Dynamic Registration#

In the dynamic registration model of federation, it is possible for relationships between members of the federation to be negotiated at the time of a transaction. This process allows components to be connected together without manually establishing a connection between components. Identity Provider (IDP)s that support dynamic registration SHALL make their configuration information (such as dynamic registration endpoints) available in such a way as to minimize system administrator involvement.

Protocols requiring the transfer of keying information SHALL use a secure method to establish such keying information needed to operate the federated relationship during the registration process, including any shared secrets or public keys. Any symmetric keys used in this relationship SHALL be unique to a pair of federation participants.

Identity Provider (IDP)s SHALL require appropriate runtime decisions to be made by an authorized party, such as the subscriber, before releasing user information. An Identity Provider (IDP) accepting dynamically registered RPs MAY limit the types of attributes and other information made available to such RPs. An RP capable of dynamically registering MAY limit which Identity Provider (IDP)s it is willing to accept identity information from.

Frequently, parties in a dynamic registration model do not know each other ahead of time. Where possible, this SHOULD be augmented by software statements, which allow federated parties to cryptographically verify some attributes of the parties involved in dynamic registration. Software statements are lists of attributes describing the RP software, cryptographically signed by an authority (either the Identity Provider (IDP) itself, a federation authority as in Section 4.1.3, or another trusted party). This cryptographically verifiable statement allows the connection to be established or elevated between the federating parties without relying solely on self-asserted attributes. (See RFC 7591 Section 2.3 for more information on one protocol’s implementation of software statements.)

4.1.3. Federation Authority#

Some federated parties defer to an authority known as a federation authority or Trust Framework Provider to assist in making federation decisions and to establish the working relationship between parties. In this model, the federation authority generally conducts some level of vetting on each party in the federation to verify compliance with predetermined security and integrity standards.

Federation authorities SHALL establish parameters regarding expected and acceptable IAL and AAL in connection with the federated relationships they enable. Federation authorities SHALL individually vet each participant in the federation to determine that they adhere to their expected security, identity, and privacy standards. Vetting of Identity Provider (IDP)s and RPs SHALL establish, as a minimum, that:

Federation authorities MAY assist the technical connection and configuration process between members, such as by publishing configuration data for Identity Provider (IDP)s or issuing software statements for RPs.

Most federations managed through authorities have a simple membership model: either parties are in the federation or they are not.
However, more sophisticated federations MAY have multiple tiers of membership which can be used by federated parties to tell whether other parties in the federation have been more thoroughly vetted. Identity Provider (IDP)s MAY decide that certain subscriber information is only releasable to RPs in higher tiers, and RPs MAY decide to accept certain information only from Identity Provider (IDP)s in higher tiers. The nature and structure of such a multi-tiered system is outside the scope of this document.

4.1.4. Proxied Federation#

In a proxied Federation Models, communication between the Identity Provider (IDP) and the RP is intermediated in a way that prevents direct communication between the two parties. There are multiple methods to achieve this effect; common configurations include:
  • A third party that acts as a federation proxy (or Identity Broker)
  • A network of nodes that distributes the communications
Where proxies are used, they function as an Identity Provider (IDP) on one side and an RP on the other side. Therefore, all normative requirements that apply to Identity Provider (IDP)s and RPs SHALL apply to proxies in their respective roles.

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-4) was last changed on 20-Mar-2017 12:05 by jim