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

Andrew Arnott andrewarnott at gmail.com
Wed Jul 13 03:27:47 UTC 2011


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.

"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.

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

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.

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.

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?

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


More information about the Openid-specs-ab mailing list