<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;" class="">Are you taking AT as query parameters?   That was what we were trying to discourage people from doing.<div class=""><br class=""></div><div class="">I think the logic at the time was that webservers convert post parameters to key value pairs automatically so accepting form post would allow any server that takes AT as a query parameter to take it as a form parameter.</div><div class=""><br class=""></div><div class="">You seem to be be exception to that logic. </div><div class=""><br class=""></div><div class="">Sec 5.3 of Core probably should have been:</div><div class=""><span style="font-family: verdana, charcoal, helvetica, arial, sans-serif; font-size: small; background-color: rgb(255, 255, 255);" class="">The UserInfo Endpoint MUST support the use of all the </span><span style="font-family: verdana, charcoal, helvetica, arial, sans-serif; font-size: small; background-color: rgb(255, 255, 255);" class="">methods defined in Sec 2 of </span><a class="info" href="http://openid.net/specs/openid-connect-core-1_0.html#RFC2616" style="font-weight: bold; position: relative; z-index: 24; text-decoration: none; color: rgb(102, 51, 51); font-family: verdana, charcoal, helvetica, arial, sans-serif;">RFC 6</a>750<span style="background-color: rgb(255, 255, 255);" class=""><font face="verdana, charcoal, helvetica, arial, sans-serif" size="2" class=""> for receiving the Authorization token.</font></span></div><div class=""><br class=""></div><div class="">The right thing to do from a security point of view is really to depreciate both query and post methods of sending the AT.</div><div class=""><br class=""></div><div class="">I take your point that you accepting post but not taking a AT as a form parameter sort of sidesteps the underlying purpose of the test, and doesn’t really accomplish anything.</div><div class=""><br class=""></div><div class="">At his point I guess you have found a bug in the test if the test is not sending the AT as a form parameter.   </div><div class=""><br class=""></div><div class="">That is the only reason for us to be testing POST on the user_info endpoint.</div><div class=""><br class=""></div><div class="">Simply fixing the test is probably not in your interest though.</div><div class=""><br class=""></div><div class="">Making you support POST on the endpoint with no benefit is also silly.</div><div class=""><br class=""></div><div class="">Out of curiosity what percentage of OAuth access is query parameter for you in production?</div><div class=""><br class=""><div class="">I grant you that the spec is currently unclear on why that MUST is attached to the user_info_endpoint.</div><div class=""><br class=""></div><div class="">That is the sort of thing testing points out.</div><div class=""><br class=""></div><div class="">John B.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 3, 2015, at 8:29 PM, William Denniss <<a href="mailto:wdenniss@google.com" class="">wdenniss@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Sending the AT in a form-encoded body parameter is a <a href="https://tools.ietf.org/html/rfc6750#section-2.2" target="_blank" class="">MAY</a> though, so if that's the only reason for userinfo requiring POST, then it probably should have been a MAY too.<div class=""><br class=""></div><div class="">We don't support ATs in a form-encoded body (as is our option), but are still compelled to support POST on userinfo to be OIDC compliant.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Apr 3, 2015 at 2:58 PM, John Bradley <span dir="ltr" class=""><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank" class="">ve7jtb@ve7jtb.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">That is because at the time it was thought that not every client could use a header to send the AT.<div class="">We were trying to avoid clients needing to send AT as query strings.</div><div class=""><br class=""></div><div class="">John B.</div><div class=""><div class=""><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 3, 2015, at 5:57 PM, Breno de Medeiros <<a href="mailto:breno@google.com" target="_blank" class="">breno@google.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Another interesting case is the mandatory POST support for userinfo endpoint requests. Given it's a read-only API it is an interesting choice.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Apr 3, 2015 at 12:11 PM, John Bradley <span dir="ltr" class=""><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank" class="">ve7jtb@ve7jtb.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class="">Our requests may be larger than OAuth only requests due to the extra parameters. </div><div class=""><br class=""></div><div class="">It is also possible that some of them may be sensitive such as the id_token hint that is better in a body than a query parameter. </div><div class=""><br class=""></div><div class="">For interoperability having the servers support both made it simpler for clients. </div><div class=""><br class=""></div><div class="">John B. <br class=""><br class="">Sent from my iPhone</div><span class=""><div class=""><br class="">On Apr 3, 2015, at 3:15 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank" class="">Michael.Jones@microsoft.com</a>> wrote:<br class=""><br class=""></div></span><div class=""><div class=""><blockquote type="cite" class=""><div class="">






