Thanks, Nat.  Inline...<br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 2:01 AM, Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br><br><div class="gmail_quote"><div class="im">On Wed, Jul 13, 2011 at 12:27 PM, Andrew Arnott <span dir="ltr"><<a href="mailto:andrewarnott@gmail.com" target="_blank">andrewarnott@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Some questions, or suggestions regarding the spec...<br>
<br>
Core<br>
Section 4.<br>
Why are UserInfo endpoint responses receivable in JSON?  If it's to<br>
make javascript client code easier, then you're encouraging using<br>
"eval" to execute arbitrary code from an untrusted server.  Query<br>
string syntax would protect against this, and is at least as friendly<br>
to web servers as JSON is.<br></blockquote><div><br></div></div><div>It was following OAuth's pattern of getting the response back in JSON </div><div>as well as following Facebook Graph API. </div><div><br></div><div>

Perhaps it is better to define a Query string version of response for </div>
<div>the implicit flow. Opinions? > Connectors. </div></div></blockquote><div><br></div><div>It's fine for OAuth (presumably) because clients only talk to a specific well-known set of authorization servers that they can decide to trust.  OpenID RPs don't have formally created trust relationships with OPs, so I think its critical that they don't execute code from them.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
"Each message" suggests any message of any type, yet the OAuth 2.0<br>
spec is more restrictive regarding which formats are allowed for<br>
specific message types.<br></blockquote><div><br></div></div><div>I think we are going to rename "core" to something like "messages" but </div><div>this document is much more general than OAuth so that we can use it </div>


<div>later to produce other bindings than HTTP. </div><div><br></div><div>To be useful, specifics has to be defined in the Binding Specs, </div><div>e.g., HTTP Redirect Binding. </div><div><br></div><div>This organization has been causing confusion among people, </div>


<div>so we are going to call "HTTP Redirect Binding" as either "Connect Core" </div><div>or just "Connect" to avoid the current confusion. </div></div></blockquote><div><br></div><div>I'm not really following your response here.  But I trust you understood me and that the right thing will happen. :)</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<br>
Section 4.1<br>
The query string serialization example includes extraneous text such<br>
as "GET", the path and other HTTP headers.<br></blockquote><div><br></div></div><div>Thanks for pointing out. </div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<br>
Section 4.2<br>
The normative instructions specify that parameters are at the "highest<br>
structure level" yet the non-normative example shows all the openid<br>
parameters added as a set of second-level parameters.<br></blockquote><div><br></div></div><div>I guess you are looking at an older version? </div><div>In any case, the current version still has the example wrong so need to fix. </div>

</div></blockquote><div><br></div><div>I was looking at draft 8.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im">


<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
UserInfo<br>
Section 2.1<br>
No text specifying that the parameters are sent as querystring, so<br>
when the access_token parameter is described as "REQUIRED", yet "MUST<br>
NOT be sent" if it's sent via Authorization header [not query string],<br>
it's confusing.  You are sending it if you're sending it any way at<br>
all.<br></blockquote><div><br></div></div><div>The recommended way of sending these parameters (exept 'id') is to use </div><div>HTTP Auth Header, though it does not preclude the possibility of using </div><div>HTTP POST.  Do you have alternative text proposal? </div>

</div></blockquote><div><br></div><div>Yes:</div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

<span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; ">REQUIRED. The access_token obtained from an OpenID Connect authorization request. This parameter MUST only be sent using one method (either query string or HTTP Authorization header).</span></blockquote>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What is this language about backward compatibility?  These specs are<br>
hot off the presses, aren't they?  How are older drafts we've never<br>
seen already implemented by enough people to justify including<br>
backward compat provisions in the first public spec?<br></blockquote><div><br></div></div><div>What older drafts are you referring to? </div></div></blockquote><div><br></div><div>I've never seen older drafts -- thus my question.  But the first draft that seemed to be public was titled "draft 8".</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<br>
Discovery<br>
Section 3<br>
Typo? "What MUST be returned in the response is the Java origin of the Issuer."<br></blockquote><div><br></div></div><div>I think this is fixed in the current draft (draft 02, July 12, 2011)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



_______________________________________________<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>
</blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a><br>


</blockquote></div><br>