On OpenID Attribute Exchange

OpenID lets users verify the ownership of an identifier - namely their OpenID URL. The protocol can also be used to exchange further data and that is what the extensions SReg (Simple Registration) and Attribute Exchange are for.

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