try { reuse; } catch (Ex) { reinvent; }

Earlier today, 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 normally make two posts so close together about such similar topics, but I realize now these really are two different topics. The concerns about hCard and privacy are very real and certainly worth consideration, but what Chris was really getting at was attribute naming.

OpenID attributes

The OpenID Simple Registration Extension was designed, much like OpenID itself, to address a very specific use case – providing the most common data requested when registering at a new website (things like name, email, gender, etc). It defines a fixed list of nine attributes that can be provided, and it works well for what it does, but it’s a bit rigid when one tries to do anything more with it. Even before the final draft of the SREG extension had been published, work was already being done on a more flexible extension for attribute exchange. This new extension defined only a mechanism for transferring attributes, but didn’t prescribe a fixed list of attributes. But in order to be at all useful, two parties must be assured that they are both talking about the same attribute. Therefore an attribute registry was established at axschema.org and a number of attributes (formatted as URLs) have already been defined which will likely be useful in common scenarios.

Attributes in Higher Education

Developed in the early 90s at the University of Michigan, LDAP quickly grew favor with higher education institutions to replace heavier-weight directory protocols. A number of LDAP object classes were defined to provide attributes deemed useful in certain contexts, for example rfc2798 defined inetOrgPerson which addressed the needs of “Internet and Intranet directory service deployments”. Higher Education had its own unique needs, so in 2001 Internet2 published the first version of the eduPerson Object Class. If (and only if) institutions required additional attributes beyond those provided by some already published object class, it was common practice to define a local object class to house those attributes.

Within a few years, the SAML specification was published and Shibboleth began finding its way onto many college campuses. Though not required by SAML, Shibboleth recommended the use of URIs for SAML attribute names, and subsequently established a collection of URN values to represent common LDAP attributes, including those defined in the eduPerson object class. As before, if campuses needed to include additional attributes in a SAML assertion, they were defined within a local namespace. Today, it is very common to see a mix of attributes at USC including those defined by Internet2:

• urn:mace:dir:attribute-def:displayName
• urn:mace:dir:attribute-def:eduPersonAffiliation

as well as those we have defined locally at USC:

• urn:mace:usc.edu:gds:attribute-def:uscUSCID
• urn:mace:usc.edu:gds:attribute-def:uscStudentDegreeProgram

Applying Precedence

No one is pretending that the fixed set of attributes defined in rfc2426 is the definitive list of attributes that could possibly be useful in OpenID, no more than eduPerson was the exhaustive list of attributes for every university that used it. All that is being questioned is why did Attribute Exchange redefine all that was already established in vCard? I would strongly support Tantek’s third proposal of hosting the official hCard XMDP profile at http://microformats.org/profile/hcard, so that AX can leverage the hCard specification while maintaining URL based attribute names. And given that it appears as though no one is currently supporting AX, now is the time to make this change.