[Openid-specs-ab] Feedback on UserInfo schema

Henrik Biering hb at peercraft.com
Fri Mar 8 01:59:56 UTC 2013


+1
to provide equal support for emailadresses and phone numbers as verified 
identifiers
to not restrict verification methods to SMS (or distinguish between pots 
and mobile phones)

Henrik

Den 07-03-2013 20:06, Torsten Lodderstedt wrote:
> +1
>
> some use cases require validation in Germany (and probably other jurisdictions), e.g. sending messages to the respective user or using the number as user id
>
> And yep, there are other verification methods :-)
>
> Am 07.03.2013 um 17:50 schrieb Chuck Mortimore <cmortimore at salesforce.com>:
>
>> +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
> _______________________________________________
> 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