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

[George Fletcher]

* Section 4.1.1

I assume that scope could include other values that are out-of-scope for 
this specification but are needed by the client and "authorizable" by 
the AS. For example, the client wants an access token that identifies 
the user and has "chat-service" authorization.


* 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


* Section 4.1.1.2.1

The second paragraph requires the client to send the request to the 
Authorization Server as an HTTP POST if the AS supports the HTTP POST 
method. Does this imply that the client is required to use HTTP POST 
redirects to redirect the user's browser to the AS? The non-normative 
example uses and HTTP GET redirect.


* Section 4.1.1.3.2

States.. "The Client SHOULD send the request using the HTTP GET method, 
but MAY send it via the HTTP POST if the authorization server supports 
it as defined in..." which seem to be the opposite semantics of section 
4.1.1.2.1. Is this intentional?


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


* Section 4.2.5.1  'id_token' description

Section 4.2.1. requires id_token to be present. If it's required for 
this flow, then do we need the "if" clause in the description. NOTE: 
from the phone call today (9/19/2011) it seems that how the client 
requests the id_token may not match what's in this document so this 
might no longer be an issue.


* Section 4.2.5.2

Should the AS return the 'state' parameter since this is an async 
response? In section 4.1.4.2 'state' is returned in the non-normative 
example.


* Section 5.1.1

I think it's confusing that the non-normative example has more 
parameters than are described. I think it would be good to reiterate 
that the client MAY provide client authentication credentials per OAuth2 
section 2.3.1. Note that OAuth2 prefers the use of HTTP Basic 
Authentication for presenting client credentials.


* Section 5.2

Why must the scope include 'openid'? What if the client is trying to 
retrieve a "down-scoped" token where scope is just "chat-service"? Is 
the expectation that the client can use the refresh_token in all the 
normal OAuth2 ways, and this section is just describing the additional 
feature provided by OpenID Connect? If so, it might be helpful to add 
some text to this effect.


* Section 5.2.1

What if the user's session is gone but initially retrieved access_token 
and refresh_token provided "offline access" scope. If the access_token 
is expired and needs to be refreshed via the refresh_token, do I receive 
an empty id_token?


* Section 6.2.1

If the userinfo endpoint is an OAuth2 protected resources, then 
shouldn't errors follow the OAuth2 Bearer token spec which requires a 
WWW-Authenticate HTTP response header with the error details. Note that 
returning JSON in the response does nothing for "Implicit flow" clients 
because they won't even see the data because the browser won't invoke 
the JS because of the HTTP error.


* Section 7.2

What is the purpose of allowing the check session endpoint returning a 
signed or encrypted JWT as the response? If the client can handle signed 
or encrypted JWTs, wouldn't the client for-go the check session endpoint 
and just validate the id_token locally?

Thanks,
George

P.S. I also created a few issues for grammer and typos I found.

-- 
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/20110919/92435664/attachment.html>