In case you want to get more advanced and use OpenID for lightweight identity management this essential, because you probably have to exchange data other than the eight attributes offered by SReg – for instance an address or phone number. This can be done using AX and as long as Relying Party and Identity Provider support the same set of attributes/type identifiers there is no problem. There aren’t many IPs and RPs with AX support out there yet, but this will improve as with AXSchema.org there are already some type identifiers defined that both sides can pick up and support.

At the University of Bremen we are implementing an OpenID Identity Provider so that students can use their OpenID to sign up for courses, log into elearning systems and prove their student status. We need to exchange attributes that are typically used in higher education like matriculation number (somewhat comparable to a student id), their affiliation and degree program. This is beyond the scope of what is already defined at AXSchema.org and so we needed to come up with our own attribute type identifiers.

Reading about how to do that, you will come across an article by Chris Messina in which he talks about looking for existing standards that you can build on top of. As an example he mentions the vCard which could have been used to associate attributes with an already standardized name – unfortunately it was not and now attributes are named differently in SReg and AX. This is an important point as there are so many existing standards out there, but somehow we tend to always reinvent the wheel – even nowadays. If you would like to dig further into the discussion of how to combine OpenID and vCard you can read Tantek’s Toughts on this – he offers a modest solution for the problem, too.

I finally decided to turn to Shibboleth and it’s EduPerson object class which includes names for some of the attributes we need to exchange. What I could not find there I took from what the DFN-AAI and SWITCH had defined – here are the resulting schemes.

Conclusion: Watch out for existing standards if you have to define your own attributes as this will at least offer the option for portability in the future. There is a lot of work to be done in standardizing much more attributes than the ones defined by AXSchema.org, but Attribute Exchange already offers enough possibilities to use OpenID for lightweight identity management – especially when you are dealing with a known circle of IPs and RPs.

This post and the decision to use EduPerson and the attributes defined by the DfN was inspired by some discussions I’ve had after giving my talk on Attribute Exchange and defining attributes (slides are in german) at the IdentityCamp Bremen two weeks ago. Thanks at Henrik Biering and Tobias Marquart for their thoughts on this.

Technorati Tags: Attribute Exchange, AX, openID, Shibboleth, EduPerson, DfN, hCard, Higher Education

You all probably know the case where you sign up for a new service using your OpenID: You are asked to identify and in most cases to submit some extra data, like an username and your email address. These are used by the relying party (the service you signed up for) to create an account and prefill the disclosed attributes. Almost every identity provider offers the possibility to manage different personae, so that you can decide which of your information should be used to sign up with. For instance you may have two personae: One for personal use and another one with your business data.

At first, there was only SReg, which has a fixed set of nine attributes: nickname, email, gender, fullname, dob (date of birth), postcode, country, language and timezone. This offers the possibility to exchange some of the most basic user attributes, but has a major disadvantage: The set of attributes is fixed and cannot be extended, so that it is not possible to exchange the name of your home town or your website url.

This is where Attribute Exchange comes into play: AX does not give us a fixed set of properties – it is a namespace in which custom attributes and their types can be defined, as for instance the ones that are defined in AXSchema. An attribute is a combination of type identifier, title, count and value. The type identifier is an URL and defines what the property is – a street address, phone number, blog url, whatever. The title is used to inform the user about the kind of data being requested, for instance “Your ICQ number”. Count defaults to one and offers the possibility to request more than one value of the same type. The value is the data that the user/identity provider discloses.

Right now AX suffers the chicken-egg-problem: It is rarely supported by relying parties and identity providers – why request, when there is no one who responds? Same the other way round… but AXSchema lays the ground to solve this problem: Relying parties are given a set of attributes they can start to request and identity providers who already support SReg can easily migrate to support AX. Theoretically Simple Registration is deprecated, now that there is Attribute Exchange.

But there is even more to it: AX is not just about relying parties fetching user data, the specification already contains store requests, too. Attribute Exchange Store can be used by the relying parties to transfer updated data back to the identity providers. Well, this seems to be far ahead, but nevertheless it offers interesting possibilities and I will spend some time experimenting with it.

Last week I implemented the fetch part of Attribute Exchange in masquerade. It was fairly easy, as it is already supported by the ruby-openid gem and one basically just has to define some extra mappings for type identifiers to persona attributes. The only other identity provider supporting Attribute Exchange Fetch I know so far is MyOpenID. They do not support the AXSchema type identifiers, but I guess this will be fixed soon, which would be great, because MyOpenID seems to be pushing the innovation in the OpenID community.

To offer myself a sandbox in which I can test exchanging data between identity provider and relying party, I also implemented AX fetch requests for venteria. Theoretically – or practically, if your identity provider supports AXSchema – you can now update your venteria profile with your submitted persona details on every login.

I will be using Attribute Exchange extensively in my bachelor thesis, which is about identity management in academia. I will be using masquerade to setup an OpenID provider for the University of Bremen so that we can offer OpenIDs to students, who can use them to sign up for lectures or use them to verify their student status to relying parties. This is an interesting field of research and some work has already been done – for example there is an eduperson namespace defined in Shibboleth. Follow up my progress here, as I will be writing about it in the upcoming weeks

Technorati Tags: OpenID, Attribute Exchange, AX, SReg, Simple Registration