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

[Songhaibin <[e-mail]>]

OK. I understand. Then I have no questions. 

Thank you for the answer.
-Haibin

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Eran Hammer
> Sent: Thursday, March 08, 2012 8:02 AM
> To: Songhaibin; Justin Richer
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Martin Stiemerling
> Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
> 
> 
> 
> > -----Original Message-----
> > From: Songhaibin [mailto:[e-mail]]
> > Sent: Friday, February 17, 2012 12:53 AM
> > To: Justin Richer
> > Cc: [e-mail]; [e-mail]; Martin
> > Stiemerling; [e-mail]; [e-mail]
> > 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:[e-mail]]
> > > Sent: Wednesday, February 15, 2012 9:44 PM
> > > To: Songhaibin
> > > Cc: [e-mail]; [e-mail]; Martin
> > > Stiemerling; [e-mail]; [e-mail]
> > > 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 [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth