Control method for providers to specify/access only their provider_ids/devices
Is your feature request related to a problem? Please describe.
Define a data access and/or authentication control method within MDS to allow providers to specify and access things like provider_ids and vehicle_ids, but only for approved providers and vehicles.
Part of the solution may include requiring that providers and cities talk about what a provider is allowed to see, and define that cooperatively digitally, and use that definition to validate specific data exchange.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Is this a breaking change
- I'm not sure
Impacted Spec
For which spec is this feature being requested?
-
agency -
policy -
provider
Describe alternatives you've considered
Likely not to allow this sort of functionality at all.
Additional context
This came up in regards to PR #469 and was identified in this comment. Allowing a provider to add any provider_ids they have control over would be problematic.
Another place this comes up with is with Stops in Agency, where device_ids and provider_id can be specified. Should providers be allowed to see other provider's vehicle_ids, and if not how do you constrain this?
@Retzoh Do you have any thought on how to address this, given that it was part of a previous proposal you had?
@schnuerle I am personally not convinced that extended access control methods should be part of the MDS APIs.
Specifying who is allowed to access which data is already done when signing the data sharing agreements between the involved parties.
Controlling who is allowed to access which data is up to the implementation: you might prefer to encode the rights in a stateless JWT token, do a lookup in a relational database, etc. depending on your architecture.
In my opinion, the only things MDS may be missing to allow PR #469 for example are:
- perhaps an
unauthorizederror type. - perhaps some wording expliciting that any implementation should enforce that the servers behind any requests is allowed to read/write the data is is trying to (although I hope everyone already does).
@karcass @avatarneil what do you think ?
Does anyone else have thoughts on this? We need some discussion and decisions for the 1.1.0 release timeline.
Moving to Future for now unless someone makes a PR proposal this week.