[oauth] To enable a provider to access consumer's resources
OAuth enables consumers to access providers' resources, but providers can't access consumers' resources reversely. We can think of scenario that a provider requests consumer's resources even though it is not mentioned in the spec. That enables reciprocal access. Do you think extending the spect for the scenario is reasonable and secure? Regards, --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[oauth] ftp, ssh, scp and the like
Any thoughts on how oauth could work for various command-line tools that today usually need a username and password? Perhaps even the mysql client? Or even better, anybody working on this? Johannes Ernst NetMesh Inc. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- inline: lid.gif inline: openid.gif http://netmesh.info/jernst
[oauth] Re: ftp, ssh, scp and the like
Hi Johannes How would you incorporate the user assent into the flow of these tools? Seems it would be... congruent to the usage? If you actualize authorization assent outside the authentication phase, then any tool accessing a resource would be able to participate as long as the provider identifies the accessor and also verifies the accessor's rights to the specific operation on the specific resource. Oh, that sounds complicated, but really isn't. I presented more about this at the IIW See more http://nocrypto.com/wiki/index.php/Authorization Hans On Thu, May 28, 2009 at 11:18 AM, Johannes Ernst jernst+google@netmesh.us wrote: Any thoughts on how oauth could work for various command-line tools that today usually need a username and password? Perhaps even the mysql client? Or even better, anybody working on this? Johannes Ernst NetMesh Inc. http://netmesh.info/jernst --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[oauth] Re: ftp, ssh, scp and the like
On Thu, May 28, 2009 at 11:18 AM, Johannes Ernst jernst+google@netmesh.us wrote: Any thoughts on how oauth could work for various command-line tools that today usually need a username and password? Perhaps even the mysql client? Or even better, anybody working on this? Yep: - http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps - http://sites.google.com/site/oauthgoog/oauth-practices/auto-detecting-approval The MySQL case is harder because OAuth assumes HTTP requests. I know some folks were thinking about XMPP+OAuth, anybody know what the conclusions were? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[oauth] Re: ftp, ssh, scp and the like
The MySQL case is harder because OAuth assumes HTTP requests. I know some folks were thinking about XMPP+OAuth, anybody know what the conclusions were? Yup, we cleaned up XEP-0235 (http://xmpp.org/extensions/xep-0235.html) and it's in use within Fire Eagle. The OAuth library for Ruby (http://github.com/mojodna/oauth, `gem install oauth`) includes a command-line application that will generate signatures, HTTP headers, and XMPP stanzas in order to ease development (as well as providing a way to initiate the authorization flow). Switchboard (http://github.com/mojodna/switchboard), my command-line tool for interacting with XMPP servers, supports OAuth-signed requests as well. The upshot (relevant for anything w/ a username/password combo) is that we can re-use the existing authorization flow (over HTTP) to obtain access tokens. Once tokens have been obtained, it's up to the application / protocol in question to define a means of using them. At its most basic, that could mean using access tokens / secrets as alternatives to usernames and passwords, but it could also mean defining a protocol-specific signing mechanism (as XEP-0235 does). seth --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[oauth] Re: Improved User Experience for Installed Applications using OAuth
Nathan Beach wrote: Google has enhanced our OAuth approval flow to significantly improve the user experience for installed applications that use OAuth to access our GData APIs. Perhaps I'm missing something, but doesn't this kinda saw one of the legs off of OAuth? This approach basically is: Everyone gets in using the same key, we'll do our best to keep users from using your app, but if they do, you'll be able to get their info. We may be the off case, but we're actually kind of interested in using the two legged approach so that we can validate developers and grant some customers adjusted rates. What this approach says is There's no way to secure the first leg of OAuth, so we're going to ignore that. Frankly, it kind of makes me wonder why bother using OAuth at all? Couldn't you simply create a new auth protocol where an app uses https to connect and authorize and then stores a returned token set you can use to validate future requests? It may just be that there are certain environments that one can't do OAuth. I'd rather that folks use a different auth mechanism for those than further confuse the standard. I really don't want to be a protocol dork here, but this sets off a good many paranoid bells in my head. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[oauth] Re: Including the signature base string in signature_invalid errors
That sounds like a fine idea, to me. I'd prefer that the server send the information without being asked. We might as well follow established practice, if it works well. What does the Python library do, exactly? Are there popular service providers that do something similar? What do they do, exactly? By the way, what service providers have implemented the problem reporting extension? http://wiki.oauth.net/ProblemReporting On May 27, 12:59 am, Manish Pandit pandit.man...@gmail.com wrote: Do you folks think it is a good idea to include the base string/ normalized request parameters, etc. in the signature check failure error message? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
