[Openid-specs-ab] long_names checked in

Mike Jones Michael.Jones at microsoft.com
Tue Jul 12 19:57:20 UTC 2011


I've pushed these changes out (after updating the spec date).  We're now using long names like "id_token" rather than short names like "idt".  Changed specs were:

OpenID Connect Core:  http://openid.net/specs/openid-connect-core-1_0.html
OpenID Connect HTTP Redirect Binding:  http://openid.net/specs/openid-connect-http-redirect-1_0.html
OpenID Connect Framework:  http://openid.net/specs/openid-connect-framework-1_0.html

Thanks for doing these changes, Nat!

                                                                -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
Sent: Tuesday, July 12, 2011 11:28 AM
To: Breno de Medeiros
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Little more feedback

Sorry, forgot to attache the edited file.
I have bumped up the rev. number and added change log.
On Wed, Jul 13, 2011 at 3:25 AM, Nat Sakimura <sakimura at gmail.com<mailto:sakimura at gmail.com>> wrote:
Breno,
On Wed, Jul 13, 2011 at 2:45 AM, Breno de Medeiros <breno at google.com<mailto:breno at google.com>> wrote:

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

No. That is why I have not touch the specs in this respect yet.
As far as I remember, it was the decision of the WG to wait the reorganization until we finish the current pass of the spec review.
The files that I sent earlier and is attaching now has not done anything wrt this.
(Just to make note of, I have not done any edit wrt the comment you made as George is working on it. )

However, it does not preclude a parallel discussion of the possible reorganization.
Current state is that George suggested a reorganization, and Pam, John, Johnny, and me +1ed.
Pam further suggested to call the entire suite as Framework, and Johnny +1ed, but Tony -1ed.


feedback we get from developers is contrary to this.

So they like the current organization?


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.

Could you kindly explain the evidence so that I can understand better?


--
--Breno

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en



--
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/20110712/709016c5/attachment.html>


More information about the Openid-specs-ab mailing list