<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Inline<br><div><div>On 2011-07-13, at 5:01 AM, Nat Sakimura wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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></blockquote><div><br></div><div>I don't know that having a key value form encoding of the User info endpoint response necessarily makes sense with some of the claims being JSON objects themselves.</div><div><br></div><div>I suppose it is something that we could add as an option if someone can describe a serialization.</div><div><br></div><div>The default response should remain JSON for the user Info endpoint.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><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></div></blockquote><div><br></div>I agree the current description is confusing.<br><blockquote type="cite"><div class="gmail_quote"><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></div></blockquote>That is fixed in the current example.   The example was from an earlier version.</div><div><br><blockquote type="cite"><div class="gmail_quote"><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></blockquote><div><br></div>Backwards computability refers to openID 2.0.   In earlier drafts of Artifact binding we were closer to 2.0 so there was a notion of backwards compatibility.  Some of that still needs to come out.<br><blockquote type="cite"><div class="gmail_quote"><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></blockquote><div><br></div>Changed in current draft.</div><div><br></div><div>Thanks </div><div><br></div><div>John B.<br><blockquote type="cite"><div class="gmail_quote"><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>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></body></html>