The ability to link people relationships to services in a very dynamic and distributed way is beginning to emerge. Envision a world where current social network relationships enable the discovery of personal services about any particular identity.
Consider the following use case: I want to notify (via the preferred mechanism of the recipient) all the people tagged as “close friends” in my “address book” or “social network”.
The problem is that while address books and social networks can know the relationship of “close friend”, they usually don’t have any way of knowing the “preferred mechanism of the recipient” to receive notifications. What’s needed is a way to “discover” via the identifiers in the “social relationship” the personal services of any particular individual.
So, what’s changing? A “new” community specification EAUT (Email-Address-to-URL-Transform) is being completed that allows an email address to be transformed (or mapped) into an OpenID. While this, in and of itself, is valuable for the adoption of the OpenID protocol, what I find really interesting is that since OpenID relies on XRDS for discovering the individual’s OpenID Provider, the mechanism is in place to discover any other service. This really enables an email-to-personal-service-discovery path that can launch a whole new set of use cases.
Even if the user doesn’t know anything about OpenID... the user’s social network could easily retrieve the OpenID’s for all of the user’s social relationships (since most are based on email address or have access to the email address). The social network could then provide additional services based on this discoverable information.
With most of the major identity providers already providing OpenIDs, all that's needed is for these players to support the EAUT specification.
[Disclaimer for my Liberty Alliance colleagues: These capabilities are already supported by combining the People Service and the Discovery Service for SOAP based deployments.]
2 comments:
There appears to be an "undistributed middle" in your argument. You begin by asking about "the preferred mechanism of the recipient" and end by using any old email address. But there's nothing to indicate that this is even the preferred email address for notifications never mind the preferred mechanism...
Sorry, I left out the part that the XRDS document would describe the preferred mechanism for notifications. This could be IM, SMS, email, etc.
Basically, the XRDS document could have a "Notification" service type which describes both the endpoint and the protocol/mechanism for communication.
Post a Comment