The other related use case here is the Google Apps marketplace model for sitewide app auth:
http://code.google.com/apis/accounts/docs/OAuth.html#GoogleAppsOAuth http://www.google.com/support/a/bin/answer.py?hl=en&answer=162105 On Mon, Mar 22, 2010 at 3:03 PM, Ethan Jewett <esjew...@gmail.com> wrote: > On Fri, Mar 19, 2010 at 6:21 PM, Brian Eaton <bea...@google.com> 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
