Consolidation of federated sharing and sharing modules

[labkode]

As discussed, the first step is to define the federating sharing specification.

Currently, this functionality is split into two different modules (federated sharing and sharing), the idea is to consolidate into one where the only share type is federated sharing.

From my point of view, to have a complete set of functionality the endpoints would be:

From a sender point of view:

• Sending a share offer
• List created shares, query parameter to filter by pending or accepted
• Delete share
• Update share ? (in case expiration can be set on fed shares?)

From the receiver point of view

• List received shares, query parameter to filter by pending or accepted
• Accept a share offer
• Reject a share offer

From both:

• Get information about a share, some field with status(pending|accepted)

The remoteID identifies the share ID given by the sender. In order to be unique in the receiver, the receiver must scope this remoteID to the trusted server and remote user to avoid any clash with other users/remote servers.

Example scenario:

UserA from Organization OA sends share offer with:

• remoteID:123
• token:$$$
• owner:UserA

to UserB from Organization OB.

Organization OB OCM implementation must save the share offer with scoped user and remote server, this could be a simple string as with prefixes like: <trustedremoteserver>:<remoteuser>:<remoteid>, in this example it would be: ocm.OA.com:UserA:123. This schema grants uniqueness of the remote ID.

Do you think it makes sense ?

A corner case is also what happens when the trusted server changes domain. How ownCloud/NextCloud handles this situation? Are shares not accessible? @karlitschek @LukasReschke @DeepDiver1975 @PVince81

Cheers

[karlitschek]

Not sure I follow you here. The federated sharing functionality is 100% in the federated sharing module. This should be the scope of our project here because it covers all the server-server interaction. The 'sharing' module is not relevant here because it covers the client-server communicated. Examples are that you can request a sharing link from your phone. This is not part of this project.

[labkode]

Hi Frank,

I see your point, let me clarify it.

I do not want to put link, user or group sharing into the federating sharing. The methods described in my previous comment relate just for federated sharing.

As the main users of federated sharing are users I think it would worth to have in the API the possibility to give users an standard access point to consult, reject, accept and modify the federated shares without having to rely on a particular implementation. This part would be consumer facing API.

If we stick to server2server, then yes, the fed sharing would be the current 4 methods plus the ones to be defined to access the remote resources,

Cheers

[dvh]

A corner case is also what happens when the trusted server changes domain.

@labkode I think a trusted server should be identified with a client key instead of the domain

[labkode]

@dvh

Hi, sure, it makes much more sense to use a client key or a client certificate.

[michielbdejong]

I think this is an old design discussion (maybe also more about IOP than about OCM?) that can be closed now. The suggestions of accept/reject/delete/update are more or less covered by the notification types we have. The suggestion of a list-shares endpoint (in both directions) is interesting -> created #107 as a follow-up to make sure we have that suggestion documented.