[Openid-specs-ab] Reserved member definitions

Mike Jones Michael.Jones at microsoft.com
Wed Sep 21 16:22:44 UTC 2011


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



More information about the Openid-specs-ab mailing list