<br><br><div class="gmail_quote">On Tue, Jul 12, 2011 at 7:44 AM, Pam Dingle <span dir="ltr"><<a href="mailto:pdingle@pingidentity.com">pdingle@pingidentity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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></ul></div></blockquote><div>Accept. Add definition on Claims Provider. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><ul><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>
</ul></div></blockquote><div>Accept in principle. Having said that I am not sure if we need all the optional endpoints. </div><div>Authorization Endpoint, Token Endpoint, UserInfo Endpoint, Introspection Endpoint suffice? </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><ul>
<li>Section 3.1.1 (ID Token) - in the definition of scope, the word "string" should be plural</li></ul></div></blockquote><div>Accept. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><ul><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>
</ul></ul></div></blockquote><div>Accept. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><ul><ul>
<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></blockquote><div>Perhaps there was "none" in earlier spec of OAuth but I do not find one anymore. What is the use of it? Could anyone explain? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><ul><ul>
</ul></ul><div>Discovery:</div></div></blockquote><div><br></div><div>I think John is still working on this so I let him handle it. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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></div></blockquote><div>Accept in principle. Need further discussion. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><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></div></blockquote><div>Accept. Session needs more work. (Have not fixed it yet.) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><div>
<ul>
</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></blockquote><div><br></div><div>Actually, "core", which is likely to be called something like "Connect Messages" are just listing all the possible variations on messages as a reference, so it does not say anything about conformance. It should be defined in the "Bindings" such as "OpenID Connect (was: HTTP Redirect Binding)". </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><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></blockquote><div><br></div><div>Things were separated out due to some request from the community member, but it proves to be more confusing than not. I suggest re-combining "core" and "framework" and call it "Connect Messages". </div>
<div><br></div><div><br></div><div>Since I still have not got the svn write access, I am attaching the fixed files here. </div><div>Note - I have not fixed the date etc. yet, so regard them as just works in progress. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><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>
<br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>