OK. That probably does not work. Currently, it states: <div><br></div><div><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif;background-color:rgb(255,255,255)">The UserInfo Endpoint MUST return Claims in JSON format unless a different format was specified during registration </span><a class="info" href="http://openid.bitbucket.org/openid-connect-messages-1_0.html#OpenID.Registration" style="font-weight:bold;text-decoration:none;color:rgb(102,51,51);background-color:rgb(255,255,255);font-family:verdana,charcoal,helvetica,arial,sans-serif">[OpenID.Registration]</a><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif;background-color:rgb(255,255,255)">. The UserInfo Endpoint MAY return Claims in JWT format, which can be signed and/or encrypted. The UserInfo Endpoint MUST return a content-type header to indicate the format that is being returned. The following are accepted content types:</span></div>
<div><font face="verdana, charcoal, helvetica, arial, sans-serif"><br></font></div><div><font face="verdana, charcoal, helvetica, arial, sans-serif">So, Userinfo response does not have to be JWT. So we need to have some words on the extension in non JWT cases. Also, even if it is JWT, it is so obscure. It would probably be kinder to state about how claims can be extended regardless. </font></div>
<div><font face="verdana, charcoal, helvetica, arial, sans-serif"><br></font></div><div><font face="verdana, charcoal, helvetica, arial, sans-serif">Nat<br></font><br><div class="gmail_quote">2013/3/7 Mike Jones <span dir="ltr"><<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">That’s in the JWT spec. See
<a href="http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-4.2" target="_blank">
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-4.2</a> on Public Claim Names.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> -- Mike<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Nat Sakimura [mailto:<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>]
<br>
<b>Sent:</b> Wednesday, March 06, 2013 2:50 PM<br>
<b>To:</b> Breno de Medeiros<br>
<b>Cc:</b> Mike Jones; <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-ab] Feedback on UserInfo schema<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">OK. If we were to add phone_number_formatted, we should state that this is <u></u><u></u></p>
<div>
<p class="MsoNormal">the string that the user entered. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">BTW, where can I find the text that claims can be extended with URI as claim names etc.? <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Nat<u></u><u></u></p>
<div>
<p class="MsoNormal">2013/3/7 Breno de Medeiros <<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>><u></u><u></u></p>
<p class="MsoNormal">The display version is as user entered, or in the common format of the<br>
user's locale. It should be displayed as is.<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On Wed, Mar 6, 2013 at 1:54 PM, Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:<br>
> I am fine with it, though how to create "formatted phone number" needs to be<br>
> clarified. Is it just how the user entered or created algorithmically? If<br>
> the later, the OP needs to have translation template for each countries as<br>
> they widely varies. As to the syntax is concerned, I prefer<br>
> phone_number_formatted instead of formatted_phone_number. Also, a +1 for<br>
> making E.164 a MUST for the machine consumption.<br>
><br>
> With respect to phone number, it just reminded me of the fact that multiple<br>
> sources expressed desire to differentiate land line phone number and mobile<br>
> phone number. Their characteristics as to the binding strength to the<br>
> subject is very different. Land line usually is only bound to the "home /<br>
> household" or "office location", the mobile phone number is much more<br>
> tightly coupled with the person / subject. So, actually, you may not want to<br>
> treat them as a single class.<br>
><br>
> So, in addition to phone_number, I would like to propose mobile_number as<br>
> well.<br>
><br>
> Nat<br>
><br>
><br>
> 2013/3/7 Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>><br>
>><br>
>> I would be fine with having both phone number claims.<br>
>> "formatted_phone_number" could be the display form (just like "formatted" is<br>
>> the address display form) and "phone_number" could be an RFC 3966 phone<br>
>> number. The "phone" scope would request both.<br>
>><br>
>> What claim names is Google actually using for these values today?<br>
>><br>
>> What do others think?<br>
>><br>
>> -- Mike<br>
>><br>
>> -----Original Message-----<br>
>> From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a><br>
>> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Breno de<br>
>> Medeiros<br>
>> Sent: Wednesday, March 06, 2013 9:15 AM<br>
>> To: <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
>> Subject: [Openid-specs-ab] Feedback on UserInfo schema<br>
>><br>
>> Google returns phone numbers in two different formats: The<br>
>> display-friendly displayable format that follows the user preferences on how<br>
>> they see the number, and a standard-compliant form for machines.<br>
>><br>
>> The UserInfo spec documents a 'phone_number' field that appears to try to<br>
>> be both. It's the user 'preferred' phone number (indicating some allowance<br>
>> for display-friendliness) and then only RECOMMENDS format compliance.<br>
>><br>
>> Option 1. Define two fields: display_phone_number and std_phone_number,<br>
>> where the latter MUST be in the E164 or RFC3966 (the latter deals with phone<br>
>> extensions as well).<br>
>><br>
>> Option 2. Clarify the current language by replacing RECOMMENDED with MUST<br>
>> if the desire is to support machine use cases<br>
>><br>
>> Option 3. Clarity the current language by saying that this is for display<br>
>> purposes only.<br>
>><br>
>> --<br>
>> --Breno<br>
>> _______________________________________________<br>
>> Openid-specs-ab mailing list<br>
>> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">
http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>> _______________________________________________<br>
>> Openid-specs-ab mailing list<br>
>> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">
http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Nat Sakimura (=nat)<br>
> Chairman, OpenID Foundation<br>
> <a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
> @_nat_en<br>
<br>
<br>
<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal">--<br>
--Breno<u></u><u></u></p>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <br>
Nat Sakimura (=nat)<u></u><u></u></p>
<div>
<p class="MsoNormal">Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<u></u><u></u></p>
</div>
</div>
</div></div></div>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>
</div>