Improve specification for sharing to `group` or `federation`

[glpatcern]

The current Share Creation Notification includes a shareType field that SHOULD (actually, MUST) be one of user, group, or federation, where the latter cases correspond to:

• group: a group of users at the Receiving Servers (should be a single Receiving Server)
• federation: a group of users that is spread out over various servers, including at least one user at the Receiving Server

The issue is that there's no provision about how to advertise or inform parties about the identifiers of such groups, in particular when it comes to a "federation" that spans multiple servers.

This is a topic that indirectly came up as part of the current build-up of the EOSC Nodes, given that some kind of global/federated AAI is sought after, and this is where such "OCM-sharing to a group or federation" would fit. In that context, a Directory Service may also host a sort of address book of federations. But in general, an OCM Server may also provide the same functionality (IIUC this is what Nextcloud names Circles).

I think we should expand the OCM specification in order to contemplate such options. Any thoughts @sunetfreitag @mickenordin ?

[KrausMatthias]

One alternative approach might be a OCM Server acting as proxy. The Proxy would receive the federated share, and forward it to the actual recipients, posing as sending server. That way the members of a federated group could stay private.

We also need to make sure to prevent loops of federated shares or forbid nested federated groups entirely

[sunetfreitag]

I went through the current document and currently have more questions than answers. I will work on the answers during the next few days. Here are my thoughts:

The current definitions and relations between 'federation' shareType, groups, federated groups, directory service and the share creation notification are ambiguous and require more specification and definition, especially their relationship to ocm address. There are currently eight references to federation in current specification.

General references to federation:

• Abstract: "Open Cloud Mesh (OCM) is a server federation protocol"
• Invite Acceptance Request Details mentions federation in the context of the WAYF Page: "[...] if the Invite Sender is part of a federation of associated OCM Servers."
• Trust security considerations: "(...) the Directory Service feature can be used to establish a trusted federation"

Technical references to federation:

• OCM API Discovery: shareTypes as part of the resourceTypes field: "The supported recipient share types. MUST contain "user" at a minimum, plus optionally "group" and "federation""
• Share Creation Notification field: "shareWith" is the OCM Address of the user, group or federation (REQUIRED)
• Share Creation Notification field: "shareType" "SHOULD have a value of "user", "group", or "federation""
• Directory Service: "federation - a human-readable name for the list of OCM Servers exposed by the Directory Service" (two mentions of federation)

This can be ambiguous, especially in the context of OCM Addresses. Here some thoughts and questions:

• If I share a resource with a federation (shareType), would that mean that all users of a federation would have access to the resource?
• If I share a resource with multiple OCM Addresses, residing on multiple servers, could this share be interpreted as a federated group?
• Should federation be mentioned in the Term definition for "Receiving Party" instead of 'party'?
• Should federation be mentioned in the Term definition of "Receiving Server", which currently only mentions user or group?
• Should federation be included in the Term definition of "OCM Address"? Would a federation OCM Address just be "@fqdn"?
• If a shareType is a federatin and a Discovery Service provides information regarding one (or several?) federations, what would the OCM Address look like? The current example only has a tag "federation": "The Science Mesh Directory".
• How would delegating access and shareTypes look like if delegated to an AAI infrastructure?

[MahdiBaghbani]

I reread the text and drafted my current understanding to move the discussion forward

ambiguous and require more specification and definition

I agree, the distinction between a federation share and a group share needs better definitions.

If I share a resource with a federation (shareType), would that mean that all users of a federation would have access to the resource?

Not clear from the current text, my understanding is that federation is a superset of group, I'll explain

• A group share targets a defined set of users (potentially spanning multiple servers if cross domain groups exist)
• A federation share is a special, broadcast like group that encompasses all users on all servers that are members of that federation

If I share a resource with multiple OCM Addresses, residing on multiple servers, could this share be interpreted as a federated group?

I don't think so. That's equivalent to sending separate direct messages to multiple recipients, not posting to a group chat. A "federated group" should be an explicitly defined entity with its own identifier, not inferred from a list of individual OCM Addresses

This implies we need an addressable notion of a group (and of a federation) with stable identifiers, The group's FQDN should be anchored to a single EFSS (likely the creator/owner domain) to avoid ambiguity. Again these are my opinions, and I could be wrong 😄

Should federation be mentioned in the Term definition for "Receiving Party" instead of 'party'?
Should federation be mentioned in the Term definition of "Receiving Server", which currently only mentions user or group?

Yes. I recommend using a more general term like Receiving Entity and enumerating user | group | federation wherever applicable to avoid duplication and drift, or mention a list of entities and then update that in future in case of new types being added

Should federation be included in the Term definition of "OCM Address"? Would a federation OCM Address just be "@fqdn"?

I'd include it. I propose making @fqdn valid when shareType=federation, meaning "all users on that EFSS." The shareType disambiguates this from a user or group address

If a shareType is a federatin and a Discovery Service provides information regarding one (or several?) federations, what would the OCM Address look like? The current example only has a tag "federation": "The Science Mesh Directory"

For multi-server federations discovered via a discovery service, @fqdn isn't sufficient. We need a namespace identifier, e.g. federation:science-mesh (or similar), resolved via the discovery/directory metadata. The Directory/Discovery Service can be described in an appendix (out of scope for spec.yaml) with a clear note that it's a third-party service

And now reviewing my own proposal: I'm not entirely sure this is the best way to specify the JSON format. Definitely we're not putting anything in spec.yaml for this as this is a third-party service: is that clear enough?

Originally posted by @glpatcern in #184 (comment)

I would say a tag isn't enough and we would need a UUID v7 or v4 ID to uniquely identify a federation

[mickenordin]

