[Openid-specs-ab] Developer Feedback

Nat Sakimura sakimura at gmail.com
Tue Jul 12 13:39:23 UTC 2011


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 listOpenid-specs-ab at lists.openid.nethttp://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110712/4db6b8d5/attachment-0001.html>


More information about the Openid-specs-ab mailing list