The MAC scheme's cookie mode [draft-ietf-oauth-v2-http-mac-00, section 6] says the cookie's creation-time is used to determine the age that goes in the nonce in a request. The creation-time is the time the client receives the Set-Cookie response - unless the client already has a cookie with the same name, domain, and path, in which case the creation-time of the existing cookie is kept [rfc6265 HTTP state management mechanism, section 5.3, step 11.3].
Is this going to cause complications in practice? A server will need to know if a client has an existing cookie before issuing a new one. That should be possible as the old cookie will be included in the request whose response contains the Set-Cookie header for the new cookie. There are some corner cases, such as an old cookie that expires after being sent to the server, but before the new cookie is returned. Perhaps they are rare enough to ignore. If a server crashes then reboots (loosing in-memory details about old cookies) it cannot just issue new cookies. First it needs to issue an expired cookie to clear the client's cookie store (deleting the old cookie that has a creation-time that the server no longer knows), then issue a new cookie with a known creation-time. That sounds painful (ie will not be implemented initially, but will eventually cause a nasty outage). It might encourage people to tack the creation-time into the cookie-value. Do that without integrity protection, however, and you are open to replay attacks. -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
