OpenID Attribute Exchange
In my previous article on OpenID 2.0, I mentioned the new Attribute Exchange extension. To me this is one of the more interesting benefits of moving to OpenID 2.0, so it deserves a more in depth look. As mentioned previously, the extension is a way of transferring information about the user between the OpenID provider and relying party. Why use Attribute Exchange instead of FOAF or Microformats? Before deciding to use OpenID for information exchange, it is worth looking at whether it is necessary at all. There are existing solutions for transferring user data such as FOAF and the hCard microformat. As the relying party already has the user's identity URL, it'd be trivial to discover a FOAF file or hCard content there. That said, there are some disadvantages to this method: Any information published in this way is available to everyone. This might be fine for some classes of information (your name, a picture, your favourite colour), but not for others (your email address, phone number or similar). The same information is provided to all parties. Perhaps you want to provide different email addresses to work related sites. The RP needs to make an additional request for the data. If we can provide the information as part of the OpenID authentication request, it will reduce the number of round trips that need to be made. In turn, this should reduce the amount of time it takes to log the user in. Why use Attribute Exchange instead of the Simple Registration extension? There already exists an OpenID extension for transferring user details to the RP, in the form of the Simple Registration extension. It has already been used in the field, and works with OpenID 1.1 too. One big downside of SREG is that it only supports a limited number of attributes. If you need to transfer more attributes, you basically have two choices: use some other extension to transfer the remaining attributes make up some new attribute names to send with SREG and hope for the best. The main problem with (2) is that there is no way to tell between your own extensions to SREG and someone else's which will likely create interoperability problems if when an attribute name conflict occurs. So this solution is not a good idea outside of closed systems. This leaves (1), for which Attribute Exchange is a decent choice. What can I do with Attribute Exchange? There are two primary operations that can be performed with the extension: fetch some attribute values store some attribute values Both operations are performed as part of an OpenID authentication request. Among other things, this allows: The OP to ask the user which requested attributes to send If the OP has not stored values for the requested attributes, it could get the user to enter them in and store them for next time. The OP could use a predefined policy to decide what to send the RP. One possibility would be to generate one-time email addresses specific…