[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