Hi Eran, The spec looks really good, thanks for all the work you put into it.
I think it was a good idea to remove the 401 responses and use only 400. A few minor comments bellow: 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? 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? 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? 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). 3.5.3.2.3 The response HTTP status code should probably be 400, not 401. 3.7.1.1 client_secret is marked as OPTIONAL. Maybe for this flow it should always be REQUIRED? 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. 3.7.2.1 For invalid assertions there are two error codes: incorrect_credentials and unauthorized_client. The first one does not make sense in this context. Maybe invalid_assertion? 5 Second to last paragraph ends in the middle of a sentence. 5.2.2 If the entity body includes other parameters, is it worth requiring that oauth_token be the first one? Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
