[Openid-specs-ab] Description of js_origin_uri (Javascrip Origin URI) in Client Registration Spec

Breno de Medeiros breno at google.com
Wed Nov 23 19:58:20 UTC 2011

Does the registration spec allow for more parameters to be specified? If
so, we could probably drop it for now.

On Wed, Nov 23, 2011 at 11:56, Edmund Jay <ejay at mgi1.com> wrote:

> So, is this in favor of removing the js_origin_uri from the Registration
> spec?
> 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?
> ------------------------------
> *From:* Breno de Medeiros <breno at google.com>
> *To:* John Bradley <ve7jtb at ve7jtb.com>
> *Cc:* Edmund Jay <ejay at mgi1.com>; openid-specs-ab at lists.openid.net
> *Sent:* Wed, November 23, 2011 11:44:08 AM
> *Subject:* Re: [Openid-specs-ab] Description of js_origin_uri (Javascrip
> Origin URI) in Client Registration Spec
> In our implementation we currently name this parameter 'origin' which I
> think has the benefit of being shorter than 'js_origin_uri'.
> A JS Origin is a well-defined HTML5 concept. (And earlier HTML specs also,
> it has not changed.)
> 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.
> At some point I would like this group to work on postmessage binding for
> connect.
> On Wed, Nov 23, 2011 at 11:39, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> It is used only for postMessage.
>> Clients wishing to use postMessage MUST register a value.
>> Looking at Google's registration and the spec a single origin looks
>> sufficient.
>> A client MUST register a JS Origin if it is requesting a postMessage
>> response.
>> A client MUST register a redirect_uri if it is requesting a fragment
>> encoded response.
>> A client MAY register a redirect_uri if it is requesting a query
>> parameter encoded response.
>> For those that haven't read the google spec you send
>> redirect_uri="postmessage" in the request.
>> The registered js_origin_uri is used to send the response.
>> It would be nice if we had a oauth2-postmessage-profile<https://groups.google.com/group/oauth2-postmessage-profile> that
>> didn't require reading the JS source!
>> Breno should correct me if I have it wrong.
>> John B.
>> On 2011-11-23, at 4:11 PM, Edmund Jay wrote:
>>  In the Registration spec, we have a js_origin_uri field which requires
>> more explanation.
>> Currently, it's defined as :
>>     OPTIONAL. Space-separated list of JavaScript Origin URIs (used for
>> Post Message flow).
>> This description is not very informative as is, so the working group
>> decided to do some research.
>> In the case of OpenID Connect, JavaScript clients may be used to
>> implement parts of the specs.
>> JavaScript has a same origin policy that only permits pages to interact
>> with each other if they originate from the same origin.
>> 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.
>> Some general background about same origin policy can be found at
>> http://www.w3.org/Security/wiki/Same_Origin_Policy
>> HTML5 defines the exact mechanism for determining the effective origin of
>> a piece of Javascript by using it's "owner".
>> http://www.w3.org/TR/html5/origin-0.html#effective-script-origin
>> 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.
>> This page describes window.postMessage
>> https://developer.mozilla.org/en/DOM/window.postMessage
>> Project homepage:
>> http://code.google.com/p/oauth2-postmessage-profile/
>> Discussion:
>> https://groups.google.com/group/oauth2-postmessage-profile
>> Authorized JavaScript Origins
>>     For example: https://example.com
>> 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.
>> Would it be correct to define the js_origin_uri as follows :
>>     OPTIONAL. A Space-separated list of allowable URIs where client
>> Javascript used for interacting with Authorization Servers reside or
>> embedded.
>> Another question is, should we eliminate the js_origin_uri, since it's
>> not mentioned anywhere else?
>> Or do we need to elaborate more on how it's used in the other specs?
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> --
> --Breno

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111123/4073a1fb/attachment.html>

More information about the Openid-specs-ab mailing list