Hey Toby, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Toby White > Sent: Saturday, February 12, 2011 5:57 PM
> * Can the timestamp parameter have leading zeroes? ie, would an > authorization header be valid which read: > > Authorization: MAC [...] timestamp="0001297561419" [...] > > (assuming the same timestamp string was used for the signature.) > > The spec doesn't forbid it, and indeed there's no obvious reason to except > that it's a thing that could be normalized and isn't. It must not. I'll make this explicit. The reason being is that this is a numerical value and is likely to be parsed out of the header first as a number, and then added to the string. > > * Does the order of parameters in the authorization header matter? > > ie - must the parameters always appear in the order token / timestamp / > nonce / (bodyhash) / signature? or is a request valid if the signature is > correct > but the parameters are in a different order? Order does not matter. Only their order in the normalized string does. > * I think there's an error in the parameters normalization example. > > The final output of the normalization algorithm at the end of 3.3.1.1 is given > as: > > a2=r%20b\n > a3=2%20q\n > a3=a\n > b5=%3D%253D\n > c%40=\n > c2=\n > > but I don't think the final newline should be there. By my reading of the > description of the algorithm, there's no reason for the final newline to be > appended - and if it should be appended, then the Normalized Request > String example at the end of 3.3.1 ought to end with *two* newlines, since > each of the HTTP request elements should be followed by a newline > character. Each of the 9 items is new-line terminated, even if empty. In 3.3.1.1, the new-line is a separator so that part does not end with a new-line. I'll clarify this. EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
