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

Andrew Arnott andrewarnott at gmail.com
Wed Jul 13 13:30:51 UTC 2011


Thanks, Nat.  Inline...

On Wed, Jul 13, 2011 at 2:01 AM, Nat Sakimura <sakimura at gmail.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.
>

It's fine for OAuth (presumably) because clients only talk to a specific
well-known set of authorization servers that they can decide to trust.
 OpenID RPs don't have formally created trust relationships with OPs, so I
think its critical that they don't execute code from them.



>
>
>>
>> "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'm not really following your response here.  But I trust you understood me
and that the right thing will happen. :)


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

I was looking at draft 8.


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

Yes:

> REQUIRED. The access_token obtained from an OpenID Connect authorization
> request. This parameter MUST only be sent using one method (either query
> string or HTTP Authorization header).



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

I've never seen older drafts -- thus my question.  But the first draft that
seemed to be public was titled "draft 8".


>
>
>>
>> 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)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110713/6d9e110f/attachment.html>


More information about the Openid-specs-ab mailing list