<div dir="ltr">Mike, thanks for the explanation. I agree with the proposed resolution of making it a WARNING.<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 25, 2015 at 10:07 AM, Mike Jones <span dir="ltr"><<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks for bringing this to our attention, Breno.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Reading
<a href="http://openid.net/specs/openid-connect-core-1_0.html#UserInfoRequest" target="_blank">http://openid.net/specs/openid-connect-core-1_0.html#UserInfoRequest</a>,
<a href="http://openid.net/specs/openid-connect-basic-1_0.html#UserInfoRequest" target="_blank">http://openid.net/specs/openid-connect-basic-1_0.html#UserInfoRequest</a>, and
<a href="http://tools.ietf.org/html/rfc6750#section-2.2" target="_blank">http://tools.ietf.org/html/rfc6750#section-2.2</a>, not requiring this functionality seems like a reasonable request, from a conformance perspective.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<pre><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">From an interop perspective, it’s there to give RPs that can’t generate an Authorization: Bearer header a way to request the information without sending the bearer token as a query parameter – a bad security practice. <a href="http://tools.ietf.org/html/rfc6750#section-2.2" target="_blank">http://tools.ietf.org/html/rfc6750#section-2.2</a> motivates the existence of the body method as being for “</span><span lang="EN">contexts where participating browsers do not have access to the "Authorization" request header field</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">”. Whereas <a href="http://tools.ietf.org/html/rfc6750#section-2.3" target="_blank">http://tools.ietf.org/html/rfc6750#section-2.3</a> says that the query parameter method “</span><span lang="EN">its use is not recommended, due to its security deficiencies</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">”.<u></u><u></u></span></pre>
<pre><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></pre>
<pre><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Since there is a good reason, from an interop perspective, for servers to support this method, but that it clearly shouldn’t be required for certification, I would propose that we leave the test, but change the result of not passing it from being an ERROR to being a WARNING. That way, servers can still test their support for the feature, but not supporting it doesn’t prevent certification.<u></u><u></u></span></pre>
<pre><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></pre>
<pre><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Please consider that resolution. Given that the test suite is now frozen, it will require a working group decision to make this change. We will take this up on the working group call at 7am Pacific Time tomorrow - <a href="https://www3.gotomeeting.com/join/181372694" target="_blank">https://www3.gotomeeting.com/join/181372694</a> or <a href="tel:%2B1%20%28646%29%20982-0002" value="+16469820002" target="_blank">+1 (646) 982-0002</a>, access code 181-372-694. Please join it if you can.<u></u><u></u></span></pre>
<pre><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></pre>
<pre><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> -- Mike<u></u><u></u></span></pre>
<pre><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></pre>
<pre><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">P.S. I’ll note that the certification tests have two purposes – certification and increasing interop, which are related, but not strictly the same. The test software tests include a bunch of functionality that isn’t strictly required for certification, such as returning specific requested claims in response to using scopes, that you can pass certification without. It issues warnings if the preferred behavior isn’t implemented. This would be another such a case.<u></u><u></u></span></pre>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Breno de Medeiros [mailto:<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>]
<br>
<b>Sent:</b> Wednesday, March 25, 2015 11:01 AM<br>
<b>To:</b> Roland Hedberg<br>
<b>Cc:</b> William Denniss; Adam Dawes; Roshni Chandrashekhar; Naveen Agarwal; Mike Jones<br>
<b>Subject:</b> POST body encoded bearer token<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">We have noticed that the compliance suite enforces that userinfo endpoint supports authentication via www-form-url-encoded parameter.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This test is not implied by the specs.'<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">1. The bearer spec mandates header parameter. Body encoded is MAY, not even SHOULD.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">2. The OpenID connect spec only mandates support for UserInfo POST requests and compliance with Bearer header spec.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Supporting only the encoding of the bearer as Header transport in a POST request is compliant with both specs.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Years ago, when the Bearer spec reached final form, we made a conscious decision not to support it because of extensive ramifications for performance of our shared API serving infrastructure. This decision is not going to be revisited.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Please remove the test <span style="font-size:10.0pt;color:#262626">OP-UserInfo-Body </span>as it is not part of spec compliance surface in what I believe is a natural reading of the specs.<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<p class="MsoNormal">--Breno<u></u><u></u></p>
</div>
</div>
</div>
</div></div></div>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">--Breno<br></div>
</div></div>