Interfederation

[Tom Scavo <>]

On Sun, Apr 14, 2013 at 2:34 PM, Ian Young 
<>
 wrote:
>
> On 10 Apr 2013, at 00:33, Tom Scavo 
> <>
>  wrote:
>
>> - Every IdP entity descriptor SHOULD include an <mdui:DisplayName>
>> element for discovery purposes.
>>
>> - If an IdP entity descriptor does not include an <mdui:DisplayName>
>> element, an <md:OrganizationDisplayName> element MUST be present and
>> moreover it MUST be a suitable replacement for <mdui:DisplayName>.
>> [ref]
>
> These seem reasonable, except that the last MUST is of course unenforceable 
> by anything other than a human.

And not just any human since only the registrar can enforce this
requirement, I believe.

> On that basis, you might consider saying "SHOULD be a suitable replacement" 
> instead.

Well, I think it needs to be a MUST in this case since the consumer
has to blindly trust this is true (by previous agreement), otherwise
the consumer might be inclined to drop all IdP entity descriptors that
do not include an <mdui:DisplayName> element.

>> - An IdP's DisplayName is computed as follows. If the IdP's entity
>> descriptor contains an <mdui:DisplayName> element, the IdP DisplayName
>> is the value of <mdui:DisplayName>. Otherwise the IdP DisplayName is
>> the value of the <md:OrganizationDisplayName> element.
>
> These aren't requirements on the aggregate, but on its users.  I don't 
> think that's really in scope.

Yes, you're right, there are no requirements in the previous
paragraph, but I need this definition of "IdP DisplayName" so that the
next requirement makes sense.

> If you do want to talk about this, you should probably say something about 
> language tags.

Yes, you're absolutely correct. I realized this when I read the
eduGAIN requirements (which I completely agree with). This needs to be
fixed.

>> For any given
>> metadata aggregate, the list of IdP DisplayNames so computed MUST NOT
>> contain any duplicates.
>
> It's not quite clear what this means, but I think you're trying to push the 
> responsibility for avoiding duplicates upstream, and as discussed on the 
> last call I don't think that's practical.

No, I'm trying to articulate a common sense requirement that any
reasonable federation should already be enforcing internally. I'm
suggesting that no reasonable export aggregate will have two identical
IdP DisplayNames (by some definition of "IdP DisplayName").

> In the long term you need to have a plan to deal with incoming duplicates, 
> whether within a single upstream aggregate or across several.

Agreed, but if each federation does it part to begin with, the problem
is minimized.

> It's not even necessary to impose such a constraint in many cases; the only 
> place it matters is when discovery is actually being performed, which in 
> the case of someone like LIGO will likely be on a filtered subset of an 
> aggregate and not the whole collection.

I don't think that's relevant.

>> - Every SP entity descriptor MUST include an <mdui:DisplayName>
>> element for login and consent purposes.
>
> This seems unlikely to be satisfiable with the current penetration of MDUI. 
>  To avoid constraining away a lot of entities you want to be able to deal 
> with, I think you'd be best to step back from the MUST here.  I'd agree 
> with a SHOULD, but I can't see that the issues that arise if DisplayName is 
> missing for an SP are severe enough to justify discarding any such entities 
> entirely.

Well, at least we agree this requirement is contentious ;-) Seriously
though, consuming foreign SP metadata without the privacy benefits of
the InCommon Participation Agreement is going to be difficult. The
only workaround (that I can see) is to profile foreign SP metadata so
that it is conducive to user consent. That means requested attributes,
<mdui:DisplayName>, <mdui:PrivacyStatement>, and maybe a logo.

Tom