[Openid-specs-ab] Comments on the OpenID Connect Standard spec 1.0 draft 4

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

Thanks,
George

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 4.1.1.2
> >
> > 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 4.1.1.2 could be...
> >
> > 
> https://server.example.com/authorize?request=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtx 
> dDMiLCJyZWRpcmVjdF91cmkiOiJodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2ZpbGUiLCJzd 
> GF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOnsiY2xhaW1zIjp7Im5hbWUiOm51bGwsIm5pY2tuYW1lIjp7Im9wdGlvbmFsIjp0cnVlfS 
> wiZW1haWwiOm51bGwsInZlcmlmaWVkIjpudWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sImZvcm1hdCI6InNpZ25lZCJ9LCJpZF9 
> 0b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiaXNvMjkxMTUiOiIyIn19.2OiqRgrbrHkA1FZ5p_7bc_RSdTbH-wo_Agk-ZRpD3wY
> >
>
> 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 4.1.4.1
> >
> > 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>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-- 
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...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110920/81937519/attachment.html>


More information about the Openid-specs-ab mailing list