On Mon, Mar 31, 2008 at 2:32 PM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> > On Mon, Mar 31, 2008 at 2:00 PM, John Panzer <[EMAIL PROTECTED]> wrote: > > A lot of the security for this devolves to container policies, which > we're > > explicitly not specifying much of in OpenSocial. Perhaps the document > could > > list some reasonable policies, and point out dangers (in a security > section) > > to watch out for? > > That would be great. We can work out security for the reasonable > policies first, and worry about the unreasonable ones later. =) > > > I think I was hoping that key management worked out for the gadget phone > > home scenarios would also help out in this situation. Perhaps just with > a > > small reversal of polarity... > > We don't really have that worked out. We have ideas, and some of them > might be good, but for now it's a matter of containers announcing > 'hey, here's where you can download my key'. That doesn't scale very > far. > > Agreeing on a well-known location for downloading certificates from > containers would be a good start on key distribution for phone home, > but I'm not sure it's the answer for the RESTful APIs because there > are more gadgets than containers. > > A couple of open questions on this issue: > - how should a container discover the certificate for > http://www.example.com/gadget.xml? > - should containers grant identical privileges to > http://www.example.com/gadget.xml and > http://www.example.com/other.xml? Well, I should read further, shouldn't I? Straw man suggestion: <Optional feature="home-server" > <param name="oauth_consumer_key" value="http://example.com"; /> <param name="oauth_signature_method" value="RSA-SHA1" /> <param name="public_key" value="http://example.com/key.cert"; /> </Optional> Installing the gadget also grants http://example.com permission to access the data. Ideally, containers could allow Consumers to specify their own URL based Consumer Key (identifier) and if needed map it internally to developer codes or whatnot, so that we don't have to have a set of consumer keys, one per possible container. The other parameters give the type of signature algorithm and in the case of PK, point at the public key to be used to verify the identify of the Consumer. By default, two gadgets on the same domain or same directory don't have any special access to each other. If they both specify the same oauth_consumer_key though, then the same back end service can access data for both.
