[Openid-specs-ab] Developer Feedback

Pam Dingle pdingle at pingidentity.com
Tue Jul 12 17:10:32 UTC 2011


I like the idea of *not* using the work 'framework' for any specific
document.  That way the whole suite could be called a framework or any other
analogous term without confusion.

I've attached a simple initial map showing George's proposed naming - I made
several assumptions that could likely be incorrect, let me know what's
inaccurate.

   - I put the JW* series outside the OpenID Connect realm, as I believe
   they are dependencies but not direct members
   - I added a separate dynamic client registration box, because I wasn't
   sure if George's proposal simply missed that doc or if the plan was to roll
   the doc into one of the other proposed titles

The nice thing about this set is that it the additional value props of
OpenID Connect are spelled right out in the titles.  If you don't want to do
the additional add-on in the title, just don't read/implement that doc.

I'm going to use this map as a placeholder in the summary doc for the real
thing, to be updated when the decision is made, so style suggestions are
also welcome :)


On Tue, Jul 12, 2011 at 10:06 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

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


-- 
*Pamela Dingle*  |  Sr. Technical Architect
*Ping**Identity*  |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
*O:* 303-999-5890   *M:* 303-999-5890
*Email:* pdingle at pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
*Connect with Ping*
Twitter: @pingidentity
LinkedIn Group: Ping's Identity Cloud
Facebook.com/pingidentitypage
*Connect with me*
Twitter: @pamelarosiedee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110712/799e5e53/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenIDConnect-NamingProposal.pdf
Type: application/pdf
Size: 12317 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110712/799e5e53/attachment-0001.pdf>


More information about the Openid-specs-ab mailing list