hCard for OpenID Simple Registration and Attribute Exchange

Microformats + OpenID

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 standard (also known as ). As you probably know, it’s this standard that defines the attributes of the 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
Email 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.

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

8 Comments

  1. at 11pm on Nov 1st # |

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

  2. Boris Mann said
    at 12am on Nov 2nd # |

    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!

  3. at 1am on Nov 2nd # |

    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?

  4. at 7am on Nov 2nd # |

    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.

  5. Tantek said
    at 2am on Nov 5th # |

    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

  6. Lee said
    at 12pm on Nov 5th # |

    Hmm. How would this cope with the need to provide different attributes to (and, more importantly, to EXCLUDE different attributes from) different sites/services?

  7. at 5pm on Nov 7th # |

    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.

  8. at 8am on Nov 9th # |

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

7 Trackbacks

  1. [...] hCard for OpenID Simple Registration and Attribute Exchange | FactoryCity (tags: openid hcard microformats) [...]

  2. [...] Messina stellt sich in seinem Artikel “hCard for OpenID Simple Registration and Attribute Exchange” die Frage warum bei der Definition der ersten AX-Typen (genauso wie bei SREG) versucht wird, [...]

  3. [...] wrote about how hCard is much more appropriate than OpenID for the provisioning use-case and Chris continued that discussion, questioning why we need SREG and Attribute Exchange when hCard works just [...]

  4. [...] I wrote about the limitations of hCard primarily in regards to private data. After talking with Chris briefly and then reading Tantek’s thoughts on the topic, it clicked with me. I wouldn’t [...]

  5. [...] We love ALL sorts of openness and expansion of the known universe from the existing status quo of Web 1.0 and bricks and mortar business as usual.  This also applies to politics, sexuality and legalized marijuana – but I’ll keep my scope more limited to the matters at hand “which standards do we support – moving forward?” [...]

  6. //dopefreshtightblog on Jun 19th at 3pm

    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, becau…

  7. [...] kommt bestimmt später noch. Aber wen es interessiert, der sollte unbedingt hier (deutsch) und hier (englisch) weiterlesen. Der Ablauf insgesamt ist zudem auch gleich wie oben [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*