sakimura at gmail.com
Thu Sep 29 01:15:32 UTC 2011
Actually, it is not only for the privacy sake, but a security problem as
JSONP is not safe to use in our use case where dynamic association may
=nat via iPhone
On 2011/09/29, at 9:29, hideki nara <hdknr at ic-tact.co.jp> wrote:
Thank you very much John.
In short, there must be some essential problem in JSONP itself for handling
not specific to using JSONP in OpenID.
Am I missing?
2011/9/29 John Bradley <ve7jtb at ve7jtb.com>
> 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.
> 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.
> Now in the case of an entirely JS client in the browser, there probably
> isn't much interesting they could do.
> 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.
> 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.
> I am hoping there are better HTML 5 ways to accomplish the same thing.
> On 2011-09-28, at 4:31 PM, hideki nara wrote:
> Hi, John.
> proper access_token
> and Cookie header which OP has Set-Cookied when the End Use was
> I'd like to know security problem around this scenario more precisely.
> 2011/9/28 John Bradley <ve7jtb at ve7jtb.com>
>> I think the issue was more of a security one.
>> perhaps unknown OP?
>> I know there are some people working on safe JSON-P
>> http://www.json-p.org/, however I don't know if that is mature enough
>> for us to include safely at this point, as it seems browser dependent.
>> Breno or others might be able to point to safe HTML 5 methods for doing
>> the same thing.
>> On 2011-09-28, at 5:06 AM, sakimura wrote:
>> > Actually, we used to have JSONP response in earlier drafts.
>> > It was dropped in preference of HTML5 postMessage, I think.
>> > =nat
>> > On Fri, 16 Sep 2011 14:24:13 +0200, Andreas üükre Solberg wrote:
>> >> I'm thinking of making a proof of concept Connect client that runs in
>> >> the browser.
>> >> I cannot think of a use case where it really makes a lot of sense,
>> >> though. What do you think?
>> >> With the implicit grant flow, it is possible and pretty simple to do
>> >> this proof of concept. You can get an access token, and the id token,
>> >> and even verify the id token, and extract the user id. What you cannot
>> >> do, though is access the user info service. To make the user info
>> >> service work, the only neccessary step; was to add support for JSONP.
>> >> Is there any good descriptions (concrete examples) available on what
>> >> use cases the implicit grant flow serves?
>> >> Andreas
>> > _______________________________________________
>> > 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...
More information about the Openid-specs-ab