[Openid-specs-ab] Little more feedback
Pam Dingle
pdingle at pingidentity.com
Mon Jul 11 22:44:54 UTC 2011
Hi all,
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.
Core:
- Claims Provider is used in the definition of Claims but is not itself
defined or used anywhere else in this doc
- 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)
- Section 3.1.1 (ID Token) - in the definition of scope, the word
"string" should be plural
- Section 3.1.2 (Authorization Response)
- 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
- 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).
Discovery:
- 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?
- Section 4.2 - the term eaa is not defined in the document and only
mentioned in shorthand on one line.
- Suggest that this line in the table
- eaa_supported | string | A comma separated list of the eaa that
this server supports
- Becomes this line:
- eaa_supported | string | A comma separated list of the "entity
authentication assurance" levels that this server supports [OpenID.CF]
UserInfo:
- section 2.2 - the description of "must return a subset" and "may return
additional attributes" seems to conflict to me.
Session:
- Why does the ID Token have a claim of pape when eaa is used everywhere
else? Seems inconsistent
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.
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.
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).
Hopefully this is useful,
Thanks,
Pamela
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110711/3a327d75/attachment.html>
More information about the Openid-specs-ab
mailing list