Hi all,<div><br></div><div>I took at look at the OpenID Connect Lite 1.0 - draft 06 spec, and I think it's great that the WG is writing a self contained easy to read spec for implementors. I haven't been following OpenID Connect all that closely, so perhaps I can give a fresh perspective on what's been written so far.</div>
<div><br></div><div><b>General Feedback:</b></div><div><br></div><div>Since the ID Token is a new concept, it would be a good idea to explain what it is, and how/when implementors should use it.</div><div><br></div><div>Implicit vs code flow: Implementors should be given more guidance as to how to decide which flow to use. The introduction to Section 3 definitely needs some more clarification.  Widely used documentation from existing implementations use the terms Server Side Flow for Code, and Client Side Flow for Implicit. </div>
<div><br></div><div>Why can't the Introspection and UserInfo endpoints be combined into a single endpoint?</div><div><br></div><div>Feedback on specific sections:</div><div><br></div><div><b>Section 3.1.1</b></div><div>
<b><br></b></div><div>PPID Scope - Unless there's widespread demand from implementors for PPID responses, I'd recommend moving PPID responses to an extension. As far as I know, PPID identifiers are not widely used for "Connect" type deployments, and mentioning it in the Lite spec hurts readability.</div>
<div><br></div><div>Display: none,popup,touch,mobile - These values should be defined, or otherwise moved to an extension. Listing optional values without defining them hurts readability.</div><div><br></div><div>Prompt: login,consent,select_account - Either define them, or remove them. Same situation as with the Display parameter.</div>
<div><br></div><div><br></div><div><b>Section 3.1.4 </b></div><div><br></div><div>Paragraph needs to be rewritten - it's unclear what implementors are supposed to do.</div><div><br></div><div><b>Section 3.1.5.1</b></div>
<div><br></div><div>Shouldn't there be an id_token in the response? Section 3.1.1 says that response_type=id_token was required in the request.</div><div><br></div><div><b>Section 3.2.2</b></div><div><br></div><div>iss - Is this like the client_id, but for the server? How is this used? What's to stop a server from reusing another server's iss?</div>
<div><br></div><div>user_id - is this globally unique? Unique for the domain? </div><div><br></div><div>aud/issued_to - why two different parameters for the same thing?</div><div><br></div><div>exp - in addition to the expiration timestamp, it might be useful to return a boolean indicating whether or not the token is valid or expired. (Clients might not know what time it is)</div>
<div><br></div><div><br></div><div><b>Section 4.1 </b></div><div><br></div><div>The description for the id parameter is confusing.</div><div><br></div><div><br></div><div>I hope my feedback was helpful,</div><div>Allen</div>
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>