OAuth for Proxied View

[charlie jiang]

When we extend OpenSocial to include proxied views, the current OAuth
model which let the container to proxy all requests to third party may
not be sufficient any more.

One of the major reason for the proxied view to exist is that the
application likes to get data from third party directly from its own
hosts. For example, for an application installed on MySpace, at the
time of the generation of a proxied view, the application might want
to get Twitter status for that viewer. The application should simply
be able to call Twitter directly using the viewer's oauth credential.
But, in current OpenSocial OAuth model, it is the container who keeps
tokens not the app.

There can be many solutions for this. Here we list couple of them to
start the discussion:

1. Container as the Proxy: We will keep the current model of letting
container to do the oauth dance and store tokens. When the proxied app
need to call a 3rd party web services, it will call the container and
let the container to be the proxy for that call. In this way, the
third party can sign the request, make the call to the 3rd party web
services, then pass the returned data back to the application.

2. Container as the Signing Agent: Keep the current model of letting
container to do the oauth dance and store tokens. The proxied view
send the request to the container and ask it to sign it. The container
sign the request with the known credential and return the signature
back to the application. The application then make the web service
call to the 3rd party using the signature it got from the container.

3. Pass Credentials to the App: There are many ways to do this.
Probably SSL has to be in play here. We either let the app to come to
container to fetch the credential in a secured way, or the app can
provide a secure endpoint that the container can use to drop the
credentials.

...

Thoughts?

-Charlie