Interfederation

[Ian Young <>]

On 2 Apr 2013, at 22:06, Tom Scavo 
<>
 wrote:

>>  scopes in 3 places are all identical in UK metadata.
>>  scopes in 2 places are all identical in InCommon metadata.
> 
> There's a strict interfederation requirement lurking here: Scope is an
> entity characteristic that is best expressed at the role level.

It's not clear to me what you think the requirement is here, or who would be 
responsible for enforcing it.  Perhaps if you could write a short sentence 
with MUST or REQUIRED in it, it would be more obvious.

I can't think of a real reason to regard any particular behaviour in this 
area as REQUIRED for interfederation.  It's entirely harmless, for example, 
to republish the same scopes at the EntityDescriptor level as are published 
at the role level.  My general position on interfederation *requirements* is 
that we should restrict ourselves to those things we think are harmful if not 
adhered to, and the UK machinery applies that rule here: any (non-regexp) 
Scope element we receive from a partner in any context is simply republished 
as-is.

I happen to disagree about Scope being best expressed at the role level: the 
fact that we both seem to think it's useful to keep the lists consistent 
across roles surely argues against this position.  Scott C can perhaps 
comment as to the reasoning behind adding the entity-level Scope handling to 
the Shibboleth SP: I don't think I was the instigator, but I do remember 
being in favour of it at the time.  But then, the UKf has 10K+ scopes and 
duplication across roles has a cost (of course, having all three is even 
worse).

As I mentioned on the call, we started adding the third set of Scope elements 
in the UKf because of a hoped-for global and universal transition to that 
arrangement when everyone adopted Shibboleth 2.0.  In retrospect, we should 
perhaps have waited until we had a better idea of how long that was going to 
take.  Today, we think we still have 33 Shibboleth 1.3 SPs, and it's pretty 
clear that no-one else in the world intends to go down this route or is even 
aware of the possibility.  In light of that, it may well make most sense for 
us to stop publishing the EntityDescriptor level scopes entirely and just put 
the whole thing down as a failed experiment.  I think I may put that on the 
agenda for our next technical meeting.

Meanwhile, if the issue is that you see some harm that I don't in Scope 
elements at the EntityDescriptor level, it's easy enough (and equally 
harmless) for you to simply discard those if they are received from 
interfederation partners.

>> scope regexp="false" always specified for InCommon.
> 
> Another interfederation requirement: explicit regexp="false"

I think in this case it's clearer what you mean when you say this is an 
interfederation requirement: like me, you feel that regexp="true" scopes from 
interfederation partners are too gnarly to be trusted almost irrespective of 
how careful your partner is, so you see potential harm in republishing them.

The approach the UKf machinery takes to this is simply to throw a hissy fit 
whenever it sees an entity with a regexp="true" scope.  The individual entity 
is (noisily) dropped, but other entities in the aggregate are not affected.

I did consider doing the extra work to filter the Scope elements rather than 
the entire entity, but the only entities I've seen which used scopes of this 
kind *only* had regexp scopes, so they would have been left with none.  Given 
how much the UKf is dependent on scoped attributes, that would have made the 
IdPs in question pretty worthless so doing the extra work didn't seem 
justified.

>>  Organization element - OrganizationDisplayName / MDUI DisplayName
> 
> The primary concern here is the discovery interface. As I mentioned to
> Rod at one point, MDUI DisplayName should be strongly recommended, if
> not required.

We do recommend that every entity included in our export aggregate be given 
MDUI information.  We don't guarantee it, though, and we likely won't ever do 
so.  Obviously a (federation) consumer of our export aggregate would be at 
liberty to discard entities on any basis it feels appropriate, including a 
lack of MDUI information, but I'd personally feel that would be unnecessary.

As you can see from the FTS draft, we don't guarantee MDUI on imported 
metadata either.  If it were the case that MDUI had anywhere close to 100% 
penetration in federations worldwide, I might feel differently, but the 
situation on the ground gives me very little hope that we will ever get 
there.  I could probably run some stats if you were interested.

> The InCommon Federation falls back on
> OrganizationDisplayName as a last resort but considering the
> complexity of the latter in the UKF, that could present some problem.

OrganizationDisplayName as used in the UKf is not in fact very complicated.  
For IdPs, it describes the identity community (usually an institution, but 
obviously not in the case of multi-community IdPs like the schools ones).  I 
don't think that's any different than InCommon or any of the other major 
federations.  We have more of those complex use cases than you do, but in the 
case of IdPs the rules boil down to "an unsurprising string suitable for use 
in discovery".

Surveying metadata from other federations quickly leads one to the 
observation that OrganizationDisplayName for SPs is subject to a huge amount 
of variation across entities and federations, to the point where it's 
essentially worthless.  That is of course the reason we wanted to specify 
MDUI as something with more predictable semantics.

My opinion is that the best approach to OrganizationDisplayName for SPs is to 
learn not to care too much about it.  I certainly don't think that trying to 
change the behaviour of other federations in this area is worth the effort.  
The choice we've made is to have the UKf machinery republish <Organization> 
elements from elsewhere without change; we think that's better than the only 
real alternative, which would have been to discard it entirely.

> On the SP side, MDUI DisplayName is likewise a strong recommendation
> (if not required).

Again, I don't think there is any point trying to regard this as REQUIRED for 
interfederation.  Yes, we recommend people do this but we don't (and probably 
never will) insist on it.  Discarding partner's entities which don't have 
MDUI would throw away too high a proportion to be a viable strategy for us.

> How do we increase the likelihood that MDUI DisplayName is globally
> unique? I think it's nontrivial to enforce uniqueness at the consumer,
> but that's exactly what you need, especially on the discovery
> interface.

This is an important point, and I don't have a good solution.  Let me give 
you some of my thoughts, though, and perhaps we can cover this in a future 
call.

We are, as registrars, each able to ensure that locally registered IdPs have 
unique DisplayName (and OrganizationDisplayName, for compatibility) and I 
think we both do just that.[1]  Equally obviously, there's no way short of a 
global and universally adhered to registry of mdui:DisplayName values to 
guarantee uniqueness across all of our possible interfederation partners.  So 
we need to work out how to live with the fact that from time to time we might 
get a duplicate display name from a partner.

One option is to simply let this happen.  The consequence will be that there 
may be discovery interfaces which present duplicate entries, and it's 
possible that one or the other of the IdPs won't be selectable.  We try and 
mitigate this risk by not presenting imported IdPs by default in our CDS.

A second option would be to noisily reject and then discard any imported IdP 
whose display name clashed with a local IdP (or an imported IdP from another 
partner).  You'd then have to manually resolve the conflict by changing the 
local IdP's display name, or asking the partner federation to get their IdP's 
name to change.  This might not match your idea of a fun way to spend the 
afternoon.

You could also resolve clashes by automated mapping of incoming display names 
to locally suitable ones.  You could do this using a manually maintained 
mapping of entityID->displayName for exceptional cases, or automatically 
compute a new name for imported clashes based, say, on a per-partner prefix 
you determine.  Obviously you could just *always* do the latter for imported 
IdPs, but that would tend to make your federation partners feel like you were 
treating them as second class.

As you can see, no really good solutions there.

        -- Ian

[1] I think the UKf tooling may possibly not check all possible cases where 
both MDUI and ODN are involved, particularly in the multi-language case.  My 
ears are bleeding just thinking about it, but I probably need to look into 
that one.

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