20180517 Meeting Notes

Identity Management meeting regarding visibility of profile fields

Attendees:

Jeff Kantor

Unknown User (bemmons)

Veronica Kinnison

Iain Goodenow

Ranpal Gill 

Purpose:

• followup to previous identity management meetings
• part of configuration of the web portal and backend database that NCSA is providing, they need to know which fields to make public for various classes of users
• first phase of this effort is to replace custom contacts database
• goal is to define what the new system will be not to replicate the old system
• which fields and who can view, access, edit, self-edit -- general public/anonymous, members of project science collaborations, internal project staff, executive level management

Discussion:

• reviewed May 11 email "Re: LSST Identity Management System profiles"
• need all fields from old system migrated so we don't lose data from the current system
• security information classification policy -- shareable, protected user, internal
• Jeff's opinion, people join these collaborations as a desire to participate and it's likely they'd be fine having their affiliation made public
• Iain is concerned over the potential for spammers to mine the data to pull out names and email
• LSST staff will have additive rights (view public data as well as additional protected data)
• Ranpal mentioned AMCL membership, SAC, and other info is currently available in our website and elsewhere.  Jeff noted that even if data is public elsewhere does not automatically mean it should be public in our new system
• Ranpal brought up NCOA, generalized as others who work for AURA that may need to work with LSST; Iain gave an example of Ryan Richmond
• org chart is a design consideration but not a requirement -- too far into future; Jeff said not a feature of the contacts database (would require a contract addendum); fields for an org chart could be added under the scope but not a graphical webpage with an org chart structure
• anyone with an identify in the database should be able to edit their shareable information with some exceptions.  group didn't come to a consensus on which were the non-editable fields (for example, Iain felt first/last name should not be editable unless you go through a formal review process)
• the general group feeling was against a static list of info (i.e. phonebook) that could easily be abused by spammers but instead require some amount of information to be entered before any data is returned (similar to the current AURA Directory site).  Ben noted even that could be circumvented with a little code and brute-force form posting (although there are firewall methods for blocking that type of activity once detected).

New features:

• Ranpal mentioned the system will need to cope with people in more than one collaboration
• emergency contact list?  not currently part of the contacts database -- sensitive
• photos
• synchronize with other AURA/LSST systems, like mailman; should be able to query database; certain fields need to capture group membership; group naming mapping between contacts db and mailing list
• home URLs -- "my website"
• social media handles/usernames
• self help and opt out -- where document/policy?
• wildcard search
• ORCID (similar topic: DOI, arXiv, Zenodo)
• preferred names -- not already in the current system (but publication name does exist)

Decisions:

• the contacts database should not contain any highly sensitive data (information restricted to executive level)
• first decision will be can people see it at all and next question is how to get to it.  regarding the first question, there was not group consensus on whether the information should be publicly accessed anonymously.  Vote: anonymous viewing?  Iain/Veronica/Ben: no, Ranpal: yes, Jeff: neutral.  Ben mentioned if public access is allowed, we should consider use of captcha technology to limit spammers from screen scraping the data.
• should we allow wildcard/partial name search?  not sure if we officially voted on this but conversation indicated most of the group liked that functionality
• collaboration membership information should be available to themselves and potentially other groups
• should contractors (e.g. CISS people running cables) have the same access to contacts database as staff?  Jeff initially proposed yes since they need an easy way to find someone to ask a question but the group voiced concerns over that approach (need-to-know best practices, social engineering security risk, LSST sponsors/liaison/single points of contact) and ultimately the group decided contractors by default would not have the same access privileges as staff but exceptions could be made and handled within the system (for contractors like Kevin Long, Sharam, etc.)
• staff photos?  consensus was yes but might need opt out options and more discussion on potential self-editing/upload
• some fields, like Affiliation, should be a dropdown instead of freeform text (to avoid typos and a variety of entries meaning the same thing)
• if data is made public, a person should be able to opt out from making that data public but it should still be accessible internally to staff
• there should be a clear place on our site that directs general public inquiries to a central "public relations" email/phone/address

Actions:

• Ranpal Gill Check with Frederika, head of science collaboration, to get her recommendations on this topic 31 May 2018 
• Jeff Kantor Write up a set of recommendations for Victor 31 May 2018 
• Iain Goodenow Map at the field level to the categories defined 31 May 2018