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

John Bradley ve7jtb at ve7jtb.com
Wed Jul 13 14:15:40 UTC 2011

I agree that it is something we need to discuss.

I am guessing that Google, Facebook, and sales force as IdP trust themselves as issuers so it has not been an issue.

The same concern would apply to parsing any JWT.

I think there are safe ways to parse JSON objects, however I am not the expert on that.

John B.
On 2011-07-13, at 9:41 AM, Andrew Arnott 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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110713/011f206f/attachment.html>

More information about the Openid-specs-ab mailing list