(Long, sorry.)

I realize ([1], [2]) that URL content-type gadgets and the web API may take some time to solidify. However, having these things working is pretty important for my container, and I'd like to at least start moving in the right direction. I would love feedback on how close to reality (or, future reality) I'm coming. It sounds like a lot of people are discussing this sort of stuff, but I'm probably just not in the right places to be hearing it.

Below is a stab at how I'd use OAuth to deal with running a "URL" content-type social gadget. A URL content-type gadget is one that is served from a domain outside the container's gadget infrastructure, and therefore is beholden to cross-domain scripting restrictions. I want the gadget to be able to interact with my social network, but I don't want to give it carte blanche to access my users' information. So it needs a way to "masquerade" as a user, but only with that user's permission.

Note that this is somewhat different that [3], wherein an HTML-type gadget (namely, one that is rendered from the container's infrastructure) needs to proxy a request back to an application server.

So, for starters, let's assume that the gadget developer has registered their gadget with the container site. This includes:

* Specifying the Google module definition.

* Setting (or being given) an OAuth "Consumer Key" and "Consumer Secret".

Now, Vinnie (the "viewer") comes along and opens a page in the container social networking site that contains the social gadget in the context of some other user Ollie's (the "owner") page.

What happens?

1. The container renders the content page, which includes an IFRAME that loads the gadget from the gadget's URL as specified in its module file.

The URL query parameters contain:

* Vinnie's identity within the container social network (maybe it's an OpenID, maybe it's just a UID).

* Information that the gadget needs to initialize itself, such as the instance of the gadget, the fact that Ollie owns it, etc.

* Information about the containing site. Probably, this is a URL to some sort of manifest that defines a bunch of access points that the gadget will need in the below OAuth interaction. (Yadis [3] springs to mind.)

Notably, we do *not* pass in any other information about the Ollie or Vinnie to the gadget.

At this point, the gadget wants to know information that's stored in the containing site (Ollie's friends, picture, whatever). That means it has to go query the container site. Furthermore, we want the gadget to have no more or less visibility into Ollie's world (or Vinnie's, for that matter) than Vinnie himself has.

Enter OAuth, where the gadget is granted a "pass" to masquerade as Vinnie -- with Vinnie's permission -- for a bit. In this case, the OAuth "Consumer" is the gadget, and the OAuth "Service Provider" is the containing social network. So...we begin the OAuth dance:

2. The gadget (the Consumer) makes an HTTP request to the container's "Serivce Provider Request Token URL". This request contains the gadget's OAuth Consumer Key, and is signed with the gadget's Consumer Secret.

3. The container verifies the signature of the request, and if its valid, responds with an "Unauthorized Request Token"

4. The gadget causes the UA to redirect the IFRAME back to the container's "Service Provider User Authorization URL". The redirect includes the "Unauthorized Request Token".

At this point, we're supposed to ask Vinnie if the gadget is really allowed to masquerade as him. There are a bunch of UE issues here, but my guess is that the way I'll deal with this is to have the "Service Provider User Authorization URL" check Vinnie's cookie, and if it's valid, claim that Vinnie has consented.

5. If Vinnie consents to allow the gadget to masquerade as him, then we redirect the IFRAME back to the gadget, and indicate that the Request Token is now kosher. The container probably has to write down somewhere that the token is now authorized, and it allows the holder to masquerade as Vinnie.

6. The gadget now makes an HTTP request to the container's "Service Provider Access Token URL" to exchange the Request Token for an Access Token. The container does exactly that, issuing an access token that can be used to masquerade as Vinnie, most likely in some limited sense.

Now the gadget can use the Access Token along with the container's OpenSocial web API to do stuff with Ollie's gadget as Vinnie. For example,

* If Vinnie is allowed to see Ollie's Person information, then the gadget can retrieve and render it.

* If Vinnie is allowed to see Ollie's friends, then the gadget can retrieve and render Ollie's friends.

Notably, if Vinnie *can't* do those things, then the gadget can't do them either.

Anyway, I'd love feedback on this. I'm kind of grasping at straws here!

thanks, chris

[1] http://feeds.feedburner.com/~r/OpensocialApiBlog/~3/191964788/thoughts-on-implementing-opensocial-for.html

[2] http://groups.google.com/group/opensocial-container/browse_thread/thread/95b374ec4f95c8b2

[3] http://opensocialapis.blogspot.com/2007/11/improved-content-fetching-for.html

[4] http://yadis.org/papers/yadis-v1.0.pdf