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

Brian Campbell bcampbell at pingidentity.com
Wed Mar 19 21:20:31 UTC 2014


That's a good point, John. RFC 6749 and OpenID Connect Core wouldn't easily
lead one to that conclusion, I don't think, but they don't seem to
explicitly disallow it either.


On Wed, Mar 19, 2014 at 2:40 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> 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
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140319/58c0b8e4/attachment.html>


More information about the Openid-specs-ab mailing list