Interfederation

[Ian Young <>]

On 25 Feb 2013, at 14:10, Tom Scavo 
<>
 wrote:

> Every InCommon entity that wants to interfederate needs a custom
> aggregate (in effect).

That sounds like a challenging approach from a scaleability point of view.  I 
know of no other federation approaching interfederation in that way.

From the later points in your message, it seems as if you want to go down 
this road because you don't want to be responsible for choosing the entities 
that are available to your members, but instead want them to do that 
individually.  I don't think that's necessary as long as you're clear about 
the difference between technical trust and behavioural trust.  I also believe 
that forcing each member to micro-manage the entity descriptors available to 
them probably isn't the interfederation service they want, and that they 
would far rather you just provide everything you can, as long as it's 
trustworthy at the technical level.  That would be an extension of your role 
as a trust broker.

>> What I would like is for LIGO to be a use case that helps
>> drive international interfederation between InCommon and other
>> federations.
> 
> I don't believe there is any such thing. Federation is between an IdP
> and an SP. Interfederation is between an IdP and an SP in different
> federations.

That's not a definition of interfederation that I recognise.  Federation 
between an IdP and SP from different federations is still just federation.  
The distinguishing "inter" is between the federations-as-organizations, not 
the individual entities.

> InCommon Operations doesn't get in the middle of the relationship
> between an IdP and an SP. I don't think we (Ops) want to change that.

Again, I think we need to be clear about the difference between technical and 
behavioural trust.  No one is asking InCommon Ops to tell IdPs what 
attributes should be released to particular SPs, or anything of that kind, 
and you definitely want to keep out of the relationship at the behavioural 
level.

But you're in the middle of that relationship all the time, with regard to 
your members.  What we've been talking about here is extending the value of a 
federation operator's services by bringing in trusted metadata (at the level 
of technical trust) from elsewhere.

> Well, no, Stephen's metadata aggregator represents an untrusted 3rd
> party. There is no basis to trust his signing key, so LIGO needs to
> own this operation (or at least that's the way I see it).

For this pilot, agreed.  Incidentally, Steven's current implementation 
doesn't sign at all, as far as I know.  So that probably goes double for the 
moment.

>> I would like to see InCommon Ops begin to think about how to
>> evolve it so it can become and InCommon service more generally
>> useful than for just LIGO.
> 
> I have, and I hinted about such a service in my previous message.
> 
>> I think it will be more than useful if InCommon Ops can put
>> together an aggregate that has some level of vetting, probably
>> determined by a mutual negotiation between InCommon and the UK
>> federation (and other federations eventually), and then let
>> the individual InCommon entities decided which other entities
>> to trust, just as can be done now with the standard InCommon
>> metadata feed.
> 
> That's essentially equivalent to what I described earlier except that
> the order of operations is different. First you tell me what other
> entities you want to trust and then I will securely assemble the
> corresponding entity descriptors into an aggregate that you can
> consume. Does that meet your needs?

As I said above, that sounds like a radically different option than other 
federations are either deploying now or are considering.  Other federations 
are either dropping everything from their interfederation partners into the 
same aggregate as everything else (the UK plan is to do this, as it will be 
simplest for our members to understand) or to publish a single separate 
"foreign metadata" aggregate (federations who regard presence in their 
production aggregate as implying a degree of behavioural trust lean in this 
direction).

        -- Ian

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