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:
- ID Match API, used to determine if a Person is already known to the IdMS
- Write API, used to add (or modify or delete) a System of Record's Role Record to the IdMS
- Read API, used to obtain an IdMS' representation of a Person (See Registry Extraction API instead.)
- 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
- Core Schema Extensibility Example
- What does response to SOR look like? ie: how does SOR get identifiers (eg: netid) and any other attributes that may be returned?
- Response codes for normalization/validation/standardization failure?
- 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?
- Discussion on ids:
- OR, PSU, etc. have an opaque identifier stored internally for the person
- Crosswalk to other identifiers
- There should be a “system to system” id which would be the “recommended” id by which to get someone
- Equivalent of “principal id” in KIM and psu_id in CPR?
- 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.
- What to call this id? SystemToSystemId? Principal ID? Something else?
- Batch?
- ID Match
- Authorization restricts some/all SORs from forcing reconciliation?
- What about non-Person entities?
- See also Parking Lot