Subject: [OAUTH-WG] draft-hammer-oauth-08.txt

From: Olivier MIEL <[email-masked]>
Date: Fri, 18 Dec 2009 11:46:36 +0100

Hi all, sorry to intrude,

I'm currently implementing OAuth 1.0a on my own
(http://code.google.com/p/pledge-oauth/), using the last (to this day)
draft of the upcoming RFC as a basis and I may have some issues with
it:

1> (http://tools.ietf.org/html/draft-hammer-oauth-08#section-3.4.1.2)
The draft-02 included a requirement to normalize empty paths as "/"
(http://tools.ietf.org/html/draft-hammer-oauth-02#section-3.3.1.3)
when computing the signature base string ; the current draft does not
explicitly, but the fact is still mentioned in the version notes
appendix (http://tools.ietf.org/html/draft-hammer-oauth-08#page-39).

It seems to have been dropped in draft-04, when the example switched
from using URL to proper HTTP requests
(http://tools.ietf.org/html/draft-hammer-oauth-04#page-17).

Some implementations - most of those I reviewed* - still support this
some way or another (out of RFC 2616 section 3.2.2 conformity). Is it
still an implicit requirement ? (I'm assuming it is)

2> (http://tools.ietf.org/html/draft-hammer-oauth-08#section-3.4.1.3.1)
Shouldn't the OAuth parameters be collected from one source only ?
There is an ambiguity : it is explicitly required that client send
their parameters either in the 'Authorization' header, in the query or
in the body of the request and in only one of those only, but there is
no matching requirement on the server side.

It could be interpreted as some leniency on the server side of the
implementation ; or maybe it's a wild assumption on my part ? (I'm
assuming it's the same on the server side)

3> The specification (section 2.) prohibits "oauth_" parameters in
end-point URLs but do not (explicitly) in call-backs. Is it implicit ?
(I'm assuming it is)

Those last two are more nitpicking on my part (I include them just to
be consistent with the list of I had prepared :) )

+> (http://tools.ietf.org/html/draft-hammer-oauth-04#section-4.4.2)
HMAC-SHA1 specifies how to encode bytes, not strings ; there is no
mention of what encoding should be used to decode the key and
signature base string into bytes ; of course, the percent-encoding
turned everything into proper ASCII characters, so ASCII and UTF-8 are
equivalent ; just nitpickin'.

+> Stale timestamps : it is not specify whether this case should be a
'bad request' or an 'unauthorized' kind of error (I'm assuming the
former).

Thank you in advance for your comments. I don't have much experience
with standardization efforts ; I pray my ramblings can be of some use.
I'll continue to review the specification along my implementation
effort. I hope I can be of help in fixing some ambiguities.

Olivier MIEL.

* namely: googlecode OAuth java
(http://oauth.googlecode.com/svn/code/java/), signpost
(http://code.google.com/p/oauth-signpost/), asemantics-oauth
(http://code.google.com/p/asmx-oauth/), spring-security-oauth
(http://spring-security-oauth.codehaus.org/) and the OAuth bits in the
GData java client library.

N.B. : (about 1>) what about OPTIONS "*" requests ? Maybe the server
hosting protected resources shouldn't be considered a protected
resource itself.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 18 Dec 2009 10:25:04 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Olivier MIEL
> Sent: Friday, December 18, 2009 2:47 AM
> To: [email-masked]
> Subject: [OAUTH-WG] draft-hammer-oauth-08.txt
> 
> (http://code.google.com/p/pledge-oauth/), using the last (to this day) draft
> of the upcoming RFC as a basis and I may have some issues with
> it:
> 
> explicitly, but the fact is still mentioned in the version notes appendix
> (http://tools.ietf.org/html/draft-hammer-oauth-08#page-39).
> 
> from using URL to proper HTTP requests (http://tools.ietf.org/html/draft-
> hammer-oauth-04#page-17).
> 
> Some implementations - most of those I reviewed* - still support this some
> way or another (out of RFC 2616 section 3.2.2 conformity). Is it still an implicit
> requirement ? (I'm assuming it is)

It is still a requirement but it is implied from HTTP. Since HTTP requires normalizing empty paths as /, the specs assumes you are sending proper HTTP requests.

> There is an ambiguity : it is explicitly required that client send their
> parameters either in the 'Authorization' header, in the query or in the body
> of the request and in only one of those only, but there is no matching
> requirement on the server side.
> 
> implementation ; or maybe it's a wild assumption on my part ? (I'm assuming
> it's the same on the server side)

oauth_ parameters should only be sent in one place, but all parameters are signed, not just the OAuth ones.

> end-point URLs but do not (explicitly) in call-backs. Is it implicit ?

No. What you do in your callback is up to you. There is no potential conflict.

> Those last two are more nitpicking on my part (I include them just to be
> consistent with the list of I had prepared :) )
> 
> HMAC-SHA1 specifies how to encode bytes, not strings ; there is no mention
> of what encoding should be used to decode the key and signature base
> string into bytes ; of course, the percent-encoding turned everything into
> proper ASCII characters, so ASCII and UTF-8 are equivalent ; just nitpickin'.

Why decode when you can just create the same string again and compare the final result?

> 'bad request' or an 'unauthorized' kind of error (I'm assuming the former).

Same as bad nonce value.

EHL

---

From: Olivier MIEL <[email-masked]>
Date: Sat, 19 Dec 2009 13:28:08 +0100

2009/12/18 Eran Hammer-Lahav <>:
>> 1> (...)

Sending and receiving, yes, I understand that.

>> 2> (...)

I didn't meant that parameters from one source or another should be
excluded from the signature, I wanted to know if, given a client that
screwed up and distributed the parameters in several source, should
the server respond with a 400 code ?
In retrospects, the question seems futile, though.

> No. What you do in your callback is up to you. There is no potential conflict.

Point taken.

> Why decode when you can just create the same string again and compare the final result?

I'm not suggesting to decode the signature into bytes. What I meant is
that there is no suggested scheme to convert the signature base string
and the key into bytes before applying HMAC-SHA1 to compute the
signature.

The signature base string is composed of characters either being "&"
(ASCII code 38) separators or characters from percent encoded strings
; these last ones are either preserved UTF-8 characters from the
unreserved set or percent-encoded UTF-8 characters. All characters
belong to the ASCII set, so all character-encoding that extend ASCII
will bear the same result (i.e. ASCII and UTF-8 are equivalent).

But if I'm using a character-encoding that's incompatible with ASCII -
such as UTF-16 - I won't get the same bytes and some implementations
may be incompatible.

>> 'bad request' or an 'unauthorized' kind of error (I'm assuming the former).

Okay.

Thank you for your swift response (and for your patience).

Olivier MIEL.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 19 Dec 2009 09:16:03 -0700

> From: Olivier MIEL [mailto:[email-masked]]
> Sent: Saturday, December 19, 2009 4:28 AM

> But if I'm using a character-encoding that's incompatible with ASCII - such as
> UTF-16 - I won't get the same bytes and some implementations may be
> incompatible.

The encoding section requires UTF-8.

EHL