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

[John Bradley]

Inline
On 2011-07-13, at 5:01 AM, Nat Sakimura 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.

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

I agree the current description is confusing.
> 
> 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 fix. 
>  
That is fixed in the current example.   The example was from an earlier version.

> 
> 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? 

Backwards computability refers to openID 2.0.   In earlier drafts of Artifact binding we were closer to 2.0 so there was a notion of backwards compatibility.  Some of that still needs to come out.
>  
> 
> 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)

Changed in current draft.

Thanks 

John B.
>  
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

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