This is a note that records the decisions made at July 7 Spec Call. <div>This for the HTTP Redirect Binding. </div><div><br></div><div><br><div class="gmail_quote">On Thu, Jul 7, 2011 at 9:29 AM, Johnny Bufu <span dir="ltr"><<a href="mailto:jbufu@janrain.com">jbufu@janrain.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello spec editors,<br>
<br>
I've given a close read to the following specifications. Below are comments about parts that I've found unclear or confusing, and questions for which I didn't find answers in the specs and would hold me back if I were to implement them.<br>

<br>
Thanks,<br>
Johnny<br>
<br><br>
------------------------------<u></u>------------------------------<u></u>----<br>
<br>
HTTP Redirect Binding (draft 01 / June 30, 2011):<br>
<br>
3.1.  Authorization Code Flow<br>
<br>
"the party that receives message MUST verify it according to the verification rule set in OpenID Connect Core 1.0 [OpenID.CC] and OpenID Connect Framework 1.0 [OpenID.CF]."<br>
<br>
There are no rules defined in Core.<br>
<br></blockquote><div><br></div><div>Language in the Framework is not clear around id_token response. Clarify. </div><div><br></div><div>Probably needs id_token be in the core, because id_token is required to make the core work. Talk to Breno. </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
3.1.1.1.  Query Parameters Method<br>
<br>
Which HTTP methods are allowed? Being a HTTP binding profile I would expect, as an implementer, to find this answer here.<br></blockquote><div><br></div><div>Define methods for each endpoints. Edmund.  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
3.1.1.1.1.  Client sends a request to the Authorization Server<br>
<br>
"any other valid means of directing the User-Agent to the URL" is ambiguous and open-ended, a HTTP binding specification should define what's acceptable.<br></blockquote><div><br></div><div>Delete valid. Edmund. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
scope: "openid" is missing from example.<br></blockquote><div><br></div><div>Add it. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
3.1.1.2.  Request Parameter Method<br>
<br>
"The JWT object MAY be signed or signed and encrypted via JWS [JWS] and JWE [JWE] respectively, thereby providing non-repudiation and/or security of the request."<br>
<br>
Non-repudiation is only one of the main benefits provided by signatures, while "security" is a too-generic term. I would suggest:<br>
"providing authentication, integrity, non-repudiation and/or confidentiality"<br></blockquote><div><br></div><div>Accept. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
And again, the allowed HTTP methods should be specified.<br></blockquote><div><br></div><div>As above.  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The second example should be replaced with the actual JWT (as the comment there says).<br></blockquote><div><br></div><div>Add footnote. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
3.2.5.1.  End-User Grants Authorization<br>
<br>
Core defines only code, token, none as acceptable response_type values, which would suggest that id_token would then be unacceptable. (See also note on Core/Section 3.1.1)<br>
<br>
Also, I couldn't find where "id_token" is listed as possible/acceptable value for the response_type parameter, and what its meaning would be.<br><br></blockquote><div><br></div><div>As above.  </div></div><br>
-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>
</div>