[Openid-specs-ab] Reserved member definitions

Mike Jones Michael.Jones at microsoft.com
Wed Sep 21 19:20:49 UTC 2011


Introducing a second schema option violates the "keep it simple" principle, would confuse developers, and hurt interoperability. That way lies madness.
________________________________
From: George Fletcher
Sent: Wednesday, September 21, 2011 12:13 PM
To: John Bradley
Cc: Mike Jones; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Reserved member definitions

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"<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> [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<mailto: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>
[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://example.com/janedoe/me.jpg>,
"http://xmlns.com/foaf/0.1/title"<http://xmlns.com/foaf/0.1/title>: "Ms"
}

-- Roland




_______________________________________________
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


_______________________________________________
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




_______________________________________________
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<mailto:george.fletcher at teamaol.com>
AOL Inc.                          Home: gffletch at aol.com<mailto: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/6593d662/attachment.html>


More information about the Openid-specs-ab mailing list