OpenId as an ad-hoc federator

[S. Sriram]

Hi,

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
OPML.

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 ?

Thanks
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
> work.
>
> 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
>  siteb.com/api/mydata
>  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
> validation.
>
> 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
model.
>
> Thanks
> S. Sriram
>
>