Thanks Dick! Comments already applied are not listed below.
> -----Original Message----- > From: Dick Hardt [mailto:dick.ha...@gmail.com] > Sent: Sunday, April 18, 2010 8:56 PM > Use of "server" term. In numerous places, the term server is used instead of > authorization server or resource server (maybe even web server). To avoid > ambiguity, I would suggest the term server is never used, and the spec is > explicit on which server is being referred to. In the user-agent flow, a web-server is another entity and is required. > User authentication at AS: Suggest putting this in one section and then > referring to it in 3.5.2.1 and 3.5.3.1 (and adding into 3.5.1) 3.1 has that text. The rest just say 'authenticate the end user'. > Having 5 levels of sections seems overly deep with the bulk of the document > being in 3.5 and 3.6. True, but if you look at the TOC, the structure makes sense. > Sections 4 and 5 seem weaker than the other sections. Not sure about section 4, but section 5 needs review before I spend more time on editorial work. > Description of autonomous flow is missing. Where? > Why are verification code, user code, device code not defined? I'm not sure they qualify as terms, but I can add them if people feel it is helpful. I felt they are more flow specific. > 3.3 > > In WRAP we had a section entitled Parameter Considerations where many > errata about parameters was contained. I'll import the missing bits in a later draft. > 3.5.1.2 > > It is unclear to me how to make the user-agent NOT include the fragment. It is not supposed to. HTTP requests do not include the fragment. The user-agent removes it before making the request. RFC 3986: the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme. > 3.5.3.2.3 > > Great to have all the different error conditions. Spec should discuss what the > client should do for each error code. We need to review first if the error codes are complete. I'm sure there are more. > 3.7.2.1 > > format parameter. Not sure why this undefined parameter is ok, but scope is > not! :) The example needs a little fleshing out. :) It's not ok. I need to incorporate text from Chuck's proposal. > 4. > > While the section introduction describes how it can be used to obtain tokens > with different security parameters and getting a secret, how and when the > developer would make different calls is unspecified. What do you mean by different calls? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
