Update person-identifiers.adoc

person-identifiers.adoc

@@ -17,6 +17,16 @@ G does have its own internal-only identifier
   id and identifier (anything that can uniquely identify a person
   Grouper external users is where the ePPN for a new member
 
+COm: In general, a multi-values list of identifiers paired with a source identifier; there is a non-shared internal ID
+  Grouper: 
+
+  Refereence ID: two match modes: Match up front; config. COmanage to match based on RefID. registry gets a ref id, and stores it 
+
+  Match API backend is just a database that understands ref id and sourceID
+
+  provision to LDAP, point Grouper subject source at LDAP;
+
+
 mp: OID is permanent, not shared name is a name-based identifier (other could be added), can change if needed, could be a campus id that users tend to know
 - globally unique by inclusion of a scope element or domain identifier
 - mP can generate any other unique id and share with external systems
@@ -36,6 +46,8 @@ can be merged if necessary.
 
 . What is the primary, wholly internal person identifier in your package?
 
+COm: identifier modules to generate identifiers with the desired characteristics; 
+
 KeithL: If you make a REST call: here's user, get the OID, use that in the actual REST call
 
 . What identifier(s) do you expose to other packages? Internal ID plus tuple source/identifier
@@ -46,6 +58,10 @@ generate anything you want, configurable; DO NOT USE OID; mP API is a case where
 
 . How do you handle changes to name-based identifiers
 -
+connectors can work w opaque: UID (used to link to the midPoint user, and another identifier, perhaps name based; mP can update the name identifier
+
+If UID link breaks, correlation can relink.
+
 
 - - -