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 
30. April 2008 um 10:27
Sam Hasler schreibt:
Thanks for this post. I’d assumed for a while that attribute exchange could do something like store requests but recently I’d somehow got the idea that it wouldn’t and I thought I might have to look at OAuth.
I’ve had an idea for a while now for a website that would have to store preferences/favourite information for each user so that it could highlighting information of interest to the user and I wanted a way for the users to take this information away and use it with any other website that wanted to provide the same service.
Store requests would be perfect for this, as even if my website went down unexpectedly the user could take their preferences to another site. With OAuth I could have allowed the user to export their preferences but they would have been stuck if the site went down unexpectedly.
I hope that that kind of totally open handed approach will become more common in future, and it will be OpenID, attribute exchange and store requests that will make it possible.
In fact, If I do get round to creating this website, that’s not the only way I plan to be open. I’d also open source the server software so anyone else could run their own implementation and experiment with different ways of providing the service.
Additionally, because there would be a potential revenue stream, I’d also be open about how much money I’m making. You might think it’s silly to think I could make money from it given that I’m allowing my users to move to competing services (so a more commercial enterprise could try and take my userbase or because I’d be open sourcing the server software I could get rival sites providing an identical service) but my hope would be that by being open about _everything_ I’m doing that users would stick with my site rather than anyone else’s while providing them the security that if I stop providing the service or “turn evil” that they still have their preferences and someone can take the server software and set up an alternate site.
There’s a line in The Matrix Reloaded where The Architect says “There are levels of survival we are prepared to accept”. I think in the future the web services that get the most users (not necessarily make the most money) are going to be ones that can accept the most openness. There are levels of openness that I’m willing to accept that I think are far lower than few other companies or organisations that provide web services (expect maybe Mozilla).
30. April 2008 um 20:34
Online Shopping with OpenID at Not So Relevant schreibt:
[...] which support this: Simple Registration and Attribute Exchange (also see Dennis Blöte’s excellent article on the topic). Both extensions allow transfer of profile data from an OpenID provider to a relying [...]
11. Mai 2008 um 02:31
Could OpenID Revolutionize Online Shopping? »TechAddress schreibt:
[...] this type of account: Simple Registration and Attribute Exchange (also see Dennis Blöte’s excellent article on the topic). Both extensions allow transfer of profile data from an OpenID provider to a relying [...]
12. Mai 2008 um 12:39
How OpenID and APML could be used by online shops - nicolas leroy schreibt:
[...] protocol which support this: Simple Registration and Attribute Exchange (also see Dennis Blöte’s excellent article on the topic). Both extensions allow transfer of profile data from an OpenID provider to a relying [...]
14. September 2009 um 17:15
Scenarios for WS-Passive and OpenID - Pablo M. Cibraro (aka Cibrax) schreibt:
[...] of the existing relying parties or identity providers do not support this spec as it is discussed here. I am just guessing
. What do you think ?. Posted: Sep 14 2009, 11:12 AM by cibrax | with no [...]
14. September 2009 um 20:08
Scenarios for WS-Passive and OpenID | I love .NET! schreibt:
[...] In addition, WS-Passive only specifies a way to interchange a security token with user claims between the involved parties (Client, STS and Relying Party), so it provides the flexibility of using any security token profile. The most common token profile used today is SAML, as it can be customized with custom assertions or claims specific to the business. OpenID also specifies a way to exchange custom data (other than Simple Registration or SReg data) through the “Attribute Exchange” spec. However, it looks like many of the existing relying parties or identity providers do not support this spec as it is discussed here. [...]