KIM FitGap Additional Notes

KIM_0001

Kuali

The registry shall support the storage of person and non-person entities (vendors, etc.)

Rolled into REG_001, should non-person be on it's own?

KIM_0002

Kuali

The registry shall support the storage of Citizenship data

Rolled into REG_0390, should be on it's own?

KIM_0003

Kuali

The registry shall support the storage of Employee Status data

Rolled into REG_0390, should be on it's own?

KIM_0004

Kuali

The registry shall support the storage of Residency data

Rolled into REG_0390, should be on it's own?

KIM_0005

Kuali

The registry shall support the storage of VISA data

Rolled into REG_0390, should be on it's own?

KIM_0006

Kuali

The registry shall support the storage of FERPA election data

Rolled into REG_0390, should be on it's own?

REG_0001

A. Neal

The Identity Merge facility shall provide the ability to link unique identity records within the registry identifying one as the primary.

REG_0002

A. Neal

The Identity Merge facility shall maintain for historical purposes the non-primary registry entries. These entries shall not be available for further use (other than historical reporting) in subscribing systems.

REG_0003

A. Neal

The Identity Merge facility shall provide the ability to merge identity data to a "primary" registry entry through either an automated process or a user controlled process (eg. system identifies records to merge, shows user relevant data, user decides interactively what to accept etc.)

REG_0004

A. Neal

The Identity Merge facility shall provide notifications to subscribing systems of the merged identities

REG_0005

A. Neal

The Identity Merge facility shall provide for the creation of business rules for the automated merging of registry data elements. (eg. defining the authoritative source by attribute when duplicates are identified)

REG_0006

A. Neal

The Identity Merge facility shall be integrated with the Access Management Module to allow for assessing and potentially merging role and access data when duplicate identities are identified and merged.

REG_0007

A. Neal

The Identity Merge facility shall be integrated with the Provisioning Module to allow for the potential deactivation of duplicate accounts.

REG_0008

PSU

The Identity Merge facility shall use a fuzzy logic searching capability for matching purposes.

REG_0100

PSU

The registry shall support the storage of identity information.

Includes both person and non-person entities

REG_0110

PSU

The registry shall support the storage of the partial (MM/DD) and/or full (MM/DD/YYYY) date of birth for a person.

Storage is of full date, display for partial would be via logic

REG_0120

PSU

The registry shall have a unique identifier (non-SSN) for each person in its data store.

REG_0130

PSU

The registry shall support the storage of a person's gender.

REG_0140

PSU

The registry shall have the ability to storage multiple net ids for a person.

REG_0150

PSU

The registry shall have an indicator as to which is the primary net id for a person.

No option for marking as primary, no roadmap item/requirement so far

REG_0160

PSU

The registry shall store a person's first, middle (optional), last name and suffix (optional).

REG_0170

PSU

The registry shall maintain a history of a person's name changes.

Names have an active status, never deleted,  However, there is not a full log of changes (who made it, etc.)

REG_0180

PSU

The registry shall store a type associated with each person's name (for example, legal name).

Type is a required attributes, but out-of the box Primary and Preferred are delivered.  However, any number of types can be added (open-ended scheme)

REG_0185

PSU

The registry shall have the capability to store multiple name types for a person. Examples include: legal name, preferred name, ...

REG_0190

PSU

The registry shall support the storage of multiple addresses for a person, indicated by a type (for example, employee home address).

REG_0200

PSU

The registry shall store for an address, the following information: street address (multiple), city, state, postal code, country, campus location and source.

Campus and source are not stored

REG_0210

PSU

The registry shall store for a person's name an flag to indicator whether a first name is unknown (FNU) and/or a last name is unknown (LNU).

REG_0220

PSU

The registry shall support the storage of multiple telephone numbers, indicated by a type (for example employee office telephone number).

REG_0230

PSU

The registry shall store for a telephone number the following information: area/country code, phone number, extension (optional) and source.

Source is not stored

REG_0240

PSU

The registry shall support the storage of a person's email address(s) and their respective type.

REG_0250

PSU

The registry shall maintain a history of all of a person's address changes.

Fields are effective dated, but full logging of changes is not done.  Roadmap item

REG_0260

PSU

The registry shall maintain a history of all of a person's telephone number changes.

Fields are effective dated, but full logging of changes is not done.  Roadmap item

REG_0270

PSU

