Brian, We've been having lots of discussions at BT.com on oauth and its use within gadgets.
We believe the Gadget server needs to support a feature (or two) to allow the gadget to make use of container services to negotiate the request token and access token. Assuming that the widget has responsibility for redirecting the user to the service provider for the authorisation. (This last point maybe debatable - it could be that the container page trips the authorise step/pop-up - I can't remember how the patch to SHINDIG-35 works - its applied on another machine). We think that the gadget also needs to provide (either directly or indirectly) the details of the request, authorise and access end-points. Either as extra gadget configuration or a pointer to an external service provider definition (in XML?). We are strongly in favour of your extension that allows for consumers (i.e. containers) to self negotiate a consumer key (by providing a consumer secret - that passes certain length/content rules) - as described at http://groups.google.com/group/oauth-extensions/t/bdd87bc7de25867c. We don't think this needs to be part of the oauth spec - as some containers may wish to do this out of band - but for those containers and providers that do support this then maybe an additional feature (the 2nd one) is required. Minor comment on your extension: <quote> - the service provider name in the consumer challenge matches the service provider name sent by the service provider. (This is done to prevent a malicious service provider from acting as a MITM by relaying the challenge to another service provider) </quote> ...However, when you describe the format of the consumer challenge it doesn't mention the service provider name, we do note however that the format of the consumer challenge is up-to the consumer. Having trouble understanding if the optional callback url within the oauth spec can actually be of use within a container. Would be interested in your thoughts. We think the longer-term goal is for a consumer key to be generated for every gadget definition added to a particular container (at the point it is added - either by a gadget developer or user or admin role) - using your proposed extension to manage the automatic distribution of the consumer key - by essentially using oauth as intended. However this is likely to generate 10s of thousands of consumer keys (i.e. 10 containers x 1000s of gadget XMLs requiring oauth), as opposed to the following which we believe is a shorter term alternative more likey to acceptable to the community... The gadget triggers the oauth dance, via the container page - the container page passes the gadget's XML url (or id or whatever), along with service provider endpoints back to the container (or the container retrieves the gadget XML url and endpoints from the id - gadget token? - passed by the container page). The container looks for an existing consumer key for the service provider endpoint - if one is not found then the container initiates your extension to generate a consumer key for the service provide endpoint. This is only done once per service provider endpoint. If the consumer keys exists for the service provider endpoint, then the oauth dance is performed by the container and the resultant access token along with the gadget XML url is stored against the consumer key. Additionally the container passes the gadget XML url to the service provider as part of the request process - section 6.1.1 of the oauth sepc allows for this. This allows service providers to: * manage a much smaller set of consumer keys - only one per container. * identify the gadget xml url that is associated with an access token * invalidate all access tokens associated with a gadget XML url This means that the consumer key does not need to be invalidated at any time, unless the container itself has gone bad. The entity model on the service provider looks somewhat like: CONSUMER_KEY -- M:M -- XML URL -- 1:M -- ACCESS_TOKEN This also allows the service provide to optionally get and cache the gadget's XML independently of the container/gadget server. Any thoughts on the above? Particularly whether the consumer should represent the container or the gadget type (which is our longer term thinking). Regards Martin & Jeremy On Feb 7, 2008 5:53 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > 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 > -- Internet Related Technologies - http://www.irt.org
