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.
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.
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
