Thanks Marius! I dropped comments already applied to the spec.
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Monday, April 19, 2010 8:04 PM > 3.5.1 > > The client is described as being incapable to act as a HTTP server, and of > receiving incoming request. The client must provide a callback, so it is > acting > as a HTTP server and it is also receiving requests. In theory a JavaScript > client > could work with the Web Server flow, it would extract the verification code > from the URL and then make a direct call to get the access token. I think it > is > more accurate to describe the client as not being capable of storing secrets? The client itself isn't able to receive incoming requests which is why it uses another web server to do that part. The key in this flow is how the token is returned, not the ability to keep the client secret private. > 3.5.2.1 > > The client must direct the user agent to the authorization server using GET. > Why is this a MUST? A POST should also work if the client prefers that, no? > Can at least this be changed to SHOULD? You are right. I left it as a MUST for now. I think we probably should discuss changing the text to allow both GET with query parameters or POST with form-encoded body. There is value here in just picking one option and sticking with it because the client will need to support both methods based on what the server decides and that's not ideal. > 3.5.2.1.1 > > Same as above, the authorization server directs the user agent back to the > redirection URI with a GET. Why MUST? No MUST here. 'GET' is only used in the example. Basically, the user-agent should use the same method it was trying before getting the redirect. So it depends on how the server issues the instructions (for example, with a form button using GET or POST). > 3.5.3.1 > > "an HTTP GET request to the authorization endpoint", should probably > read: "an HTTP POST request to the token endpoint" (POST and token > endpoint). The token endpoint only returns tokens. The authorization endpoint returns codes... This is half of the authorization step. As for POST, I don't care. What do others think? It will also mean using form-encoded body. > For invalid requests there are two error codes: incorrect_credentials and > unauthorized_client. Since only client credentials are present in the request, > it is not clear what the difference is. I do agree that both codes are useful, > the second makes reference to an invisible scope, if the scope was present it > would be easier to explain that case. The second is about a client not authorized to use this specific flow. None of the error codes are explained yet. > 5.2.2 > > If the entity body includes other parameters, is it worth requiring that > oauth_token be the first one? Why not last? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
