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

John Bradley ve7jtb at ve7jtb.com
Wed Nov 23 19:39:05 UTC 2011


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 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

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


More information about the Openid-specs-ab mailing list