Eran, >> 13. The MAC algorithm should be explicitly indicated in the request, instead >> of being implied by the access-token/id. I suggest including an "algorithm" >> parameter in the "Authorization" request header. I also suggest including an >> "algorithms" parameter in the "WWW-Authenticate" response header that is >> a (comma-separated?) list of MAC algorithms that the server supports.
> Why? The client does not get a choice which algorithm to use. There is no > negotiation here. Pretty much every standardised crypto message indicates the algorithm used to protect it in the message itself. Why be different? Consider hashing the body. You don't need the secret key to do this, but you do need to know the hash algorithm. With an algorithm parameter, a front-end web server can use that to confirm the body-hash parameter is correct before passing the message to a middle tier where the secret key is available to verify the MAC. An algorithm parameter offers some ability to migrate to stronger MAC algorithms if, say, (more) weaknesses in SHA-1 are found. Without it you need to issue new credentials to migrate. If you have a environment of heterogeneous servers (legacy, new, vendor A, vendor B...) they might support different algorithms, but it would handy if clients could use a single credential. Secret keys are generally handled separately in software than support for crypto algorithms. For instance, you can store a secret key in a Java Key Store, but I don't think there is an associated spot to specify a MAC algorithm. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
