Phil,
> It is useful for the resource authorization policy server to know what client > is acting on behalf of what user. E.g. if a financial aggregator was using > OAuth to access a bank, the bank systems can differentiate rights between > normal end-user access and a client app access (e.g. read-only regardless of > scope). I know scope already covers some of this, but it seems like an > important distinction if for some reason a policy server needs to apply > additional rules for clients beyond those of scope. It certainly makes sense for a bank "protected resource" to be able to distinguish requests from (1) a financial aggregator app acting on a user's behalf, and (2) requests from the user. But the bank gets that by arranging with the authorization server (also the bank) to issue tokens that distinguish those cases. Eg user-ids are 16-digit credit card numbers; tokens issued to client apps start with "DELEGATE_...". The client app need not care how the bank does this. It does not need the OAuth2 framework to specify an explicit client_id parameter to include in those requests. -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
