[Openid-specs-ab] Reserved member definitions

George Fletcher gffletch at aol.com
Wed Sep 21 16:38:10 UTC 2011


Sorry Mike, I wasn't meaning to suggest that we reverse the decision. 
Just thinking that with the schema parameter, there is an extension 
point. While an OP MUST support the openid schema it could support other 
schemas. And so if an AS wants to support another schema it is easy to do.

Thanks,
George

On 9/21/11 12:22 PM, Mike Jones wrote:
> Having multiple schemas hurts - not helps - interoperability.  An explicit working group decision was made to move away from Portable Contact and to use a schema with lowercase_separated_by_underscores and names taken from Facebook Connect where they made sense, so as to make life easier for implementers who want to speak both OpenID Connect and Facebook Connect.
>
> I believe that this was the right decision to help adoption and I'm strongly against reversing it now.
>
> 				-- Mike
>
> -----Original Message-----
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Justin Richer
> Sent: Wednesday, September 21, 2011 9:09 AM
> To: George Fletcher
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Reserved member definitions
>
> +1 poco
>
>   -- Justin
>
> On Wed, 2011-09-21 at 12:06 -0400, George Fletcher wrote:
>> I still like the idea of 'schema=poco' and then the schema is defined
>> :)
>>
>> On 9/20/11 6:57 PM, John Bradley wrote:
>>> I took collision resistant namespace to be URI (including URN).
>>>
>>>
>>> I don't know that for user-info endpoint interoperability we
>>> necessarily want to go as far as JWT where almost anything is
>>> allowed.
>>>
>>>
>>> For openID connect we should require or strongly recommend URI for
>>> claims.   Otherwise we get IdP defining different semantics for the
>>> same claim names.
>>>
>>>
>>> John B.
>>>
>>> On 2011-09-20, at 7:15 PM, Mike Jones wrote:
>>>
>>>> Actually, claim names need not be URIs.  See Section 4 the JWT
>>>> spec, which allows the use of any of reserved claim names, public
>>>> claim names (which are to be taken from a collision-resistant
>>>> namespace), and private claim names (which can be any string at
>>>> all).  The UserInfo claim names are actually an example of the use
>>>> of private claim names.  Others could be used as well besides
>>>> those defined by the JWT and OpenID Connect Messages specs.
>>>>
>>>>                                                                  --
>>>> Mike
>>>>
>>>> -----Original Message-----
>>>> From: openid-specs-ab-bounces at lists.openid.net
>>>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of
>>>> John Bradley
>>>> Sent: Tuesday, September 20, 2011 2:44 PM
>>>> To: Roland Hedberg
>>>> Cc: openid-specs-ab at lists.openid.net
>>>> Subject: Re: [Openid-specs-ab] Reserved member definitions
>>>>
>>>> The schema is extended by using claims.
>>>>
>>>> All claim names MUST be URI.
>>>>
>>>> Just a small number of non URI strings are reserved in the schema
>>>> for common claims.
>>>>
>>>> So yes you could use foaf or eduperson URI.
>>>>
>>>> Perhaps that needs clarification.
>>>>
>>>> John
>>>>
>>>>
>>>> On 2011-09-20, at 3:39 AM, Roland Hedberg wrote:
>>>>
>>>>> 19 sep 2011 kl. 23:54 skrev John Bradley:
>>>>>
>>>>>> I am sympathetic to the position.
>>>>>>
>>>>>> However without namespace support in JSON, we just end up
>>>> adding extra characters to the reserved names for not much more
>>>> than formal correctness.
>>>>> Yeah, that is a serious limitation to JSON.
>>>>>
>>>>>> The decision was to go for a fixed schema (implied namespace)
>>>> and fully namespaces claims.
>>>>> What do you mean with 'fully namespaces claims' ?
>>>>>
>>>>>> Perhaps being clear that all of the reserved claim names have a
>>>> implied namespace that is not included in the JSON itself.
>>>>> That would be important in the future.
>>>>>
>>>>> OpenID Connect comes from OpenID which I have understood as
>>>> being geared towards individuals maintaining their net identity.
>>>>> I've been think about what it would take to make OpenID Connect
>>>> usable in an organization context or for that matter in the
>>>> context of federations of organizations. Something which I'd like
>>>> to see as in scope.
>>>>> And the first thing I stumble across is the lack of/limited
>>>> extensibility of the schema.
>>>>> This is a major limitation.
>>>>> There is just a matter of course that there isn't an
>>>> organization out there that doesn't have at least one attribute
>>>> that is specific to them (at least they think it is) that they
>>>> just have to have in an identity provider for it to be usable in
>>>> their context.
>>>>> So having an implied namespace for the OpenID Connect attributes
>>>> could we allow for 'fully qualified' attributes from other
>>>> namespaces ?
>>>>> For instance:
>>>>>
>>>>> {
>>>>> "name": "Jane Doe"
>>>>> "given_name": "Jane",
>>>>> "family_name": "Doe",
>>>>> "email": "janedoe at example.com",
>>>>> "picture": "http://example.com/janedoe/me.jpg",
>>>>> "http://xmlns.com/foaf/0.1/title": "Ms"
>>>>> }
>>>>>
>>>>> -- Roland
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>

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


More information about the Openid-specs-ab mailing list