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 <buhake@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 <matake@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.faynberg@alcatel-lucent.com>
>> To: 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 <nov@matake.jp>
>>> To: oauth WG <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
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> The Elite Gentleman