This Strawman is a draft for discussion purposes only. It uses a REST representation, but other representations may be useful.

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 (See Registry Extraction API instead.)
  4. Core Schema Strawman and Core Schema Draft Specification, defining representations of common attributes

As a general rule, the SOR-Registry is concerned only with the syntax of conveying attributes between a system of record and the identity registry. The semantics of what the registry does with the attributes (including how downstream systems use them) are mostly out of scope.

Questions

  1. Core Schema Extensibility Example
  2. What does response to SOR look like? ie: how does SOR get identifiers (eg: netid) and any other attributes that may be returned?
  3. Response codes for normalization/validation/standardization failure?
  4. 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?
  5. 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?
  6. Batch?
  7. ID Match
    1. Authorization restricts some/all SORs from forcing reconciliation?
  8. What about non-Person entities?
  9. See also Parking Lot