Minimal Entity Registry Data

The idea of minimal person data in the registry is driven by requirement # 10 and the idea that the data repository for IAM

is comprised of a registry, a group and a ODS/MDM person data repository. Data for IAM operations can go to or be

brought from the virtual combination of these three data repositories. Requirement 10

Diagram from May 2016 TIER Entity registry documents.

This document focuses on PERSON entity can be extended to document other supported entities.

This is a final DRAFT doc. Items in RED are examples suggested or explanative content to assist in understanding extensibility and the minimal model.

Entity Object- person, instutional contact, code client (thing calling api), service/priviledged acct, IOT(device), etc.

Each occurrence will have a unique identifier assigned to identify it for use in the IAM architecture to uniquely know this “thing” from all other “things”.
This requires a high level structure in the data to provide uniqueness for all entities.
In the case of matching, merging of suspect records this is a key capability.

Entity level attributes: Requirement 3

Entity object ID
- internal
- used internal to registry only
- UUID type of value
- Key value for any registry entry
Entity Type Code requirement 11
- Person
- Client/Service
Date created
Date Inactivated
Entry Description / Name
Status
- (suspect, merged, active, inactive)
- Inactive = soft delete requirement 15
Institutional Entity Identifier Requirement 3

Object Maintenance Fields ( rather than show this at each object or field this is shown once)

Definition – Internal processes maintain these fields on the data object to support logging, auditing and change data capture. This can be applied to each field or any object Person, name, email, affiliation, etc. Discussion topic for group.

Attributes:

i. Begin Time Stamp Requirement 9

ii. End Time Stamp Requirement 9

iii. Updating entity ID Requirement #1 (identifies the client doing the update)

iv. Updating SOR Identifies SOR (or Business area) of last update

Entity Type: person

Person object:
- Protect/Secured
  - Definition – Person entity is accessible or is protected from exposure, although a more robust solution for privacy could be extended to each/all lower level object or fields this is the minimal level. Person on/off.
  - Requirement(s) – Allowed values are “Y” or “N”
    - Additional Information - Person information may not be public because of person preferences or for legal protection reasons.
    - There are persons with specific security roles that have access to Protect/Secured information.
    - Specific roles have maintain authority Protect/Secured.
- Active, Inactive and Pending Status
  - Definition – The state of the Person record for usage by authoring systems
  - Requirement(s) – value must exist in code table
  - Additional Information:
    - “Pending” indicates that an identity resolution event is underway
    - “Inactive” indicates that the record did not survive the collapse/merge process a new record exist
    - “Active” indicates that the record is to be used for common business usages

Identifier Object (At least one occurrence is required many are allowed per institutional need, "Institutional Entity Identifier" from the Entity object must reside in person identifier have used a bunch of examples (these can vary per institution)
- Identifier Type Code requirement 11
- - Access management identifiers
    - - (USERIDs various net id local or federated, it would be expected that one of these would be present) ) Requirement 36/35
    - Net ID -- no special editing; Highly recommended
    - federated login identifier(s)
      - eppn or similar federated id of choice.

Affiliation object
- - (Occurs multiple per Person entity (0-M) ) Requirement # 6 multiple allowed
- Institutional Affiliation Type Code Requirement #7 The fields shown type thru end date, requirement 11,
- Department/organization ID
  - Definition – Department ID from the application that is assigned to the combination of Person and Affiliation,
  - Requirement # 8 (multiple per affiliation type in different dept id)
  - Requirement(s)
    - Must exist in code table
    - Required field on maintain request for Affiliation; cannot be null
- Affiliation Start Date Requirement 9
  - Definition – Date that indicates when the institutional Affiliation becomes active
  - Requirement(s):
    - Date value on maintain request can be null; registry defaults to the current timestamp
    - Date value when passed on maintain request, conforms to date standards
    - Date value can be changed by a maintain request
    - Date value can be in the past, equal to, or in the future from the current date
