[Openid-specs-ab] Feedback on UserInfo schema

Breno de Medeiros breno at google.com
Fri Mar 8 16:57:52 UTC 2013


I can't identify a clear trend in this thread for how to proceed.

On Fri, Mar 8, 2013 at 7:49 AM, Anthony Nadalin <tonynad at microsoft.com> wrote:
> SCIM schema is not an agreed upon item yet, there are extension issues
>
>
>
> From: openid-specs-ab-bounces at lists.openid.net
> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of nov matake
> Sent: Thursday, March 7, 2013 8:45 PM
> To: John Bradley
>
>
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Feedback on UserInfo schema
>
>
>
> Yeah, I'm OK with using non "openid" schema.
>
>
>
> However, in that case, I think the sentence
>
> "The sub (subject) Claim MUST always be returned in the UserInfo Response."
>
> should be
>
> "If the requested schema is openid, the sub (subject) Claim MUST always be
> returned in the UserInfo Response. If other schema is used, it MUST (or
> SHOULD?) include sub equivalent claim."
>
>
>
> On Mar 8, 2013, at 10:04 AM, John Bradley <ve7jtb at ve7jtb.com> 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> 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>
>
> 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
> _______________________________________________
> 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
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>



--
--Breno


More information about the Openid-specs-ab mailing list