Subject: [OAUTH-WG] Queries on draft-hammer-oauth-v2-mac-token-02

From: Toby White <[email-masked]>
Date: Sun, 13 Feb 2011 01:57:09 +0000

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

---

From: Skylar Woodward <[email-masked]>
Date: Sun, 13 Feb 2011 13:10:04 +0100

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 each param is followed by a newline which is not exactly how the spec words it, but it's the same result.

For me, ending the params with a newline results in the same signature values as the spec.

What might be unclear is if there should be an empty newline if the query string is empty.  Eran?

---

From: Toby White <[email-masked]>
Date: Sun, 13 Feb 2011 14:02:15 +0000

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 with a \n. From
the list, item 1 is "The access token", not "The access token followed
by a newline." So, by analogy, I read Section 3.3.1.1 as telling me
how to construct the string ITEM_9 - not telling me how to construct
the string "ITEM_9\n".

I think you're reading the spec as saying that the NormalizedRequestString is
"ITEM_1ITEM_2[...]ITEM_8ITEM_9

so that the trailing '\n's are part of the ITEMs. But I can't square
that with the description of the items in the list using the text
currently there.

For what it's worth, I'm not being pernickety for no reason - I came
across this because I wrote a bunch of tests for my
parameter-normalization function, based on reading the description of
the algorithm, and then found this issue only because pasting the
example from the spec into my testsuite caused it to fail, due to the
extra trailing newline.

Toby

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 13 Feb 2011 10:57:50 -0700

Hey Toby,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Toby White
> Sent: Saturday, February 12, 2011 5:57 PM

> 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.
 
> 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.

> 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

---

From: Rasmus Lerdorf <[email-masked]>
Date: Sun, 13 Feb 2011 10:47:47 -0800

> 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 than being really explicit, and I think it might help slightly
if you provide the actual signature produced by the example in section
3.3.1.  I can see people leaving in the trailing newline in 3.3.1.1 and
then adding another newline when add the request string to the signature
string.

Also, section 3.3.3 should say "hmac-sha-256" at the beginning there.

-Rasmus

---

From: Skylar Woodward <[email-masked]>
Date: Sun, 13 Feb 2011 20:13:12 +0100

> 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 course, a new-line) if the query string is empty. That would be a helpful point to add to 3.3.1.1 as you did in 3.3.1, item #4.

+1 to removing the last new-line in 3.3.1.1 (Toby and I resolved our confusion), and to the suggestion of adding a sample signature to 3.3.1

---

From: William Mills <[email-masked]>
Date: Mon, 14 Feb 2011 08:41:44 -0800

> the
> 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

Perhaps an explicit example would help make it lear?

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 15 Feb 2011 12:41:35 +1100

In my mind, the simplest normalized request string has one line for each name=value query parameter. If there are no parameters, there are no lines. The confusion in the current text seems due to some new line chars coming from section 3.3.1 and others from 3.3.1.1. It would be better for latter to return a sorted array of name=value strings, and the former to output them one pair per line.

My suggested text:

3.3.1. Normalized Request String
...
  9. Each query parameter from the HTTP request URI
     (each on its own line name=value\n),
     after being normalized and sorted
     as described in section 3.3.1.1

3.3.1.1. Parameters Normalization
...
[drop step 4 "...sorted parameters are concatenated..."
...
[drop the last 2 paragraphs, after the "Sorted" table.
This part of the example is already repeated at the
end of section 3.3.1. anyway.]

--
James Manger