[Openid-specs-ab] Feedback on UserInfo schema

Mike Jones Michael.Jones at microsoft.com
Fri Mar 8 22:55:00 UTC 2013 

This is part of the analysis.  The other important analysis needed is what syntax we should use should we decide to provide claim(s) for these purposes.

                                                                -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
Sent: Friday, March 08, 2013 2:30 PM
To: George Fletcher
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Feedback on UserInfo schema

So I and John analyzed the issue face to face yesterday. John, please correct me if I am wrong or missing some points.


  *   The claim that email is the only needs to be verified for easy interaction with basic RPs is false. There are enough use cases that requires verified mobile phone number etc. There even are cases that there is compliance requirement to do the mobile phone number verification (while I am not aware of email).
  *   Mobile phone number that I cited is used to infer other information. In my case, it was the age (whether s/he is a minor or not) from a regulatory database. Torsten's usecase also talks about validation so he seems to be using it as an identifier of some sort as well. There may be other identifier of this sort which would not only useful but sometimes required in some jurisdiction. (e.g., citizen registration number, etc.)
  *   We tentatively name the class of identifier as external verified identifier (evi).
  *   The main use case of the evi is to use it as a hint to link one account at one place to another.
  *   evi may be used as a login_hint as well.
  *   The response should contain the identifier itself as well as the type of identifier and possibly the verification method information as metadata. e.g., +1-123-456-7890 as identifier and 'mobile' as the type and 'sms' as the verification method, and the date.
  *   While evi is not only useful but sometimes required, it may also pose a privacy risk, so it has to be dealt with care. You should not be giving it just because it has been asked but evaluate how it would be used.
  *   The type of evi should be registered in a registry (such as the IANA Link Relations registry described in RFC5988.)
Verified email class is just one example of evi. Mobile number seems to be gaining more importance these days (possibly more important than email in many places.) Other example of evi may include: credit card number, National ID Number, Frequent Flyers Number, etc.

Personally, I feel that mobile number is basic enough use case that may be worthwhile in calling it out, but I agree this is a member of a class. I am fine either way, but not having a way to express it would do much disservice to the basic relying parties that needs them.

Nat

2013/3/9 George Fletcher <gffletch at aol.com<mailto:gffletch at aol.com>>
Maybe this is a bad analogy.. but I look at this as similar to the SREG vs AX extensions in OpenID2 (don't take the analogy too far:)  The point of the 'openid' schema serves the same purpose as SREG. If that's good enough, then great. If more is needed, then an extended set of claims needs to be defined (as was allowed via AX). My preference for this extended set of claims would be to use an existing schema syntax (if possible). While AX allowed for any "schema" a few go adopted and that could play out in this case as well.

As for the issue of mobile phone number, verified status, etc that is all very useful to an RP, though as a user I find it a little scary that any RP could ask for my mobile phone number. I'd want my IdP to give me some pretty good controls around that which likely complicate the "consent UI":)

Thanks,
George
On 3/8/13 11:57 AM, Breno de Medeiros wrote:

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

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



--

--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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130308/7c06d987/attachment.html>

More information about the Openid-specs-ab mailing list