On Wed, Apr 2, 2008 at 2:36 PM, John Panzer <[EMAIL PROTECTED]> wrote:
> > > 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. > > > Could the gadget XML file simply point at the certificate for its > associated server, possibly as a 'requires' feature? A container can get > this information at gadget installation time. > That's in line with Brian Eaton's proposal, and would probably make sense if it's just pointing to a public cert anyway. -- ~Kevin
