...
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.
...
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.
...
- 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
[2] A single CA would not fit the definition of a federation, but a rather complex set CAs would do.