> -----Original Message----- > From: Songhaibin [mailto:[email protected]] > Sent: Friday, February 17, 2012 12:53 AM > To: Justin Richer > Cc: [email protected]; [email protected]; Martin > Stiemerling; [email protected]; [email protected] > Subject: RE: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 > > Hi Justin, > > Thank you for the clarification. See in line. > > > -----Original Message----- > > From: Justin Richer [mailto:[email protected]] > > Sent: Wednesday, February 15, 2012 9:44 PM > > To: Songhaibin > > Cc: [email protected]; [email protected]; Martin > > Stiemerling; [email protected]; [email protected] > > Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 > > > > On 02/15/2012 04:33 AM, Songhaibin wrote: > > > 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 protected] 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? > > > > 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. > > > > 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?
It can allow the server to enforce policies, but more importantly, client authentication is part of every access token request make to this endpoint as part of the overall architecture. > > > 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. > > > > 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. > > > > 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? It is the only one. Only the resource owner can grant access. EH > > Thanks, > -Haibin > > > > > 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
