[Openid-specs-ab] Some feedback on OpenID Connect spec family

Nat Sakimura sakimura at gmail.com
Wed Jul 13 14:06:29 UTC 2011

On Wed, Jul 13, 2011 at 10:41 PM, Andrew Arnott <andrewarnott at gmail.com>wrote:

> On Wed, Jul 13, 2011 at 6:32 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> On Wed, Jul 13, 2011 at 12:27 PM, Andrew Arnott <andrewarnott at gmail.com>wrote:
>>> Some questions, or suggestions regarding the spec...
>>> Core
>>> Section 4.
>>> Why are UserInfo endpoint responses receivable in JSON?  If it's to
>>> make javascript client code easier, then you're encouraging using
>>> "eval" to execute arbitrary code from an untrusted server.  Query
>>> string syntax would protect against this, and is at least as friendly
>>> to web servers as JSON is.
>> It was following OAuth's pattern of getting the response back in JSON
>> as well as following Facebook Graph API.
>> Perhaps it is better to define a Query string version of response for
>> the implicit flow. Opinions? > Connectors.
>> I don't know that having a key value form encoding of the User info
>> endpoint response necessarily makes sense with some of the claims being JSON
>> objects themselves.
>> I suppose it is something that we could add as an option if someone can
>> describe a serialization.
>> The default response should remain JSON for the user Info endpoint.
> If the default response should remain JSON, are we going to have in the
> security section a comment saying RPs running as Javascript clients SHOULD
> NOT call the UserInfo endpoint and execute its results to deserialize the
> JSON objects?  Do you agree that would be dangerous?

Yes. Use json_parse.js or json-sans-eval like JSON parser which does not do

Nat Sakimura (=nat)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110713/3f95bb20/attachment.html>

More information about the Openid-specs-ab mailing list