Allow more fine-grained access permissions

[m-mohr]

[W]e just started leveling up from the simple binary anonymous-vs-authenticated model, by introducing the "early adopter" check for openEO platform. In the longer term more complex permission use cases might pop, e.g.

• user can only do "light" synchronous processing, but no batch jobs
• user can not store UDP or user can not store private UDP
• user can only have N concurrent batch jobs at the same time
• user has no access to this particular collection, bbox or process
• ....

Originally posted by @soxofaan in https://github.com/openEOPlatform/architecture-docs/issues/105#issuecomment-938642969

Yes, we may need to revamp the "endpoints" solution from GET / and also provide this in the GET /me endpoint on a per-user basis.

Originally posted by @m-mohr in https://github.com/openEOPlatform/architecture-docs/issues/105#issuecomment-938647864

[soxofaan]

I think we already have a working basis for fine-grained permissions: https://github.com/Open-EO/openeo-api/blob/f303d65a3291d4cd74dacc0e796803bb5d6fa03b/errors.json#L352-L354

The description might need some fine-tuning to focus less on authentication and more on authorization, but back-ends can already use this to implement fine-grained permissions (e.g. like the "early adopter check" in current version of aggregator).

However, I guess you're more thinking about knowing about potential permission issues before sending a request that may fail, e.g. to dynamically adapt an interactive user interface like the web editor or jupyter widgets (hiding features/panels, graying out buttons, ...). Or do you also have concerns about non-interactive usage (running a python script), and more "turn-based" usage (running a notebook cell by cell)?

[m-mohr]

However, I guess you're more thinking about knowing about potential permission issues before sending a request that may fail, e.g. to dynamically adapt an interactive user interface like the web editor or jupyter widgets (hiding features/panels, graying out buttons, ...).

Yes, indeed. The user experience would get much worse as right now the UIs adapt a lot based on what is exposed in GET / and users should not really see what they can't use (e.g. right now a Platform user would see completely unusable file and web service management tabs).

Or do you also have concerns about non-interactive usage (running a python script), and more "turn-based" usage (running a notebook cell by cell)?

R and Python don't use the endpoint list, right? So there it's try and error. What I believe would be nice to have: Allow users to request an overview of what they can and can't do. That may help to set expectations and avoid some frustration.