Hi Eran, A few more comments:
1. Only one endpoint. While I think collapsing the access token and refresh token URLs into one URL was a good think, keeping the user authorization as a separate URL could be beneficial. I think there should be 2 endpoints defined: access token and user authorization. Calls to the access token endpoint are alway direct calls and restricted to HTTPS and POST, and with many frameworks this can be enforced through configuration. The user authorization endpoint is always accessed with a browser. 2. Section 2.1: "The authorization endpoint advertised by the server MUST NOT include a query or fragment components as defined by [RFC3986] section 3." Why do we disallow query parameters? If we want to enforce strict matching of callback URLs maybe we should just demand that. 3. Section 2.2: "The values of the request and response parameters defined in this section MUST only contain the following characters". I asked in another thread what is the reason behind this limitation. Why not any UTF-8 string? 4. Section 2.4.1.1: "The client directs the end user to the constructed URI using an HTTP redirection response, or by other means available to it via the end user's user-agent. The request MUST use the HTTP "GET" method." Why do we enforce GET? 5. Section 2.4.2. Web Client Flow combines both rich app and JavaScript flows. It think the two flows should be treated separately. For the rich apps the flow should include a verification code step, similar to Web Client Flow. Also, in this case the callback URL should be optional and if not present the authorization server must display a page with instructions and a special title. For the JavaScript flow, the presence of an empty fragment in the callback URL is a signal that the response should be put there? Can we make it mandatory that the response always goes to the fragment? It is not defined how is the response supposed to be encoded into the fragment. I assume that also URL encoded, but it should be specified. 6. Sections 4.1.2 and 4.1.3, the parameter name should probably be oauth_access_token. 7. Section 4.2, shouldn't we require a "version" parameter with value "2.0"? Thanks, Marius On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <[email protected]> wrote: > I'm making good progress working off David's draft and bringing text from > WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far > it is largely in line with David's proposal and the majority of changes are > purely editorial. > > The only significant change I have made (which is of course open to debate) > is renaming all the authorization flows parameters. I dropped the oauth_ > prefix (no real need since these are purely OAuth endpoints, not protected > resources), and made most of the parameter names shorter. I am not done so > they are not consistent yet. > > You can follow my progress (changes every few hours) at: > > http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth > .txt > > Please feel free to comment on anything you like or dislike. I will publish > the whole thing as an I-D once it is feature complete for the WG to discuss > before we promote this to a WG draft. > > I hope to be done with the initial draft by middle of next week (I'll be > flying most of Fri-Sat so no progress over the weekend). > > EHL > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
