On Feb 12, 2008 3:35 AM, Martin Webb <[EMAIL PROTECTED]> wrote: > We've been having lots of discussions at BT.com on oauth and its use within > gadgets.
Awesome. Would BT be acting as an OAuth consumer or an OAuth service provider? > 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?). Yeah, this needs to happen, so someone will need to propose an update to the gadget spec to get the ball rolling. If you've got an opinion on how this should look please feel free to draft a proposal. > ...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. I think you've got it exactly. The format of the consumer challenge is opaque to the protocol; it's only interpreted by the consumer software, so it doesn't need to be standardized. My prototype implementation used an encrypted, signed, timestamped blob as the consumer challenge. Part of the encrypted data was the service provider name. This probably needs to be clarified, maybe by including a reference implementation in the (eventual) spec. > 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. Yes, I think it can be useful. I don't have it implemented in SHINDIG-35, but a container could use the callback URL to trigger the process of exchanging the request token for an access token. User interaction could be the trigger as well. <snip proposal for per container keys rather than per container/gadget keys> > Any thoughts on the above? Particularly whether the consumer should > represent the container or the gadget type (which is our longer term > thinking). Interesting proposal. A few comments on the goals, and some questions on how it would work: goal: identify the gadget xml url that is associated with an access token - this seems really useful to me, service providers should know what applications use their services. Service providers could associate this information with the consumer key, perhaps, but it would also be good for containers to forward this to service providers. Maybe as an HTTP header or a URL parameter? I see this as mostly for convenience rather than security, roughly analogous to the HTTP user-agent header. If you want something with security properties the consumer key or the oauth token are better choices. goal: be able to invalidate all access tokens associated with a gadget XML url - this also seems useful, there should be a way for service providers to respond to abusive gadgets or gadgets with security problems that make them unsafe to use. One mechanism would be to search their consumer key database to find the particular gadgets key and revoke it, but if we can make it easier to implement that check we should. goal: manage a much smaller set of consumer keys - only one per container. - this seems less important to me. If you assume that all of your users will have several gadgets that use OAuth, you're still talking about a most an extra few hundred bytes per user. If that extra storage is really unacceptable there are cryptographic tricks you can do to push the storage to the consumer side. For example, you can set the consumer key to be an encrypted version of the consumer secret, so the service provider can always derive the necessary consumer secret directly from the OAuth messages. (The STUN RFC proposes this trick, I believe.) There are some security trade-offs here, so I'd be inclined to just bite the bullet and pay for the extra storage. question: how should containers decide which gadgets get to use the consumer key? question: how will this interact with service providers that haven't implemented these extensions to the OAuth protocol? Will they be able to associate multiple access tokens associated with a single consumer key, or will things break? How will they convey to their users the notion that they aren't just granting authority to a particular container, they are granting authority to a gadget? I'd like to avoid a situation where a service provider asks the user a question like "do you want to grant Orkut permission to view your data?" if a more accurate version of the question would be "do you want to grant gadget X permission to view your data?" Cheers, Brian
