One of the many promises of OpenID is the ability to more easily federate profile information from an identity provider to secondary consumer applications. A simple example of this is when you fill out a basic personal profile on a new social network: if you’ve ever typed your name, birthday, address and your dog’s name into a form, why on earth would you ever have to type it again? Isn’t that what computers are for? Yeah, I thought so too, and that’s why OpenID — your friendly neighborhood identity protocol — has two competing solutions for this problem.
Unfortunately, both Simple Registration (SREG for short) and its potential successor Attribute Exchange (AX) go to strange lengths to reinvent the profile data wheel with their own exclusive formats. I’d like to propose a vast simplification of this problem by adopting attributes from the vCard standard (also known as RFC2426). As you probably know, it’s this standard that defines the attributes of the hCard microformat and therefore is exceptionally appropriate for the case of OpenID (given its reliance on URLs for identifiers!).
Very quickly, I’ll compare the attributes in each format so you get a sense for what data I’m talking about and how each format specifies the data:
| Attribute | SREG | AX | vCard |
|---|---|---|---|
| Nickname | openid.sreg.nickname |
namePerson/friendly |
nickname |
| Full Name | openid.sreg.fullname |
namePerson |
n (family-name, given-name) or fn |
| Birthday | openid.sreg.dob |
birthDate |
bday |
| Gender | openid.sreg.gender |
gender |
gender |
openid.sreg.email |
contact/email |
email |
|
| Postal Code | openid.sreg.postcode |
contact/postalCode/home |
postal-code |
| Country | openid.sreg.country |
contact/country/home |
country-name |
| Language | openid.sreg.language |
pref/language |
N/A |
| Timezone | openid.sreg.timezone |
pref/timezone |
tz |
| Photo | N/A | media/image/default |
photo |
| Company | N/A | company/name |
org |
| Biography | N/A | media/biography |
note |
| URL | N/A | contact/web/default |
URL |
Now, there are a number of other other attributes beyond what I’ve covered here that AX and vCard cover, often overlapping in the data being described, but not in attribute names. Of course, this creates a pain for developers who want to do the right thing and import profile data rather than having folks repeat themselves yet again. Do you support SREG? AX? hCard? All of the above?
Well, regular people don’t care, and shouldn’t care, but that doesn’t mean that this isn’t a trivial matter.
Instead, the barriers to doing the right thing should be made as low as possible. Given all the work that we’ve done promoting microformats and the subsequent widespread adoption of them (I’d venture that there are many million hcards in the wild), it only makes sense to leverage the upward trend in the adoption of hcard and to use it as a parallel partner in the OpenID-profile-exchange dance.
While AX is well specified, hCard is well supported (as well as well-specified). While AX is extensible, hCard is too. Most importantly, however, hcard and vcard is already widely supported in existing applications like Outlook, Mail.app and just about every mobile phone on the planet and in just about any other application that exchanges profile data.
So the question is, when OpenID is clearly a player in the future and part of that promise is about making things easier, more consistent and more citizen-centric, why would we go and introduce a whole new format for representing person-detail-data when a perfectly good one already exists and is so widely supported?
I’m hoping that reason and sense will prevail and that OpenID and hCard will naturally come together as two essential building blocks for independents. If you’re interested in this issue, please blog about it or express your support to specs@openid.net. I think the folks working on this spec need to hear from folks who make, create, build or design websites and who recognize the importance and validity of betting on, and support and adopting, microformats.
Factory Joe 
I hate that every spec author feels the need to reinvent new attributes names. It doesn’t make you unique and cool, just annoying. Using vCard as reference was obviously a good choice on part of microformats.
But I do have to warn that inferring the preference language from the document language is mono-lingual myopic. It’s common to be named in one language, which you’ll want to use for your vCard, and prefer to use services in a different language, which you’ll want to use as login preference. One does not imply the other.
Also, vCard does have a timezone property (tz).
I’m still frustrated by this lack of understanding. AX will plug directly into a dynamic bit of code / database on the backend. The *display format* can easily be hCard…or anything else. We’re not hand coding stuff here. This is not something for openid or specs to deal with. AX is already extensible, as you said.
Have you considered hosting an hCard schema at microformats.org? Unique URLs define each attribute, so doing microformats.org/hcard/firstname (or whatever, just continue the process) so that everyone implementing AX and wanting to follow a centralized definition of attributes can just use those. Go for it!
Chris, is there a reason URL is listed twice in your table, or that just a typo?
And I definitely agree, there’s an overlap between protocols here that should be eliminated. There are some implementation details that would need to be worked out first though. The most striking one being that there’s no guarantee a URI acting as an OpenID Identifier will also contain an hCard.
I think this is a perfect use for Yadis. Why not create a new service type for pointing towards either a vCard or hCard?
What I would like to see is the http://www.axschema.org/types/ extended with recognized support for microformats. e.g. defining types like ‘type.microformats.xfn’ and use those types to exchange microformats over OpenID Attribute Exchange.
Site X wants a friends list, sure, just request ‘type.microformats.xfn’ and get the xfn formatted list as part of the exchange.
The same with the other microformats.
Chris, here is my opinion at what steps we can take to replace OpenID SREG with hCard:
http://tantek.com/log/2007/11.html#d02t2318
Thanks for your post.
Tantek
Hmm. How would this cope with the need to provide different attributes to (and, more importantly, to EXCLUDE different attributes from) different sites/services?
How do you propose the relying party get the hCard? As a payload in the OpenID response, alongside the signature, and signed?
If not, then as discovery? (fetching the public URL) In that case, how do you deal with non-public information?
I’m not disagreeing with anything you said; just curious how you see this working.
+1 to using hCard/vCard.
Totally agree – don’t need yet-another-schema.
Having built several webapps in the last few years that store identity data, I’ve found using the vCard schema all the way down to the database layer very effective.
Schema reuse is just as powerful as code reuse.