[Openid-specs-ab] Comments on the OpenID Connect Standard spec 1.0 draft 4
gffletch at aol.com
Tue Sep 20 19:12:21 UTC 2011
Ok, that makes sense. I think we need to add some text to that affect.
As for processing rules, is the AS supposed to ignore any parameter that
is in the query/post parameter list if there is a matching parameter in
request object? It seems strange to allow a request where the data is
different between the two sets of parameters. I'd prefer to reject any
request where the same named parameters don't match.
On 9/20/11 2:19 PM, Edmund Jay wrote:
> The query parameters need to be sent even when "request" parameter is
> sent because the request needs to conform to OAuth specs.
> The "request" parameter is an extension parameter used for creating
> more complex requests and as a way to sign/encrypt the request.
> Therefore the query parameters need to be present in the "request"
> object also and will take precedence.
> *From:* Roland Hedberg <roland.hedberg at adm.umu.se>
> *To:* George Fletcher <gffletch at aol.com>
> *Cc:* "openid-specs-ab at lists.openid.net"
> <openid-specs-ab at lists.openid.net>
> *Sent:* Mon, September 19, 2011 11:49:53 PM
> *Subject:* Re: [Openid-specs-ab] Comments on the OpenID Connect
> Standard spec 1.0 draft 4
> 20 sep 2011 kl. 03:37 skrev George Fletcher:
> > * Section 126.96.36.199
> > The second paragraph says that parameters specified in the "OpenID
> Request Object" take precedence over query parameters. Yet the
> non-normative example, shows the same parameter in both the query
> string and the OpenID Request Object. Given that the Request Object
> takes precedence, isn't just the request object enough? So the last
> example in section 188.8.131.52 could be...
> I went through the same reasoning but I came out the other end with
> the idea that the parameters that matter, those you want to sign, they
> should be in the request JWT and those that isn't vital (are there any
> such) could be in the query string.
> Anyway I also see no reason for parameters to be in both.
> > * Section 184.108.40.206
> > This probably isn't an issue, but ensuring the entire URL does not
> exceed 512 bytes, requires both the AS and the Client to work
> together. If the client has a really large state value, and the AS has
> a large code value, the combined length could be greater than 512.
> Agreed, a bad behaved client can make it impossible for a server to
> construct URLs shorter then 512 bytes.
> -- Roland
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
Chief Architect AIM: gffletch
Identity Services Engineering Work: george.fletcher at teamaol.com
AOL Inc. Home: gffletch at aol.com
Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab