Off to build kiteflying.com now…

Let’s say kiteflying offers OpenIDs for each of its users via their profile page (say drnic.kiteflying.com). Alternately, as suggested above, perhaps the profile page allows me to delegate the url to a different OpenID provider like I do with drnicwilliams.com. But that’s off topic here.

So kiteflying can accept OpenIDs for ppl to login/create accounts, but can then turn around and let those accounts be OpenIDs themselves.

Is that any clearer?

That is, say your app is kiteflying.com. I use drnicwilliams.com as my OpenID to register/login to kiteflying.com.

Now it turns out that drnic.kiteflying.com is also an OpenID url (it could be a delegate like drnicwilliams.com is to myopenid.com, or kiteflying.com could be an OpenID provider itself).

But the point is that your app can be a consumer of OpenIDs and a provider of OpenIDs independently.

I’ll take a look at PIP. I wonder if there is an advantage to actually being an identity provider versus delegating authentication on user pages to other identity providers… for the purpose of saying ‘yes, that user has an account here and he owns that url’ delegation seems less hassle.

There is a server within the ruby-openid gem (lib/openid/server.rb) and there is a full-blown OpenID provider application built by EastMedia Group and Verisign, called PIP, which I think was shown off at RailsConf2006.

Note, when you setup the PIP app, I discovered it only runs on Rails 1.1.6, not 1.2+

If you play around with these, let me know what you find.

to the head of the HTML. (Section 3.1 of http://openid.net/specs/openid-authentication-1_1.html)

So, service A could add that tag to all user pages. Then when the user signs up for service B and provides their service A identifier page, service B would know the user owned that account over at service A.

This all would happen with a single openID provider. So, I answered my own question. Sorry to work that out for myself here:-)

I see little reason why you can’t associate several logon systems of whatever type with one account, whether they are OpenID or some other authentication protocol. Perhaps Google/Yahoo/etc. will open up their authentication systems at some point.

And of course a user may have several URLs for the same OpenID with the redirection capability. And I might forget which one I’m using today.

It seems an interesting idea though: as more service providers make their user accounts available as OpenIDs, that apps can use this mechanism as a built-in “prove you have an account with app XXX” by giving me your OpenID, and then making them signin with it.

Currently, sites like Flickr implement their own “will you let your Flickr account be used by external application YYY?” mechanism. Perhaps they could just give everyone OpenIDs (http://openid.flickr.com/drnic) and then upon login to Flickr OpenID via the 3rd party app.

To be fair, this use case isn’t well thought out by me, but its intriguing.

It seems to me that it might be better to allow 1 OpenID, and allow them to manually set their their AIM, and other info. I shouldn’t have to login with multiple OpenID’s just to get the functionality of their providers.

It strikes me that this OpenID stuff is still so new we don’t have a widely accepted set of best practices for application integration just yet.