<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Yes for response mode if you understand the mode but don't support it sending a error would be the correct thing.<div><br></div><div>John B.<br><div><div>On Mar 20, 2014, at 8:08 AM, Pedro Felix <<a href="mailto:pmhsfelix@gmail.com">pmhsfelix@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">I try to avoid user-facing errors as much as possible (UX reasons), but I'm starting to also agree with John.</span><div style="font-family:arial,sans-serif;font-size:13px">
<br><div>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.</div>
<div><br></div><div>For instance, if a AS that only supports code receives an implicit  request, then it should either:</div><div>1) Return unsupported_response_type using the *fragment* binding</div><div>2) Present a user-facing error.</div>
<div><br></div><div>Makes sense?</div><div><br></div><div>Thanks</div></div><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="gmail_extra"><div><div class="h5"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Wed, Mar 19, 2014 at 10:06 PM, Thomas Broyer <span dir="ltr"><<a href="mailto:t.broyer@gmail.com" target="_blank">t.broyer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir="ltr">+1</p><p dir="ltr">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.</p>
<div class="gmail_quote">Le 19 mars 2014 21:49, "John Bradley" <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>> a écrit :<div><br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">




<div style="word-wrap:break-word"><div>The default for everything other than code is fragment encoding.</div><div><br></div><div>So the error response would be in the fragment as the default.  That is probably not useful unless you have JS to catch it.</div>




<div><br></div><div>It may be better to treat it the same as a bad redirect URI and report it to the user.</div><div><br></div><div>John B.</div><div><br><div><div>On Mar 19, 2014, at 5:08 PM, Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>> wrote:</div>




<br><blockquote type="cite"><div dir="ltr">I'd just assumed you'd return the error using the default mode for the given response type.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 19, 2014 at 2:05 PM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>






<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div>






<div><br></div><div>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.</div><div><br></div><div>Hopefully discovery and registration will take care of it before it gets to be an error.</div>






<div><br></div><div>John B.</div><div><br><div><div>On Mar 19, 2014, at 4:50 PM, Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>> wrote:</div>

<br><blockquote type="cite"><div dir="ltr"><div>I believe that, given the specs as they are now, <span style="font-size:1em">"</span><span style="font-size:1em">invalid_request" would be</span> the proper error value for an unsupported or invalid response_mode parameter along with perhaps some explanation in the error_description parameter value.<br>








<br></div><div>As you've seen, there is no <span style="font-size:1em">"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 </span><br>








<span style="font-size:1em"><span style="font-size:1em">unsupported_response_mode just for consistency </span>with some of the other parameters and associated error codes that Connect defines. Omitting a </span><span style="font-size:1em"><span style="font-size:1em"><span style="font-size:1em">unsupported_response_mode error code</span></span> 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. <br>








<br></span></div><div><span style="font-size:1em">That's my take anyway. But maybe it's an errata candidate or something along those lines? <br></span></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">








On Wed, Mar 19, 2014 at 3:57 AM, Pedro Felix <span dir="ltr"><<a href="mailto:pmhsfelix@gmail.com" target="_blank">pmhsfelix@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">








<div dir="ltr"><div style="font-family:arial,sans-serif;font-size:13px">In the context of the "OAuth 2.0 Multiple Response Type Encoding Practices"</div><div style="font-family:arial,sans-serif;font-size:13px">







<br>

</div><span style="font-family:arial,sans-serif;font-size:13px">    1) What should be the proper authorization response error value when the request contains an unsupported or invalid "response_mode"? </span><div style="font-family:arial,sans-serif;font-size:13px">









<br></div><div style="font-family:arial,sans-serif;font-size:13px">    2) OAuth 2.0 defines the "<span style="font-size:1em">unsupported_response_type" for unsupported "response_type". Should there be a "unsupported_response_mode" or should we use the generic "</span><span style="font-size:1em">invalid_request"</span></div>









<div style="font-family:arial,sans-serif;font-size:13px"><span style="font-size:1em"><br></span></div><div style="font-family:arial,sans-serif;font-size:13px"><span style="font-size:1em">Thanks</span></div><span><font color="#888888"><div style="font-family:arial,sans-serif;font-size:13px">









<span style="font-size:1em">Pedro</span></div></font></span></div>
<br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>






</blockquote></div><br></div></div></blockquote></div><br></div>
</blockquote></div><br></div></div><br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div></div>
<br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br></div>
</div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class=""><font color="#888888">-- <br>Thomas Broyer<br>/t<a href="http://xn--nna.ma.xn--bwa-xxb.je/" target="_blank">ɔ.ma.bʁwa.je/</a>
</font></span></div>
</blockquote></div><br></div></div>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></div></body></html>