<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
margin-top:7.5pt;
margin-right:0in;
margin-bottom:0in;
margin-left:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:975717719;
mso-list-template-ids:-636162012;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I actually view the mobile phone number request and the request for having separate display and canonical phone number representations and possibly having verified
phone numbers as being a lot like the country_code claim proposal in <a href="https://bitbucket.org/openid/connect/issue/798/messages-25-add-country_code-claim">
https://bitbucket.org/openid/connect/issue/798/messages-25-add-country_code-claim</a> – not that it’s not useful, but that it’s not necessary to enable interaction with a basic RP. Mark Wahl’s eventual conclusion about country_code may be illustrative here
as well. I quote from the “won’t fix” result:<o:p></o:p></span></p>
<p style="margin-left:.25in"><span lang="EN" style="font-size:10.5pt;font-family:"Arial","sans-serif";color:#333333">Mark Wahl withdrew his request to have this added to the set of standard claims upon further discussion, not because it's not useful, but because
it's not needed to enable interaction with simple RPs.<o:p></o:p></span></p>
<p style="margin-left:.25in"><span lang="EN" style="font-size:10.5pt;font-family:"Arial","sans-serif";color:#333333">Rather than adding it to the standard set, he instead proposed that we define an extended set of enterprise-focused claims in a separate specification.
This might also include claims to indicate the user's affiliation, and other standard claims typically found in a corporate directory.<o:p></o:p></span></p>
<p style="margin-left:.25in"><span lang="EN" style="font-size:10.5pt;font-family:"Arial","sans-serif";color:#333333">For the record, his use case was having a claim saying which country's laws should apply to the session.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I completely agree that a verified mobile phone number would be useful in some application contexts. That doesn’t mean that it has to be in the standard claim
set, any more than country_code has to be.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We have a mechanism for defining additional claims outside the basic set. For those needing verified mobile phone numbers, they can easily define additional
claims for that (or even better yet, use ones from existing schemas), and use them. If there’s a business need, there won’t be any problem getting those OPs and RPs to choose to use the additional claims – particularly if they’re in a well-defined profile
specifying an additional set of claims that meet the needs of their use case.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’m with John on this. We should be discussing adding any additional claims not strictly needed for enabling interactions with a majority of simple RPs in
a holistic fashion at this point, and not tacking them on one at a time because they might be useful to someone. Nearly all of them would be useful to someone.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> -- Mike
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<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""> John Bradley [mailto:ve7jtb@ve7jtb.com]
<br>
<b>Sent:</b> Thursday, March 07, 2013 5:04 PM<br>
<b>To:</b> Nat Sakimura<br>
<b>Cc:</b> Mike Jones; openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-ab] Feedback on UserInfo schema<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The discussion on the call was not against verification in any way but that multiple phone numbers etc are all part of existing schemas.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For complicated provisioning we should be pointing to SCIM or some other schema rather than incrementally adding to the simple account registration schema that we defined for the user_info endpoint.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Once we start adding elements piecemeal it is a slippery slope. What about work and personal mobile and home vs work landline. We also have Multiple postal , home and work addresses each of those can also be verified as in the Yahoo
Japan case.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So I would not characterize the discussion as rejecting the notion of phone verification only saying that the existing schema is intended to be as simple as possible for account registration based on current RP experience from Google Facebook
and others.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If we are going to do something more complex it needs to be done as a proper schema design and not tacked on to the current account registration schema incrementally.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That leaves SCIM, portableContacts , EDUPerson and perhaps AD schemas as possibilities. (some much better than others) <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We need to have that discussion in a larger group. I prefer to have the larger discussion rather than picking elements off one at a time.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">John B.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On 2013-03-08, at 9:14 AM, Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">As the chair of the WG, I have a bit of problem to state that "the working group decided" here. WG is not just the people who have called in to a telephone conference but the sum of the all people who is expressing their desire. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">From the minute, I see that John Bradley, Mike Jones, Roland Hedberg, Justin Richer, Brian Campbell, Edmund Jay, George Fletcher, Pamela Dingle was in the call but those people on this thread, me, nov, Ryo, Chuck, and Torsten expressing
the desire in having mobile number were not. Given that I heard this desire from another WG person, I suspect that there are more people thinking the same. I gather that the consensus is not yet reached. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">I would float the issue for a few more days -- till Sunday US time. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Please discuss. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Nat<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">2013/3/8 Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>><o:p></o:p></p>
<p class="MsoNormal">FYI, the working group decided to keep only a single phone number, because even that isn't typically needed for our design use case for the UserInfo Endpoint, which is enabling easy interaction with basic RPs. In particular, people felt
strongly that we shouldn't be inventing new Connect-specific phone number schemas; if people need more specific data, they should probably use schemas that already exist, such as Portable Contacts or SCIM.<br>
<br>
We *did*, however, decide to clarify how phone numbers with extensions should be represented.<br>
<br>
See <a href="https://bitbucket.org/openid/connect/issue/800/" target="_blank">https://bitbucket.org/openid/connect/issue/800/</a> for more details.<br>
<br>
-- Mike<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
-----Original Message-----<br>
From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Chuck Mortimore<br>
Sent: Thursday, March 07, 2013 8:51 AM<br>
To: Ryo Ito<br>
Cc: <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
Subject: Re: [Openid-specs-ab] Feedback on UserInfo schema<br>
<br>
+1 although I wouldn't constrain to SMS as the verification method, and<o:p></o:p></p>
</div>
<p class="MsoNormal">+simply say mobile_phone_verified<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
- cmort<br>
<br>
On Mar 7, 2013, at 8:30 AM, "Ryo Ito" <<a href="mailto:ritou.06@gmail.com">ritou.06@gmail.com</a>> wrote:<br>
<br>
> Some services verify user's mobile phone number by sending SMS.<br>
> "sms_verified" claim may be useful if "mobile_phone" scope is defined.<br>
> This is the same as relations of "email" and "email_verified" claims.<br>
><br>
> Ryo<br>
><br>
> 2013/3/8 nov matake <<a href="mailto:nov@matake.jp">nov@matake.jp</a>>:<br>
>> Does "phone" scope include "mobile_number" claim?<br>
>> or do we need another scope for mobile phone?<br>
>><br>
>> I think we need "mobile_phone" scope.<br>
>><br>
>> On 2013/03/07, at 6:54, Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>> wrote:<br>
>><br>
>> I am fine with it, though how to create "formatted phone number"<br>
>> needs to be clarified. Is it just how the user entered or created<br>
>> algorithmically? If the later, the OP needs to have translation<br>
>> template for each countries as they widely varies. As to the syntax<br>
>> is concerned, I prefer phone_number_formatted instead of<br>
>> formatted_phone_number. Also, a +1 for making E.164 a MUST for the machine consumption.<br>
>><br>
>> With respect to phone number, it just reminded me of the fact that<br>
>> multiple sources expressed desire to differentiate land line phone<br>
>> number and mobile phone number. Their characteristics as to the<br>
>> binding strength to the subject is very different. Land line usually<br>
>> is only bound to the "home / household" or "office location", the<br>
>> mobile phone number is much more tightly coupled with the person /<br>
>> subject. So, actually, you may not want to treat them as a single class.<br>
>><br>
>> So, in addition to phone_number, I would like to propose<br>
>> mobile_number as well.<br>
>><br>
>> Nat<br>
>><br>
>><br>
>> 2013/3/7 Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">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<br>
>>> "formatted" is 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">openid-specs-ab-bounces@lists.openid.net</a><br>
>>> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Breno<br>
>>> de Medeiros<br>
>>> Sent: Wednesday, March 06, 2013 9:15 AM<br>
>>> To: <a href="mailto:openid-specs-ab@lists.openid.net">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<br>
>>> preferences on how they see the number, and a standard-compliant form for machines.<br>
>>><br>
>>> The UserInfo spec documents a 'phone_number' field that appears to<br>
>>> try to be both. It's the user 'preferred' phone number (indicating<br>
>>> some allowance for display-friendliness) and then only RECOMMENDS format compliance.<br>
>>><br>
>>> Option 1. Define two fields: display_phone_number and<br>
>>> std_phone_number, where the latter MUST be in the E164 or RFC3966<br>
>>> (the latter deals with phone extensions as well).<br>
>>><br>
>>> Option 2. Clarify the current language by replacing RECOMMENDED with<br>
>>> MUST if the desire is to support machine use cases<br>
>>><br>
>>> Option 3. Clarity the current language by saying that this is for<br>
>>> display purposes only.<br>
>>><br>
>>> --<br>
>>> --Breno<br>
>>> _______________________________________________<br>
>>> Openid-specs-ab mailing list<br>
>>> <a href="mailto:Openid-specs-ab@lists.openid.net">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">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>
>> Openid-specs-ab mailing list<br>
>> <a href="mailto:Openid-specs-ab@lists.openid.net">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>
>> Openid-specs-ab mailing list<br>
>> <a href="mailto:Openid-specs-ab@lists.openid.net">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>
> Ryo Ito<br>
> Email : <a href="mailto:ritou.06@gmail.com">ritou.06@gmail.com</a><br>
> ====================<br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">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">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">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><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Nat Sakimura (=nat)<o:p></o:p></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<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>