OpenId as an ad-hoc federator

[Evan Martin]

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