[Openid-specs-ab] Error value for unsupported "response_mode"
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
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"
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab