OpenId as an ad-hoc federator
Anas M. Nebuchadnezzar XXXVII
Duck at kronkltd.net
Mon Oct 10 14:27:44 PDT 2005
This is exactly why I recommend that we make a standard call to
compliant OpenId clients that will initiate a login. That way we can use
my idea of Client auto-discovery. That way, if Site B needs to
authenticate with another Site on the user's behalf, then all Site B
would have to do is pull up Site A, read the openid.client tag, and then
re-direct the user to that address with the user's identity in the
openid_url parameter. (and perhaps also an openid_mode=login)
Daniel E. Renfer (http://kronkltd.net/)
S. Sriram wrote:
> 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
> the user.
> 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 ?
> S. Sriram
> ----- 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