[Openid-specs-ab] Reserved member definitions

[George Fletcher]

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.  SeeSection 4 
>> <http://self-issued.info/docs/draft-jones-json-web-token-05.html#anchor4>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> 
>> [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 
>> <mailto: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 <mailto: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

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