Defining Attributes for OpenID AX

In one of my last articles I wrote about Attribute Exchange and how this namespace can be used to exchange whatever personal data you like. You are not bound to a fixed set of attributes like the one that the Simple Registration extension offers, because you can define your own type identifiers.

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