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

[Leif Johansson <leifj AT sunet.se>]

On 2014-04-02 17:06, Lukas Hämmerle wrote:
> On using RequestedAttribute to express what attributes an SP
> requires/desires:
> 
> On 27.03.14 15:44, Leif Johansson wrote:
>> In short: a frekkin mess :-)
> 
> Might be, but it's still the best (broken) mess we have today :-)
> 

That doesn't mean it works d00d :-)

> 
>> Let me explain using an example: connect.sunet.se needs a name, an email
>> address, a unique identifier/username and an affiliation.
> 
> This set of attributes is very common. So, this probably is a typical
> scenario (even more typical would be this list minus affiliation).
> 

Sure but I suspect we'll run into the same situation where we have
overlapping but semantically equivalent attributes in the future.

> 
>> 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.
> 
> What's so bad about declaring overlapping attribute needs? IMHO this
> would still be way better than declaring no attribute at all.
> 

We should be declaring "higer-level" attributes instead of the
represenation a particular local federation/scope happens to have zeroed
in on.

> Looking at the example of connect.sunet.se. Leif stated that this
> information is needed about a user:
> * name
> * email address
> * unique identifier
> * affiliation
> 
> To get this information a SP somehow has to express these needs.
> So, let's have a closer look at these:
> 
> * Email address
> I think we can agree that the mail attribute probably is not a critical
> attribute in this context as it is pretty standard and used in all
> federations. So, declare RequestedAttribute for mail with
> isRequired="true" and things should be pretty clear to anybody what is
> required and what should be released.

Yes - email is pretty simple.

> The only issues I could think of in the case of mail are:
> - Organisations releasing multiple values for the mail attributes
>   Don't think this is very common as most applications probably could
>   not handle multiple email addresses
> - Value contains not organisation mail address but private (read
>   Gmail, Hotmail, ..) address.
>   Well, probably not something the service has to care about as long
>   as the mail address still works and the user can receive mails
>   via this address.
> 
> * Name
>   Some federations support displayName, others givenName and surname,
>   others (multi-valued) commonName.
>   I would argue here that if the application really *requires* the name
>   of a user, that it should list basically displayName, givenName,
>   surname and commonName als *required* attributes. I would assume
>   that all these attributes contain the same information value, so
>   an organisation does not release more information if it releases
>   displayName, surname and givenName in most cases. And even if, an
>   organisation that is not happy with that, could still limit
>   the release so that for example only displayName is released.
>   As long as there is some name in one of these attributes that
>   somehow is related to the user, why should an application really
>   care? These names are probably in most cases just used to show
>   something more beautiful than "cshu23sd98324rouh" (e.g. an ePTID)
>   in the Adobe Connect Users list.
>   In the end the application then has to - as Leif suggested - act
>   defensive, which in this case means it somehow has to define a
>   priority in which attributes are used (e.g. "if display name
>   is available use that, otherwise use given name and surname if both
>   are available, otherwise the first value of common name, otherwise
>   display error message")

But the applications doesn't *require* all of those syntactic attributes
- it only requires enough of them.


> 
> * Affiliation
>   Basically the same as above. Same information in scoped
>   and unscoped affiliation value. So, if the application requires it,
>   list both as required.
>   What's the difference between "staff" and "staff AT switch.ch"
>   assuming that is pretty obvious that in the first case that value
>   was released by SWITCH when the SP knows it comes from an IdP with
>   entityID https://aai-logon.switch.ch/idp (which obviously
>   includes the scope "switch.ch").


But the applications doesn't *require* all of those syntactic attributes
- it only requires enough of them.

(yes that was copy-paste from above)


> 
> * UniqueID
>   This is a bit trickier as the ePTID probably contains less information
>   than the ePPN because it is targeted (different for each SP). So,
>   declaring both of them as required will result in slightly different
>   data about the user. Then again, if the service also requires and
>   gets an email address, what is the use/benefit of using the ePTID?
>   Having an email address from a user (or to some extent his name)
>   makes it relatively easy to identify this user across different
>   services and gone is one of the major advantages (from a privacy
>   point of view) of the ePTID.
>   What the application could do in this case is to store both, ePPN
>   and ePTID or one of these values that is available. This would
>   allow identifying the user both ways, which probably is good for the
>   user and the application operator.
> 
> 
> 
> So, on Leif's analyisis
> 
>> My analysis is that ...
>>
>> 1. RequestedAttribute is only useful _locally_, i.e between the SP (or
>> IdP) and its local metadata oracle.
> 
> I disagree. RequestedAttribute might be a bit less useful globally than
> locally but it *still is useful* and it's basically all we have today to
> somehow indicate what attributes an SP needs. Even if some better way
> (using EntityCategories or whatever) would be introduced to express
> attribute needs, it probably would need a lot of time (years) to
> establish this.
> 

No it certainly won't. All fedops have the ability to rewrite metadata
as it is presented to downstream customers.

Adding a filter that transforms semantic labels to ReqestedAttribute
would be a snap for most.

> 
>> 2. An SP needs to code defensively and handle *all* of the attribute
>> syntax it is likely to run into given its "connectivity"
> 
> Yes, agreed. And at least in the case of Shibboleth, it might not even
> be necessary to change code to use either/or attribute, thanks to
> attribute transforming techniques:
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeResolver#NativeSPAttributeResolver-TransformAttributeResolver%28Version2.5andAbove%29
> 

Yep

> 
>> 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. 
> 
> Can someone give an example of how EntityCategories could be used to
> solve the problem of expressing attribute needs in a flexible way? It's
> still a bit unclear to me (and maybe others) how that is supposed to
> work. Maybe Leif and Ian could give an example for the Adobe Connect
> Scenario.


The R&S category solves 99% of the problem for connect. The only thing
missing is affiliation and that is probably an orthogonal category

> 
> Best Regards
> Lukas
> 
>