Skip to Content.
Sympa Menu

interfed - [inc-interfed] One use case at a time

Subject: Interfederation

List archive

[inc-interfed] One use case at a time

Chronological Thread 
  • From: John Krienke <>
  • To: <>
  • Subject: [inc-interfed] One use case at a time
  • Date: Tue, 26 Feb 2013 11:59:04 -0500
  • Authentication-results:; dkim=neutral (message not signed) header.i=none

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.

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.


  • [inc-interfed] One use case at a time, John Krienke, 02/26/2013

Archive powered by MHonArc 2.6.16.

Top of Page