That is, to take another tack at this that might make it more clear:

The fact that Software Instance A is authorized to do something on 
Server B is _not_ baked in at compile time to Software A. That is not 
OAuth's security model, in part because it is not a feasible security 
model, nobody has yet figured out a way to do that.

Instead, the fact that Software Instance A is authorized to do something 
on Server B is, neccesarily, in OAuth's model, determined at run time 
with the interaction of a user.  Once the user does this interaction, 
Software Instance A can keep a security token around that will let it 
keep doing that Something on Server B for a Very Long Time, until the 
token expires.  But that initial authorization requires user interaction 
at run-time.  That is OAuth's security model. 

OAuth's security model does not require each piece of client software to 
have a baked-in key of any kind.  OAuth does require that there be a 
user who has a secret (ie, a login/password) on the foreign server, and 
that the user be asked for that secret and enter it (usually directly on 
the foreign server, Shibboleth-style) before the first time the software 
instance accesses the protected functionality.

Jonathan

Jonathan Rochkind wrote:
> MJ Ray wrote:
>   
>> 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?
>>   
>>     
> OAuth, as I understand it,  is about confirming that (eg) Jonathan 
> Rochkind has given authorization to Software A, to access API services 
> that read and write to confidential information associated with Jonathan 
> Rochkind's account on Server B.   Server B can be sure that Jonathan 
> Rochkind authorized Software A to do that.  (Or someone that knew 
> Jonathan Rochkind's secret password did, anyway). And additionally can 
> let Jonathan Rochkind specify to Server B exactly _which_ services he'd 
> like to authorize Software A to use, not just all or nothing.  Which 
> happens to be the problem case that ILS api stuff finds itself dealing 
> with.
>
> I am fairly certain there is _no_ protocol that will allow you to 
> securely prove that a piece of software on the network is really a 
> trusted _copy_ of software, when copies of that software are distributed 
> to untrusted users.  It is not a solvable problem. I guess if OAuth 
> documentation implies they solve it, you can fault them for implying it, 
> but you can't fault them for not doing it. I am positive you will be 
> able to find no protocol anywhere that does that.  If you need that, 
> then OAuth will work as well as anything else you can find -- that is, 
> it won't work, and neither will anything else.
>
> Jonathan
>
>