The folks over at ClaimID have recently added a “contacts” feature to their site, which makes it one of the first sites to attempt a decentralized social networking feature. They ran into a problem in that when adding an arbitrary OpenID identifier to your contact list, there is no obvious way to contact them and get them to verify the relationship. ClaimID's current solution is to have users enter both an OpenID identifier and an email address, which works after a fashion but is a little redundant.
It is with this use-case in mind that I've drafted up the “Send a Message” Protocol, which is a very simple protocol built on top of OpenID Exchange that allows a site to send a message on behalf of a user to an OpenID Identifier — assuming that the recipient actually supports this protocol, naturally.
Of course, sites sending messages on behalf of users is a rather slim use-case that doesn't have much of a purpose outside of social networking “handshakes”. It'd be cooler if the site could send a message as itself to an OpenID identifier, thus allowing an RP site a means to get in contact with a user that has signed in using OpenID without requiring an email address as well. This would be useful, for example, to send notifications to the user. This sort of thing requires a two-party rather than three-party (as with OpenID Exchange) approach to authentication. It was this sort of use case that drove me to draft HTTP authentication bindings for OpenID Authentication several months ago, but people quite rightly had reservations due to its reliance on “dumb mode” as the only supported mechanism. I'm hoping to spark some discussion on the mailing list about fixing this limitation while retaining the spirit of HTTP authentication.
The most obvious approach to “Send a Message” is simply to dispatch all incoming messages to some email address. However, nothing requires the use of email: one possible setup is that most messages could go into an email mailbox, but certain nominated senders could cause a Jabber message to be sent to me providing instant notification. In the future, the protocol could be used with multipart/alternative message bodies to provide both human-readable and machine-readable representations of a notification message, and have the message endpoint process the message and send the right parts to the right places.
For now, though, I'd be happy if RP sites could just use this instead of requiring my email address.