Federation Interoperability Patterns

Typical identity federations occupy a confined space, limiting their scope to a type of business and region. The list of federation in Kantara’s Global Trust Framework Survey[1] leads to this conclusion. Yet users in some federations have a need to interoperate with services in other federations. There are some patterns to be observed that try to solve this requirement.

1. Interoperability by Actor:

1.1 IdP or AP

An Identity or Attribute Provider having a contract with multiple federations, possibly serving different rule sets. Example: CAs providing federated identity services to multiple federations connected with different bridges and differ bridge policies.

1.2 SP

A Service Provider joining multiple federations, probable accepting different technical and policy requirements. Example: Elsivier connecting to various higher education federations.

1.3 SB/Hub

A Service Broker (Hub) looks like an IdP for its connected SPs and looks like an SP for its IdPs. Thus it is a convenient point to join multiple federations. Example: The hub of SIR, connecting the Spanish higher education AAI federation with STORK.

1.4 Discovery Service, Consent Service

In theory discovery and consent services might be operated across multiple federations. 

1.5 In between Federation Operators (FO-FO)

The federation operator (representing the federation as a whole) is contracting with another federation to link up both services. E.g. The Austrian eGov-Federation with the G2B federation, or 2 cross-signed CA[2]s.

1.6 Federation of Federations

Many federations joining in a meta-federation, and likely organizing some entity to coordinate them. Example: eduGAIN.

2. Interoperability by Layer

2.1 Technical Layer

Federations interoperating (primarily) on protocol interoperability (e.g. the SAML2Int profile) with some kind of implied trust. Some NRENs claim to operate their federations like this. It would also apply to degenerate federations, like PingOne serving cloud services, or Enterprises using their IdPs for Google Apps.

2.2 Legal Layer

Federations interoperating (primarily) on a common legal basis, mutually acknowledging their operating rules. E.g. Federations joined in the 4-bridges forum.

2.3 Privacy Layer

The EU DPD and Safe Habor could be seen as a schema that allows interoperabiltiy between federations. Depending on the viewpoint the privacy layer could be seen as part of the legal layer.

3. Other Interoperability Concerns

Additional topics might be:

-       Attribute semantics (how to map the data models without centralized control)

-       Credential interoperability (mutually accepting credentials, but having separate identity binding including different policies and procedures)