I finally decided I wanted to set up an OpenID ID attached to the URL of my personal website, apocryph.org. I just set up an account on MyOpenID, installed the Drupal OpenID URL module, and configured it to point to my MyOpenID URL.

I set OpenID Server to ‘http://www.myopenid.com/server’, OpenID Delegate to ‘http://codebloc.myopenid.com/’, and OpenID XRDS Location to ‘http://codebloc.myopenid.com/xrds’. And that was it. Now http://apocryph.org is a valid OpenID. Too easy.

I happened to be reviewing the 10th draft of the OpenID 2.0 Authentication spec, when I noticed this nugget in section 5.2.1 of the draft:

[HTTP redirect] method is deprecated as of OpenID Authentication version 2.0 though is still required for implementation to aide in backwards compatibility.

In place of the HTTP redirect used by OpenID 1.1, is this, in section 5.2.2:

A mapping of keys to values can be transferred by returning an HTML page to the User-Agent that contains an HTML form element. Form submission MAY be automated using JavaScript.

The <form> element’s “action” attribute value MUST be the URL of the receiving Web site. Each Key-Value pair MUST be included in the form as an <input> element.

A few weeks ago, I emailed Johannes Ernst, asking him how (if at all) he saw lightweight URL-based ID management technologies like LID being used to express group membership semantics. As he promised, he’s put together a long post on group implementation in LID, which answers my questions.

On the plus side, I’m encouraged to see that this type of use case has been on the minds of the ID management players for at least a year, and that they recognize at least as clearly as I do how powerful this concept could be.

Like everyone else, I’ve recently heard buzz about PeopleAggregator. Though on the surface it’s simply a standards-based social networking service, upon further investigation it’s much more.

First, it’s embracing the URL-based lightweight ID management technologies I’ve posted about previously, which is another step in the direction of de facto standardization. Second, it’s building tools and standards for decentralized hosting and portability of all sorts of user information, not just identity and social network. The presentation materials on the site now specifically call out file and media storage as additional use cases.

What’s important is that PeopleAggregator isn’t just offering to host these services; that’s been done before.

Another weekend project idea is to investigate the implementation of an ASP.NET Membership Provider that supports LID/OpenID/Yadis identities. There’s an existing OpenID implementation for .NET, implemented in Boo, but you have to wire it up to your app yourself. A membership provider would be more drop-in, assuming the lightweight URL-based identity idioms can be shoe-horned into the fairly narrow membership provider API.

In a previous post on emerging ID management technologies I came to a few conclusions about these lightweight URL-based technologies that were subsequently corrected in an email conversation with Johannes Ernst.

A while back I ran across LID, a novel idea for a distributed identity based on the URL which was based on a few simple Web techniques, could be hosted anywhere with PHP or Perl access, and wasn’t control by any one organization.

Since then, this type of idea has come to be called ‘Identity 2.0’, no doubt as an outgrowth of an epidemic of irrational exuberance perhaps best characterized as ‘Bullshit 2.0’. Lame marketing monikers aside, there are a few decentralized ID management technologies out now, all of which intrigue me.

First, you have LID, the first technology I encountered which attempts to create an identity out of a URL.