Igor, >> .... Adding client_id here is unnecessary (the server can include it >> in the token if it is convenient for protected resources), and harmful >> (it means the protocol that uses the credentials from the token >> response cannot look like a normal authentication protocol).
> Could you please clarify the last point (i.e., "cannot look like a > normal authentication protocol")? I simply don't understand what you mean. Perhaps an example would help. Consider a server (of protected resources) that authenticates requests using the HTTP DIGEST scheme (or substitute any other request signing scheme that is not OAuth-specific). If it wants, the server can authenticate requests directly from users: by returning WWW-Auth: DIGEST... to trigger the browser to prompt the user for their password. To support delegated access (requests from a client app on a user's behalf) the server tells the client app to orchestrate an OAuth2 flow. The client app ends up with a token response that contains credentials to use with the HTTP DIGEST scheme (ie a user-id/password pair that represents this delegation). The client app now makes requests on the user's behalf to the server using "normal" HTTP DIGEST. On the wire, these requests are totally standard HTTP DIGEST authentication requests (so they can use totally standard implementations and APIs). There is no extra client_id field in the HTTP DIGEST scheme. It does take an id, but in this context that is the id of the delegation (client app X acting for user Y). DIGEST assumes a model with two parties that shared a secret -- it simply has no use for the extra concept of a third party, and neither will any other "normal" authentication protocol. I believe the SASL model is a bit more sophisticated. It includes 2 ids: an authentication_id and an authorization_id. But neither of those would correspond to client_id. The authorization_id could be a bearer token (when there is no authentication_id); or the authentication_id could be the id from a token response that had a secret key (and the authorization_id could be the user-id). If the OAuth framework spec forced an explicit client_id parameter into requests for protected resources it would be unusable with HTTP DIGEST (and every other authentication scheme, past and future, that is not OAuth-specific). Is my meaning any clearer now? -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
