Jonathan Rochkind wrote: [...]
> But if you just want to "publish an OAuth-using client that's not easy 
> to impersonate" -- well, it depends on what you mean. Do you mean you 
> want the server to know that the client application, that is distributed 
> to end-users,  is "The Twitterific Client", in a crypto-secure way?  You 
> indeed can not do that. This is not OAuth's fault, it's the universe's 
> fault.  There is no way to do this absolutely reliably, although the DRM 
> people sure try, and Facebook tried, causing the problems that blogger 
> was complaining about. There's no other solution that will do that 
> either, it's not a unique failing of OAuth, and it's not the problem 
> domain OAuth was trying to solve, mainly.

Mainly?  Why does it include something that even looks like a solution
to a problem that is actually insoluble?

What problem was it trying to solve?  If it was "a process for
end-users to authorize third-party access to their server resources
without sharing their credentials" then I feel a simpler method is
possible, as described below. (Quote from RFC 5849)

> Do you not care about authenticating that the client software is "The 
> Twitterific Client", but you just care about knowing that Joe Smith has 
> authorized it (whatever it is) to access Joe Smith's twitter account?  
> Ah, now THAT is indeed the use case of OAuth. The first one was not the 
> use case of OAuth, and Facebook trying to use OAuth anyway to accomplish 
> it is what causes the problems.

What is the use case?  http://oauth.net/core/1.0a/ claimed "OAuth
creates a freely-implementable and generic methodology for API
authentication."  Shouldn't we expect generic authentication to
include authenticating both peers?

I feel that OAuth has tried to be jack of all trades.

> How do you do this?  By, as mentioned in the blog post you cited, 
> following the OAuth specs recommendations, unlike Twitter:
> 
> "In many applications, the Consumer application will be under the 
> control of potentially untrusted parties. For example, if the Consumer 
> is a freely available desktop application, an attacker may be able to 
> download a copy for analysis. In such cases, attackers will be able to 
> recover the Consumer Secret used to authenticate the Consumer to the 
> Service Provider. Accordingly, Service Providers should not use the 
> Consumer Secret alone to verify the identity of the Consumer." [right 
> from the OAuth spec; that Twitter may have ignored this is not OAuth's 
> fault].

I think we're rehashing what's written in links already posted, but
that section continues "Where possible, other factors such as IP
address should be used as well" which seems somewhat inadequate
as an authentication component.

The specs don't really give any positive direction on how to handle
published Consumer applications, so I feel it's not surprising that
Twitter and others filled the vacuum with silliness.

> Yes, to do this, OAuth requires one of two workflows, neither ideal:
> 1) Redirect to Twitter where the user logs in, and is then redirected 
> back [...]
> 2) Have the user enter their twitter login/password directly in client 
> application, which then sends it on to twitter. [...]
> Not ideal, true. But no other solution is going to do better, because 
> that's just how the universe works, unless some genius can come up with 
> something nobody's thought of yet. 

The authentication workflow isn't the problem.  It's this consumer
secret nonsense.  I've been pointed at Yahoo's CCK which looks like
an API to work around this problem with OAuth:
http://developer.yahoo.com/oauth/guide/create-consumer-key-guide.html

But what's wrong with the idea of a CCK-like way of creating a
subsidiary username with limited privileges and communicating that
back to the app for use?  The authentication workflow can even be the
same.

In other words, apart from this consumer secret confusion, what does
OAuth add to this field which wasn't already there with HTTPS
authentication and cookies?

Confused,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for Koha work http://www.software.coop/products/koha