If existing (RSA) signed fetch continues to work, it's probably fine. Breaking that would break many social gadgets.
On Wed, Aug 13, 2008 at 11:31 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > On Mon, Aug 11, 2008 at 12:50 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > Not necessarily. As we learned with REST, validating the spec within the > > reference implementation is a very useful exercise to go through before > > voting in a standard. > > > > I'd rather have shindig eat the pain of upgrading than live with a crappy > > spec. > > Funny you should mention that trade-off. > > I've just sent a proposal to the spec mailing list: > > http://groups.google.com/group/opensocial-and-gadgets-spec/msg/4f65d43e0446abbc > . > I don't think it would be a good idea to make the proposal a part of > the opensocial spec until we've got a working implementation, > preferably backed by one or more social containers saying "wow, that's > compelling, we're investing time to make it work for us." > > Implementing this in Shindig would mean replacing most of the signed > fetch code with the OAuth equivalent (though of course in a backward > compatible fashion.) That's potentially disruptive, but it has some > compelling advantages. In particular, it leads directly to support > for HMAC signatures in signed fetch. Non-Shindig containers have that > already, so having it in Shindig would be nice. > > To summarize the pros: > - we get HMAC sigs in signed fetch > - we reduce code duplication > - we probably get social containers to deploy full OAuth > > To summarize the cons: > - anyone deploying Shindig w/ signed fetch needs to sync up with the > changes. I don't think this will be too painful, but it will mean > keeping up with changes as they happen. > > Thoughts on this? > > Cheers, > Brian >
