Here is my review of the Basic Client doc, draft 12: My first thought is that this is a *really* readable document. Congratulations on keeping things simple, and creating a document flow that is simple and straightforward.<div>
<br></div><div>Most of my comments are typos and definitions - the only serious question I have about the underlying meaning/content of a section is in section 4. As much as the Check Session endpoint is all about the currently authenticated user, I think that the User Info endpoint needs to serve profile information for the lifetime of the access token, not just the lifetime of the initial session. Perhaps I'm just misinterpreting?</div>
<div><br></div><div>Thanks,</div><div><br></div><div>Pamela</div><div><br><div><br></div><div>Introduction: </div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>
<b>text</b>: "OpenID Connect Basic Client is a profile of the full OpenID Connect 1.0 Specification that is designed to be easy to read and implement for Relying Parties"</div><div><b>comment</b>: Are we saying that in OpenID Connect, Relying Parties and Clients are the same thing? </div>
<div><br></div></blockquote>Section 2: Terminology<div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><ul><li>The following terms are used but not defined in either Basic Client or in the referred OAuth 2.0 spec:</li>
<ul><li>Identity Provider</li><li>Relying Party</li><li>User-Agent</li><li>Assertion</li></ul></ul></div></blockquote><div><br></div>Section 3: Protocol Flows</div><div><ul><li>text: "Clients wanting to use the code flow and Identity Providers should consult the full OpenID 1.0 specification"</li>
<li>comment: can we point to a specific document where the code flow is described? Standard perhaps?</li></ul><div><br></div><div>Section 3.2.1: Client Prepares an Authorization Request</div><div><ul><li>scope parameter:</li>
<ul><li>definition of scope should not start with "It". </li><li>suggestion: replace "It MUST include openid as one of the space separated strings" with "Scope MUST include openid as one of the space separated strings"</li>
</ul><li>redirect_uri parameter:</li><ul><li>typo: missing a closing parenthesis</li></ul><li>prompt parameter:</li><ul><li>need a reference to the OpenID Connect document where login, consent, and select_account are defined.</li>
</ul><li>typo: "Authorization servers MUST support" should be "Authorization Servers MUST support"</li></ul><div>Section 3.3: Check Session Endpoint</div></div><div><ul><li>typo in the end of the first sentence: id-token should be replaced with id_token</li>
</ul><div>Section 4: UserInfo Endpoint</div></div><div><ul><li>text: "The id_token and Check Session Endpoint MUST be used to validate the identity of a session"</li><li>comment: Is this meant to say that the User Info endpoint can only be used when a user has a valid session? What happens if the client has a valid access token but the session has expired? Should the User Info endpoint refuse to serve the data?</li>
<li>I think that there are many situations where information about the user needs to be retrieved without an active session. If we want to differentiate between "information about the (this moment) authenticated user" and "information about the owner of the supplied access token", we need to be much clearer.</li>
</ul><div>Section 6: Security Considerations:</div></div><div><ul><li>We have a whole bunch of sections about security considerations of assertions - but nowhere in the implicit flow are assertions mentioned. Is the id_token an assertion? If so we should say so. If not, we should define what exactly is.</li>
<li>Suggest putting all the assertion threats together, ie section 6.1.1, 6.1.2, etc</li></ul><div><br></div></div><div>Section 6.9: Availability</div><div><ul><li>Which server is "the server"? Which server is the "web server"? And why is the client allowing the USER to associate multiple servers? Generally the user has nothing to do with redundancy.... This section is not helpful as written. </li>
</ul></div><div><br></div><div><div><div><div><div><br></div>-- <br><span style="font-family:'Lucida Grande', Tahoma, Arial, Verdana, sans-serif;font-size:10px;color:rgb(42, 42, 42)"><font color="#343634" face="Tahoma" style="color:rgb(52, 54, 52);font-size:12px"><strong><span>Pamela Dingle</span></strong> | <span>Sr. Technical Architect</span></font><br>
<font face="Arial" style="font-size:11px"><font color="#343634" face="Tahoma"><strong>Ping</strong></font><font color="#E71939" face="Tahoma"><strong>Identity</strong></font> | <a href="http://www.pingidentity.com" target="_blank">www.pingidentity.com</a><br>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br><font color="#005568"><strong>O:</strong></font> <font color="#343634"><span>303-999-5890</span></font> <font color="#005568"><strong>M:</strong></font> <font color="#343634"><span>303-999-5890</span></font><br>
<font color="#005568"><strong>Email:</strong></font> <span><a href="mailto:pdingle@pingidentity.com" target="_blank">pdingle@pingidentity.com</a></span><br>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br>
<table cellpadding="0" cellspacing="0"><tbody><tr valign="top"><td nowrap><div style="float:left"><font face="Arial" style="font-size:11px"><font color="#005568"><strong>Connect with Ping</strong></font><br><font color="#000000">Twitter: @pingidentity</font><br>
<font color="#000000">LinkedIn Group: Ping's Identity Cloud</font> <br><font color="#000000">Facebook.com/pingidentitypage</font></font></div></td><td nowrap><div style="margin-left:20px"><font face="Arial" style="font-size:11px"><font color="#005568"><strong><span>Connect with me</span></strong></font><br>
<font color="#000000"><span>Twitter: @pamelarosiedee</span></font><br><font color="#000000"><span></span></font></font></div></td></tr></tbody></table></font></span><br>
</div></div></div></div></div></div>