Privacy for Job IDs

[matthias-mueller]

This issue popped up when I read the discussion in #69 where several examples hinted that there is some kind of "get all jobs" endpoint. This might be a privacy issue because you can actually spy on other people's activity an data. In the original WPS2.0 spec we had an explicit comment on that:

6.7 Job Monitoring
...
For privacy, it is recommended to keep this identifier confidential between client and server.
...

Having a publicly accessible endpoint that lists all jobID overrides this safety mechanism.

I am not saying that this feature should not be avaliable in WPS installation because it is convenient for administration/monitoring - but I would not make it part of a public API without some kind of security layer.

[pvretano]

@matthias-mueller in our implementation even if you have the job id does not mean that you access to the job resource since there is an orthogonal security and access control layer that sits on top of the processes API.

[matthias-mueller]

@pvretano The security layer makes sense. - I would also consider response filtering to show an authenticated user only those job-IDs for which he/she has access rights.

[christophenoel]

I also support peter's answer. What you suggest matthias is indeed exactly what I did in a previous project.

[bpross-52n]

We should probably extend the respective section of the security considerations with additional text.

[matthias-mueller]

I think it's a bit more than just additional text. If you decide that this is the way to do it you can hardly imagine a WPS-REST with anonymous access. Because you "log" all transactions (i.e. the jobs) and put them in a publicly visible place for every one to crawl. To take an analogy with data services, this is eqivalent to logging WFS/WMS/WCS requests/responses an put them in a browsable location for a short period of time. Except that WPS calls may include external (possibly non-public) input data.

[bpross-52n]

What do you propose to cope with this, then? Also, keep in mind that the job list is an extension, so it is up to the implementer to support this.

[christophenoel]

@matthias-mueller:
I think that the idea of an orthogonal security is that you don't specify/impose a security policy, but rather provide guidelines for a security model.

One implementation could enforce a role-based permissions system, while another implementation could live with a simple authentication system (members access all, guest access nothing).

What do you think ?

[matthias-mueller]

Well, the first step would be to agree on whether operating a publicly/intra-organisation accessible anonymous WPS service is a viable use case. Everything else follows from there.

[christophenoel]

Well, it is probably not a viable use case. But this doesn't imply the standard should specify anything about how to handle the authentication and access control aspects. I assume this is all the same for WCS, WFS, WMS ...

[matthias-mueller]

@bpross-52n In fact I was not aware that a granular feature like the job list had its own extension. So the security implications should go in front of that extension.