The registry shall maintain a history of all of a person's email address changes.

Fields are effective dated, but full logging of changes is not done.  Roadmap item

REG_0280

PSU

The registry shall support the storage of information about all of the credentials a person holds (for example: kerberos principal, secure id token serial number, PKI, ...).

External identifiers are stored along w/a type

REG_0290

PSU

The registry shall support the storage of all a person's affiliations.

REG_0300

PSU

The registry shall support the storage of a person's Identity Assurance Profiles.

REG_0310

PSU

The registry shall store information related to an identity proofing event.

REG_0320

PSU

The registry shall support the storage of identity card information.

External identifiers are stored along w/a type.  As long as this is just the card_id and other card attributes (photos, etc.) are from another area, this is a fit.

REG_0330

PSU

The registry shall either store an indicator or have a calculation to determine a person's primary affiliation.

A default indicator is provided

REG_0340

PSU

The registry shall support the mapping of its affiliations to the eduPerson attributes.

Could be written, but not currently supported or on roadmap

REG_0350

PSU

The registry shall provide a comments facility to be used for authorized personnel (Security) to record information about person's identity.

REG_0360

PSU

The registry shall have complete auditing of information in its registry

If the intent is that full change log tracking is done, then this is a roadmap item for KIM

REG_0370

PSU

The registry shall provide a facility by which authorized personnel can obtain a read-only view of portions of its data.

REG_0380

PSU

The registry shall maintain a single namespace for person identifiers and network ids.

REG_0390

PSU

The registry shall support the storage of common HR and student information, like title, status and department.

Also supports storage of Citizenship Status, Employee Status, Residency, VISA, and FERPA preferences

REG_0400

PSU

The registry shall support the storage of international forms of user information.

The database is capable of storing international characters (UTF-8) but searching against international characters with current/provided tools is lacking

REG_0410

Jasig/OR

The registry shall support the storage of organization-specific attributes.

Not currently, but for identity, this is a roadmap item

REG_0420

Brown

The Registry shall support the ability to associate a START DATE with each Affiliation type.

REG_0430

Brown

The Registry shall support the ability to define different life cycle processes for removing an Affiliation type (eg staff accounts are disabled immediately; faculty retain their accounts for six months but with reduced services).

MAN_0100

PSU

The registry shall provide interfaces for authorized registry authorities to manage information in its data store.

MAN_0110

PSU

The registry shall provide services to add, update, and archive persons.

MAN_0120

PSU

The registry shall provide services to add, update, and archive address information for a person.

MAN_0130

PSU

The registry shall provide services to add, update, and archive name information for a person.

MAN_0140

PSU

The registry shall provide services to add, update, and archive telephone number information for a person.

MAN_0150

PSU

The registry shall provide services to add, update, and archive net id information for a person.

MAN_0160

PSU

The registry shall provide services to add, update, and archive credential information for a person.

MAN_0170

PSU

The registry shall provide services to add, update, and archive Identity Assurance information for a person.

MAN_0180

PSU

The registry shall provide services to add, update, and archive affiliation information for a person.

MAN_0190

PSU

The registry shall provide services that are either SOAP and/or REST-based.

SOAP only currently, but REST is on roadmap

MAN_0200

PSU

The registry shall provide a web-based front-end to the data contained in its registry for authorized personnel.

MAN_0210

Jasig/OR

The registry shall provide a flexible batch-file interface for importing and extraction of data, including support for fixed column, CSV, XML, .xls, and other formats.

XML format is on roadmap

MAN_0220

Brown

The Registry shall provide a means of purging categories of entries (eg Applicants)

MAN_0230

Committee

The registry shall provide a configurable means by which changes can be (optionally) reviewed and approved

KIM is part of Kuali Rice which is delivered with KEW (workflow)

ES_0100

PSU

The registry shall support the notification of data changes to entities either using publish/subscribe or point to point communications.

For some events, on roadmap for all events

ES_0110

PSU

The registry shall support auditing of all actions for a person record.

Yes for some, but on roadmap for all events

ES_0120

PSU

The registry shall support data reporting of registry data for authorized personnel.

No, relies on local data warehouse for exports/reporting

ES_0130

PSU

The registry shall notify end-users via email x days prior to the expiration of their services.

ES_0140

PSU

The registry shall have rules for cleansing and standardizing data before its entered into the data repository.

Via UI checks and validation only