Back to TIER Entity Registry Wiki Home Page
The ‘glue’ that binds IAM services together is an Entity Registry. Such a Registry facilitates the creation, maintenance, and distribution of person and other subject / entity information across TIER components and other elements of the institutional IT landscape. It must be capable of receiving, deduplicating, resolving collisions and otherwise grooming this information from authoritative 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 Group is tasked with identifying and documenting the minimum viable requirements for a TIER Registry component and making recommendations to the TIER Community Architecture Planning and Engagement (CAPE) group about the criteria for the adoption of an official TIER Registry component. This set of recommendations will then be used to guide the relevant API, development and packaging work.
Different audiences will need to be invited to engage on different aspects of this work. It will be important for team members to bring the perspective and represent the interests of at least the following stakeholder groups:
IAM software component designers and developers
Campus IAM and security service providers
Campus integration teams
Application developers
Any interested member of the community may participate in the activity of the group. Members self-select by 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 Hoc Advisory group .
The group should complete its first version of the following Phase I items no later than April 1, 2016.
Draw on the existing TIER Stakeholder Requirements, TIER component integration requirements (primarily Grouper and COmanage), CIFER API, CIFER Provisioning and Integration, performance requirements, and other documentation
To help determine the minimal operational functionality for an Entity Registry.
To define core APIs and Messaging Interfaces required for integrating the Entity Registry with other TIER components.
To communicate those minimal requirements to the TIER API working group for iteration/refinement and 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 types and data fields that this first iteration Entity Registry must be able to support (example: institutional person, guest person, profile information).
Build a glossary for the set of enrollment, credential generation/linking, and other institutional processes that this Registry must eventually be able to support (example: conscripted enrollment, invitation-based enrollment, delegated enrollment, self-service enrollment, generating credentials or linking external credentials).
Determine gaps between COmanage’s registry and the minimal, first iteration requirements for the TIER Entity Registry. Recommend to CAPE that development work be commissioned to fill those gaps.
Iteration 1 (Monday, February 1 to Friday, March 4, 2016)
Document Functional Requirements for System of Record (SoR) to the Entity Registry per the conscription pattern of enrollment.
In the conscription pattern of enrollment, person resources are created/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 returns ‘no match’
The Registry creates a new mock person resource and returns a unique id to the calling SoR.
Document operations on person resources to be exposed as APIs and as event messages for the above connections, SoR to Registry and Registry to IDMatch;
Share drafts of these documents with TIER Data Structures and APIs WG for their comments and questions.
Define a minimal first iteration Registry person schema/resource; Share with the API WG.
Draft a first iteration glossary of institutional processes around identity lifecycle management.
Draft fit/gap analysis between current COmanage registry functionality and this WG’s minimal, first iteration requirements.
Provide CAPE with rough definition of work required to fill in gaps in COmanage functionality, recommend commissioning that work.
Iteration 2 (Monday March 7 to Friday, April 1, 2016)
After completion of the above tasks and deliverables, this Working Group 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 Registry Component of TIER. Phase II work should also identify gaps, document resource needs and outline a roadmap for implementing expanded functionality 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 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/project-config/TER
Creation of calendar invitation (Google calendar, Outlook, Office 365).
Ongoing assistance
Funding to offset time and work being 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" above