[Openid-specs-ab] Reserved member definitions

Mike Jones Michael.Jones at microsoft.com
Tue Sep 20 22:15:49 UTC 2011

Actually, claim names need not be URIs.  See Section 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] 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.


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

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

More information about the Openid-specs-ab mailing list