Hi all,<div><br></div><div>I've been going through the specs as well to try to draw up the summary page, here are a few inconsistencies I've noted, hopefully they aren't duplicates to what has been brought up before, I have tried to remove any I've found.   </div>


<div><br></div><div>Core:</div><div><ul><li>Claims Provider is used in the definition of Claims but is not itself defined or used anywhere else in this doc</li><li>User Info Endpoint is defined but the others are not (you find the definitions in other documents, but since most people will read core first, I think having them in core is important)</li>


<li>Section 3.1.1 (ID Token) - in the definition of scope, the word "string" should be plural</li><li>Section 3.1.2 (Authorization Response) </li><ul><li>most of this section describes how response_type should be formatted, but response_type isn't actually a query string element in the chosen example.  Suggest to do an example of both a request containing response_type and the subsequent redirection</li>


<li>there is a description of what response_type="none" but no description of what happens if there is no response type in the request.  If this is because response_type is declared as required in some other spec, we should put a reference to that location in (or else redundantly state that response_type is a required parameter).</li>


</ul></ul><div>Discovery:</div><div><ul><li>Section 3 only mentions that one item - the Java Origin of the Issuer - must be returned.  Section 4 says Issuer ID was discovered in the previous section - does that mean that Issuer ID == Java Origin?</li>


<li>Section 4.2 - the term eaa is not defined in the document and only mentioned in shorthand on one line. </li><ul><li>Suggest that this line in the table</li><ul><li>eaa_supported  | string | A comma separated list of the eaa that this server supports </li>


</ul><li>Becomes this line:</li><ul><li>eaa_supported | string | A comma separated list of the "entity authentication assurance" levels that this server supports [OpenID.CF]</li></ul></ul></ul><div>UserInfo:</div>


<ul><li>section 2.2 - the description of "must return a subset" and "may return additional attributes" seems to conflict to me.</li></ul><div>Session:</div><div><ul><li>Why does the ID Token have a claim of pape when eaa is used everywhere else? Seems inconsistent</li>


</ul></div><div>In general, I agree that the short names are confusing for beginners or people trying to discern meaning only from code.  I found the specs very easy to read and understand, but tough to know whether some pieces were required to be developed or just optional. </div>


</div><div><br></div><div>For example:  Core section 4 (Serialization) states that messages can be serialized in either format (JSON or Query String) unless expressly forbidden on a per-message basis -- but nothing in section 4 answers the question of whether or not an implementer is required to support both serializations to be conformant, or whether they can only support one.</div>


<div><br></div><div>Another example is ID Token - it appeared in the session and userinfo specs but not in the core, http binding, or framework spec (unless I missed it). </div><div><br></div><div>Hopefully this is useful,</div>

<div><br></div><div>Thanks,</div><div><br></div><div>Pamela</div><div><br></div><div><br></div><div><br></div>
</div>