Closed soxofaan closed 4 months ago
Can you point me to where the openEO API assume a real person? I don't see specific action items to work on right now.
This is not per se about real vs non-real persons, but more about the disconnect between "normal" users and client credential based service accounts in OIDC. For example, user Alice also uses a service account through client credentials auth for machine-to-machine workflows. There is no standardized way to express the connection between Alice and that service account, so Alice has to log in separately with the service account, e.g. to list batch jobs and inspect their status/results. And on the web editor there is even no way to authenticate with client credentials.
But regardless, I don't see quick wins or concrete action items at the moment. Instead of more advanced user management at API level, we're seem to be growing to a consensus of sharing through signed URLs and STAC, So I'm fine to close this one due to lack of concrete problem and plan
I believe this issue is actually not something we would need to solve on the openEO API level. Isn't this something to solve in the implementation? Connecting client credentials with users and sharing resources between these "accounts"...
This comes out of discussions about "machine-to-machine" auth, like https://github.com/openEOPlatform/architecture-docs/issues/134 . The question/request is still a bit vague to be honest, but I just wanted to plant a seed here.
The openeo API currently has a user concept, and because of how OIDC works (the recommended auth mechanism in openEO) this pretty much corresponds 1-on-1 to a real person that interacts with a computer or other device.
Often in use cases however we see the need for a less strict "user" definition, for example:
As noted before, this might be primarily an authentication problem that has to be solved on the level of OIDC. Still, I'm wondering if there are some places in the openEO API where we might want to eliminate or avoid implicit "user==real person" assumptions.