EDGC DECISION: Sensitive/Restricted Data Authorization in the Person API

Posted on

DECISION: Sensitive/Restricted Data Authorization in the Person API

EDGC Decision Date: April 22, 2024

DECISION: Sensitive/Restricted Data Authorization in the Person API

Reference

Background

The Enterprise Integration API Team started Person API development work for the T2 parking system used across Universities of Wisconsin on Nov 15, 2023.  This work is categorized by ATP/ASP as a “Big Ball of Yarn” meaning it has widespread implications for data integration and many stakeholders.  The current strategy promoted by ATP and the Universities of Wisconsin CIO calls for Person API to be the primary means for Person data integration across Universities of Wisconsin.

The following new data elements will need to be added to the Person API to support T2:

  • Home Address
  • Home Phone
  • Cell Phone
  • Date of Birth
  • Payroll Deductions (an alternate means to get this data exists)
  • Salary (an alternate means to get this data exists)

The API Team believes the following based on preliminary discussions with representatives (Liz Cota, Stacy Scholtka) from the Enterprise Data Governance Council (EDGC):

  • Since August 2023, EDGC has not been able to categorize these data elements consistently across Universities of Wisconsin institutions, and thus have not been able to provide guidance to the API Team.
  • The data elements needed for the T2 use case may be classified as sensitive or greater, possibly depending on context.
  • Not all Person API consumers should be granted access to these data elements if they do not have a business need.
  • Additional levels of authorization will need to be added to the Person API to granularly restrict which applications might request, be approved, and consume these data elements.

 Sensitive+ Data Authorization

We will discuss with UW-Madison Data Governance Council representation as a next step.  Perhaps UW-Madison data governance can define a working path forward that Universities of Wisconsin Enterprise Data Governance Council can react to and/or adopt following Madison’s lead.

API Team Perspective

Based on current usage of the API and its future as the primary mechanism to extend Person data across Universities of Wisconsin, the API team believes any solution should ideally align with the following criteria:

  • Balance least privilege with reasonable datasets
  • Defined and owned by appropriate data governance
  • Consistent across systems of reference (i.e. Person API and EAP should have identical datasets and authorization)
  • Consistent across Universities of Wisconsin institutions
  • Approved based on viable business needs as defined by data governance
  • Limited sensitive+ datasets based only on use cases across UW (i.e. we only add data to the API as business needs arise)

 Example:

  • We envision the Person API, EAP, and any other enterprise integration solution might express datasets like “Person-Sensitive”, “Person-Restricted”, etc. to align with the way the Data Warehouse differentiates domain and classification.
  • These datasets would not be available by default, but with some additional request/justification, review, and attestation.
  • The Person API could likely differentiate Student and Employee data in this manner as well if that granularity is recommended, e.g. “Person-Student-Internal”, “Person-Employee-Internal”, etc.

Conversely, we do not believe the following characteristics are viable:

  • Authorization based on individual data elements (i.e. each data element requiring a separate authorization mechanism in the API – does not scale to current or future usage)
  • Person API-specific data sets
  • Defined and managed by the API Team
  • Differ based on institution (i.e. Home Phone is “demographic-sensitive” at UW-Madison but “demographic-restricted” at UW-Milwaukee)
  • Tied to a specific use case (e.g. a T2-, Assetworks-, etc.-specific dataset)

Proposed Next Steps

  • Meet with Core Person Operational Data Governance group (UW-Madison) and Enterprise Data Governance Council to frame the problem and the need.
  • Work with data stewards to classify the data elements expressed in the Person API
  • Group these data elements into according to their classifications, e.g. Person-Sensitive, possibly breaking down further with respect to students or other sub-classifications
  • Express these data elements in the Person API only to approved applications – everyone does not need sensitive data.