I should add a section detailing the interesting API client use cases for context.
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? For many situations, the policies are the same as for sharing data with gadgets (given that gadgets can already communicate with their home servers, from a security point of view the same policies should apply to both I think, otherwise you have a security hole in one or the other). 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... On Mon, Mar 31, 2008 at 1:46 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > My only objection to this proposal so far is that it punts everything > over to OAuth on the security and authentication front, and OAuth > doesn't answer any of the interesting security questions. For > example: > > - who (in real life) will the caller of the APIs be? Are these gadget > home servers? Consumers? Somebody else? > > - what permissions are the callers of the APIs intended to have? > > - how will the container know to trust the caller of the APIs? > > - how will keys be distributed? > > - how will keys be changed? > > Good answers to those questions will probably be necessary in order > for these APIs to interoperate across containers. It might be worth > holding up the implementation until we're confident we understand how > security is going to work. > > Cheers, > Brian > > > On Sun, Mar 30, 2008 at 12:32 PM, Louis Ryan <[EMAIL PROTECTED]> wrote: > > +1 Very interested in getting this moving. > > > > > > > > On Tue, Mar 25, 2008 at 2:07 PM, John Panzer <[EMAIL PROTECTED]> wrote: > > > Summary: > > > > > > Do we have a consensus on the broad outlines of the OpenSocial RESTful > API > > proposal? Please reply with +1 if you agree with moving forward with > the > > current spec (https://docs.google.com/Doc?docid=dc43mmng_2g6k9qzfb&hl=en > ) > > while filling in the details as we build up a reference implementation. > I > > hope we can declare consensus by this Friday at the latest. > > > > > > More details: > > > > > > Most people seem to be generally okay with the proposal. While > details > > remain to be hammered out, a lot of these are best addressed in > conjunction > > with creating a reference implementation. David Primmer volunteered on > > shindig-dev to help create a Java reference implementation as part of > the > > Shindig project, and others have expressed an interest as well. I'd > like to > > give them a green light to go ahead on this, and to do that I'd like to > take > > a straw poll of the people on this group to see if we have a consensus > on > > the basic ideas in this proposal. What this means is that you're okay > with > > the overall framework, think it's the right time to start a reference > > implementation, and the only things remaining to be done are details or > > optional parts of the spec. > > > > > > My personal list of current spec issues, from email threads: > > > > > > 1 [EMAIL PROTECTED] Need enum-type field in person example > > Can we get a good example? > > > 2 [EMAIL PROTECTED] Add optional <summary> element in person > to > > provide for feed reader viewing Added a note with a placeholder -- > how > > should a client request such an element? > > > 3 [EMAIL PROTECTED] Does application/json content with no > type > > imply 'text' as in Atom? Yes. > > > 4 [EMAIL PROTECTED] Should escaping of HTML content be part > of > > the JSON format spec (matching Atom) or left to the client (more > JSON-y)? > > Believe this should be escaped as is -- based on security discussion on > > shindig-dev. > > > 5 [EMAIL PROTECTED] How does AppData JSON represent > substucture > > It's turtles all the way down. > > > 6 [EMAIL PROTECTED] XML in content needs to carry JSON type > > information, JSON true/false/null may need special handling Query: > Can > > lack of a type attribute indicate string type? > > > 7 [EMAIL PROTECTED] JSON spec requires double quotes for all > strings, > > spec should adhere to that Agreed, looking for a good find & replace > > utility. > > > 8 [EMAIL PROTECTED] Need a linking structure that doesn't muddy > REST > > semantics for updates -- collection of data of friends of a user is > > immutable, so we need to have implicit or explicit links to an editable > > resource. Agreed, should this be part of discovery? > > > 9 [EMAIL PROTECTED] Need to work on url scheme to make resource > > identification more deterministic; e.g., we can't use 'self' as a group > name > > in /people/{uid}/self vs. /people/{uid}/{groupid} Suggestion: @self? > > > 10 [EMAIL PROTECTED] Use of PUT/DELETE are a non-trivial barrier > to > > adoption for many developers Believe this was addressed in email > > > 11 [EMAIL PROTECTED] Need to at least be able to specify a > > per-container URL prefix (container can pick a "base URL"). Agreed, > added > > a placeholder > > > 12 [EMAIL PROTECTED] Can we provide batching in a JSON-list > manner as > > well? E.g., via a single JSON document, specify multiple operations in > a > > list. If needed, this could be added as an alternative batch format > -- > > the logic stays the same. Would like to get more input on cost/benefit > > ratio of requiring this. > > > 13 [EMAIL PROTECTED] Advise against using URL template rules > for > > discovering collections (see > > http://www.xml.com/pub/a/2005/04/06/restful.html). Forces all requests > to > > go through single domain name. Agreed with the critique, but would > like > > to have more input on the cost/benefit ratio of adding more complicated > > discovery > > > > > > I also welcome co-editors and/or a better way to track and annotate > > issues. We have the existing site, > > http://code.google.com/p/opensocial-resources/issues/list, which could > be > > used to track spec issues, though it's not clear to me exactly how they > > could be easily separated from other issues (there are labels, but those > are > > applied by project owners at triage time, not at input time). Looking > for > > input here. > > > > > > Thanks, > > > John > > > > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ > > You received this message because you are subscribed to the Google > Groups > > "OpenSocial and Gadgets Specification Discussion" group. > > To post to this group, send email to > > [EMAIL PROTECTED] > > To unsubscribe from this group, send email to > > [EMAIL PROTECTED] > > For more options, visit this group at > > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en > > -~----------~----~----~----~------~----~------~--~--- > > > > >
