On Feb 13, 2011, at 6:57 PM, Eran Hammer-Lahav wrote:
> 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.
Yes, it's not clear that item 9 should be an empty string (followed by of
On 2/13/11 9:57 AM, Eran Hammer-Lahav wrote:
> 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.
This section is going to trip people up. Not much that can be done about
it, other t
Hey Toby,
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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:
>
> Authorizat
I think you're reading the section differently from me. My reading is
that the Normalized Request String is composed of each of the itemized
elements, with newlines appended to them, concatenated together.
"ITEM_1\nITEM_2\n[...]ITEM_8\nITEM_9\n"
My reading is that none of the items - per se - end
I think it's meant to be there. If you look at Signature Base String
construction, item 9 is a normal "line item" just like all others and should
have a newline at the end. So you can think of it as the params as one sting w/
newline between followed by a newline. In the example, it looks like e
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 signa