My first choice for defining a federation would be to specify an array of ocm-adresses in the recipient field, such that all servers know all the information about the federation. It would work by the sharing server doing a ocm share with an array of ocm addresses, and the recieving server would loop through the array, and act on those that belong to that server. For future reference it might save all the addresses in the recipient field as a federation entity associated with the resource.

My second choice would be the ocm-proxy variant where a single recipiant at a server is acting as the placeholder as proposed by Mahdi. In this case we will need additional logic to establish the federation and broad casting information about it in separate messages I think.

[MahdiBaghbani]

My first choice for defining a federation would be to specify an array of ocm-adresses in the recipient field, such that all servers know all the information about the federation. It would work by the sharing server doing a ocm share with an array of ocm addresses, and the recieving server would loop through the array, and act on those that belong to that server. For future reference it might save all the addresses in the recipient field as a federation entity associated with the resource.

I think these two can co-exist

The way I understand the protocol, if they are part of the federation, they would have a directory service right? even if not exposed on discovery, the EFSS has some internal means to

reference it might save all the addresses in the recipient field as a federation entity associated with the resource

so, sending server knows which servers to send the notifications, and receivers can verify:

1. the notification comes from a server for a federation (identified via name, id, etc), the sender is part of that federation, receiver (itself) is also part of federation, request is sigennd, if a condition fails => reject
2. Do the work of adding share to individual user accounts on its own instance

I think of it as an email service, we have predefined mailing-lists address that handles the propagation and the CC and BCC ability

[KrausMatthias]

My understanding of ShareTypes:

• user: One individual user at one OCM Server
• group: Multiple users at one OCM Server (members of that group are known by the OCM Server)
• federation: Multiple users on multiple OCM Servers (forming a "federated group", where memberships in this federated group are kept is yet unclear)
  • optionally all OCM Servers need to be in a federation via a Discovery Service?

Representing a "federation share" via a list in the recipient (shareWith) field might be problematic as it would make changing the members of a federated group quite complex as that would need to be propagated to all recipients of all existing shares to that federated group.

Options I see:

1. federated group is published by Discovery Service as a list of OCM Address of users or groups

• Sending Server sends copies of the Share to all Receiving OCM Servers based on that list with shareWith pointing to that list
• Receiving Server checks federated group list to know to which individual users or groups this share needs to make accesible
• Receiving Server would need to check for updates of this list for additions/removals from this list
• Memberships are public or only accessible to OCM Servers in the federation via httpsig

2. Sending Server keeps a list of members of the federated group (Proposal by @MahdiBaghbani at Improve specification for sharing to group or federation #270 (comment))

• Sending Server sends copies of the Share to all Receiving OCM Servers based on that list with shareWith pointing to individual recipients
• Receiving Servers do not know about other members of the federated group (same as it doesn't know other recipients of "user shares" to other Servers)
• SendingServer updates shares on changes to the list of members of the federated group

3. Proxy Approach

• SendingServer doesn't need to know anything about the federated group and sends share to Proxy (doesn't even need to know it's a federated share)
• Proxy keeps a list of members of the federated group
• see behavior of option 2.

[KrausMatthias]

For multi-server federations discovered via a discovery service, @fqdn isn't sufficient. We need a namespace identifier, e.g. federation:science-mesh (or similar), resolved via the discovery/directory metadata. The Directory/Discovery Service can be described in an appendix (out of scope for spec.yaml) with a clear note that it's a third-party service

I would keep @fqdn und use it as namespace identifier. We could say for federated shares the fqdn points to the discovery service or the the OCM Proxy (which might be the same). Then we won't have the conflicts with tags "federation:science-mesh" and avoid unreadable UUIDs.

Instead we could have "@federation.science-mesh.org" where federation.science-mesh.org might have a .well-known/ocm for a Proxy or a Directory Service at some to be defined endpoint (or use "@federation.science-mesh.org/directory-arbitrary-example.json" where the path is part of the identifier)

[glpatcern]

Sorry I can't review the entire discussion now (happy to see such activity though!), but just adding a clarification, also for #268:

A federation was NOT meant to be a broadcast to all users of an EFSS. This is in most cases just meaningless (e.g. at CERN we have 30K+ accounts, and we know there are EFSS with over 100K accounts). The idea is that the recipients of a federation are spread across multiple different EFSS systems / OCM servers, whereas users in a group all belong to the same OCM server (and we have to fix the typo in the spec).

That said, I'm only aware of Nextcloud having implemented some kind of share-to-federation, via "Circles", but I don't know the details, and how they use the opaque part of the OCM Address to identify the federation/circle. Surely for all the rest we can speculate on the specs as much as you wish :) but eventually we need to have a reality check.

[mickenordin]

What about this user story:

As a user I create a share to an ocm address on the form of <group>@<federation>, perhaps by searching a special "Federated groups" searchbox in the EFSS, by copy/pasting an address in to a recipiant box or by some other means indicating the will to create a federation share during the sharing gesture..

In practice, this means that my server in turn creates a share notification with the same type and reciver and send it to all members of <federation> with share type federation one by one, without the need for a centralized component.

Creating the group in advance on all servers is out of scope, it can be done manually on all servers by out of band agreement by all server admins in the federation, by use of a common AAI system, or by some other mean.

Similarly, maintaing the group is out of scope, users can be added or removed at will on each server.

The size of the group on each server does not matter, it can have a single user on one server, or all users an all servers, the mechanism will be the same. And in fact, any ocm address could be used as the recipient, as long as it can be resolved on the server recieving the share notification.

This will be easy to implement, it will be backwards compatible and build on the work we have done with the discovery service, which is a good tool for knowing which servers are in a federation, but is in no way mandatory, configuring membership in a federation can be done in any way on the sending server.

This will also allow us to build on this work in the future, by perhaps inventing a "federated group invitation" from a server participating in a federation.