With the caveat that this is not my area of expertise, nor a complete proposal, I'd like to propose adding some structure around identifying who is making the API requests.
The authentication section includes an API key
x-api-key: <your api key>
My understanding is that this API key would be setup and static for a given system-to-system communication. Each of those systems will have any number of users, and generally those users would be identified in each request (when data is being written) with the userId field.
I'd like to see a mechanism where the authenticated user on the consumer side is passed through to the provider in a way that is cryptographically signed and validate-able. That would mean get requests could be attached to the user who performed them (not just the system with the API connection) and changes could be attached to that user via the userId field populated by the validated user ID.
If the API key in the implementation already is intended to be applied to only one user, we may be close, and just need a way to pass a userId or user object that can be validated on receipt to ensure we know who is making the request and who to attribute changes to.
Motivation
To ensure the receiving HMIS can validate who is making the API requests, ensure logging can be attributed in such a way that audit trails are follow-able, and ensure any changes requested are attributed to the user who made the request.
Track User in the Request
Summary
With the caveat that this is not my area of expertise, nor a complete proposal, I'd like to propose adding some structure around identifying who is making the API requests.
The authentication section includes an API key
x-api-key: <your api key>My understanding is that this API key would be setup and static for a given system-to-system communication. Each of those systems will have any number of users, and generally those users would be identified in each request (when data is being written) with the
userIdfield.I'd like to see a mechanism where the authenticated user on the consumer side is passed through to the provider in a way that is cryptographically signed and validate-able. That would mean get requests could be attached to the user who performed them (not just the system with the API connection) and changes could be attached to that user via the
userIdfield populated by the validated user ID.If the API key in the implementation already is intended to be applied to only one user, we may be close, and just need a way to pass a
userIdoruserobject that can be validated on receipt to ensure we know who is making the request and who to attribute changes to.Motivation
To ensure the receiving HMIS can validate who is making the API requests, ensure logging can be attributed in such a way that audit trails are follow-able, and ensure any changes requested are attributed to the user who made the request.