OpenId as an ad-hoc federator

[Anas M. Nebuchadnezzar XXXVII]

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:
> 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
>>
>>
>>     
>
>
>
>
>