November 21st, 2007 | Published in Google OpenSocial
We've been getting great feedback on the 0.5 version of the OpenSocial API. One of the top requests we've heard from application developers is for a non-spoofable version of IG_FetchContent. See below for our current thinking, which incorporates some pieces of OAuth, based on a proposal from Jeremiah Robison of Slide.
OpenSocial applications need a mechanism to pass data from gadgets back to application servers in a way that cannot be spoofed. The basic solution is for the container server (e.g. orkut.com) to proxy communications from the gadget to the application server (e.g. ilike.com). Therefore trusted content fetching has two main steps:  the gadget contacts the container server, and  the container server contacts the application server.
For step 1 (gadget to container server), the container needs to be able to validate any parameters it knows about: the viewer id, the owner id (if known), and the application id. Validating these parameters is an implementation detail that is likely to vary between containers; for example, Orkut uses an encrypted token passed in the document fragment of the gadget URL. We will provide an open source implementation of this scheme.
For step 2 (container server to app server), the app server needs to be able to validate that the parameters really came from the container server (and were not forged by some other entity). OpenSocial will use OAuth's parameter signing algorithm. Note that most of the OAuth standard, including token exchange, is not required; OpenSocial only plans to use the parameter signing piece of the standard (including timestamp and nonce). OpenSocial will permit the HMAC-SHA1 method (except that the key is a shared secret between container and app, not a concatenation of tokens as specified in section 9.2) and the RSA-SHA1 method. HMAC-SHA1 is faster and easier to implement, but it requires more coordination than RSA-SHA1.
Let us know if you have any comments. We'll keep you posted as plans firm up.