Open Stack

We don't utilize email address for anything. It is not meant to be a top-level column. We've had a lot of discussions on this. The main result is we decided that Keystone should be getting out of the PII game as much as possible. 

I am  against making email a top level attribute. Instead we should be de-emphasizing adding in email (for PII reasons, as keystone does not have a way to securely store them - even as a top-level column) unless email is used as a username. As I recall "email address" was meant to be removed from most/all of our API examples for these reasons. Unless OpenStack or Keystone starts making real use of the email address and needs that PII in the keystone store, it doesn't make sense to treat it as a first class attribute. Keystone is not a CRM tool. 

As a side note, I have proposed a way (it needs further work and would be a Mitaka target) to add validation to the extra attributes on a case-by-case basis for a given deployment. [1]

[1] https://review.openstack.org/#/c/190532/

Sent via mobile

> On Sep 11, 2015, at 06:55, Lance Bragstad <lbragstad at gmail.com> wrote:
> 
> 
> 
>> On Fri, Sep 11, 2015 at 8:04 AM, David Stanek <dstanek at dstanek.com> wrote:
>>> On Fri, Sep 11, 2015 at 8:26 AM, Christian Berendt <christian at berendt.io> wrote:
>>> At the moment it is possible to create new users with invalid mail addresses. I pasted the output of my test at http://paste.openstack.org/show/456642/. (the listing of invalid mail addresses is available at http://codefool.tumblr.com/post/15288874550/list-of-valid-and-invalid-email-addresses).
>>> 
>>> Is it intended that addresses are not be validated?
>>> 
>>> Does it makes sense to validate addresses (e.g. with https://github.com/mailgun/flanker)?
>> 
>> 
>> I don't know the complete history of this (I'm sure others can chime in later), but since Keystone doesn't use the email address for anything it was never really considered a first class attribute. It is just something we accept and return through the API. It doesn't even have its own column in the database.
> 
> Correct, I believe this is the reason why we don't actually tie the email address attribute validation into jsonschema [0]. The email address attribute is just something that is grouped into the 'extra' attributes of a create user request, so it's treated similarly with jsonschema [1]. I remember having a few discussions around this with various people, probably in code review somewhere [2]. 
> 
> I think jsonschema has built-in support that would allow us to validate email addresses [3]. I think that would plug in pretty naturally to what's already in keystone.
> 
> [0] https://github.com/openstack/keystone/blob/aa8dc5c9c529c2678933c9b211b4640600e55e3a/keystone/identity/schema.py#L24-L33
> [1] https://github.com/openstack/keystone/blob/aa8dc5c9c529c2678933c9b211b4640600e55e3a/keystone/identity/schema.py#L39 
> [2] https://review.openstack.org/#/c/132122/6/keystone/identity/schema.py
> [3] http://python-jsonschema.readthedocs.org/en/latest/validate/#validating-formats
> 
> 
>> 
>> I don't like this for a variety of reasons and we do have a bug[1] for fixing this. Last Thursday several of us were discussing making a database column for the email address as part of the fix for that bug.
>> 
>> 1. https://bugs.launchpad.net/keystone/+bug/1218682
>> 
>> -- 
>> David
>> blog: http://www.traceback.org
>> twitter: http://twitter.com/dstanek
>> www: http://dstanek.com
>> 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150911/e5575c8d/attachment.html>