I did notice a strange behaviour in OpenID; I’m not yet certain if I missed it in the spec or if it’s left to one’s judgement (note to self: read the spec again)… Anyway, here’s what happens:

- Say I sign up with “roosenmaallen.com”. This site delegates to my ClaimID page, so the openid.identity response is http://openid.claimid.com/silvermoon82, and this is what I actually use to identify the user.
To my thinking, I should be able to log in using “roosenmaallen.com” (since that delegates to my ClaimID), or claimid.com/silvermoon82, or openid.claimid.com/silvermoon82. These URLs all end up at the same identity, so they should be equivalent — and that’s how I implemented it on Rosebleed.

I’ve noticed other OpenID-enabled sites handle this differently. On the OpenID Directory for instance, I first signed up as “claimid.com/silvermoon82″. I’ve gotten in the habit of logging in using roosenmaallen.com; but when I try that at OpenID Directory, I get an error message that my email address is already registered to my ClaimID URL.

So, barring finding that the spec keeps “equivalent” OpenID URLs separate, I think I’m in the right here; always open to feedback though.

Update [2008-03-19]: I’ve checked the spec, and as it turns out, I’m actually in the wrong:

So, to use www.example.com as their Identifier, but have Consumers actually verify http://exampleuser.livejournal.com/ with the Identity Provider located at http://www.livejournal.com/openid/server.bml, they’d add the following tags to the HEAD section of the HTML document returned when fetching their Identifier URL.

<link rel=”openid.server” href=”http://www.livejournal.com/openid/server.bml”>
<link rel=”openid.delegate” href=”http://exampleuser.livejournal.com/”>

Now, when a Consumer sees that, it’ll talk to http://www.livejournal.com/openid/server.bml and ask if the End User is exampleuser.livejournal.com, never mentioning www.example.com anywhere on the wire.

The main advantage of this is that an End User can keep their Identifier over many years, even as services come and go; they’ll just keep changing who they delegate to.

I tracked it down to two separate issues:

1. Technorati uses DoubleClick advertising, which uses document.write() to drop new scripts into the page. This <script>-within-a-<script> seems to confuse the w3′s tidy proxy and breaks everything.
   I managed to work around this with a big ugly hack in hkit.class.php which attempts to detect the document.write() and fix the damage. It’s pretty ugly and probably pretty delicate as well, but it’s something.
   Feedback is always welcome: Modified hKit 0.5
2. Satisfaction uses AJAX to pull the hCard info through a script on their server. The script seems to have the same shortcoming as the Microformatic tool with URLs containing a ?. This one was an easy fix on my end; I updated Rosebleed’s profile page to accept the username either from the GET string (profile.php?user=silvermoon82) or from pathinfo (profile.php/silvermoon82). The hCard fetcher works with the new format links, so all is well in the universe.

Still in the works on the SN side is implementing OpenID for logins and order tracking, and hCard, hCard+XFN and FOAF profile-pulling.

Technorati Tags: Rosebleed, microformat, hcard, hCard+XFN, FOAF, OpenID