[Openid-specs-ab] Comments on the OpenID Connect Standard spec 1.0 draft 4
gffletch at aol.com
Tue Sep 20 01:37:06 UTC 2011
* 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 184.108.40.206
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 220.127.116.11 could be...
* Section 18.104.22.168.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 22.214.171.124.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
126.96.36.199.1. Is this intentional?
* Section 188.8.131.52
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 184.108.40.206 '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 220.127.116.11
Should the AS return the 'state' parameter since this is an async
response? In section 18.104.22.168 'state' is returned in the non-normative
* 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?
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...
More information about the Openid-specs-ab