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

Mike Jones Michael.Jones at microsoft.com
Wed Nov 23 19:36:50 UTC 2011


The definition you propose doesn't reference any of the "origin" definitions cites or say that this is about a postMessage profile.  I think it should.

In private notes on this topic, John Bradley had written:

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



====

I just set up a client ID for Google and it set a JS ORIGIN.

That doesn't convey that it is used only for postMessage.

The JS inter iFrame fragment flow also known as token or implicit in OAuth 2.0 uses redirect_uri to call the iframe from the RP.

Include the links to the google postMessage profile  from my last message that is the important part.

Can you propose a new definition that includes a reference providing a definition of same-origin policy and that incorporates John's suggestions above?

                                                            Thanks,
                                                            -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Edmund Jay
Sent: Wednesday, November 23, 2011 11:12 AM
To: openid-specs-ab at lists.openid.net
Subject: [Openid-specs-ab] Description of js_origin_uri (Javascrip Origin URI) in Client Registration Spec

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111123/7b595dc8/attachment.html>


More information about the Openid-specs-ab mailing list