On Feb 12, 2008 10:06 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > Awesome. Would BT be acting as an OAuth consumer or an OAuth service > provider? >
As an OAuth service provider in the short term - as a consumer as well in the longer term > Interesting proposal. A few comments on the goals, and some questions > on how it would work: > > 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. I don't see this as an attempt to reduce the data storage. I see this as a way to ease the manual management (for those that don't support the extension) to only have to deal with a small number of consumer keys rather than thousands. The data storage will not change in either model: CONSUMER_KEY (igoogle) -- M:M -- XML URL (xyz) -- 1:M -- ACCESS_TOKEN vs: XML URL (xyz) -- 1:1 -- CONSUMER_KEY (represents xyz:igoogle) -- 1:M -- ACCESS_TOKEN In the first there is a many-to-many relationship which will need a resolver in the implementation. question: how should containers decide which gadgets get to use the > consumer key? In the pre-gadget world the container is the consumer. My argument is that in the gadget world the container is still the consumer (else you need to expose consumer keys and consumer secrets to the gadget - and thus they leak). So all (or white-listed and not black-listed) gadgets get to use container's consumer key - but they don't ever see the key or the secret. The longer term goal is to provide the extensions to actually create consumer-keys on the fly that represent a gadget on a container - but I can't see this being supported by all containers just yet... 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?" An out of band process is needed between each container and each service provider - but the numbers and combinations should be small enough to not make this overly onerous? What I would hate to see is the need for a gadget developer to: * pre-register their gadget with a provider to obtain a consumer key/secret * pre-register their gadget with all containers with the consumer key/secret What happens if months down the line a new container starts up, will 10,000s of developers needing to pre-register their gadgets on the new container? How does this help end users who want to use a 3rd party gadget on a container where the developer hasn't pre-registered? Regards Martin -- Internet Related Technologies - http://www.irt.org
