[Openid-specs-ab] Feedback on UserInfo schema

Mike Jones Michael.Jones at microsoft.com
Thu Mar 7 17:24:20 UTC 2013


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.

We *did*, however, decide to clarify how phone numbers with extensions should be represented.

See https://bitbucket.org/openid/connect/issue/800/ for more details.

				-- Mike

-----Original Message-----
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Chuck Mortimore
Sent: Thursday, March 07, 2013 8:51 AM
To: Ryo Ito
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Feedback on UserInfo schema

+1 although I wouldn't constrain to SMS as the verification method, and 
+simply say mobile_phone_verified

- cmort

On Mar 7, 2013, at 8:30 AM, "Ryo Ito" <ritou.06 at gmail.com> wrote:

> Some services verify user's mobile phone number by sending SMS.
> "sms_verified" claim may be useful if "mobile_phone" scope is defined.
> This is the same as relations of "email" and "email_verified" claims.
> 
> Ryo
> 
> 2013/3/8 nov matake <nov at matake.jp>:
>> Does "phone" scope include "mobile_number" claim?
>> or do we need another scope for mobile phone?
>> 
>> I think we need "mobile_phone" scope.
>> 
>> On 2013/03/07, at 6:54, Nat Sakimura <sakimura at gmail.com> wrote:
>> 
>> I am fine with it, though how to create "formatted phone number" 
>> needs to be clarified. Is it just how the user entered or created 
>> algorithmically? If the later, the OP needs to have translation 
>> template for each countries as they widely varies. As to the syntax 
>> is concerned, I prefer phone_number_formatted instead of 
>> formatted_phone_number. Also, a +1 for making E.164 a MUST for the machine consumption.
>> 
>> With respect to phone number, it just reminded me of the fact that 
>> multiple sources expressed desire to differentiate land line phone 
>> number and mobile phone number. Their characteristics as to the 
>> binding strength to the subject is very different. Land line usually 
>> is only bound to the "home / household" or "office location", the 
>> mobile phone number is much more tightly coupled with the person / 
>> subject. So, actually, you may not want to treat them as a single class.
>> 
>> So, in addition to phone_number, I would like to propose 
>> mobile_number as well.
>> 
>> Nat
>> 
>> 
>> 2013/3/7 Mike Jones <Michael.Jones at microsoft.com>
>>> 
>>> I would be fine with having both phone number claims.
>>> "formatted_phone_number" could be the display form (just like 
>>> "formatted" is the address display form) and "phone_number" could be an RFC 3966 phone
>>> number.   The "phone" scope would request both.
>>> 
>>> What claim names is Google actually using for these values today?
>>> 
>>> What do others think?
>>> 
>>>                                -- Mike
>>> 
>>> -----Original Message-----
>>> From: openid-specs-ab-bounces at lists.openid.net
>>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Breno 
>>> de Medeiros
>>> Sent: Wednesday, March 06, 2013 9:15 AM
>>> To: openid-specs-ab at lists.openid.net
>>> Subject: [Openid-specs-ab] Feedback on UserInfo schema
>>> 
>>> Google returns phone numbers in two different formats: The 
>>> display-friendly displayable format that follows the user 
>>> preferences on how they see the number, and a standard-compliant form for machines.
>>> 
>>> The UserInfo spec documents a 'phone_number' field that appears to 
>>> try to be both. It's the user 'preferred' phone number (indicating 
>>> some allowance for display-friendliness) and then only RECOMMENDS format compliance.
>>> 
>>> Option 1. Define two fields: display_phone_number and 
>>> std_phone_number, where the latter MUST be in the E164 or RFC3966 
>>> (the latter deals with phone extensions as well).
>>> 
>>> Option 2. Clarify the current language by replacing RECOMMENDED with 
>>> MUST if the desire is to support machine use cases
>>> 
>>> Option 3. Clarity the current language by saying that this is for 
>>> display purposes only.
>>> 
>>> --
>>> --Breno
>>> _______________________________________________
>>> 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
>> 
>> 
>> 
>> 
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> _______________________________________________
>> 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
> 
> 
> 
> --
> ====================
> Ryo Ito
> Email : ritou.06 at gmail.com
> ====================
> _______________________________________________
> 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