I can implement all the features describes in the OAUTH-MAC draft in my scheme but I don't think the reverse is true.
The idea here is that we take out the session continuation component and make it a single common feature that OAUTH, OpenID, SAML and Web Services authentication schemes can all share so that we have one way to do it for all HTTP schemes. Designing in the context of OAUTH only leads to a scheme that is difficult to then apply as a generic. There are two problems to be addressed in a session continuation mechanism, one is which parts of the message (if any) should be covered by the authentication mechanism and second how to prevent replay attacks. Which choices you take are going to depend on which particular authentication problem to solve. If what we are trying to do here is to simply replace bearer token cookies with something less disastrous then we are not going to want to have any authentication binding to the content at all so that we avoid the problem of intermediaries raised by Hannes etc. We are going to be concerned about replay attacks though and probably want to ensure that the solution is stateless at the server. If what we are doing is looking to replace the SOAP/WS-Security stack then we are going to want a MAC over the message contents and probably the request URI as well. Replay attack might not be a concern then because we might prefer to do that in the application layer or if we do it in the HTTP layer we probably don't care much about the overhead of per connection state.
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
