On Wed, Jun 8, 2011 at 11:30 PM, Adam Barth <[email protected]> wrote: > > Maybe I'm not completely clear how a mechanism with a server-supplied > nonce would work. How do you avoid having to make a round-trip to the > server for every request?
Maybe I'm confused about the expected flow here. It's not clear to me where the initial credentials are coming from, or how much the server knows about the MAC credentials. The specification has multiple servers (resource servers and authorization servers) in play sometimes, but other times it refers to "the server". Also, section 4 makes it seem like quite a lot coordination is expected between the authorization server and the resource server. This might all be obvious to someone who lives and breathes OAuth, but I think it is worth clarifying. Here's what I was thinking: The example in section 1.1 includes an initial 401 response. If that initial 401 response is expected, then the server can include some domain-wide data in the WWW-Authenticate header, and refresh it at will, even in successful responses. GET /resource/1 HTTP/1.1 Host: example.com ... HTTP/1.1 401 Unauthorized WWW-Authenticate: MAC opaque="abc123abc123" ... GET /resource/1 HTTP/1.1 Host: example.com Authorization: MAC ... opaque="abc123abc123" ... HTTP/1.1 200 OK WWW-Authenticate: MAC opaque="def456def456" ... GET /resource/2 HTTP/1.1 Host: example.com Authorization: MAC ... opaque="def456def456" That opaque string can be anything the server wants, and it can change with every request, or less often. Adding this field could help servers even if it doesn't , in cases where a misbehaving client is getting the client nonce wrong. If the goal of the scheme is to avoid encountering a 401 even for the initial request, then I suggest updating the example in section 1.1. >> >> That makes sense. I'm having trouble reconciling the Design >> Constraints section (1.1) with the section on Entropy of MAC Keys >> (7.5). How long are these keys supposed to be around in practice? > > I'd recommend using a MAC key of roughly the same length as the block > size of the MAC. For example, for hmac-sha-1, I'd use 20 bytes. > I was asking about how often keys might expire. Section 7.5 says something like 2 weeks. What can we reasonably expect from the use cases we have in mind? - Rob _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
