[Openid-specs-ab] Feedback on UserInfo schema

Henrik Biering hb at peercraft.com
Fri Mar 8 01:44:07 UTC 2013 

+1
(could not agree more to every aspect of this)

Henrik

Den 08-03-2013 02:04, John Bradley wrote:
> The discussion on the call was not against verification in any way but 
> that multiple phone numbers etc are all part of existing schemas.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> That leaves SCIM, portableContacts , EDUPerson and perhaps AD schemas 
> as possibilities. (some much better than others)
>
> 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.
>
> John B.
>
> On 2013-03-08, at 9:14 AM, Nat Sakimura <sakimura at gmail.com 
> <mailto:sakimura at gmail.com>> wrote:
>
>> 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.
>>
>> 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.
>>
>> I would float the issue for a few more days -- till Sunday US time.
>>
>> Please discuss.
>>
>> Nat
>>
>> 2013/3/8 Mike Jones <Michael.Jones at microsoft.com 
>> <mailto:Michael.Jones at microsoft.com>>
>>
>>     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>
>>     [mailto: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
>>     <mailto: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
>>     <mailto: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 <mailto: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
>>     <mailto: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
>>     <mailto: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>
>>     >>> [mailto: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
>>     <mailto: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
>>     <mailto: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
>>     <mailto: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
>>     <mailto: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
>>     <mailto:Openid-specs-ab at lists.openid.net>
>>     >> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>     >
>>     >
>>     >
>>     > --
>>     > ====================
>>     > Ryo Ito
>>     > Email : ritou.06 at gmail.com <mailto:ritou.06 at gmail.com>
>>     > ====================
>>     > _______________________________________________
>>     > Openid-specs-ab mailing list
>>     > Openid-specs-ab at lists.openid.net
>>     <mailto: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
>>     <mailto: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
>>     <mailto: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 
>> <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130308/6c9736be/attachment.html>

More information about the Openid-specs-ab mailing list