On Wed, Sep 17, 2008 at 8:31 PM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 16, 2008 at 11:26 PM, Eiji Kitamura <[EMAIL PROTECTED]> wrote: > > [2] xoauth_public_key > > > > According to following proposal: > > http://dirk.balfanz.googlepages.com/oauth_key_rotation.html > > > > Public Key Identifier should be specified using "xoauth_public_key". > > Same on google code gadgets site. > > But actual implementation in Shindig seems like using > > "xoauth_signature_publickey". > > > > Which is correct or should they be treated differently? > > I think we should change the spec to use xoauth_signature_publickey, > since that's what real world implementations have done. If there's > consensus on shindig-dev I'll send that proposal to the spec list. > > > App url should be specified using "xoauth_app_url". But it looks like > > there's "opensocial_app_url" mentioned on google code gadgets site. > > Shindig is implemented with "opensocial_app_url" too. > > > > Which is correct or should they be treated differently? > > Both have identical values, so at least we don't have a conflict to worry > about. > > opensocial_app_url was proposed as an alternative to > opensocial_app_id, because opensocial_app_id was difficult for gadget > developers to understand. > > xoauth_app_url was proposed on one of the OAuth mailing lists do deal > with cases where a proxy is using a single key for multiple OAuth > consumers, xoauth_app_url identifies the real application making the > request. > > opensocial_app_url was added most recently, so it's probably the > easiest to do away with, if we want to do so. OTOH, it is doing no > harm. > > Anybody on shindig-dev have a pressing technical reason to prefer one > approach over the other? If we've got a strong technical argument, > I'll present that argument to the spec list. Otherwise I'll just > raise the issue on the spec list as something that requires some > clarification. Why does it need clarification? The spec is pretty clear on this issue (for a change!). It sounds to me like we've screwed up and/or have been lazy about keeping up to date with the specification. Reading the specification, it's very clear what parameters should be sent. Of course, it doesn't actually say anything about OAuth, just SIGNED fetch. That's probably something that does need to be fixed. http://www.opensocial.org/Technical-Resources/opensocial-spec-v08/gadgets-reference08#gadgets.io.makeRequest If *opt_params*[gadgets.io.RequestParameters.AUTHORIZATION] is set to gadgets.io.AuthorizationType.SIGNED, the container needs to vouch for the user's identity to the destination server. The container does this by doing the following: 1. Removing any request parameters with names that begin with oauth, xoauth, or opensocial (case insensitive). 2. Adding the following parameters to the request query string: opensocial_viewer_id*Optional.* The ID of the current viewer, which matches the getId() value on the viewer person object. opensocial_owner_id*Required.* The ID of the current owner, which matches the getId() value on the owner person object. opensocial_app_url*Required.* The URL of the application making the request. Containers may alias multiple application URLs to a single canonical application URL in the case where an application changes URLs. opensocial_instance_id*Optional.* An opaque identifier used to distinguish between multiple instances of the same application in a single container. If a container does not allow multiple instances of the same application to coexist, this parameter may be omitted. The combination of opensocial_app_url and opensocial_instance_iduniquely identify an instance of an application in a container. opensocial_app_id*Optional.* An opaque identifier for the application, unique to a particular container. Containers that wish to maintain backwards compatibility with the opensocial-0.7 specification may include this parameter. xoauth_public_key*Optional.* An opaque identifier for the public key used to sign the request. This parameter may be omitted by containers that do not use public keys to sign requests, or if the container arranges other means of key distribution with the target of the request. 3. Signing the resulting request according to section 9 of the OAuth specification <http://oauth.net/core/1.0/#signing_process>.
