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:

(Actors in this context are organizations or persons, who can resume legal responsibility)

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

Different layers of an interoperability arrangement don't need to have the same form. So you can have a 'flat' technical layer if everyone has compatible technologies but supported by a 'bridge' style legal layer where the parties each agree with some central organisation that doesn't participate in the technical stuff. Or indeed vice-versa - for example a mesh of peer-to-peer legal agreements could invoke a separate technical architecture such as PEER!

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.

If the legal layer doesn't have to have a common legal basis that would be the easy way to do that if you were in the same jurisdiction. But when looking at links between the UK and US in one direction and other European countries on the other, JSIC found that it was possible to 'bridge' between two different legal bases so long as there was a common understanding of contract law. Then using that for a contract agreeing how to link together the necessary parts of those different legal bases. (NB watch out for local rules on whether a contract can affect third parties, and whether things other than simple bilateral contracts are valid).

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). A concept of "minimum harmonisation" is likely to be needed. Even when European higher education federations thought they had all implemented the same eduPerson standard we found [1] that there were significant differences. A few uses were 'identical' (or at least as identical as language translation); some usages were 'close enough' (e.g. be prepared to accept another country's assessment of "student"); and some were hopelessly inconsistent or even contradictory (e.g. "faculty" :( ). Rather than mapping, we settled for pointing out which attributes we thought fell into each category. With regret we had to conclude that some were simply unusable outside the federation where a particular usage had developed.

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

[1] http://www.terena.org/activities/refeds/docs/ePSAcomparison_0_13.pdf