Interfederation

[Ian Young <>]

On 15 Apr 2013, at 20:18, Tom Scavo 
<>
 wrote:

> On Mon, Apr 15, 2013 at 2:51 PM, Chris Phillips
> <>
>  wrote:
>> 
>> I don't know if inCommon would want to emulate the model of one metadata
>> file or multiple files.
> 
> We haven't worked out the details but I'd say it's highly unlikely we
> can do everything that needs to be done with a single file.

I think some kind of multiple aggregate solution will end up being the route 
most federations take in the end.  The UKf has been very careful throughout 
its history not to rule that possibility out by accident, so we're in the 
happy position of being able to go with a single production aggregate, but 
while I obviously think that's the ideal approach I accept that we're 
probably an outlier.

So for most federations, the questions will be whether to have one more 
aggregate or many, and what the additional aggregate or aggregates should 
contain.

Most federations aren't thinking in terms of multiple arrangements, feel that 
eduGAIN will serve their needs, and reach a conclusion that an additional 
"eduGAIN import" aggregate is the right route.  As I mentioned on one of the 
earlier calls, I think that's the wrong label because it leads to a model 
where if you ever need to add a second import, the expectation is that it 
will be kept separate again and you end up with members having to understand 
several different aggregates.  They also need to know which route entity 
metadata takes to get to them, even though that may change over time.

So for federations who have to go down the additional aggregate route, I'd 
always advocate trying to get as close to my ideal of a single aggregate for 
everything as possible by having a single "interfed" aggregate.  There still 
remains the question of what to put in there.

I think most federations I've looked at so far have opted for an extra 
aggregate which *only* contains the imported entities; I personally prefer 
the route the current pilot has been going down in which the additional 
aggregate contains all imported entities *as well as* the locally registered 
entities.  In other words, the additional aggregate is a superset of the 
production aggregate and people can consume it instead of the original 
production aggregate once they are ready.  Ending up with a single source of 
trusted metadata will always be better, I think.  It is easier for people to 
understand, and it fits better with a query approach to metadata 
distribution: you really don't want end entities to be querying across a 
number of endpoints.

        -- Ian

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