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

Nat Sakimura sakimura at gmail.com
Wed Nov 23 22:33:28 UTC 2011

I believe we have been careful enough not to exclude postMessage flow. That
has been a cause for confusion for some readers but it was for a good

=nat via iPhone

On 2011/11/24, at 4:44, Breno de Medeiros <breno at google.com> wrote:

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

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


Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111124/c1f5ff8d/attachment.html>

More information about the Openid-specs-ab mailing list