[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.html>
More information about the Openid-specs-ab
mailing list