create new share: add permission specification

[moscicki]

I am thinking if or not basic permission information should be made protocol independent. So it is clear for example if resource is shared read-only or the receiver may modify it in some way. Pushing everything to the protocol level actually makes the “standard” very implementation specific (i.e. not standard).

[dvh]

We can add a global permission field but this will not give any guarantees. If, for example, the global permission for a share is read-only but the protocol options provide write access and the receiving service doesn't respect the global permission field, the receiver could still write to the resource.

[labkode]

@dvh If the receiving party does not respect the global permission of the specification I would rather say that such service is not OpenCloudMesh compliant.

[dvh]

True, but it can also be a mistake in the request. Imagine I send a global permission read-only and the protocol specific permission mechanism doesn't match this global permission, then the request should fail because of a validation error (global permission conflicts with protocol specific permission settings). However, to enable this kind of validation, the receiving party will always have to validate all possible protocol specific permission scenarios against the 'global permission' standard of OCM. I think this will introduce a lot of complexity and error risks while lowering the ease of maintenance.

[schiessle]

At Nextcloud we already send permissions along with a federated share. We provide the complete permission set we also have for internal shares:

• Files: edit permissions, reshare permissions
• Folder: create, change, delete, reshare permissions.

In our case all permissions are also enforced by the owner. Create, change, delete operations are just blocked by the owner if the permissions are not granted. Resharing is also blocked if it is not allowed since Nextcloud 10 version because of the flat re-sharing I presented during the workshop. (Of course we can't stop someone from downloading it and sending it by mail or uploading a copy with a different name and share this one).

Since permission can be changed at any time by the owner we have a additional API call for it which looks like this /shares/{id}/permissions. Maybe it makes sense to define something like this as well? Of course we could also use for almost everything the "notification" call but I don't think this reflex a good API. Actually this is a general problem I have with the "notification" end-point. It looks like a general collection for everything you might do. But I think it becomes quite confusing if you then need to read the payload to decide what to do with the notification. But that's a separate issue.