Subject: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23

From: Songhaibin <[email-masked]>
Date: Wed, 15 Feb 2012 09:33:22 +0000

I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC [email-masked] if you reply to or forward this review.

First, I should apologize for the delay in this review, I should have finished it two days ago. I have some common security knowledge but not an expert.

Summary

This draft is basically ready for publication, but has nits that should be fixed before publication.

General issues need discussion: 

1. Section 1.3.3 and 1.3.4 discuss two authorization grant type: resource owner password credentials, and client credentials. These two have the same flow and many in common, and they are significantly different than the authorization code grant type and implicit grant type described in previous sections. And in section 1.3.4, it also says " Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner),...". Is it better to combine these two grant types as one "client credentials" grant type where the client can be the resource owner?

2. Two concepts confused me in section 2.4, I don't know if I am the only person who is confusing here. One is user-agent-based application and another is native application, why are they executed on the device used by the resource owner? I think they can run on any device used by resource consumer instead of resource owner. Resource owner is only used to grant access to resources.

Nits:
1. Section 3.1, paragraph 4, the last sentence is confusing, is it the authorization server who sends the request to the authorization endpoint? Or is it the resource owner?

2. Section 3.1.1, paragraph 3, "...where the order of values does not matter.." I think a little clarification on the reason for this would be better for people like me.

3. Section 3.2, paragraph 4, the last sentence is confusing, is it the authorization server who sends request to the token endpoint?

4. Section 10.12, paragraph 4, should the terminology "end-user" be changed to "resource owner"? There are same issues in other places of this document.

5. Section 10.6, paragraph 2, second sentence, When the attacker is sent to.../ When the authorization code request is sent to...

Kind regards,
-Haibin

---

From: Justin Richer <[email-masked]>
Date: Wed, 15 Feb 2012 08:44:24 -0500

> 1. Section 1.3.3 and 1.3.4 discuss two authorization grant type: resource owner password credentials, and client credentials. These two have the same flow and many in common, and they are significa…

No, they are quite distinct -- It all comes down to what you're 
authenticating. The Resource Owner Password Credentials flow *also* 
includes client credentials which are distinct from the resource owner's 
own credentials. The client's credentials are going to be the same for a 
given client across many different users, while the Resource Owner's 
credentials are going to be different across different users, but the 
same across different clients (for the same resource owner). In most 
flows, the client's credentials identify just the client, and the 
resource owner is identified through some other means (a direct 
password, a redirected login to the authz endpoint). In the Client 
Credentials flow, the client's credentials are the only ones that you have.

> 2. Two concepts confused me in section 2.4, I don't know if I am the only person who is confusing here. One is user-agent-based application and another is native application, why are they executed…

OAuth's main 3-legged pattern allows what's called "Alice-to-Alice 
sharing", in that the Client is consuming on behalf of the resource 
owner. In cases where you have an in-user-agent app or a native app, the 
end user (resource owner) is going to be the one running it, and the one 
authorizing it.

Thanks for your feedback, and I hope this can help clear up the intent 
of the working group here. If you can suggest language that will 
solidify these points further, it can help make sure this doesn't 
further confuse people.

  -- Justin

---

From: Songhaibin <[email-masked]>
Date: Fri, 17 Feb 2012 08:52:52 +0000

Hi Justin,

Thank you for the clarification. See in line.

> -----Original Message-----
> From: Justin Richer [mailto:[email-masked]]
> Sent: Wednesday, February 15, 2012 9:44 PM
> To: Songhaibin
> Cc: [email-masked]; [email-masked]; Martin Stiemerling;
> [email-masked]; [email-masked]
> Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
> 
> > I've reviewed this document as part of the transport area directorate's ongoing
> effort to review key IETF documents. These comments were written primarily for
> the transport area directors, but are copied to the document's authors for their
> information and to allow them to address any issues raised. The authors should
> consider this review together with any other last-call comments they receive.
> Please always CC [email-masked] if you reply to or forward this review.
> >
> > First, I should apologize for the delay in this review, I should have finished it two
> days ago. I have some common security knowledge but not an expert.
> >
> > Summary
> >
> > 1. Section 1.3.3 and 1.3.4 discuss two authorization grant type: resource owner
> password credentials, and client credentials. These two have the same flow and
> many in common, and they are significantly different than the authorization code
> grant type and implicit grant type described in previous sections. And in section
> 1.3.4, it also says " Client credentials are used as an authorization grant typically
> when the client is acting on its own behalf (the client is also the resource
> owner),...". Is it better to combine these two grant types as one "client
> credentials" grant type where the client can be the resource owner?
> 

Okay, in the Resource Owner Password Credentials flow, it adds client credentials, but any client who was issued credentials from the authorization server can pass. How much security does the client credential in this flow add?

> > 2. Two concepts confused me in section 2.4, I don't know if I am the only person
> who is confusing here. One is user-agent-based application and another is native
> application, why are they executed on the device used by the resource owner? I
> think they can run on any device used by resource consumer instead of resource
> owner. Resource owner is only used to grant access to resources.
> 

Yes, I understand that. But the document seems like resource owner is the "only" one who can run the UA app or native app? Or I missed something?

Thanks,
-Haibin