<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The RP is the one at risk. They windup exciting JS from the IdP. In openID Connect that may be an unknown IdP that they just registered with.<div><br></div><div>As I understand it if the OP returns a proper JSON-P response that is not a problem, however the IdP might return other JS that might affect the RP.</div><div><br></div><div>Now in the case of an entirely JS client in the browser, there probably isn't much interesting they could do.</div><div><br></div><div>However the general concern over having the IdP return a script stands. Unless we are certain that it will not create a security problem we need to be cautious.</div><div><br></div><div>The specific issue was having the user-info endpoint return responses in JSON-P so that a pure JS client loaded from a different domain can access the endpoint.</div><div><br></div><div>I am hoping there are better HTML 5 ways to accomplish the same thing.</div><div><br></div><div>John</div><div><br><div><div>On 2011-09-28, at 4:31 PM, hideki nara wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi, John.<br><br>A JSONP request from a Javascript MUST includes Authorization header with a proper access_token <br>and Cookie header which OP has Set-Cookied when the End Use was authenticated.<br>I'd like to know security problem around this scenario more precisely.<br>
<br>---<br>hdknr<br><br><div class="gmail_quote">2011/9/28 John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I think the issue was more of a security one.<br>
<br>
Do we really want to be responsible for having RP execute JavaScript from perhaps unknown OP?<br>
<br>
I know there are some people working on safe JSON-P <a href="http://www.json-p.org/" target="_blank">http://www.json-p.org/</a>, however I don't know if that is mature enough for us to include safely at this point, as it seems browser dependent.<br>
<br>
Breno or others might be able to point to safe HTML 5 methods for doing the same thing.<br>
<font color="#888888"><br>
John<br>
</font><div><div></div><div class="h5">On 2011-09-28, at 5:06 AM, sakimura wrote:<br>
<br>
> Actually, we used to have JSONP response in earlier drafts.<br>
><br>
> It was dropped in preference of HTML5 postMessage, I think.<br>
><br>
> =nat<br>
><br>
> On Fri, 16 Sep 2011 14:24:13 +0200, Andreas Åkre Solberg wrote:<br>
>> I'm thinking of making a proof of concept Connect client that runs in<br>
>> the browser.<br>
>><br>
>> I cannot think of a use case where it really makes a lot of sense,<br>
>> though. What do you think?<br>
>><br>
>> With the implicit grant flow, it is possible and pretty simple to do<br>
>> this proof of concept. You can get an access token, and the id token,<br>
>> and even verify the id token, and extract the user id. What you cannot<br>
>> do, though is access the user info service. To make the user info<br>
>> service work, the only neccessary step; was to add support for JSONP.<br>
>><br>
>> Is there any good descriptions (concrete examples) available on what<br>
>> use cases the implicit grant flow serves?<br>
>><br>
>> Andreas<br>
><br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
</div></div><br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br>
</blockquote></div><br></div></body></html>