The drive behind federated authentication is to be able to deploy and use services outside of a single institution. Therefore, there is a need for agreement over which attributes should be used and what format they should take. While Shibboleth can technically support each institution using different attributes and formats of data, this should not be intended and is not practical. Shibboleth is designed to be used in loosely coupled federations. The purpose of the federation is to decide on standards for attribute sharing.
In practice it is likely that the federations themselves will seek to standardise attribute formats and types across federations. The technical and administrative overhead of accessing different data about a user and distributing it in various formats mean that there is a large incentive to use global standards. One such standard is the eduPerson standard, which has come from the US educational sector.
http://www.educause.edu/eduperson/
EduPerson was originally conceived, by an EDUCAUSE/Internet2 working group, as a schema for LDAP directories to store information which represents users in a standard way. It was envisaged that software used in one university could be reused in another with minimal need for recoding. It would also help commercial software suppliers develop systems for campuses. The eduPerson standard defines many different types of data that can be stored about a user. A subset of these data could prove useful in making authorisation decisions about a user.
The UKeduPerson project[2] followed three strands: an assessment of the international picture; a “bottom-up” assessment of potential requirements for a UKeduPerson schema; and, a consultation exercise with Shibboleth-aware information vendors. The project resulted in the production of the UKeduPerson schema and made recommendations to JISC for future development. There has been no real impetus for internationalising the schema[3].
The use of attributes in the context of Shibboleth is an academic community driven process; it is therefore likely to be subject to "fashions". If the federations you wish to join and the services you wish to use require certain attributes then your institution will have to provide them in order to gain access to those services. That said, it is against both the federations and the service providers best interests to dictate too onerous a set of attribute requirements.
In practice a very limited set of attributes is currently being used. Only a slightly more expansive list is being contemplated for future developments by most federations.
The key currently used attributes are:
eduPersonScopedAffiliation: used for the basic authorisation decision: does uni.ac.uk subscribe to the service?
eduPersonPrincipalName: identifies an individual editing account
eduPersonTargetedID: Many services can make use of, but do not require, the eduPersonTargetedID attribute. This is a persistent opaque identifier, which can be used to represent a user on a particular site but which is not used with other sites and enables service personalisation (remembering data such as stored searches about a user over different login sessions) without the service provider knowing the user's real identity.
Further attributes under consideration for use in federations (e.g. SDSS[4] in the UK) are:
given name
surname
common name
eduPersonEntitlement
The eduPersonEntitlement attribute is where all the individual entitlements (or capabilities) are held. In the SDSS project at Edinburgh University, the attributes currently supported are those deemed 'highly recommended' by the InCommon Federation which are those given in the two lists above, plus:
userid (uid)
The uid attribute can also be described as a Universal User Name (UUN). The uid is usually automatically assigned to staff and students at an institution, based on name or matriculation number, and can be assigned to registered visitors (including alumni) with format dependent on the category.
It is worth noting that some sensitive personal data will be automatically created through use of systems. Tags for (e.g.) reading habits are kept and in the real world could be used as personal identifiers. Fundamentally this type of data should not be collected, but it could be used to enhance the user's experience of using a resource. Anonymised personalised services can be offered through the use of the uid. Universities need to implement an attribute release policy to assure that attribute authority access is the only way to get third party access to personal data. The attribute release policy needs to be machine readable; current institutional processes may not be secure enough, and ad hoc releases of data may fall under the Data Protection Act[5].
A common misconception is that the Federation defines what attributes can be exchanged. In fact federations can provide attribute flexibility, since the federation should only provide a framework for attribute exchange within a common set of policies. Which attributes are exchanged are a matter of agreement between the identity and service providers.
There are at least two ways to approach the issue
to define all that users might want to access and attibutes to go with those items; however, without use cases this is tricky, and it should not be a case of what can be invented, but most usefully what can be done to solve the current issues
to invent the minimum number of attributes, and use existing ones to solve use cases that already have issues (such as the sharing of medical resources being addressed by IAMSECT)
The latter option has the advantage of increasing interoperability when new use cases arise. An attribute allowing "different levels of entitlement" needs to be demonstrated.
See the IAMSECT document 'Joining a Shibboleth Federation' for more information on attributes and federations.
[2] UKeduPerson: www.angel.ac.uk/UKeduPerson/
[3] John PAschoud (LSE); UK EduPerson Project manager; in conversation, May 2005
[4] http://sdss.ac.uk/
[5] Additional guidance on the Data Protection Act and other legal issues surrounding the use of information is available from The Information Commissioners Office: http://www.informationcommissioner.gov.uk/eventual.aspx?id=34