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 wrote:
> On Fri, Ma
On Mon, Mar 22, 2010 at 3:03 PM, Ethan Jewett wrote:
> 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
On Fri, Mar 19, 2010 at 6:21 PM, Brian Eaton 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 req
On Fri, Mar 19, 2010 at 1:28 PM, Ethan Jewett wrote:
> I don't think so. In the OpenSocial case, the only "OAuth Consumer"
> per se is the OpenSocial container. The gadget is not making signed
> requests and is completely trusting the container to represent it
> properly to the OAuth Provider. In
On Fri, Mar 19, 2010 at 2:16 PM, Ethan Jewett wrote:
> On Fri, Mar 19, 2010 at 2:44 PM, Brian Eaton wrote:
>> Plaintext doesn't work in this context, because it sends long-lived
>> secrets in clear-text to servers that are under the control of the
>> application author, or, in the case of gadgets
Accidentally sent the following directly to Brian instead of the list.
I'll try again
On Fri, Mar 19, 2010 at 2:44 PM, Brian Eaton wrote:
> Plaintext doesn't work in this context, because it sends long-lived
> secrets in clear-text to servers that are under the control of the
> application a
On Fri, Mar 19, 2010 at 2:45 PM, Brian Eaton wrote:
>
> Ah, the other reason plaintext doesn't work is because one of the
> goals is to guarantee the integrity of the identity information passed
> in the request - neither the application author nor the viewer of the
> application is permitted to t
On Fri, Mar 19, 2010 at 11:44 AM, Brian Eaton wrote:
> Plaintext doesn't work in this context, because it sends long-lived
> secrets in clear-text to servers that are under the control of the
> application author, or, in the case of gadgets, everyone viewing the
> gadget.
Ah, the other reason pla
On Fri, Mar 19, 2010 at 10:52 AM, Ethan Jewett wrote:
> If I'm reading correctly, if the gadget chooses to use the container's
> private key, then that is making use of the RSA signature mechanism.
> If the gadget chooses to use the container's shared secret, then that
> is the HMAC-SHA1 signature
I think 4.5 should read "iLike gadget can choose to sign request with
MySpace's private key or with a shared secret between iLike &
MySpace."
If I'm reading correctly, if the gadget chooses to use the container's
private key, then that is making use of the RSA signature mechanism.
If the gadget ch
Here is one of the original writeups of OpenSocial + 2LO with a scanned
napkin drawing :-)
http://sites.google.com/site/oauthgoog/2leggedoauth/2opensocialrestapi
On Tue, Mar 16, 2010 at 11:12 AM, David Recordon wrote:
> Kevin Marks has been bugging me for awhile to understand how
> OpenSocial ma
On Tue, Mar 16, 2010 at 11:12 AM, David Recordon wrote:
> Kevin Marks has been bugging me for awhile to understand how
> OpenSocial makes use of two-legged OAuth. I reached out to the team
> and here's their description (via Evan Gilbert). In general it seems
> like they're more making use of OA
Kevin Marks has been bugging me for awhile to understand how
OpenSocial makes use of two-legged OAuth. I reached out to the team
and here's their description (via Evan Gilbert). In general it seems
like they're more making use of OAuth's RSA signature mechanism rather
than the user authorization
13 matches
Mail list logo
