The code and implicit response_type are defined in RFC 6749. https://tools.ietf.org/html/rfc6749#section-4.1.2 https://tools.ietf.org/html/rfc6749#section-4.2.2
It describes one way to encode the response in each case with no mention of that being extended. In the text there is no normative MUST. I personally think changing the encoding of code via response_mode might be a technical violation of RFC 6749, it will defiantly cause interop problems. The multiple response type spec restates the defaults from RFC 6749, but doesn't explicitly say that you can change them with response_mode. In Connect we were careful not to override anything in RFC 6749. In your deployment using response_mode with code might work perfectly fine. Interop problems by implementations not expecting response_mode with the code response_type are the only real concern. John B. > On Feb 10, 2015, at 10:35 AM, Bill Burke <[email protected]> wrote: > > > > On 2/10/2015 7:06 AM, Brian Campbell wrote: >> >> >> On Mon, Feb 9, 2015 at 3:59 PM, John Bradley <[email protected] >> <mailto:[email protected]>> wrote: >> >> Connect has a response_mode that allows the response to be form >> encoded rather than fragment. >> I read RFC 5849 as only allowing code to be query encoded. The >> response_mode was intended for the new response types we defined in >> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >> >> >> Actually response_mode is defined in that spec itself in section 2.1 >> <http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#ResponseModes>. >> > > Yeah, and it looks like you can use it for anything. It only defines default > modes for various response types (code, token, etc.) > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
