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

Mike Jones Michael.Jones at microsoft.com
Wed Mar 19 20:37:58 UTC 2014


I agree that as the specs are written, "invalid_request" is the right error to return.

                                                            -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Brian Campbell
Sent: Wednesday, March 19, 2014 1:09 PM
To: John Bradley
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Error value for unsupported "response_mode"

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/35e7ed28/attachment.html>


More information about the Openid-specs-ab mailing list