<div class=""><p class="MsoNormal">Per <b class=""><a href="http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest" target="_blank" class="">http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest</a></b>, POST support is mandatory for authentication requests in Connect.<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal" style="margin-left:.5in"><span lang="EN" style="font-family:Verdana,sans-serif" class="">Authorization Servers MUST support the use of the HTTP
</span><tt class=""><span lang="EN" style="font-size:10.0pt" class="">GET</span></tt><span lang="EN" style="font-family:Verdana,sans-serif" class=""> and
</span><tt class=""><span lang="EN" style="font-size:10.0pt" class="">POST</span></tt><span lang="EN" style="font-family:Verdana,sans-serif" class=""> methods defined in
<a href="http://openid.net/specs/openid-connect-core-1_0.html#RFC2616" target="_blank" class=""><span style="text-decoration:none" class="">RFC 2616 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.)</span></a>
 [RFC2616] at the Authorization Endpoint. Clients MAY use the HTTP </span><tt class=""><span lang="EN" style="font-size:10.0pt" class="">GET</span></tt><span lang="EN" style="font-family:Verdana,sans-serif" class=""> or
</span><tt class=""><span lang="EN" style="font-size:10.0pt" class="">POST</span></tt><span lang="EN" style="font-family:Verdana,sans-serif" class=""> methods to send the Authorization Request to the Authorization Server. If using the HTTP
</span><tt class=""><span lang="EN" style="font-size:10.0pt" class="">GET</span></tt><span lang="EN" style="font-family:Verdana,sans-serif" class=""> method, the request parameters are serialized using URI Query String Serialization, per
<a href="http://openid.net/specs/openid-connect-core-1_0.html#QuerySerialization" target="_blank" class="">
<span style="text-decoration:none" class="">Section 13.1 (Query String Serialization)</span></a>. If using the HTTP
</span><tt class=""><span lang="EN" style="font-size:10.0pt" class="">POST</span></tt><span lang="EN" style="font-family:Verdana,sans-serif" class=""> method, the request parameters are serialized using Form Serialization, per
<a href="http://openid.net/specs/openid-connect-core-1_0.html#FormSerialization" target="_blank" class="">
<span style="text-decoration:none" class="">Section 13.2 (Form Serialization)</span></a>.<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span lang="EN" style="font-family:Verdana,sans-serif" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal">Per <b class=""><a href="https://tools.ietf.org/html/rfc6749#page-25" target="_blank" class="">https://tools.ietf.org/html/rfc6749#page-25</a></b>, POST support is optional for authorization requests in OAuth 2.0.<u class=""></u><u class=""></u></p>
<pre class=""><span lang="EN" class="">      The authorization server MUST support the use of the HTTP "GET"<u class=""></u><u class=""></u></span></pre>
<pre class=""><span lang="EN" class="">      method [<a href="https://tools.ietf.org/html/rfc2616" title=""Hypertext Transfer Protocol -- HTTP/1.1"" target="_blank" class="">RFC2616</a>] for the authorization endpoint and MAY support the use of the "POST" method as well.<u class=""></u><u class=""></u></span></pre>
<pre class=""><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"" class=""><u class=""></u> <u class=""></u></span></pre><p class="MsoNormal">Does anyone remember why we went beyond the OAuth 2.0 requirements in this regard?<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">                                                            -- Mike<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>


</div></blockquote></div></div><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><span class=""><br class=""><span class="">Openid-specs-ab mailing list</span><br class=""><span class=""><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" class="">Openid-specs-ab@lists.openid.net</a></span><br class=""><span class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br class=""></span></div></blockquote></div><br class="">_______________________________________________<br class="">
Openid-specs-ab mailing list<br class="">
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" class="">Openid-specs-ab@lists.openid.net</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="">--Breno<br class=""></div>
</div>
</div></blockquote></div><br class=""></div></div></div></div><br class="">_______________________________________________<br class="">
Openid-specs-ab mailing list<br class="">
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" class="">Openid-specs-ab@lists.openid.net</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br class="">
<br class=""></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div></div></body></html>