How to manage and share site location privacy?

[amabdallah]

DRAFT

All WaDE's data is public except for some states, we do not want to publically share the coordinates of water supply sites (e.g., wells or treatment plants) for national homeland security reasons). It is a state-by-state case. For data query and visualization purposes in WaDE and its dashboard, we will mask the site's location by using the centroid of a small standardized watershed boundary called (HUC12) that the site falls within. The centroid will be calculated using GIS tools before loading the data to the database.

However, the USGS federal agency is one of our data users, they do need the real coordinates of those sites through a password-protected API call.

This issue applies to this data type, not water rights
https://schema.westernstateswater.org/diagrams/2_SiteSpecificAmounts.html

Question: How do we store both the actual site coordinates (for USGS use) and the masked site coordinate (HUC centroid)?
The public WaDE API will show the HUC site coordinate, while the password-protected API will show the actual site coordinates.

Possible Solution: What if we add the following two new fields to the sites table? HUC12Latitude and HUC12Longitude

The USGS API call will serve the Latitude and Longitude values, and the public WaDE call will serve the HUC12Latitude and HUC12Longitude values.

Complex case:
A few states, as in Utah, are okay with sharing the site location, which we want to publish through the WaDE public API and dashboard. Do we need a new third field that indicates if the site location is protected or public? If Protected, the API would show the HUC12Longitude, and if public, would the API shows the actual coordinates? How would the users know if they're getting the real location or the masked one? Is the CoordinateMethodCV a good place to report that?

Sites table
https://schema.westernstateswater.org/tables/Core_Sites_dim.html

[amabdallah]

We need to decide on how we want to use authentication to grant access to our protected API

Our sister project (OpenET) is using user-specific tokens for API authentication. Users can create accounts on the OpenET portal https://explore.etdata.org where they can generate a FireBaseID https://firebase.google.com/docs/reference/rest/auth

Then in the API, users can use that token to authenticate the API. This user-specific authentication allows API tracking per user.
https://openet.dri.edu/docs