- Affiliation End Date Requirement 9
  - Definition – Date that indicates when the institutional Affiliation becomes inactive
  - Requirement(s):
    - Date value can be null except for the following condition(s) where a date value must be passed on the maintain request with the institutional Affiliation:
    - Affiliation Owner = “1. Anyone”
    - Date value when passed on maintain request, conforms to date standards
    - Date value can be in the past, equal to, or in the future from the current date
    - Date value can be no more than (limited time frame) month/years into the future
    - Date value on an existing institutional Affiliation on Person can be changed
    - Date value must be greater than the Affiliation Start Date
    - On Mutually Exclusive Affiliations, the following logic applies:
      - If there is an active institutional Affiliation in the set
      - if setting the Affiliation End Date breaks the above rule for the Affiliation End Date to be greater than the Affiliation Start Date, then the maintain request is failed and the response is an error message. It will be up to the submitter to correct the situation.

Name object (Structure Occurs at least once but may be multiple per Person entity (1-M) )
- Name Type (requirement 11)
  - Definition – Legal (used as example institution chooses type)
  - other possible types Display, Prefered Former, Alias, etc
  - Institutional control in adding types

First Name (Given1-4)
- Definition –
- Requirement(s):
  - Value is required
  - Fail transaction if null
Middle Name
- - Definition –
  - Requirement(s):
    - Optional – Null allowed
Last Name (Surname)
- Definition –
- Requirement(s):
  - Value is required
  - Fail transaction if null
  - 1^st position must be a capitalized alphabetic character
Prefix
- From a code Table
Suffix
- From a code Table

Contact Method Email Object
- - requirement 11
  - multiples allowed
  - 1 required
- Email Type
- Email Address

Contact Method Telephone Object

- requirement 11
- multiple allowed
- 1 required
- Basic Phone International Rules apply
Device Type – Maintain the type of device (example types are Wired and Cell)
Telephone Number – Full number is to be stored

Country Code
Area Code
Telephone Number
Device Type
SMS Capable

Organization/Department Code:

Code table for org/departments in the registry

Organization Type Code requirement 11
- Definition – Defines the organization type
Organization Code
- Definition – Defines the organization Code value
Organization Description
- Definition – Name / description of organization Code

Note: code tables in above information Structure: similar to organization code table above. Extensions to much of this is based on the code table.

New objects could also be defined using a similar table driven extension. (these then would drive to a registry API schema)

Audit trail : or similar mechanism is required to be able to review and look at all changes to data.

entity, attribute identifier, verb, old value, new value, timestamp of change (example)
should be able to trigger an update notifications/events to Provision when an “attribute” changes on a Person record
Requirement #5

Notes on support for VOs and collaborations wrt Minimal Entity Registry Data

Requirement #57

Support for collaborations (as provided by central IT) can broadly be segmented into two categories;

"Simple" collaboration needs cover researchers on campus (ie: those who have campus NetIDs) collaborating with others on campus via access to campus managed services (email lists, documentation spaces, etc). In general, this functionality can be provided with a combination of (existing) group and person registry services, often with a minimal "service enablement" layer to allow authorized individuals to define the collaboration groups and map them into enabled services.

"Advanced" collaboration needs expand to include researchers not affiliated with the campus (ie: those who would leverage federated identity to participate), complex enrollment procedures (invitation, self signup, approval, etc), larger collaborations with delegation requirements, and finer grained service management. Meeting these needs often implies solutions like COmanage.

Page tree

Entity level attributes: Requirement 3

Entity Type: person

Person object:

Protect/Secured

Definition – Person entity is accessible or is protected from exposure, although a more robust solution for privacy could be extended to each/all lower level object or fields this is the minimal level. Person on/off.

Requirement(s) – Allowed values are “Y” or “N”

Additional Information - Person information may not be public because of person preferences or for legal protection reasons.

There are persons with specific security roles that have access to Protect/Secured information.

Specific roles have maintain authority Protect/Secured.

Active, Inactive and Pending Status

Definition – The state of the Person record for usage by authoring systems

Requirement(s) – value must exist in code table

Additional Information:

“Pending” indicates that an identity resolution event is underway

“Inactive” indicates that the record did not survive the collapse/merge process a new record exist

“Active” indicates that the record is to be used for common business usages