<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Portable contacts have a namespace: <span class="Apple-style-span" style="color: rgb(68, 68, 68); font-family: 'courier new', monospace; font-size: 13px; line-height: 19px; "><a href="http://portablecontacts.net/ns/1.0">http://portablecontacts.net/ns/1.0</a></span><div><font class="Apple-style-span" color="#444444" face="'courier new', monospace"><span class="Apple-style-span" style="font-size: 13px; line-height: 19px;"><br></span></font></div><div><span class="Apple-style-span" style="line-height: 19px; ">They can all be used as claims in the request and response as the spec is now.<br></span></div><div><div><div><br></div><div>For supporting full portable contacts with sync and all of the other things, that is probably best done by publishing an additional poco endpoint.</div><div><br></div><div>John B.</div><div>On 2011-09-21, at 1:38 PM, George Fletcher wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">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.<br>
<br>
Thanks,<br>
George<br>
</font><br>
On 9/21/11 12:22 PM, Mike Jones wrote:
<blockquote cite="mid:4E1F6AAD24975D4BA5B16804296739435C1F9BA5@TK5EX14MBXC285.redmond.corp.microsoft.com" type="cite">
<pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [<a class="moz-txt-link-freetext" href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Justin Richer
Sent: Wednesday, September 21, 2011 9:09 AM
To: George Fletcher
Cc: <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>
Subject: Re: [Openid-specs-ab] Reserved member definitions
+1 poco
-- Justin
On Wed, 2011-09-21 at 12:06 -0400, George Fletcher wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I still like the idea of 'schema=poco' and then the schema is defined
:)
On 9/20/11 6:57 PM, John Bradley wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
[<a class="moz-txt-link-freetext" href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of
John Bradley
Sent: Tuesday, September 20, 2011 2:44 PM
To: Roland Hedberg
Cc: <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">19 sep 2011 kl. 23:54 skrev John Bradley:
</pre>
<blockquote type="cite">
<pre wrap="">I am sympathetic to the position.
However without namespace support in JSON, we just end up
</pre>
</blockquote>
</blockquote>
<pre wrap="">adding extra characters to the reserved names for not much more
than formal correctness.
</pre>
<blockquote type="cite">
<pre wrap="">Yeah, that is a serious limitation to JSON.
</pre>
<blockquote type="cite">
<pre wrap="">The decision was to go for a fixed schema (implied namespace)
</pre>
</blockquote>
</blockquote>
<pre wrap="">and fully namespaces claims.
</pre>
<blockquote type="cite">
<pre wrap="">What do you mean with 'fully namespaces claims' ?
</pre>
<blockquote type="cite">
<pre wrap="">Perhaps being clear that all of the reserved claim names have a
</pre>
</blockquote>
</blockquote>
<pre wrap="">implied namespace that is not included in the JSON itself.
</pre>
<blockquote type="cite">
<pre wrap="">That would be important in the future.
OpenID Connect comes from OpenID which I have understood as
</pre>
</blockquote>
<pre wrap="">being geared towards individuals maintaining their net identity.
</pre>
<blockquote type="cite">
<pre wrap="">I've been think about what it would take to make OpenID Connect
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">And the first thing I stumble across is the lack of/limited
</pre>
</blockquote>
<pre wrap="">extensibility of the schema.
</pre>
<blockquote type="cite">
<pre wrap="">This is a major limitation.
There is just a matter of course that there isn't an
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">So having an implied namespace for the OpenID Connect attributes
</pre>
</blockquote>
<pre wrap="">could we allow for 'fully qualified' attributes from other
namespaces ?
</pre>
<blockquote type="cite">
<pre wrap="">For instance:
{
"name": "Jane Doe"
"given_name": "Jane",
"family_name": "Doe",
"email": <a class="moz-txt-link-rfc2396E" href="mailto:janedoe@example.com">"janedoe@example.com"</a>,
"picture": <a class="moz-txt-link-rfc2396E" href="http://example.com/janedoe/me.jpg">"http://example.com/janedoe/me.jpg"</a>,
<a class="moz-txt-link-rfc2396E" href="http://xmlns.com/foaf/0.1/title">"http://xmlns.com/foaf/0.1/title"</a>: "Ms"
}
-- Roland
</pre>
</blockquote>
</blockquote>
<pre wrap="">
_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<pre wrap=""></pre>
</blockquote>
<pre wrap="">
_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></div></body></html>