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.

(For the non-technical, the title roughly reads “First try to reuse. Only if that doesn’t work, then reinvent.”)

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?

While I certainly agree with Chris that hCard has a role to play in the new world of online identity, I don’t want SREG or AX to be dismissed too quickly. I don’t believe he was suggesting that hCard would replace SREG/AX in all use cases, but I want to labor this point just a little bit so that others are not confused.

There is one huge benefit to SREG and AX that hCard doesn’t (and by it’s nature, can’t) address… releasing different attributes to different relying parties. This can take a number of forms. The one most commonly supported in OpenID providers today is the idea of personas - a complete set of attribute values that reflect your online identity within a particular context. You may have a “work” persona that includes your formal name, work email address and website, etc. Separately, you may have a “personal” persona that has some informal nickname along with a personal email address, website. etc. Separate still, you may have an “anonymous” persona that includes little (or fabricated) data about yourself. Depending on which relying party you are authenticating to, you may use a particular persona.

Varying this slightly, one can imagine a use case that will be become increasingly important as OpenID continues to expand. hCard is suitable for public attributes I want to post for the world to see, but what about not-so-public data? It will likely be some time before we start transferring credit card numbers over OpenID+AX, but I have no doubt it will happen eventually (as nervous as that makes even me). But even before then, I can imagine a host of data that I may need or want to provide to a relying party, but do not want to publish in my public hCard. As I included in my OpenID provider wish-list, OpenID providers will need to provide the tools to manage the policies controlling this release of data, a feature that has the potential to really differentiate one provider from the rest of the pack. This fine-grained level of control has always been a core requirement for the Shibboleth SAML Identity provider, and I would argue that the (currently beta) Shibboleth 2.0 IdP has one of the most powerful and flexible (and admittedly, verbose) filtering engines of its kind anywhere.

So there are really two issues at play in Chris’s question, that of the data format and separately, the mechanism for conveying that data. I haven’t really addressed the issue of the data format, because I agree with Chris in principal at least. His comparison table of attribute names shows a very clear overlap between the different methods, and perhaps it would be useful to work to consolidate some of that. But the mechanisms for making that data available address different, and equally valid, use cases and each play a role in making all of this stuff work.

Imagine being able to update your shipping address in one place when you move house and having all the online retailers you use receive the updated address immediately. Or changing your email address and having all the bugzilla instances you use pick up the new address instantly (perhaps requiring you to verify the new address first, of course).

While I agree this kind of experience would be very neat, it is not a use case for OpenID nor the Attribute Exchange extension. I am not surprised to hear someone say this, as this is a common point of confusion here at USC in regards to Shibboleth. When it comes to attribute delivery, both OpenID and SAML are primarily designed to provide data at the time of login ¹. So this means that if a user never logs in to your service, you never get any data about them. And if a user’s data changes since their last login, you don’t find out about until they next login, since that is the only time attribute delivery occurs. It is also important to note that you are typically only getting data about the user that is logging in, no one else. You can’t treat an OpenID provider as a lookup service to get data about some other user.

So how does a relying party update their data without waiting on the user to login again? One option is to have the data pushed to each service using some kind of messaging hub. There is a whole market for enterprise messaging complete with its own set of acronyms like ESB, EMS, EAI, and many many more. I’m particularly interested in a project developed by a colleague of mine in Sweden called JEvent, which uses the XMPP Publish-Subscribe protocol to deliver these types of messages using a standard XMPP server in the middle. Your Jabber messaging window becomes your console. :)

The other method of getting at user data is for each relying party to pull the data. This is the model we use at USC, where that mechanism for pulling data is LDAP. A number of services on campus use LDAP to address both use cases mentioned above — refreshing data about users, as well as looking up data about someone other than the user who logged in. So what’s the equivalent in the decentralized OpenID world? Well honestly there isn’t anything just yet but we have a good foundation. Thanks to microformats like hCard, you can publish your data in a standard, machine-parsable format that your online retailers or bugzilla instances could watch periodically. When you update your hCard on your homepage they can respond in kind, perhaps by immediately updating their databases or sending you a confirmation email of the change. Right now all of this data is decentralized, published on personal blogs and webpages. I don’t argue that this data should certainly be under individual control, but it puts an awful large burden on the individual service providers to do all that spidering. I don’t know what the answer is, but I’ve been thinking about an hCard crawler with an LDAP front-end as a simple place to start. Configure Apple AddressBook or Outlook to use LDAP, and you’re off and running.

I’m a little confused by his use of microID in the comments. In addition to adding microIDs to the blog HEAD and posts, Richard’s plugin (which I have installed here) adds a microID to blog comments that is computed using the commenter’s email and webpage. I see two different use cases when it comes to microIDs and blog comments…

Verifying email/URL couplet

Richard quotes something Jeremie says on the microID homepage —

Blog comment systems can check the given email address against a MicroID from the entered home page link to help reduce link spamming and blatant spoofing.

So this means a blog could potentially use a microID to verify the authenticity of an email/url claimed by a commenter. That is, when I make a comment on someone’s blog, their comment filtering system would compute a microID using the email and URL I claimed, and would make an out-of-band call back to my blog and compare the microID that I have on my site there. If it matches, then the email and URL are “valid” so to speak, and we’re done. If it doesn’t match, then the email addresses used to compute each ID are obviously different.

However, I do disagree with Jeremie’s claim that this could help reduce blatant spoofing (Jeremie even mentions this himself in an FAQ). Nothing prevents me from entering someone else’s email address and URL into a comment box. When they compare microIDs, of course they will match. This simply verifies a valid email/url couplet, but does not verify that the person making the comment actually owns either of those items. Put simply, microID does not do authentication (which the webpage mentions). Use openID for that!

Attributing ownership

The second use case is that of attributing ownership of a given comment to the author of that comment (which I think is what Richard was going after with his plugin). A microID is basically an assertion of ownership with three distinct parts.

• The authority making the assertion — this is the actual webpage that the content is hosted on. If you have the ability to manipulate the content of a given website, then it is assumed that you have some kind of authority over that security domain (or at least a small portion of it). This authority is the URL used to compute the microID.
• The person who owns the content — in the microID world, people are identified by email address, and this email address is used to compute the microID.
• The content for which ownership is being asserted — this is not part of the microID itself, but rather is implied based on the placement of the ID. If I am asserting ownership of an entire website, then the microID should appear within the HEAD tag. If ownership is being asserted for a small portion of content (such as a specific blog comment), then class values are used.

Back to Richard’s plugin, the content is obviously the actual comment itself and the person is the commenter, but where I think his plugin goes astray is the authority. In this case, the authority is not the commenter’s URL, but rather the URL of where this comment is hosted (most likely the URL of the original blog post the comment was made on). This would allow the commenter to make a claim of ownership of that comment on a system such as claimID (although I believe claimID only supports page level claims right now… not sections of content like this. Speaking of which, how would you specify which portion of a webpage you were claiming ownership of? Maybe use an #anchor in the URL? The microID verifier would certainly have to know how to deal with that).

So all that to say, I think the following function:

function add_microid_on_comment($comment = '')
{
    $microid = microid_hash(get_comment_author_email(), get_comment_author_url());
    return "<div class='microid-$microid'>$comment</div>";
}

should instead be changed to

function add_microid_on_comment($comment = '')
{
    $microid = microid_hash(get_comment_author_email(), get_permalink());
    return "<div class='microid-$microid'>$comment</div>";
}

(Wasn’t trying to pick on Richard in this post… actually I really like his plugin and find it very useful. Explaining all this in this fashion actually helped clear it up in my head as well).