[Openid-specs-ab] Little more feedback

Nat Sakimura sakimura at gmail.com
Tue Jul 12 17:17:26 UTC 2011


On Tue, Jul 12, 2011 at 7:44 AM, Pam Dingle <pdingle at pingidentity.com>wrote:

> 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
>
> Accept. Add definition on Claims Provider.

>
>    - 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)
>
> Accept in principle. Having said that I am not sure if we need all the
optional endpoints.
Authorization Endpoint, Token Endpoint, UserInfo Endpoint, Introspection
Endpoint suffice?

>
>    - Section 3.1.1 (ID Token) - in the definition of scope, the word
>    "string" should be plural
>
> Accept.

>
>    - 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
>
> Accept.

>
>    - 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).
>
> 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?


>
>
> Discovery:
>

I think John is still working on this so I let him handle it.

>
>    - 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.
>
> Accept in principle. Need further discussion.


> Session:
>
>    - Why does the ID Token have a claim of pape when eaa is used
>    everywhere else? Seems inconsistent
>
> Accept. Session needs more work. (Have not fixed it yet.)

>
>
> 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.
>

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)".


> 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).
>

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".


Since I still have not got the svn write access, I am attaching the fixed
files here.
Note - I have not fixed the date etc. yet, so regard them as just works in
progress.


>
> Hopefully this is useful,
>
> Thanks,
>
> Pamela
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110713/dfaa4e9d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openid-connect-core-1_0.xml
Type: text/xml
Size: 38676 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110713/dfaa4e9d/attachment-0003.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openid-connect-http-redirect-1_0.xml
Type: text/xml
Size: 53562 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110713/dfaa4e9d/attachment-0004.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openid-connect-framework-1_0.xml
Type: text/xml
Size: 47575 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110713/dfaa4e9d/attachment-0005.xml>


More information about the Openid-specs-ab mailing list