[Openid-specs-ab] Reserved member definitions

George Fletcher gffletch at aol.com
Wed Sep 21 19:12:29 UTC 2011


Hi John,

In looking at the most recent messages spec, it does not (at least in 
the userinfo section) discuss using claims with a namespace. Are you 
suggesting that the response would be something like...

{
    "http://portablecontacts.net/ns/1.0", { ... poco schema here ... }
}

or that each individual claim would be "prefixed" with the namespace. If 
this, then I can't find any test that says this is allowed or 
recommended. Maybe we should update the spec.

Agreed that full poco support should be handled by a poco endpoint.

Thanks,
George

On 9/21/11 1:29 PM, John Bradley wrote:
> Portable contacts have a namespace: http://portablecontacts.net/ns/1.0
>
> They can all be used as claims in the request and response as the spec 
> is now.
>
> For supporting full portable contacts with sync and all of the other 
> things, that is probably best done by publishing an additional poco 
> endpoint.
>
> John B.
> On 2011-09-21, at 1:38 PM, George Fletcher wrote:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net 
>> <mailto: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

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


More information about the Openid-specs-ab mailing list