<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">* Section 4.1.1<br>
<br>
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.<br>
<br>
<br>
* Section 4.1.1.2<br>
<br>
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...<br>
<br>
<a class="moz-txt-link-freetext" href="https://server.example.com/authorize?request=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtx">https://server.example.com/authorize?request=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtx</a>
dDMiLCJyZWRpcmVjdF91cmkiOiJodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2ZpbGUiLCJzd
GF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOnsiY2xhaW1zIjp7Im5hbWUiOm51bGwsIm5pY2tuYW1lIjp7Im9wdGlvbmFsIjp0cnVlfS
wiZW1haWwiOm51bGwsInZlcmlmaWVkIjpudWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sImZvcm1hdCI6InNpZ25lZCJ9LCJpZF9
0b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiaXNvMjkxMTUiOiIyIn19.2OiqRgrbrHkA1FZ5p_7bc_RSdTbH-wo_Agk-ZRpD3wY<br>
<br>
<br>
* Section 4.1.1.2.1<br>
<br>
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.<br>
<br>
<br>
* Section 4.1.1.3.2<br>
<br>
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?<br>
<br>
<br>
* Section 4.1.4.1<br>
<br>
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.<br>
<br>
<br>
* Section 4.2.5.1 'id_token' description <br>
<br>
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.<br>
<br>
<br>
* Section 4.2.5.2<br>
<br>
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.<br>
<br>
<br>
* Section 5.1.1<br>
<br>
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.<br>
<br>
<br>
* Section 5.2<br>
<br>
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.<br>
<br>
<br>
* Section 5.2.1<br>
<br>
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?<br>
<br>
<br>
* Section 6.2.1<br>
<br>
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.<br>
<br>
<br>
* Section 7.2<br>
<br>
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?<br>
<br>
Thanks,<br>
George<br>
<br>
P.S. I also created a few issues for grammer and typos I found.</font><br>
<pre class="moz-signature" cols="72">--
Chief Architect AIM: gffletch
Identity Services Engineering Work: <a class="moz-txt-link-abbreviated" href="mailto:george.fletcher@teamaol.com">george.fletcher@teamaol.com</a>
AOL Inc. Home: <a class="moz-txt-link-abbreviated" href="mailto:gffletch@aol.com">gffletch@aol.com</a>
Mobile: +1-703-462-3494 Blog: <a class="moz-txt-link-freetext" href="http://practicalid.blogspot.com">http://practicalid.blogspot.com</a>
Office: +1-703-265-2544 Twitter: <a class="moz-txt-link-freetext" href="http://twitter.com/gffletch">http://twitter.com/gffletch</a>
</pre>
</body>
</html>