Name, Rank and Number

July 17, 2012 in Uncategorized by nicole | 3 comments

Last week, I chaired the consultation meeting for the EC AAA Study that is being lead by TERENA with a consortium of partner organisations across Europe. The focus of that report is access and identity management for researchers specifically, but a lot of the comments at the meeting are very applicable to federation as a whole. The report from TERENA is not too long and is currently open for consultation, please do feedback to the team if you can.

One of the things that struck me at the meeting was a comment from David Kelsey on the oxymoron of ‘Identity Provider’ as a name. David pointed out that one of the last things that Identity Providers in our community do is provide identity information, and I think this is a very fair point – we are currently sticking to the modern day equivalent of name,rank and number. I don’t have any detailed information on the attribute release policies of members of the UK federation, but I am fairly certain that most do not release much more that ScopedAffiliation (i.e. staff@…, student@…) and TargetedID (an opaque identifier). I think there are several reasons for this:

• The UK federation rules only specifically mention 4 attributes. These are intended to be a minimum set of attributes to support, but have become by default a maximum.
• Major concerns about the data protection act make most institutions very reluctant to release any data at all. It is better to do nothing than fall foul of the law.
• Although there was a real buzz around getting federated access implemented in 2007 – 09, there has not been enough follow up to really exploit the uses that attribute management can be put to. IdM is not being prioritised in the current funding climate within institutions.
• There are not sufficient tools in place to delegate attribute management and population well across the institution, which is desperately needed for the process to work effectively.
• The UK has focused on the publisher use case, and publishers are not asking for more complex attributes. There is a catch-22 for other scenarios where researchers, for example, are not using federations because they don’t supply attributes and institutions aren’t providing attributes because they do not see the demand.

There are a couple of efforts under way to try and address this problem and encourage institutions to a) more effectively manage their attribute release policies and b) feel confident releasing attributes to certains groups. One is being lead by the edugain team and is called the ‘Code of Conduct‘. The idea is that Service Providers will be able to self declare that they will abide by a conduct statement when it comes to handling attributes. Compliance with the code will be registered in metadata and the intention is that the presence of this flag will give IdPs more confidence in passing information to the SP. There is a consultation open on this at the moment and edugain would really like to here from Identity Provider organisations in particular.

Another approach is more local to the federation. The idea of ‘SP cateogries’ is that when joining the federation, an SP can ask to be added to a certain type of category described by the federation. This might be, for example, ‘student services’ or ‘scholarly publishing’ or ‘research and scholarship’. The federation would provide some minimal vetting, and on completion would assign the SP to that group. IdPs would be asked to automatically release attributes of a certain type to all members of that group. InCommon are currently piloting this approach.

So will either of these processes work and help us to build a richer attribute economy? The Code of Conduct is a clean approach that has the backing of lawyers involved in the project, and is easily described and actioned in current metadata. However it still requires IdPs to have a separate interaction about the attribute requirements of each and every SP, and I am not sure if there is much incentive for SPs to volunteer to sign up to such an agreement.

Member categories are nice as they would allow a simple way for IdPs to manage attribute release for large groups of SPs, but it will have its limitations in attempts to make the groups manageable. It also introduces a new overhead for the federations and its member SPs at point of registration, and it could be difficult to retrospectively get existing members to sign-up to categories.

I’d be really interested to hear from Identity Providers in the UK as to whether either of these approaches would convince them to provide richer attribute release, what we could do to help faciliate this and any other ideas you might have in this space. I’d also encourage you to reply to both of the consultations I mention in the post as they would love your feedback.

Functional Requirements (new)

In the comments, Andy has rightly pointed out that this post does not identify any functional requirements. So here are just a few to get started:

• The CERN lead FIM report is explicit that attribute release on a ganular level is essential if the research communities are going to make proper use of federated access. To quote: “Many of use cases identified by the research communities call for personal information to be aggregated with community defined attributes in order to grant access to digital resources and services.”
• European projects CLARIN, DARIAH and Project Bamboo have all cited limited attribute release as a barrier for them in adopted federated access.
• JISC Services, such as JUSP have asked institutions to release additional attributes and have been unsuccessful in getting the majority of institutions to achieve this.
• In discussion with many blogging and wiki platforms, lack of release of email address has been cited as a reluctance to use federated access.

As I do state in the original text for this blog, I feel there is a really large chicken and egg problem here. There are many many services that want richer attribute release but reject access via the UK federation as they don’t believe they wil achive this level of granularity. These organisations therefore don’t join, which leads to an impression that this is not a requirement and therefore institutions do not perceive a need to manage this, which is the point Andy makes below in describingthe two approaches to development. I am however convinced that there is real demand and there are drivers. We actually need to be tackling both schools of thought to provide a service that meets community need.

3 comments