[OPEN-ILS-DEV] Feature proposal: SSN-censoring functionality

[Kivilahti Olli-Antti]

The more I look at the list of issues you present, the more I am
convinced that storing SSNs as they currently are is a *bad* thing.
Perhaps storing them in general is a bad thing?

I am not sure can we not store SSNs. Here they are collected wherever you do business. Transmitted over phone to marketers, asked pretty much where ever your identification is of question.
Currently every staff member here has access to every patrons' SSN.

Patron Editing/Registration - Do you show the full value by default,
or provide a change/update interface that can load the full value
(provided you have permissions to see the un-sanitized current value)?

We can access the full SSN along with the rest of the patron data in the edit view of our current ILS. We were planning for Evergreen to display the full SSN as well in the patron edit view (as is). Also the sanitized SSN would be displayed as well with a description of the filter used to sanitize the SSN.

A better solution may be to define a new table for storing one or more
pieces of data for identifying the patron. Permissions can then be
used to allow enforcement of who is allowed to see the information,
complete with whether or not they can see the un-sanitized data. (This
could, in theory, allow Massachusetts libraries to store this data and
still comply with the law.)

That definitely is an idea worth considering. To me it looks like an ugly solution where we have multiple columns representing the same identification data. But considering that it might be a significantly easier approach to compatibility and security, ofcourse sounds great.

"Sanitizing" the data as it comes out requires flagging it as to be
ignored going back in, unless non-sanitized data comes back. This will
really screw with the code paths for patron editing and retrieval.
Note that currently the *only* place I know of with protection for
US-style SSNs is the patron sidebar view. Hitting "Edit" shows you the
full thing anyway.

If we take non-sanitized data for the patron editing view, we will push it back as well.

Reporter - It tends to bypass permissions.

Maybe we could make another Evergreen database user, evergreen-secure, to have access to the separate SSN-table?



On 08/13/2012 06:36 PM, open-ils-dev-request at list.georgialibraries.org<mailto:open-ils-dev-request at list.georgialibraries.org> wrote:

Re: Feature proposal: SSN-censoring functionality



--
Olli-Antti Kivilahti
Open Library 2013
Library of Joensuu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20120813/d3b93cae/attachment.htm>