[Openid-specs-ab] Error value for unsupported "response_mode"

Pedro Felix pmhsfelix at gmail.com
Thu Mar 20 11:08:54 UTC 2014


I try to avoid user-facing errors as much as possible (UX reasons), but I'm
starting to also agree with John.

Even for plain OAuth 2.0, the unsupported_response_type error should only
be used if the AS does not supports the response type but *does*
understands it and is able to use the proper response binding to return the
error.

For instance, if a AS that only supports code receives an implicit
 request, then it should either:
1) Return unsupported_response_type using the *fragment* binding
2) Present a user-facing error.

Makes sense?

Thanks


>>
>> On Wed, Mar 19, 2014 at 10:06 PM, Thomas Broyer <t.broyer at gmail.com>wrote:
>>
>>> +1
>>>
>>> I used to return invalid_request (I only support code response type, for
>>> now at least), but will change to a user-facing error tomorrow.
>>> Le 19 mars 2014 21:49, "John Bradley" <ve7jtb at ve7jtb.com> a écrit :
>>>
>>> The default for everything other than code is fragment encoding.
>>>>
>>>> So the error response would be in the fragment as the default.  That is
>>>> probably not useful unless you have JS to catch it.
>>>>
>>>> It may be better to treat it the same as a bad redirect URI and report
>>>> it to the user.
>>>>
>>>> John B.
>>>>
>>>> On Mar 19, 2014, at 5:08 PM, Brian Campbell <bcampbell at pingidentity.com>
>>>> wrote:
>>>>
>>>> I'd just assumed you'd return the error using the default mode for the
>>>> given response type.
>>>>
>>>>
>>>> On Wed, Mar 19, 2014 at 2:05 PM, John Bradley <ve7jtb at ve7jtb.com>wrote:
>>>>
>>>>> One problem with unsupported response mode would be not knowing how to
>>>>> return the error to the client as you don't understand or support the way
>>>>> that you meed to return the error to the client via the browser.
>>>>>
>>>>> In general I would expect a error reported to the user as the AS
>>>>> doesn't know how to send the response to the client.
>>>>>
>>>>> Hopefully discovery and registration will take care of it before it
>>>>> gets to be an error.
>>>>>
>>>>> John B.
>>>>>
>>>>> On Mar 19, 2014, at 4:50 PM, Brian Campbell <
>>>>> bcampbell at pingidentity.com> wrote:
>>>>>
>>>>> I believe that, given the specs as they are now, "invalid_request"
>>>>> would be the proper error value for an unsupported or invalid
>>>>> response_mode parameter along with perhaps some explanation in the
>>>>> error_description parameter value.
>>>>>
>>>>> As you've seen, there is no "unsupported_response_mode" defined
>>>>> anywhere and the specs that would have defined it (core or multi response
>>>>> types) are now final. It probably would have made sense to define a
>>>>> unsupported_response_mode just for consistency with some of the other
>>>>> parameters and associated error codes that Connect defines. Omitting a unsupported_response_mode
>>>>> error code was likely an oversight but unless we expect clients to
>>>>> take programmatic action to rectify the situation, I don't think it really
>>>>> matters. And Discovery does define response_modes_supported as part of
>>>>> Provider Metadata, which a client can use to figure out what modes are
>>>>> supported before making a request.
>>>>>
>>>>> That's my take anyway. But maybe it's an errata candidate or something
>>>>> along those lines?
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 19, 2014 at 3:57 AM, Pedro Felix <pmhsfelix at gmail.com>wrote:
>>>>>
>>>>>> In the context of the "OAuth 2.0 Multiple Response Type Encoding
>>>>>> Practices"
>>>>>>
>>>>>>     1) What should be the proper authorization response error value
>>>>>> when the request contains an unsupported or invalid "response_mode"?
>>>>>>
>>>>>>     2) OAuth 2.0 defines the "unsupported_response_type" for
>>>>>> unsupported "response_type". Should there be a "unsupported_response_mode"
>>>>>> or should we use the generic "invalid_request"
>>>>>>
>>>>>> Thanks
>>>>>> Pedro
>>>>>>
>>>>>> _______________________________________________
>>>>>> Openid-specs-ab mailing list
>>>>>> Openid-specs-ab at lists.openid.net
>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>
>
>
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140320/2a0a010f/attachment-0001.html>


More information about the Openid-specs-ab mailing list