Well, there's nothing wrong with declaring reserved words without specifying what they are for. That maybe a good compromise.<br><br><div class="gmail_quote">On Wed, Nov 23, 2011 at 12:21, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com">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">We don't currently have a registration process for new registration elements.  Nothing stops someone from sending them, but nothing to stop collisions.<div>
<br></div><div>It may be clearer to have reserved names for:</div><div><br></div><div>postmessage_origin   The JS Origin to be used in a postMessage response</div><div>postmessage_proxy   The Window ID to be used in a postMessage response. Default value is '<span style="border-collapse:collapse;color:rgb(0,136,0);font-family:Monaco,'DejaVu Sans Mono','Bitstream Vera Sans Mono','Lucida Console',monospace;font-size:12px;white-space:pre-wrap">oauth2-relay-frame'</span><span style="border-collapse:collapse;white-space:pre-wrap;background-color:transparent"> if not specified.</span></div>
<div><span style="border-collapse:collapse;white-space:pre-wrap;background-color:transparent"><br></span></div><div><span style="border-collapse:collapse;white-space:pre-wrap;background-color:transparent">What I was trying to avoid was requiring redirect_uri for flows that don't use them.</span></div>
<div><span style="border-collapse:collapse;white-space:pre-wrap;background-color:transparent"><br></span></div><div><span style="border-collapse:collapse;white-space:pre-wrap;background-color:transparent">I like the post message response flow, it just needs more work to make it an extension.</span></div>
<div><span style="border-collapse:collapse;white-space:pre-wrap;background-color:transparent"><br></span></div><div><span style="border-collapse:collapse;white-space:pre-wrap;background-color:transparent">It might be better as an OAuth extension, as long as it can encode multiple tokens.</span></div>
<div><span style="border-collapse:collapse;white-space:pre-wrap;background-color:transparent"><br></span></div><div><span style="border-collapse:collapse;white-space:pre-wrap;background-color:transparent">If you want to do it all later that's fine.</span></div>
<div><span style="border-collapse:collapse;white-space:pre-wrap;background-color:transparent"><br></span></div><div><span style="border-collapse:collapse;white-space:pre-wrap;background-color:transparent">John B.</span></div>
<div><div class="h5"><div><span style="border-collapse:collapse;white-space:pre-wrap;background-color:transparent"><br></span></div><div><span style="border-collapse:collapse;white-space:pre-wrap;background-color:transparent"><br>
</span></div><div><br><div><div>On 2011-11-23, at 4:44 PM, Breno de Medeiros wrote:</div><br><blockquote type="cite">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 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 style="font-family:tahoma,'new york',times,serif;font-size:13px">js_origin_uri is used to send the response.</span></div><div><span style="font-family:tahoma,'new york',times,serif;font-size:13px"><br>

</span></div><div><span style="font-family:tahoma,'new york',times,serif;font-size:13px">It would be nice if we had a </span><span style="font-family:tahoma,'new york',times,serif;font-size:13px"><a 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 style="font-family:tahoma,'new york',times,serif;font-size:13px"><br></span></div><div><span style="font-family:tahoma,'new york',times,serif;font-size:13px">Breno should correct me if I have it wrong.</span></div>

<div><span style="font-family:tahoma,'new york',times,serif;font-size:13px"><br></span></div><div><span style="font-family:tahoma,'new york',times,serif;font-size:13px">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-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>

<div><div><div style="margin-right:0px;font-size:10pt;margin-left:0px;margin-bottom:0px;font-family:tahoma,'new york',times,serif;margin-top:0px"><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 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 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 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 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 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></div></span></blockquote></div><br></div></div></div></blockquote></div>
<br>
<br clear="all"><div><br></div>-- <br>--Breno<br>
</div>
</blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>--Breno<br>