Some queries arising, having been working through a trial implementation:
* 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.
* 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?
* 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.
--
http://timetric.com
2nd Floor, White Bear Yard, 144a Clerkenwell Road, London EC1R 5DF
phone: +44 20 3286 0677 (office), +44 7747 603618 (mobile)
twitter: @timetric, @tow21 | skype: tobyohwhite
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
