OpenId as an ad-hoc federator

[Martin Atkins]

S. Sriram 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.
> 

This sounds a bit like the "OpenRPC" thing I was proposing a while back,
though that wasn't really all that RESTy. The key is that the request
must be "user accompanied", which is to say that at least part of the
transaction must happen via a redirect in the user's browser so that the
request comes with whatever session tracking information is necessary to
do the OpenID authentication.

One way to do this is to use the client browser to exchange a token
representing the request, which was the approach I took. The request
proper then happens directly between the two remote sites where a more
suitable transport can be used.

If you generalised my approach a bit you could probably make something
resembling a REST API using a similar technique. I was focussed on
providing simple, consistant APIs for performing certain common
operations such as "post in this weblog" or "fetch this profile
information" and less on REST purity, but it wouldn't take much
refactoring I'd guess.