Allen Tom wrote: > > We believe that it is impossible to safeguard any secrets embedded in > downloadable client applications. Someone with a debugger and some > patience will be able to extract the secrets very quickly. Likewise, any > secret protocol between a downloadable client and a server can also be > easily reverse engineered. Therefore, it's impossible to securely > identify a client application, and a downloadable client application's > consumer key (even when signed with its consumer secret) is about as > meaningful as your browser's HTTP User-Agent string. >
With that in mind, it seems like requiring preregistration of desktop clients is providing no value whatsoever and is just an unnecessary barrier to creating an app. It would be interesting to figure out how a User-Agent-like mechanism can be added to OAuth so that clients can say who they are in a browser-like way without having to pre-register. I would expect SPs to treat such unregistered callers the way they treat registered desktop clients today. This may include, for example, not allowing the app to renew its access token without going through the interactive user approval flow a second time. This unregistered mode would also be useful for OpenID-style web-based interactions where there's no pre-existing business relationship, as long as the web app is willing to accept the limitations of being an unregistered consumer. The app may wish to register for certain big providers to get added value in the common cases, but can do ad-hoc authorization against lesser-known or self-hosted SPs. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
