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

Brian Campbell bcampbell at pingidentity.com
Wed Mar 19 19:50:04 UTC 2014

I believe that, given the specs as they are now, "invalid_request"
would bethe proper error value for an unsupported or invalid
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140319/f8911a63/attachment.html>

More information about the Openid-specs-ab mailing list