Specify the Date requirements further

[nickveenhof]

Date field should be more specific. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html. If Date is not supplied, it should not be replaced by a custom header, only the time-sensitive validation should be able to read from both.

[cpliakas]

Thanks for the pull request. It seems there are two issues that the pull request is trying to tackle: Enforcing the Date header as the only source of the timestamp and enforce a 15 minute time threshold. I am not 100% clear if I have a good handle on the first point, so please correct me if I am misunderstanding it.

Regarding enforcing the Date header, based on how I read the request I do not agree that we should enforce a date header for the following reasons:

1. In the rfc2616 spec that was referenced in the OP, it states that "Clients SHOULD only send a Date header field in messages that include an entity-body, as in the case of the PUT and POST requests, and even then it is optional." The spec doesn't force a Date header and actually discourages its use use in some cases, therefore we would not be following the spec by enforcing the Date header.
2. According the to links below, some HTTP client libraries do not support setting the Date header. Therefore he onus is on us to disprove this before changing strategies.
   • http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#RESTAuthenticationTimeStamp
   • https://github.com/Asquera/warden-hmac-authentication#date-and-ttl

Regarding enforcing a threshold, I do not think that this spec should enforce a threshold. That should be the implementors decision since we have no idea what our implementors' requirements are. If the companies / people using this spec reach consensus that a 15 minute (or other) threshold is a good idea then we should revisit it, but until we have that information we shouldn't assume that this will work for everyone.

[nickveenhof]

To be clear, I am not voting to force to set a Date header, the only clarification I want to make is that the custom header could be used in the implementation for time-attack prevention. Not having the Date header is perfectly fine (as the spec says). But it is not related to the x-acquia-timestamp header at all.

I am also not forcing the spec to state that a threshold has to be enforced. But perhaps that needs to be clarified. The only enforcement I want to push through here is that we need to state that the Date header needs to be conform the RFC 1123 norm.

[cpliakas]

Ah, thanks for clarifying. I am in agreement with everything you propose, then.

[nickveenhof]

The implementation of this specification "change" can be seen here: https://github.com/acquia/project-dice/blob/master/doc/auth.md

I'll try to reword it

[pwolanin]

I'm writing a v 2.0 implementation for hackathon projects

Is there a reason the ruby one is a private repo? On May 20, 2015 9:51 AM, "Nick Veenhof" notifications@github.com wrote:

The implementation of this specification "change" can be seen here: https://github.com/acquia/project-dice/blob/master/doc/auth.md

I'll try to reword it

— Reply to this email directly or view it on GitHub https://github.com/acquia/http-hmac-spec/pull/2#issuecomment-103894941.

[cpliakas]

@pwolanin No particular reason, but it would be nice to bake it further before making it public like this repo. Definitely no reason not to develop in the open other than potentially frustrating early adopters when the internals change around.

[nickveenhof]

I think this can be closed?