Date: Thu, 28 Mar 2024 15:36:42 +0000 (UTC) Message-ID: <1305356537.6587.1711640202657@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6586_1238762689.1711640202655" ------=_Part_6586_1238762689.1711640202655 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Back to TIER Entity Registry Wiki Home Page
The =E2=80=98glue=E2=80=99 that binds= IAM services together is an Entity Registry. Such a Registry facilitates t= he creation, maintenance, and distribution of person and other subject / en= tity information across TIER components and other elements of the instituti= onal IT landscape. It must be capable of receiving, deduplicating, re= solving collisions and otherwise grooming this information from authoritati= ve sources and disseminating canonical person and other entity information = to downstream services as a data hub or replication source.
The TIER Entity Registry Phase I Working Grou=
p is tasked with identifying and documenting the minimum viable require=
ments for a TIER Registry component and making recommendations to the TIER&=
nbsp;Community Architecture Planning and Engagement (CAPE)
Different audiences will need to be invited to engage on different aspec= ts of this work. It will be important for team members to bring the perspec= tive and represent the interests of at least the following stakeholder grou= ps:
IAM software component designers and developers
Campus IAM and security service providers
Campus integration teams
Application developers
Any interested member of the communit= y may participate in the activity of the group. Members self-select b= y subscribing to the group mailing list and contributing during group calls= and in discussions on the WG mailing list.
Warren Curry is the chair as approved= by the TIER Ad Ho= c Advisory group .
The group should complete its first v= ersion of the following Phase I items no later than April 1, 2016.= p>
Draw on the existing TIER Stakeholder Requirements, TIER component int= egration requirements (primarily Grouper and COmanage), CIFER API, CIFER Provisioning and Integration, performance requirements, a= nd other documentation
To help determine the minimal operational functionality for an Entit= y Registry.
To define core APIs and Messaging Interfaces required for integratin= g the Entity Registry with other TIER components.
To communicate those minimal requirements to the TIER API working group for iteration/refinement an= d delivery to the affected component(s) for implementation.
To use those requirements as a basis for the following deliverables.=
Determine and document a set of entities and their associated data t= ypes and data fields that this first iteration Entity Registry must be able= to support (example: institutional person, guest person, profile informati= on).
Build a glossary for the set of enrollment, credential generation/li= nking, and other institutional processes that this Registry must eventually= be able to support (example: conscripted enrollment, invitation-based enro= llment, delegated enrollment, self-service enrollment, generating credentia= ls or linking external credentials).
Determine gaps between COmanage=E2=80=99s registry and the minimal, = first iteration requirements for the TIER Entity Registry. Recommend to CAP= E that development work be commissioned to fill those gaps.
Iteration 1 (Mo= nday, February 1 to Friday, March 4, 2016)
Document Functional Requirem= ents for System of Record (SoR) to the Entity Registry per the = conscription pattern of enrollment.
In the conscription pattern of enrollment, person resources are crea= ted/mastered in the Registry; an SoR sends the Registry a representation of= a person resource that is new to them.
The Registry invokes a mock ID Match API operation that always retur= ns =E2=80=98no match=E2=80=99
The Registry creates a new mock person resource and returns a unique= id to the calling SoR.
Document operations on perso= n resources to be exposed as APIs and as event messages for the above conne= ctions, SoR to Registry and Registry to IDMatch;
Share drafts of these documents with TIER Data Structures and APIs W= G for their comments and questions.
Define a minimal first itera= tion Registry person schema/resource; Share with the API WG.
Draft a first iteration glos= sary of institutional processes around identity lifecycle management.
Draft fit/gap analysis betwe= en current COmanage registry functionality and this WG=E2=80=99s minimal, f= irst iteration requirements.
Provide CAPE with rough definitio= n of work required to fill in gaps in COmanage functionality, recomm= end commissioning that work.
Iteration 2 (Mo= nday March 7 to Friday, April 1, 2016)
After completion of the above tasks and deliverables, this Working Gr= oup should help draft a charter for a follow-on Phase II Entity Registry Working Group charged with determining a richer set of functionality for the Entity Re= gistry Component of TIER. Phase II work should also identify gaps, document= resource needs and outline a roadmap for implementing expanded functionali= ty in future releases of the TIER Entity Registry package.
Already completed
Creation of a WG Wiki space
Creation and archiving of a WG mailing list TIER-entreg@internet2.edu
NOTE: For now, we will use the&nb= sp;TIER-API= @internet2.edu list
Set up BlueJeans for WG meetings
Set up an issue tracking service using JIRA
JIRA Kanban Board has been created (SZoppi)
Project Owner: Warren Curry (whcurry@ufl.edu)
https://bugs.internet2.edu/jira/plugins/servlet/p= roject-config/TER
Creation of calendar invitation (Google calendar, Outlook, Office 36= 5).
Ongoing assistance
Funding to offset time and work b= eing done by external subject matter experts
Propose and send out agendas and meeting reminders
Arrange for TIER developers, QA people, and others to allocate some = of their time to working together with this WG as specified under "Tasks" a= bove