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
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
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
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:
-
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
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
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,
