You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Draft

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

XXX Core Schema + Extensibility Example

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?
  8. See also Parking Lot
  • No labels