It seems that OAuth 1.0 was designed with both web and installed desktop apps in mind. Great work. However, I've yet to see a single Service Provider write a friendly way for installed apps to work. Consider this...
Any app that installs onto a customer's machine cannot carry with it any secret or X.509 private key from the software publisher, as that would compromise the secret. But it would be a simple matter for the installer of that application to generate a new X.509 certificate and send that to the Service Provider to establish a new consumer_key for this machine+application combination. So basically a Service Provider with a programmatic interface for registering new OAuth consumers, that preferably does not require a user account on that SP to sponsor the consumer as Google and Twitter currently do, would satisfy the requirement. But even if a user had to sponsor the consumer registration, that's fine too. Imagine this: As a user, I install Google Picasa, an OAuth Consumer-enabled client application. During install, Picasa registers itself with Google's OAuth SP and gets a consumer_key and consumer_secret assigned to it, which Picasa stores in an encrypted file on disk. During that process a browser may have popped up asking me to log into Google to sponsor the registration. Now anyone using Picasa on my computer can access PicasaWeb and publish their photos without Picasa asking them for their username/password since it can use the standard OAuth flow of popping up a browser allowing whoever is using my computer at the time to log into Google and authorize Picasa to publish photos. Finally, if my computer were ever stolen, I could log into Google and delete the consumer_key that Picasa on that computer had created, thereby invalidating all access tokens Picasa may have acquired from users of that computer. If Picasa had been able to register as a consumer with Google without me sponsoring that registration, then invalidating access tokens in the event of a stolen computer would be an individual process of revoking each token. But the story today is quite poor. No programmatic interface for registering a consumer (that I know of), and having the user log into Google while installing Picasa would be confusing to the user, I think, and shouldn't be a necessary step. Thoughts? This isn't a Google feature request as much as a request that the OAuth community, perhaps a future spec, push for SPs to add this feature generally, so that consumer desktop apps can benefit from OAuth the same way web apps can. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
