OpenId as an ad-hoc federator
ssriram at gmail.com
Sun Oct 9 21:20:44 PDT 2005
By ad-hoc federation, I mean that Site B agrees to honor
a request for user data provided that the request is
accompanied by an openID.
This request would be "interactive" i.e. requested by the user when
the user is online, so Site B could "validate" the OpenID with
By OpenID validation, I mean that Site B acting as a consumer would
go through the standard OpenID validation with the OpenID server.
As an example, say I am on a cool new rss reader site (Site A)
and I want to load in all my rss feeds. These feeds are sitting
on my account with another site online (Site B). Site B provides
an export to OPML option and Site A provides an import OPML option.
So, I go to Site B, export OPML and get back to Site A and import it.
With ad-hoc federation, I would simply provide my OpenID and the
Site B REST-api url to Site A and Site A would go out, Site B would
validate that the OpenID was really my identity and provide the
So, if I wanted to move my tags around the web, or my bookmarks,
my feeds, my attention etc. I would just pass my OpenID around.
Besides adoption issues and requiring Site's A & B to support this,
are there any intrinsic weeaknesses in the model ?
----- Original Message -----
From: "Evan Martin" <martine at danga.com>
To: "S. Sriram" <ssriram at gmail.com>
Cc: <yadis at lists.danga.com>
Sent: Sunday, October 09, 2005 5:12 PM
Subject: Re: OpenId as an ad-hoc federator
You don't define what "user openid validation" happens between site A and B.
Unless there's a new mechanism in place, either:
- If site A only stores OpenID identifier: Evil user E sends user's
OpenID to site B and gets the private data.
- If site A stores whatever secrets are necessary to do normal
validation on B: site A can now be the user on any site they want,
even when the user isn't around.
On 10/9/05, S. Sriram <ssriram at gmail.com> wrote:
> OpenId as an ad-hoc federator:
> Could someone point out why such a scenario may not
> Site A has it's own identity island. It asks user for his
> OpenID , validates it and stores it away.
> Site B does the same thing.
> Site B offers a rest api
> and expects an OpenID in the XML POST data
> Now, when user at Site A wants to get his data from Site B
> to use within site A, it becomes ez since all Site A has
> to do is call the Site B's REST api call with user's openID.
> Site B of course only passes on the data on user openid
> Advantages to the user are: He does not need to provide Site A with
> all his usernames & passwords for all the different services.
> I'd be interested in knowing what weaknesses if any are there to this
> S. Sriram
More information about the yadis