Interfederation

[Ian Young <>]

On 21 Feb 2013, at 17:59, Steven Carmody 
<>
 wrote:

> One of the next questions, tho, is which IC entries do we want to include ?

The answer to this is going to depend on who we expect to consume the file, 
and what they will use it to replace (if anything).  Which is another way of 
saying that it depends on what we think you're prototyping there… although 
I'm personally pretty happy with the idea that one of the points of a 
prototype is to find out what you should really be building, not just how to 
do it.

> Stated another way, if IC made available an export file, and this mechanism 
> used the IC and UK export files as input, what would IC include in its 
> export file ?

I hadn't thought about the current activity in terms of combining the export 
aggregates of two federations; it's not clear to me who would want to consume 
such a thing other than perhaps another federation.  That is after all 
exactly what an exchange like eduGAIN looks like, and I don't think we're 
trying to build an eduGAIN competitor here.  Not this week, anyway (consider 
it your homework for next week).

Combining all of InCommon plus the UKf export aggregate might be useful for 
an InCommon member who wanted a single place to get all their metadata from.  
It's the kind of model we're attempting in the UK, where the intention is 
that our production aggregate is a combination of our registered entities 
plus imports from each of our federation partners.

Scott K is going to be able to weigh in with what LIGO entities need to 
consume, but I think I recall that they already whitelist selected entities 
from within InCommon.  They might therefore be able to make use of something 
like the system you've just built if it had a whitelisting stage after the 
merge.  That's very easy to do, by the way, and I can send you a snapshot 
with an example in it now that I've written the InCommon import for the UKf.  
Note that the way the stages work means that you can whitelist each input 
with the same bean in order to minimise the amount of data you're carrying 
around prior to the merge.

        -- Ian

Attachment: smime.p7s
Description: S/MIME cryptographic signature