Create expanded RestAPI endpoint for patrons/validate that exposes a limited set of patron fields
We have many vendors who have a need to check data in a few patron record fields as part of their authentication process. Fields such a ptype, home library, the expiration date, etc...are necessary to confirm that a patron is affiliated with the institution subscribing to that vendor's resource and that their card remains in good standing are necessary to provide. However, doing so currently requires providing the patron read permission, which also exposes a variety of additional sensitive data that these vendors should not have access to for their needs (PII, checkouts, fines, reading history, etc.)
The lesser patron validate role merely runs a binary check on a barcode/pin combination to ensure that data matches a patron in the database. We really require there to be something in-between those two extremes, more like the legacy non-rest API.
Jeremy Goldstein
shared this idea
-
Liza Arend
commented
This development is becoming increasingly important to our libraries. We are finding that some vendors are not willing to authenticate via the non-REST Patron API (https). Our libraries have depended on the legacy Patron API for authentication because it allows for p-type validation. We cannot open up REST API Patron Read access to vendors for authentication, because this opens up too many sensitive fields in the patron record. But the Patron Validate option does not allow validation by p-type, which is our libraries' preferred method of authentication. It would be great to have the Patron Validate fields expanded to allow p-type and also to allow validation without a PIN/Password.