Subject: [OAUTH-WG] feedback on 4/17 draft

From: Marius Scurtescu <[email-masked]>
Date: Mon, 19 Apr 2010 20:03:35 -0700

Hi Eran,

The spec looks really good, thanks for all the work you put into it.

I think it was a good idea to remove the 401 responses and use only 400.

A few minor comments bellow:

3.5.1

The client is described as being incapable to act as a HTTP server,
and of receiving incoming request. The client must provide a callback,
so it is acting as a HTTP server and it is also receiving requests. In
theory a JavaScript client could work with the Web Server flow, it
would extract the verification code from the URL and then make a
direct call to get the access token. I think it is more accurate to
describe the client as not being capable of storing secrets?

3.5.2.1

The client must direct the user agent to the authorization server
using GET. Why is this a MUST? A POST should also work if the client
prefers that, no? Can at least this be changed to SHOULD?

3.5.2.1.1

Same as above, the authorization server directs the user agent back to
the redirection URI with a GET. Why MUST?

3.5.3.1

"an HTTP GET request to the authorization endpoint", should probably
read: "an HTTP POST request to the token endpoint" (POST and token
endpoint).

3.5.3.2.3

The response HTTP status code should probably be 400, not 401.

3.7.1.1

client_secret is marked as OPTIONAL. Maybe for this flow it should
always be REQUIRED?

For invalid requests there are two error codes: incorrect_credentials
and unauthorized_client. Since only client credentials are present in
the request, it is not clear what the difference is. I do agree that
both codes are useful, the second makes reference to an invisible
scope, if the scope was present it would be easier to explain that
case.

3.7.2.1

For invalid assertions there are two error codes:
incorrect_credentials and unauthorized_client. The first one does not
make sense in this context. Maybe invalid_assertion?

5

Second to last paragraph ends in the middle of a sentence.

5.2.2

If the entity body includes other parameters, is it worth requiring
that oauth_token be the first one?

Marius

---

From: Dick Hardt <[email-masked]>
Date: Mon, 19 Apr 2010 21:06:34 -0700

> I think it was a good idea to remove the 401 responses and use only 400.
In WRAP we had used 401s when the client credentials were invalid and 400
when the parameters were invalid in an attempt to stick with HTTP error
codes.

I agree that is is better to consistently return 400 and an optional error
parameter that provides more clarity to the developer on what caused the
error.

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 21 Apr 2010 14:34:34 -0700

Thanks Marius!

I dropped comments already applied to the spec.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Marius Scurtescu
> Sent: Monday, April 19, 2010 8:04 PM

> 3.5.1
> 
> The client is described as being incapable to act as a HTTP server, and of
> receiving incoming request. The client must provide a callback, so it is acting
> as a HTTP server and it is also receiving requests. In theory a JavaScript client
> could work with the Web Server flow, it would extract the verification code
> from the URL and then make a direct call to get the access token. I think it is
> more accurate to describe the client as not being capable of storing secrets?

The client itself isn't able to receive incoming requests which is why it uses another web server to do that part. The key in this flow is how the token is returned, not the ability to keep the client secret private.

> 3.5.2.1
> 
> The client must direct the user agent to the authorization server using GET.
> Why is this a MUST? A POST should also work if the client prefers that, no?
> Can at least this be changed to SHOULD?

You are right.

I left it as a MUST for now.

I think we probably should discuss changing the text to allow both GET with query parameters or POST with form-encoded body. There is value here in just picking one option and sticking with it because the client will need to support both methods based on what the server decides and that's not ideal.

> 3.5.2.1.1
> 
> Same as above, the authorization server directs the user agent back to the
> redirection URI with a GET. Why MUST?

No MUST here. 'GET' is only used in the example. Basically, the user-agent should use the same method it was trying before getting the redirect. So it depends on how the server issues the instructions (for example, with a form button using GET or POST).

> read: "an HTTP POST request to the token endpoint" (POST and token

The token endpoint only returns tokens. The authorization endpoint returns codes... This is half of the authorization step.

As for POST, I don't care. What do others think? It will also mean using form-encoded body.

> For invalid requests there are two error codes: incorrect_credentials and
> unauthorized_client. Since only client credentials are present in the request,
> it is not clear what the difference is. I do agree that both codes are useful,
> the second makes reference to an invisible scope, if the scope was present it
> would be easier to explain that case.

The second is about a client not authorized to use this specific flow. None of the error codes are explained yet.

> 5.2.2
> 
> If the entity body includes other parameters, is it worth requiring that
> oauth_token be the first one?

Why not last?

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 21 Apr 2010 15:04:36 -0700

> The token endpoint only returns tokens. The authorization endpoint returns codes... This is half of the authorization step.

I see how you made the distinction.

I was assuming that the authorization endpoint will be hit only with
browsers and the token endpoint only with direct calls from the
client. This allows a clean separation of characteristics for the two
endpoints and this is the reason with did not combine them. Following
this logic, it is better for the above to use POST and the token
endpoint.

>> oauth_token be the first one?

If was just following the same convention as in OAuth 1.0, see RFC
5849, section 3.5.2.

Thanks,
Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 21 Apr 2010 17:15:56 -0700

> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Wednesday, April 21, 2010 3:05 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] feedback on 4/17 draft
> 
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Marius Scurtescu
> > The token endpoint only returns tokens. The authorization endpoint
> returns codes... This is half of the authorization step.
> 
> I was assuming that the authorization endpoint will be hit only with browsers
> and the token endpoint only with direct calls from the client. This allows a
> clean separation of characteristics for the two endpoints and this is the
> reason with did not combine them. Following this logic, it is better for the
> above to use POST and the token endpoint.

I agree.

I need to take a look at POST vs GET throughout the whole spec. It's a bit broken right now.

> If was just following the same convention as in OAuth 1.0, see RFC 5849,
> section 3.5.2.

I did get a kick from you referencing RFC 5849. It took me a second... :-)

Which BTW says:

   The entity-body MAY include other request-specific parameters, in
   which case, the protocol parameters SHOULD be appended following the
   request-specific parameters, properly separated by an "&" character
   (ASCII code 38).

As in... last.

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 21 Apr 2010 17:22:20 -0700

> I did get a kick from you referencing RFC 5849. It took me a second... :-)

Glad you liked it.

>   request-specific parameters, properly separated by an "&" character

You are right, my mistake.

I thought the reason it should be first, and also single part, is to
help proxies or filters to grab just the beginning of the body and
decide if there is any oauth stuff there.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 21 Apr 2010 17:28:36 -0700

> Sent: Wednesday, April 21, 2010 5:22 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> >> >> If the entity body includes other parameters, is it worth
> >> >> requiring that oauth_token be the first one?
> >> >
> >> > Why not last?
> >>

OCD is an editor's best friend.

> I thought the reason it should be first, and also single part, is to help proxies
> or filters to grab just the beginning of the body and decide if there is any
> oauth stuff there.

It's last to be less intrusive to the protected resource request.

EHL