[Openid-specs-ab] Little more feedback

Breno de Medeiros breno at google.com
Tue Jul 12 17:45:42 UTC 2011


On Tue, Jul 12, 2011 at 10:17, Nat Sakimura <sakimura at gmail.com> wrote:
>
>
> 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".

I don't think there's agreement in our group to do so. All the
feedback we get from developers is contrary to this.

The reason things are confusing right now has to do with the fact that
the spec has been refactored many times and the writing did not keep
up well. We need to fix the writing, not merge specs when we have
evidence it will be damaging to the message of
simplicity+extensibility we want to convey.

>
> 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
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>



-- 
--Breno


More information about the Openid-specs-ab mailing list