An open discussion list for topics related to the eduGAIN interfederation service.

[Leif Johansson <leifj AT sunet.se>]

On 2014-03-27 12:03, Niels van Dijk wrote:
> Hi Leif,
> 
> Thanks for you comment
>>

schweet :-) read on to my lengthy text below...

>> This is a broken mechanism btw.
>>
>> I have lots of practical experience from interfederation from my work
>> with the NORDUnet adobe connect service and I bring this message from
>> the Twilight Zone of interfederation.... :
>>
>> RequestedAttribute *does* *not* *work*, repeat DOES NOT WORK
>>
> 
> I would be really interested to learn what part of it is not working:
> - The SP (software) cannot publish this?

In general no it can't, but thats irrelevant since the fedop needs to
look at and approve those fields anyway.

> - The IdP (software) cannot read it?

It often can - at least indirectly by generating filter definitions for
instance.

> - The SP still cannot get the attributes it needs?

Aaaaalmost but not quite (read on).

> - The Idps are/remain unwilling to publish these attributes?

Its the fedops job anyway... cf above.

> What part of this does not work?

This is the problem:

RequestedAttribute is about syntax but SPs care about semantics.

Let me explain using an example: connect.sunet.se needs a name, an email
address, a unique identifier/username and an affiliation.

However instead of expressing that in metadata it lists a bunch of
attribute _representations_ that overlap to cover these _semantic_
requirements from all of the connected IdPs.

For instance a name from China is displayName and nothing else whereas a
displayName from HAKA contains the "non-familiar givenName" of the
subject. From HAKA and SWAMID affiliation is eduPersonScopedAffiliation
but from WAYF and FEIDE it is eduPersonAffiliation, etc etc. We have
these differences because they matter to us and they are not going away.

The SP unpacks what it gets and does the best it can to map what it gets
to the internal representation of the attributes in the service identity
store.

The result is metadata that is full of RequestedAttribute-elements that
overlap, has isRequired=true where it really isn't -- at least not for
everyone, etc etc.

In short: a frekkin mess :-)

My analysis is that ...

1. RequestedAttribute is only useful _locally_, i.e between the SP (or
IdP) and its local metadata oracle.

2. An SP needs to code defensively and handle *all* of the attribute
syntax it is likely to run into given its "connectivity"

3. Semantic labels are needed which can be transformed into locally
meaningful RequestedAttribute elements by the local metadata oracle.

Entity categories are almost the semantic-level attribute requirements
we need in practice. Ian is right that they don't exactly align and
won't cover all cases but they are also all we have right now and is
probably good enough for the 80/20

        Cheers Leif