LIGO Reconciliation Requirements and Design Considerations

Enrollment flow and form functionality

• An instance of an enrollment flow should be configurable as to whether or not forms associated with the flow will offer reconciliation help or clues to the form user.
  • An example of an enrollment flow that should not offer any reconciliation assistance to the form user is summer interns. We probably do not want them given any hints about existing identities known to the registry.
  • An example of an enrollment flow that should offer reconciliation assistance to the form user is the standard flow for new LIGO Laboratory employees.
• An enrollment flow that does offer reconciliation assistance to the user should should be configurable to only do so for users with particular roles or privileges.
  • A CO or COU admin should be offered reconciliation assistance.
  • "Hiring managers" and certain administrative assistants should be offered reconciliation assistance.
  • Self enrollment flows for non-authenticated users probably should not offer reconciliation assistance since it is a way to probe existing identity information in the registry anonymously. 
  • We can have authenticated users, like postdocs, that are known to the platform and even to a CO(s) use the self enrollment. Ideally they would instead be using some type of transfer functionality instead but it is not out of the question that there could be scenarios where they do use self enrollment forms. In those cases reconciliation assistance should be offered.

Form functionality draft

Administrator enrollment

• As the administrator types in the form text box for "Given name" a drop down with matches to existing org identity given names known to the CO should appear. Hence the CO one is working with has to be chosen or set first.
• Same for middle name and family name.
• A platform configuration should be whether reconciliation is allowed across all COs. That would be the case for LIGO since people move around COs (LIGO Laboratory, LIGO collaborators, Virgo) all the time.
• Once all the name entries have been entered the server should be queried and any "fuzzy" (TBD) or exact matches should be presented in a popup that clearly indicates this is a known org identity to the CO or platform. 
• The popup should include more information about the identity such as email addresses, phone numbers, other attributes (photo?) including CO specific attributes and any history of COs (in the case of reconciliation across the platform) and COUs that the identity belonged to. 
  • Display of all those details for known matching details should depend on role/privilege for the administrator.
• The popup should give the administrator the choice to select one of the known identities and when selected the correct values should be put into the form. 
• The form should probably also then indicate with a checkbox that this is a known identity.
• If a known identity was chosen a slider should show up on the form and the form user should be asked to indicate how confident is he/she that the enrollee === known identity
• Entry of an email address that matches to a known org identity should also trigger the reconciliation popup if the form user has not already selected a known identity from a popup. Since addresses, especially office addresses, are shared they should not trigger, nor should office phone numbers. Mobile phone numbers might?

Server side requirements to support form functionality

• A REST API function call so that as a string of characters is entered into the "Given name" text box matches are sent back to the client. 
• Same for middle and family name. 
• Same for email.
• Same for mobile phone.
• A REST API function call that sends up given, middle, family, email, mobile phone and returns a list of "fuzzy" (TBD) or exact matches and for each match includes
  • given
  • family
  • middle
  • suffix
  • email(s)
  • mobile number(s)
  • CO specific attributes
  • photo?
  • CO and COU histories
    • CO/COU name, date joined, date left
• Enrollment form submission needs to include
  • indicator that a known identity was selected and it became the input
  • amount of confidence form user has that enrollee === known identity
  • identity of the form user making the assertion 

Reconciliation flow/engine inputs

Reconciliation flow/engine outputs

 Fuzzy matching