[Openid-specs-ab] Little more feedback

John Bradley ve7jtb at ve7jtb.com
Tue Jul 12 20:05:42 UTC 2011


I think that is where we are heading.

The question in my mind is if some or all of messages also need to be in core,  or is it OK to have that as a separate document.

Nat and I are together all next week than Mike and I are together the week after.  
We decided on the call to wait for that F2F time before doing the major reorg surgery.

John B.
On 2011-07-12, at 2:28 PM, Breno de Medeiros wrote:

> On Tue, Jul 12, 2011 at 11:25, Nat Sakimura <sakimura at gmail.com> wrote:
>> Breno,
>> On Wed, Jul 13, 2011 at 2:45 AM, Breno de Medeiros <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?
> We have consistent feedback that the core should be: (1) an HTTP
> binding; (2) contain only the minimum necessary to create an SSO
> protocol.
> That means (according to common agreement in yesterday's call) how to
> express the most basic of OpenIDConnect requests and how to use the
> retrieved oauth2 token to obtain an audience-restricted statement of
> user id.
> I maintain that nothing else should be in the core.
>>> --
>>> --Breno
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>> http://twitter.com/_nat_en
> -- 
> --Breno
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

More information about the Openid-specs-ab mailing list