[Openid-specs-ab] Developer Feedback

[John Bradley]

That is sounding better.

On 2011-07-12, at 9:39 AM, Nat Sakimura wrote:

> To me, it sounds like a good idea. (Ok. I am not a marketing type so I may be completely off...) 
> 
> Let us see what the community think. 
> 
> =nat
> 
> On Tue, Jul 12, 2011 at 10:21 PM, George Fletcher <gffletch at aol.com> wrote:
> I was wondering about something like...
> 
> OpenID Connect (HTTP Binding with normative references to OpenID Connect Messages)
> OpenID Connect Session Management (with normative references to OpenID Connect Messages)
> OpenID Connect Messages (contains all abstract messages both Basic and Advanced)
> OpenID Discovery
> 
> OpenID UserInfo 
> 
> If we need other profiles we can add them. Not sure if this breaks the desired modularity, but from a developer perspective would be easier for me to follow. I know what doc to start with and it can reference another doc to provide message details as necessary.
> 
> Thanks,
> George
> 
> On 7/11/11 6:23 PM, Nat Sakimura wrote:
>> 
>> 
>> On Tue, Jul 12, 2011 at 5:05 AM, Johnny Bufu <jbufu at janrain.com> wrote:
>> On 11-07-11 10:16 AM, Nat Sakimura wrote:
>> 1. We should make sure to place HTTP Redirect Binding as the Center Piece.
>>    This actually is the confusion that even Breno was falling into. He
>> was thinking that Core was something to be implemented.
>>    It is not. It is the HTTP Redirect Binding that the developers
>> should read. We may want to rename it to something more
>>    attractive and feel as the main spec. (Perhaps rename core as
>> "Messages" and let the HTTP Binding assume the name
>> "Core" etc.?)
>> 
>> Just for the sake of the call: 
>> 
>> Mike's suggestion: 
>> 
>>  Core Messages
>>  Core Bindings
>>  Framework Messages
>>  Framework Bindings
>> 
>> My suggestions are 
>> 
>>     Basic Messages (for Connect)
>>     Advanced Messages (for Connect)
>>     Basic (HTTP bindings)
>>     Advanced
>>  
>> 
>> I too feel that the current number of separate documents makes it harder to get the big picture, even though I like modular specs. I guess the modularization is not laid out in a way that's easy to get. For example:
>> 
>> - The separation between what is an "abstract" message and what a binding is required/allowed to define is not very clear.
>> 
>> - ID Tokens are needed, one way or another (JWT encoded or not) to complete a full OpenID-Connect authentication. I'd rather learn about them from Core.
>> 
>> - UserInfo endpoint seems to be covered by both UserInfo and Framework specs.
>> 
>> 
>> 2. Short names are unpopular.
>> [...]
>> 
>> Here are my suggestions:
>> inf -> userinfo
>> idt -> id_token
>> clm -> claims
>> fmt -> format
>> mxa -> max_age
>> eaa -> iso29115
>> nor -> unsigned
>> sig -> signed
>> enc -> encrypted
>> aat -> auth_time
>> loc -> locale
>> opt -> optional
>> 
>> +1 if there's no clear technical reason that prevents using these slightly longer names.
>> 
>> Johnny
>> 
>> 
>> 
>> -- 
>> 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
> 
> -- 
> Chief Architect                   AIM:  gffletch
> Identity Services Engineering     Work: george.fletcher at teamaol.com
> AOL Inc.                          Home: gffletch at aol.com
> Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
> Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch
> 
> 
> 
> -- 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110712/b001f87e/attachment.html>