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

Nat Sakimura sakimura at gmail.com
Wed Jul 13 09:01:21 UTC 2011

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.

> "Each message" suggests any message of any type, yet the OAuth 2.0
> spec is more restrictive regarding which formats are allowed for
> specific message types.

I think we are going to rename "core" to something like "messages" but
this document is much more general than OAuth so that we can use it
later to produce other bindings than HTTP.

To be useful, specifics has to be defined in the Binding Specs,
e.g., HTTP Redirect Binding.

This organization has been causing confusion among people,
so we are going to call "HTTP Redirect Binding" as either "Connect Core"
or just "Connect" to avoid the current confusion.

> Section 4.1
> The query string serialization example includes extraneous text such
> as "GET", the path and other HTTP headers.

Thanks for pointing out.

> Section 4.2
> The normative instructions specify that parameters are at the "highest
> structure level" yet the non-normative example shows all the openid
> parameters added as a set of second-level parameters.

I guess you are looking at an older version?
In any case, the current version still has the example wrong so need to

> UserInfo
> Section 2.1
> No text specifying that the parameters are sent as querystring, so
> when the access_token parameter is described as "REQUIRED", yet "MUST
> NOT be sent" if it's sent via Authorization header [not query string],
> it's confusing.  You are sending it if you're sending it any way at
> all.

The recommended way of sending these parameters (exept 'id') is to use
HTTP Auth Header, though it does not preclude the possibility of using
HTTP POST.  Do you have alternative text proposal?

> What is this language about backward compatibility?  These specs are
> hot off the presses, aren't they?  How are older drafts we've never
> seen already implemented by enough people to justify including
> backward compat provisions in the first public spec?

What older drafts are you referring to?

> Discovery
> Section 3
> Typo? "What MUST be returned in the response is the Java origin of the
> Issuer."

I think this is fixed in the current draft (draft 02, July 12, 2011)

> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

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

More information about the Openid-specs-ab mailing list