Objective: Allow Libraries to assign granularity to API role permissions.

When Libraries give a 3rd party vendor read access, we want to be able to restrict the endpoints associated with the role. In addition, we want to restrict the fields that can be returned. Ideally, the implementation of the requested features below will provide an interface to the Innovative clients where the vendor access will be managed.

There are endpoint and field restriction examples below to show how assigning granularity to API role permissions would allow libraries to improve access management.

Endpoint restriction example:
We would like to be able to restrict the endpoints available to the vendor to a subset of options below.

The patron read role includes the following endpoints:

GET /v6/patrons - Get a list of patrons.

GET /v6/patrons/checkouts/{checkoutId} - Get a checkout by checkout ID.

GET /v6/patrons/find - Find a patron by varField fieldTag and varField content.

GET /v6/patrons/fines/{fineId} - Get a fine record by fine ID.

GET /v6/patrons/holds/{holdId} - Get a hold record by hold ID.

GET /v6/patrons/metadata - Get a list of metadata.

POST /v6/patrons/query - Filter the records by a query in JSON format.

GET /v6/patrons/validate/authmethods - Available methods for authentication.

GET /v6/patrons/{id} - Get a patron by record ID.

GET /v6/patrons/{id}/checkouts - Get checkout data for a single patron record.

GET /v6/patrons/{id}/checkouts/history - Get checkout/read history for a single patron record.

GET /v6/patrons/{id}/checkouts/history/activationStatus - Get the patron's reading history status.

GET /v6/patrons/{id}/fines - Get the fines data for a single patron record.

GET /v6/patrons/{id}/holds - Get the holds data for a single patron record.

GET /v6/patrons/{id}/holds/request/form - Get the hold request form for a bib record.

Field restriction examples:

Say we have allowed the use of the following endpoint:

GET /v6/patrons/{id} - Get a patron by record ID.

We would like to have the ability to restrict the patron record fields that are returned. Different vendors require access to patron data for various reasons and below are three scenarios that we hope will illustrate the utility of this requested feature:

Vendor A only needs to validate the PIN of a patron so that they allow use of a public access computer. In this case, we only need to provide patron validation access.

Vendor B needs to validate the PIN of a patron for the use of a public access computer, but they also need to ensure that the patron is not blocked. In this case, we need to provide patron validation access as well as read access to the blockInfo field.

Vendor C needs to validate the PIN of a patron as well as provide metrics on the age group. In this case, we need to provide validation access as well as access to the birthDate field.