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

[Lukas Hämmerle <lukas.haemmerle AT switch.ch>]

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 :-)


> 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).


> 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.

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.
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")

* 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").

* 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.


> 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


> 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.

Best Regards
Lukas


-- 
SWITCH
Lukas Hämmerle, Central Solutions
GÉANT Project Task Leader "Enabling Users"
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 05, direct +41 44 268 15 64
lukas.haemmerle AT switch.ch, http://www.switch.ch