Update comanage-wb-registry.adoc

comanage-wb-registry.adoc

@@ -1,3 +1,4 @@
+- - -
 _2021-11-17 14:00 COmanage as Workbench Registry_
 
 Tommy Doan, Ethan Kromhout, Keith Hazelton zoom:
@@ -10,6 +11,32 @@ COm will be primary place Help Desk looks for user info, so good to have emails
 
 COmanage will mint an email alias; users might want a different one, mark one as primary, or mark another as inactive
 
+
+integrate WB SIS and HR with COmanage as Registry
+
+COm populates a table with all CO persons; to present the data to Grouper, we'll need a view that can serve as a subject source, and a source for mP
+
+make aliases visible to
+
+UNC favors API, or messaging; (religious distaste for direct access to tables or views or LDAP)
+
+API contracts are better; Messaging, too; (SMU: for PS Integration Broker)
+EK: Person Basic sync would be better than UNCs customized IB messages
+
+TommyD guiding principles: 1) treat as modular as possible so any one of them can be replaced. 2) if we had table or views, seems to simplify the integration
+
+
+TD is doing PS to COm
+EK is doing PS to mP for now Campus Solutions is effectively their Registry, want to move to mP; Grouper manages roles, and maps to PS privs.
+
+TD: wants to produce per integration point diagrams; He'd need WB to process PS IB messages; High Priority: Develop the COmanage view that Grouper uses as a subject source.; Have mP leverage same view into source tables; Then WB becomes really interesting as another way to look at the TAP suite as a whole.
+
+Grouper subj source: Identifiers, name, dept? description?? EK: Ripe for review at UNC since it's tricky to find the desired subject when LDAP has millions
+
+
+
+
+
 - - -
 
 22 Oct SIWG: