Interfederation

[John Krienke <>]

It seems to me that the difficulty of the work increases dramatically when we 
start to generalize the concepts of interfederation to take on global meaning. 
I'd like to suggest that we'll learn some important points that can be 
generalized if we stick to some very specific use cases that allow us to tease 
them out. It's been helpful for me to draw a simple picture.

I'd like to focus on the SP use case presented by LIGO, a single SP in InCommon, 
that would like to interfederate with a single IdP in the UK Federation, 
Cardiff. I know there are other needs, such as for the LIGO IdP, but it's 
helpful to be simple first. I think we'll discover a lot. We already have.

I've created a visual representation of this in a Google drawing, since it's 
easier for some (me) to think in visual terms.
https://docs.google.com/drawings/d/1yoUZGWwWRobJ5rAXQy9vVldxaC0ZUQI6eh1t9RYEeiw/edit?usp=sharing

In this use case, the UK is Federation A; the US is Federation B.

To support the LIGO use case:
- Fed A needs to put the LIGO SP into an aggregate (maybe /the/ aggregate, but 
for now, let's just say /an/ aggregate, represented by A2 in the visual matrix). 
Why? So that Cardiff can "know" and "trust" the LIGO SP. More about those two 
terms in a bit.
- Feb B needs to put the Cardiff IdP into an aggregate as well, so that LIGO can 
"know" and "trust" the Cardiff IdP.

Ian has talked about "technical trust"; Scott K about an SP being "known." The 
common notion here is that an entity needs to be visible/discoverable/known to 
the other party. This is best accomplished today by being included in a common 
metadata aggregate.

There are two other pieces to trust that some would say are a part of technical 
trust and others would say are a part of behavioral or policy-level trust. I 
would posit that these trust areas are:

1. State: The characteristics of an entity, its noun-ness and adjectives. An 
entity in metadata is bound to an organization (or it's not if you don't know 
who the submitter is (e.g., entities in EduGain)). For example, the LIGO SP can 
trust that a given IdP really is the Cardiff IdP (or not, depending on the 
practices of the metadata Registrar -- the UK Federation). Additional 
adjectives, such as Identity Assurance or category attributes about that IdP or 
SP, are expressed in its State, with various parties being authoritative for 
them (Federation, or self-expressed some day real soon now).

2. Intention: These are the behavioral guarantees, the verbs of interaction that 
are bound up in policy. For example, when an IdP sends attributes to an SP, 
there is an understanding (or silence) -- expressed in policy -- about how those 
attributes will be used downstream.

I'm sure we can come up with better names than state and intention, but if we 
can split these trust hairs cleanly, we can avoid getting wrapped around the 
axles of simultaneous or cross-linked conversations. The conversation about 
state is really about metadata Registrars (Federations). The conversation about 
Intention is about Federation policy, and the meaning (if any at all) 
represented by, for instance, the signing of a metadata aggregate. We have to 
respond to each of the issues, in turn, with an answer. So far, I'm seeing three 
main areas to address from this single but-not-so-simple use case: entity 
visibility, trust in the entity's state, and trust in the entity's intentions 
and actions.

john.