On Fri, Mar 19, 2010 at 6:21 PM, Brian Eaton <[email protected]> wrote: > > The gadget tells the container *where* to send the request. So if > OpenSocial gadgets supported PLAINTEXT, a malicious gadget author, or > a malicious user of a gadget (they are pure javascript) could tell the > container "please send a request to > https://www.example.com/log_my_secret";. > > And the container would then leak the secret to www.example.com.
I've got to be missing something in the OpenSocial specification, but in my mind the container *must* be keeping track of which secrets belong to which domain, even for the signing case. Signing a request to a random domain with a random secret isn't going to work, so the application must be taking requests from gadgets and doing some matching to secrets based on the URL. This matching (done correctly - a big "if") should preclude leaking secrets. In any case, this is probably neither here nor there. I agree with your assessment of the two main interesting Open Social use cases. Especially the idea that it is an example of a type of trusted containers that can protect secrets from other applications or mediate for an application in a not-as-highly-trusted environment. Ethan _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
