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

[John Bradley]

OK I will do that change.

John


On 2011-11-23, at 5:37 PM, Mike Jones wrote:

> I think that declaring reserved words at this point is overkill.  We’re only at (pre) Implementer’s Draft stage, after all.
>  
> For now, let’s just delete the js_origin_uri element and say in Registration that “other elements MAY be included in the registration”.
>  
> I do agree that we should avoid requiring redirect_uri for flows that don't use them.  For now, its inclusion should probably be RECOMMENDED or SHOULD, to be able to accommodate such flows in the future.
>  
>                                                             -- Mike
>  
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Breno de Medeiros
> Sent: Wednesday, November 23, 2011 12:27 PM
> To: John Bradley
> Cc: openid-specs-ab at lists.openid.net; Edmund Jay
> Subject: Re: [Openid-specs-ab] Description of js_origin_uri (Javascrip Origin URI) in Client Registration Spec
>  
> 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 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/9798210f/attachment.html>