[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 20:27:07 UTC 2011


Well, there's nothing wrong with declaring reserved words without
specifying what they are for. That maybe a good compromise.

On Wed, Nov 23, 2011 at 12:21, John Bradley <ve7jtb at ve7jtb.com> wrote:

> We don't currently have a registration process for new registration
> elements.  Nothing stops someone from sending them, but nothing to stop
> collisions.
>
> It may be clearer to have reserved names for:
>
> postmessage_origin   The JS Origin to be used in a postMessage response
> postmessage_proxy   The Window ID to be used in a postMessage response.
> Default value is 'oauth2-relay-frame' if not specified.
>
> What I was trying to avoid was requiring redirect_uri for flows that don't
> use them.
>
> I like the post message response flow, it just needs more work to make it
> an extension.
>
> It might be better as an OAuth extension, as long as it can encode
> multiple tokens.
>
> If you want to do it all later that's fine.
>
> John B.
>
>
>
> On 2011-11-23, at 4:44 PM, Breno de Medeiros 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
> 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
>
>
>


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


More information about the Openid-specs-ab mailing list