<div dir="ltr">Incidentally, we do support POST on userinfo now (we enabled that to pass the OIDC conformance test).  And I believe the tests for form-parameters on userinfo were switched from errors to warnings to honor the MAYs in RFC6750.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 3, 2015 at 5:17 PM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We attempt to ensure that our libraries always user the Authorization Header (and I think several of the 3rd party libraries do so) so a large percentage of integrations use Authorization header. Our documentation also highlights Header primarily, including in examples. However in our experience most 'hand-rolled' integrations use query parameter simply because it's easier. We do not block that for userinfo calls since we think the risk of leakage is not high (our endpoint is TLS-only).</div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Fri, Apr 3, 2015 at 5:02 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Are you taking AT as query parameters?   That was what we were trying to discourage people from doing.<div><br></div><div>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><br></div><div>You seem to be be exception to that logic. </div><div><br></div><div>Sec 5.3 of Core probably should have been:</div><div><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small;background-color:rgb(255,255,255)">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)">methods defined in Sec 2 of </span><a href="http://openid.net/specs/openid-connect-core-1_0.html#RFC2616" style="font-weight:bold;text-decoration:none;color:rgb(102,51,51);font-family:verdana,charcoal,helvetica,arial,sans-serif" target="_blank">RFC 6</a>750<span style="background-color:rgb(255,255,255)"><font face="verdana, charcoal, helvetica, arial, sans-serif"> for receiving the Authorization token.</font></span></div><div><br></div><div>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><br></div><div>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><br></div><div>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><br></div><div>That is the only reason for us to be testing POST on the user_info endpoint.</div><div><br></div><div>Simply fixing the test is probably not in your interest though.</div><div><br></div><div>Making you support POST on the endpoint with no benefit is also silly.</div><div><br></div><div>Out of curiosity what percentage of OAuth access is query parameter for you in production?</div><div><br><div>I grant you that the spec is currently unclear on why that MUST is attached to the user_info_endpoint.</div><div><br></div><div>That is the sort of thing testing points out.</div><div><br></div><div>John B.</div><div><div><div><br><div><blockquote type="cite"><div>On Apr 3, 2015, at 8:29 PM, William Denniss <<a href="mailto:wdenniss@google.com" target="_blank">wdenniss@google.com</a>> wrote:</div><br><div><div dir="ltr">Sending the AT in a form-encoded body parameter is a <a href="https://tools.ietf.org/html/rfc6750#section-2.2" target="_blank">MAY</a> though, so if that's the only reason for userinfo requiring POST, then it probably should have been a MAY too.<div><br></div><div>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><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 3, 2015 at 2:58 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">That is because at the time it was thought that not every client could use a header to send the AT.<div>We were trying to avoid clients needing to send AT as query strings.</div><div><br></div><div>John B.</div><div><div><div><br></div><div><div><blockquote type="cite"><div>On Apr 3, 2015, at 5:57 PM, Breno de Medeiros <<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>> wrote:</div><br><div><div dir="ltr">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><div class="gmail_quote">On Fri, Apr 3, 2015 at 12:11 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Our requests may be larger than OAuth only requests due to the extra parameters. </div><div><br></div><div>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><br></div><div>For interoperability having the servers support both made it simpler for clients. </div><div><br></div><div>John B. <br><br>Sent from my iPhone</div><span><div><br>On Apr 3, 2015, at 3:15 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>> wrote:<br><br></div></span><div><div><blockquote type="cite"><div>






<div><p class="MsoNormal">Per <b><a href="http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest" target="_blank">http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest</a></b>, POST support is mandatory for authentication requests in Connect.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal" style="margin-left:.5in"><span lang="EN" style="font-family:Verdana,sans-serif">Authorization Servers MUST support the use of the HTTP
</span><tt><span lang="EN" style="font-size:10.0pt">GET</span></tt><span lang="EN" style="font-family:Verdana,sans-serif"> and
</span><tt><span lang="EN" style="font-size:10.0pt">POST</span></tt><span lang="EN" style="font-family:Verdana,sans-serif"> methods defined in
<a href="http://openid.net/specs/openid-connect-core-1_0.html#RFC2616" target="_blank"><span style="text-decoration:none">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><span lang="EN" style="font-size:10.0pt">GET</span></tt><span lang="EN" style="font-family:Verdana,sans-serif"> or
</span><tt><span lang="EN" style="font-size:10.0pt">POST</span></tt><span lang="EN" style="font-family:Verdana,sans-serif"> methods to send the Authorization Request to the Authorization Server. If using the HTTP
</span><tt><span lang="EN" style="font-size:10.0pt">GET</span></tt><span lang="EN" style="font-family:Verdana,sans-serif"> 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">
<span style="text-decoration:none">Section 13.1 (Query String Serialization)</span></a>. If using the HTTP
</span><tt><span lang="EN" style="font-size:10.0pt">POST</span></tt><span lang="EN" style="font-family:Verdana,sans-serif"> 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">
<span style="text-decoration:none">Section 13.2 (Form Serialization)</span></a>.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN" style="font-family:Verdana,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal">Per <b><a href="https://tools.ietf.org/html/rfc6749#page-25" target="_blank">https://tools.ietf.org/html/rfc6749#page-25</a></b>, POST support is optional for authorization requests in OAuth 2.0.<u></u><u></u></p>
<pre><span lang="EN">      The authorization server MUST support the use of the HTTP "GET"<u></u><u></u></span></pre>
<pre><span lang="EN">      method [<a href="https://tools.ietf.org/html/rfc2616" title=""Hypertext Transfer Protocol -- HTTP/1.1"" target="_blank">RFC2616</a>] for the authorization endpoint and MAY support the use of the "POST" method as well.<u></u><u></u></span></pre>
<pre><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><u></u> <u></u></span></pre><p class="MsoNormal">Does anyone remember why we went beyond the OAuth 2.0 requirements in this regard?<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">                                                            -- Mike<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p>
</div>


</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><span><br><span>Openid-specs-ab mailing list</span><br><span><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a></span><br><span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br></span></div></blockquote></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><br clear="all"><div><br></div>-- <br><div>--Breno<br></div>
</div>
</div></blockquote></div><br></div></div></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>
</div></blockquote></div><br></div></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div>--Breno<br></div>
</font></span></div>
</blockquote></div><br></div>