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