[Openid-specs-ab] Feedback on UserInfo schema

Mike Jones Michael.Jones at microsoft.com
Wed Mar 6 23:10:42 UTC 2013


That's in the JWT spec.  See http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-4.2 on Public Claim Names.

                                                            -- Mike

From: Nat Sakimura [mailto:sakimura at gmail.com]
Sent: Wednesday, March 06, 2013 2:50 PM
To: Breno de Medeiros
Cc: Mike Jones; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Feedback on UserInfo schema

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<mailto: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<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


--
--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/20130306/1d225585/attachment-0001.html>


More information about the Openid-specs-ab mailing list