On Feb 7, 2008 12:53 AM, Martin Webb <[EMAIL PROTECTED]> wrote: > * Will oAuth require a dependency/feature, ala: > > <ModulePrefs title="Hello World!"> > <Require feature="oauth" /> > </ModulePrefs>
Probably. I'd love to see proposals for what information should be provided in the gadget spec vs provided in the gadgets.io.makeRequest call. If you look at the oauth.patch attachment to https://issues.apache.org/jira/browse/SHINDIG-35 you'll see that I've hard coded several OAuth values in GadgetStore.java: - the oauth URLs - the 'nickname' the gadget uses to refer to the URLs - the oauth consumer key and consumer secret Key distribution is an open issue. When a gadget wants to use OAuth, it somehow needs to have a consumer key. That key should uniquely identify a particular container/gadget pair. How should the container figure out what key to use for the gadget? One option would be automated registration: a protocol for consumers to automatically register with service providers. The container could automatically drive this registration process. Another, manual option, would be for gadget authors and container administrators collaborate to get the appropriate keys in place. A third option would allow gadget authors to automatically get their OAuth gadget working in containers, without container administrator intervention. When a gadget author wants to enable OAuth for their gadget in a particular container, they would go to that container and add the gadget. The container would detect that an OAuth consumer key was necessary, and would prompt the person adding the gadget to provide the right keys. This somewhat messy key distribution problem could be simplified by having containers register a single consumer key and secret with service providers, so that instead of one consumer key per gadget you would have only one per container. Containers would then need to somehow manage the process of users granting approval to individual gadgets to use the consumer key and secret. I don't like that last solution. It doesn't really simplify the key management problem, it just moves it around. > * Does it mean that *all* widgets on the container will have access to the > data. ie once the user approves a container host, will the container host > naively hand anything over to the user. Hopefully, it will be the user > approving iGoogle+xyz widget, so that iGoogle knows to only hand over data > to xyz. However, I'm not sure how, under normal oauth operations, a consumer > can be called "iGoogle+xyz". Different people have looked at this from different perspectives, but I agree with you that users should approve "iGoogle+xyz" and not just "iGoogle." The container should hold keys on behalf of a particular gadget, and should never share those keys with other gadgets. This should work fine with OAuth service providers. They don't need to know the difference between a normal web application acting as a consumer and a container/gadget pair acting as a consumer. OAuth service providers identify consumers with a consumer key, an opaque string. That opaque string could represent a desktop application, a web based app, or a container/gadget pair. > * Need to see more detail about the consumer keys involved, and also the > mechanism for passing tokens to/from widgets, or perhaps making calls on > behalf of the widget. Maybe the container never gives the token to the > widget, but just accepts a "RESTful Command" object which it transforms into > an OAuth REST call. This would guarantee that the token isn't stolen and the > widget (and its provider) can only make calls while running in the > container? Yes, exactly. The long lived secrets should never leave the container. It's too easy for browsers to leak secrets. Instead the gadget will receive a 'gadget security token' that it can use to request that the container make OAuth calls on behalf of the gadget. Cheers, Brian
