Section 3.1.1 states: If an authorization request is missing the "response_type" parameter, the authorization server MUST return an error response as described in Section 4.1.2.1.
The intention was to make this the catch-all scenario. While I do appreciate the issue here of the client using a response type that may require special encoding of the error information in the response, it is pretty easy to also support the authorization code response type error transport when using a response type other than code and token. I have made the following change to clarify this: If an authorization request is missing the "response_type" parameter, [[or if the response type is not understood, ]] the authorization server MUST return an error response as described in Section 4.1.2.1. "Not understood" means the server does not know anything about it. It should know about code and token, even if one or both are not supported and provide the required error response. This really is only about unknown extensions. Then according to section 4.1.2.1, the error code should be 'unsupported_response_type'. I have tried to make the change as small as possible, but if my explanation isn't clear from the new text, please let me know and we'll get it clarified. EH From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of matake@gmail Sent: Tuesday, February 21, 2012 4:23 AM To: Buhake Sindi Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Quick question about error response for "response_type=unknown" When server cannot understand the response_type, it can't know where the error response should be included. ex.) A JS client used response_type=code%20id_token and expected all returned parameters would be included in fragment. However server couldn't understand the response_type and returned error messages in query. Then client won't be able to handle the error. Actually, clients expects returned parameters in query only when it uses response_type=code, at least in current proposed response_types. (I'm thinking "current proposed response_types" as "code", "token", "code token", "token id_token", "code id_token" and "code token id_token") On 2012/02/21, at 20:42, Buhake Sindi wrote: Oops. Sorry, I believe I should have said, case 2. And why is case 2 impossible? The only time case 1 is valid in the redirect_uri is invalid. Buhake Sindi On 21 February 2012 13:40, Buhake Sindi <buh...@googlemail.com<mailto:buh...@googlemail.com>> wrote: Hi guys, OAuth 2, Draft 23, Paragraph 4.1.2.1 clearly states: If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error, and MUST NOT automatically redirect the user-agent to the invalid redirection URI. So, Case 1 is the only accepted case here. Buhake Sindi On 21 February 2012 13:34, matake@gmail <mat...@gmail.com<mailto:mat...@gmail.com>> wrote: So the answer is "Show the error to the user without redirecting back to the client", right? I'm now developing OAuth2 and OpenID Connect ruby library, and both of them return errors case 1. redirect with error in query if response_type is "code" but it's not supported case 2. redirect with error in fragment if response_type is "token code", "token id_token", "token code id_token" or "code id_token" but it's not supported case 3. otherwise show error to the user without redirect since server cannot understand the response_type at all But other server might not understand some of response_types listed in case 2 at all and choose case 3 in such case. (ie. OAuth servers which don't understand OpenID Connect won't understand "id_token") So I'm afraid that it reduces interoperability, a bit. On 2012/02/21, at 13:22, William Mills wrote: I does allow some parts of your server config to be discovered. More of a problem in error responses is usually echoing back the user data, or allowing user enumeration for example. Care is required, but you don't have a ton of options here. ________________________________ From: Igor Faynberg <igor.faynb...@alcatel-lucent.com<mailto:igor.faynb...@alcatel-lucent.com>> To: oauth@ietf.org<mailto:oauth@ietf.org> Sent: Monday, February 20, 2012 9:37 AM Subject: Re: [OAUTH-WG] Quick question about error response for "response_type=unknown" Could there be a potential security hole in providing an error response? (Not that I see it, but many problems in the past had been caused by helpful responese.) Igor On 2/20/2012 11:57 AM, William Mills wrote: Respond with an error in protocol. Thta won't include a redirect, and the client has to know what to do. ________________________________ From: nov matake <n...@matake.jp><mailto:n...@matake.jp> To: oauth WG <oauth@ietf.org><mailto:oauth@ietf.org> Sent: Monday, February 20, 2012 6:11 AM Subject: [OAUTH-WG] Quick question about error response for "response_type=unknown" Hi OAuthers, My apologies if you already discussed this. When OAuth server received unknown response_type, how should the server handle the error? 1. Show the error to the user without redirecting back to the client 2. Redirect back to the client including the error in query 3. Redirect back to the client including the error in fragment Since choosing 2 or 3 is impossible in this case, 1 seems reasonable for me. -- nov _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- The Elite Gentleman
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
