On Feb 7, 2008 12:53 AM, Martin Webb <[EMAIL PROTECTED]> wrote: > On Feb 5, 2008 11:14 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > On Feb 5, 2008 12:21 PM, Reinoud Elhorst <[EMAIL PROTECTED]> wrote: > > > So I'm wondering what the mystery AUTHENTICATED method should do (it > > looks > > > like SHINDIG-35 implements it, still English might be easier to get > the > > big > > > picture), and what the goal of this method is (what extra > authentication > > > would it provide)? > > > > Glad you asked. AUTHENTICATED is for implementing the full OAuth > > protocol flow. Check out http://oauth.net for the gory details, but > > here's the basic idea: a user has two accounts on two different sites. > > One of them is a gadget container. The other site (which we'll call > > the service provider) has some of the user's personal data. The user > > would like to display some of their data from the service provider on > > the gadget container site. > > > Brian, > > Myself and a few others for the company (BT.com) I work for are following > this topic with interest. I've pointed them at your proposal for > automated consumer registration. A couple of questions: > > * Will oAuth require a dependency/feature, ala: > > <ModulePrefs title="Hello World!"> > <Require feature="oauth" /> > </ModulePrefs> > > * 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".
Because of the same origin policy, the gadget data requests have to go through the container. So it will effectively be the container that's granted the OAuth rights. I would expect containers as good policy to only share OAuth access with the gadgets that have received it. Though technically the container could share it with other gadgets, this would be very bad behaviour. * 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? I'll let other people fill in the details here. As for having the token stolen, that is a legitimate concern. We should keep it out of urls and in the header + similar related work to make it harder to leak. The main point about a token is that it can be revoked, unlike a username / password. So if the token is revoked or passes it's expiration date, the token becomes useless at that point, though it could have been used previously. Regards > Martin > > -- > Internet Related Technologies - http://www.irt.org >
