Does the registration spec allow for more parameters to be specified? If so, we could probably drop it for now.<br><br><div class="gmail_quote">On Wed, Nov 23, 2011 at 11:56, Edmund Jay <span dir="ltr"><<a href="mailto:ejay@mgi1.com">ejay@mgi1.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div style="font-family:tahoma,new york,times,serif;font-size:10pt"><div>So, is this in favor of removing the js_origin_uri from the Registration spec?<br>
As I mentioned before, the Registration spec is the only place where it's mentioned and the companion specs do not mention it and offers no guidance in its usage. If it's part of implementation detail like the postmessage binding, perhaps it should be moved there?<br>
<br><br></div><div style="font-family:tahoma,new york,times,serif;font-size:10pt"><br><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight:bold">From:</span></b> Breno de Medeiros <<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>><br>
<b><span style="font-weight:bold">To:</span></b> John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>><br><b><span style="font-weight:bold">Cc:</span></b> Edmund
 Jay <<a href="mailto:ejay@mgi1.com" target="_blank">ejay@mgi1.com</a>>; <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br><b><span style="font-weight:bold">Sent:</span></b> Wed, November 23, 2011 11:44:08 AM<br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [Openid-specs-ab] Description of js_origin_uri (Javascrip Origin URI) in Client Registration Spec<br></font><div><div class="h5"><br>In our implementation we currently name this parameter 'origin' which I think has the benefit of being shorter than 'js_origin_uri'.<div>
<br></div><div>A JS Origin is a well-defined HTML5 concept. (And earlier HTML specs also, it has not changed.) </div>
<div><br></div><div>I am not sure we need to put it in the spec provided that we write the spec so that other bindings than HTTP redirect transport (e.g., postmessage-based transport) are allowed to be composed.</div><div>

<br></div><div>At some point I would like this group to work on postmessage binding for connect.<br><br><div class="gmail_quote">On Wed, Nov 23, 2011 at 11:39, John Bradley <span dir="ltr"><<a rel="nofollow" href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">It is used only for postMessage.<div><br></div><div>Clients wishing to use postMessage MUST register a value.</div>

<div><br></div><div>Looking at Google's registration and the spec a single origin looks sufficient.</div><div><br></div><div>A client MUST register a JS Origin if it is requesting a postMessage response.</div><div>A client MUST register a redirect_uri if it is requesting a fragment encoded response.</div>

<div><div><br></div><div>A client MAY register a redirect_uri if it is requesting a query parameter encoded response.</div><div><br></div><div>For those that haven't read the google spec you send redirect_uri="postmessage" in the request.</div>

<div>The registered <span>js_origin_uri is used to send the response.</span></div><div><span><br>
</span></div><div><span>It would be nice if we had a </span><span><a rel="nofollow" href="https://groups.google.com/group/oauth2-postmessage-profile" target="_blank">oauth2-postmessage-profile</a> that didn't require reading the JS source! </span></div>

<div><span><br></span></div><div><span>Breno should correct me if I have it wrong.</span></div>
<div><span><br></span></div><div><span>John B.</span></div><div><br><div><div>
<div><div>On 2011-11-23, at 4:11 PM, Edmund Jay wrote:</div><br></div></div><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>

<div><div><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">
In the Registration spec, we have a js_origin_uri field which requires more explanation.<br>Currently, it's defined as :<br>    OPTIONAL. Space-separated list of JavaScript Origin URIs (used for Post Message flow).<span> </span><br>

<br>This description is not very informative as is, so the working group decided to do some research.<br><br>In the case of OpenID Connect, JavaScript clients may be used to implement parts of the specs.<br>JavaScript has a same origin policy that only permits pages to interact with each other if they originate from the same origin.<br>

Origin is defined by the scheme, host, and port of a URL. Pages have the same origin if and only if the scheme, host, and port matches exactly.<br><br><span>Some general background about same origin policy can be found at<span> </span><a rel="nofollow" href="http://www.w3.org/Security/wiki/Same_Origin_Policy" target="_blank">http://www.w3.org/Security/wiki/Same_Origin_Policy</a></span><br>

<br>HTML5 defines the exact mechanism for determining the effective origin of a piece of Javascript by using it's "owner".<br><span><a rel="nofollow" href="http://www.w3.org/TR/html5/origin-0.html#effective-script-origin" target="_blank">http://www.w3.org/TR/html5/origin-0.html#effective-script-origin</a></span><br>

<br><br>Given this restriction, there are techniques used by providers to allow cross domain communication. Otherwise, only scripts in the same origin as the providers would be able to work.<br><br>This page describes window.postMessage<br>

<span><a rel="nofollow" href="https://developer.mozilla.org/en/DOM/window.postMessage" target="_blank">https://developer.mozilla.org/en/DOM/window.postMessage</a></span><br><br>Project homepage:<br><span><a rel="nofollow" href="http://code.google.com/p/oauth2-postmessage-profile/" target="_blank">http://code.google.com/p/oauth2-postmessage-profile/</a></span><br>

<br>Discussion:<br><span><a rel="nofollow" href="https://groups.google.com/group/oauth2-postmessage-profile" target="_blank">https://groups.google.com/group/oauth2-postmessage-profile</a></span><br><br>Authorized JavaScript Origins<br>
<span>    For example:<span> </span><a rel="nofollow" href="https://example.com" target="_blank">https://example.com</a></span><br>
<br><br>So for the Registration spec, it would just be a list of allowable URIs where client Javascript resides that would interact with the Authorization servers.<span> </span><br><br>Would it be correct to define the js_origin_uri as follows :<br>

<br>    OPTIONAL. A Space-separated list of allowable URIs where client Javascript used for interacting with Authorization Servers reside or embedded.<br><br>Another question is, should we eliminate the js_origin_uri, since it's not mentioned anywhere else?<br>

Or do we need to elaborate more on how it's used in the other specs?</div></div></div></div>_______________________________________________<br>Openid-specs-ab mailing list<br><a rel="nofollow" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>

<a rel="nofollow" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></div></span></blockquote></div><br></div></div></div></blockquote>
</div><br>
<br clear="all"><div><br></div>-- <br>--Breno<br>
</div>
</div></div></div></div>



</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>--Breno<br>