[Openid-specs-ab] Feedback on UserInfo schema

Nat Sakimura sakimura at gmail.com
Wed Mar 6 22:50:29 UTC 2013


OK. If we were to add phone_number_formatted, we should state that this is
the string that the user entered.

BTW, where can I find the text that claims can be extended with URI as
claim names etc.?

Nat

2013/3/7 Breno de Medeiros <breno at google.com>

> The display version is as user entered, or in the common format of the
> user's locale. It should be displayed as is.
>
> On Wed, Mar 6, 2013 at 1:54 PM, 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
>
>
>
> --
> --Breno
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130307/24a33100/attachment.html>


More information about the Openid-specs-ab mailing list