...
Requirement ID | Requirement Source | Requirement Description | PSU | Open Registry | |
|---|---|---|---|---|---|
REG_0100 | PSU | The registry shall support the storage of identity information. | | | |
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. | | | |
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. | | | |
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. | | | |
REG_0180 | PSU | The registry shall store a type associated with each person's name (for example, legal name). - Does this imply that multiple name types can be stored? (Legal / Preferred etc.) | | | |
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. | | | |
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. | | | |
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. | | | |
REG_0260 | PSU | The registry shall maintain a history of all of a person's telephone number changes. | | | |
REG_0270 | PSU | The registry shall maintain a history of all of a person's email address changes. | | | |
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, ...). | | | |
REG_0290 | PSU | The registry shall support the storage of all a person's affiliations. (Should we add something here distinguishing between affiliations vs. roles per the email discussion) | | | |
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. | | | |
REG_0330 | PSU | The registry shall either store an indicator or have a calculation to determine a person's primary affiliation. | | | |
REG_0340 | PSU | The registry shall support the mapping of its affiliations to the eduPerson attributes. | | | |
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 | | | |
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. | | | |
REG_0400 | PSU | The registry shall support the storage of international forms of user information. | | | |
REG_0410 | Jasig/OR | The registry shall support the storage of organization-specific attributes. | | | |
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). | | | |
REG_0440 | PSU | The registry shall support the ability to associate an END DATE with each Affiliation Type. | | | |
- Where do attributes like department / organization / campus fit in the above requirements? Would this be in address and or affiliations or should we be explicit in identifying these things if appropriate?
- Not sure if i missed it or if it is implied, do we have some sort of status indicator? active / in active (in HR terms it might be active, terminated, retired, etc.)
-- many of the attributes that the Registry is required to store (eg email address) strike me as being related to an Affiliation (eg if I'm STAFF and ALUM, I may want to associate different email addresses with those Affiliation types).
-- often there are faculty in senior administrative positions (eg Provost and Prof of Mathematics). Full info (eg telephones, office location) should be maintained for each of these positions that one person occupies.
-- Brown delivers instruction through academic depts; we deliver research via Centers and Institutes. Many faculty/researchers have multiple associations, and even multiple offices.
-- should the Registry be able to store info about Federated Users (eg Jane is a faculty member @ Cornell; she is a member of groups at PSU); same question about people (parents) who authN with Social Credentials to access campus based services (eg Student Bill)
-- do we need requirements related to non-person entries in the Registry ?
DRAFT Requirements (Sept 9 conversation about Affiliate types)
| KIM | PSU | Open Registry |
|---|---|---|---|
The Registry shall support a LIFE CYCLE model. Each user is in a specific state; incoming events MAY trigger a transition to a new state; entering a new state MAY trigger sending events. Each of these transitions MAY be associated with a different Business Process. | | | |
The Registry shall support having unique LIFE CYCLE models for each Affiliation type (eg staff accounts are closed immediately on separation; faculty permissions are trimmed on separation but accounts are closed six months after separation). | | | |
The Registry shall support allowing a site to manage the Rules that define the transitions within a LIFE CYCLE. | | | |
The Registry shall support optionally sending events whenever a user's attributes or Affiliation types changes. | | | |
The Registry shall support a core set of information that is maintained about each person (eg name(s), DOB, citizenship, etc). | | | |
The Registry shall optionally support, for each Affiliation type, a scheme that defines the set of information and attributes that will be maintained for this Affiliation type for each user (eg staff have titles and office locations, students do not) | | | |
It shall be easy for sites to modify and extend the schema associated with an Affiliation type (both the data definition step, and adding code to do specialized processing). | | | |
The Registry shall come with scheme sets that could be used with different models of Person Registry (eg thin, medium, fat). | | | |
The Registry shall provide the ability to have people review and approve changes and transitions via a Workflow mechanism. | | | |
Management Functions
The section will detail requirements related to management information that the registry should provide. The interfaces will typically be Web Services (SOAP and/or REST-based).
Requirement ID | Requirement Source | Requirement Description | PSU | Open Registry | |
|---|---|---|---|---|---|
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. | | | |
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. | | | |
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 | |
| |
-- I'm assuming that many of the above process would be built on top of a Workflow system (allowing people to request a change, which is then reviewed and approved) ?
Enterprise System
This section will detail requirements related to the enterprise system aspect of the registry.
...