<br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 12:27 PM, Andrew Arnott <span dir="ltr"><<a href="mailto:andrewarnott@gmail.com">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>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> </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>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> </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>Thanks for pointing out. </div><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>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> </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>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> </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>What older drafts are you referring to? </div><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>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">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/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>