The SOR-Registry API consists of three types of API operations:

1. ID Match API, used to determine if a Person is already known to the IdMS
2. Write API, used to add (or modify or delete) a System of Record's Role Record to the IdMS
3. Read API, used to obtain an IdMS' representation of a Person

Real-Time API Operations

SOR Person / Write API

Exposed by Registry component.

• SORPersonRoleAdded
  • Encompasses both “person” and “role” level attributes that the SOR may assert
  • Up to the Registry to decide how to map them to its data model
• SORPersonRoleDeleted
• SORPersonRoleUpdated

Example of SORPersonRoleAdded with Person-level attributes:

{
 Name: Pat Lee
 SORID: X12345
 [
  {
   SORRoleID: R98765
   Title: Professor of Phrenology
   PercentAllocation: 50%
  },
  {
   SORRoleID: R98766
   Title: Administrative Assistant
   PercentAllocation: 34%
  }
 ]
}

Example of SORPersonRoleAdded with Person-level attributes expressed as Role-level attributes:

{
 [
  {
   SORID: X12345
   SORRoleID: R98765
   Name: Pat Lee
   Title: Professor of Phrenology
   PercentAllocation: 50%
  },
  {
   SORID: X12345
   SORRoleID: R98766
   Name: Pat Lee
   Title: Administrative Assistant
   PercentAllocation: 34%
  }
 ]
}

Example of SORPersonRoleAdded without Person-level attributes:

{
 [
  {
   ReconciledPersonID: P54321
   SORID: X12345
   SORRoleID: R98765
   Name: Pat Lee
   Title: Professor of Phrenology
   PercentAllocation: 50%
  },
  {
   ReconciledPersonID: P54321
   SORID: X12345
   SORRoleID: R98766
   Name: Pat Lee
   Title: Administrative Assistant
   PercentAllocation: 34%
  }
 ]
}

Person / Read API

This API is intended for tightly bound applications, such as the identity console or the Kuali apps. General application read access to identity data would typically be via LDAP or some other provisioning/integration mechanism.

• GetPerson(SystemToSystemID)
  • Principal ID in KIM
  • Perhaps there is a need for some standardized terminology for different types of identifiers, etc
  • Pass ID+Type instead? Otherwise SystemToSystemID needs to be configured somehow before API is usable
• GetPersonRole(s)
• GetSORPerson (needed?)
• GetPersonSORRole(s) (needed?)
• MapIdentifier
• attributes specific gets?

Questions

1. What does response to SOR look like? ie: how does SOR get identifiers (eg: netid) and any other attributes that may be returned?
2. Response codes for normalization/validation/standardization failure?
3. If there is a core schema, how does that affect the API design? eg: POST /people with a bundle of attributes vs POST /people and POST /names, POST /addresses, etc (eg: COmanage REST API). Add vs Update? Both?
4. Discussion on ids:
   1. OR, PSU, etc. have an opaque identifier stored internally for the person
   2. Crosswalk to other identifiers
   3. There should be a “system to system” id which would be the “recommended” id by which to get someone
      1. Equivalent of “principal id” in KIM and psu_id in CPR?
      2. In OR, person ID is intended to be internal to registry. Need to define an enterprise-wide system-to-system identifier to use for this purpose.
      3. What to call this id? SystemToSystemId? Principal ID? Something else?
5. Batch?
6. ID Match
   1. Authorization restricts some/all SORs from forcing reconciliation?
7. What about non-Person entities?