Federation type information at discovery endpoint

[MahdiBaghbani]

This PR change to OCM spec allows the OCM service to let others know if it trusts all servers (hence the type open) or only servers from a (or multiple) directory(s) (hence the type closed).

In addition to that, an instance MAY decide to trust domains outside of directories too.

Returned JSON in case of trusting everyone:

"federation": {
    "type": "open",
}

Returned JSON in case of trusting closed networks:

"federation": {
    "type": "closed",
    "trusted": {
      "domains": [
        "trusted-cloud-storage.org"
      ],
      "directories": [
        "https://iop.sciencemesh.uni-muenster.de/iop/mentix/cs3"
      ]
    }
}

I don't like the names open and closed but I cannot think of anything better.

[glpatcern]

I definitely support the idea, an improvement/simplification for the two cases follows.

1. Pure OCM, trust everyone

"federation" : {
  "trusted-domains" : [ "*" ]
}

2. OCM with whitelist of trusted parties

"federation" : {
  "trusted-domains" : [
    "trusted-cloud-storage.org"
  ],
  "trusted-directories" : [
    "https://sciencemesh-directory.org"
  ]
}

And the assumption remains that in the absence of this federation attribute, the server operates in pure OCM mode i.e. trusting everyone.

[MahdiBaghbani]

And the assumption remains that in the absence of this federation attribute, the server operates in pure OCM mode i.e. trusting everyone.

Agreed! "federation" field is optional, the "trusted-domains" and "trusted-domains" are also optional. I think "type" should be required.

---

I initially came up with a JSON object similar to your idea but then asked myself "What if the provider doesn't want to disclose its trusted parties?"

So "type": "closed" is my attempt to answer that question.

[glpatcern]

"What if the provider doesn't want to disclose its trusted parties?"

So "type": "closed" is my attempt to answer that question.

Understood. I also thought about "is this about disclosing information without the other party's consent", and if I don't see issues with a directory's URL (after all it's there to be well known), the concern applies to specific domains where EFSSs are hosted.

At this point I'm thinking, if not too wild, to have a response that depends on the client making the request:

1. Pure OCM, trust anyone: "trusted-domains" : "*"
2. I trust "you" (the domain where the request comes from): "trusted-domains" : "some-efss-domain.org"
3. I don't trust "you": "trusted-domains" : "restricted" or some specific word to mean that the EFSS is part of a restricted/closed federation, which the requestor is not part of.

[MahdiBaghbani]

Is this about disclosing information without the other party's consent

I agree. so it needs mutual consent. the admins of the parties should agree on showing this kind of info on their respective servers.

So we can have 3 possible cases for the "trusted-domains":

1. "trusted-domains" : ["*"]
2. "trusted-domains" : ["restricted"]
3. "trusted-domains" : ["mahdi-domain.org", "cloud-drive.dev"]

At this point I'm thinking, if not too wild, to have a response that depends on the client making the request

This is also interesting, for example in cases 2 and 3 from above, some hidden domains only are shown to the requests coming from trusted parties. so the outcome would be:

2. "trusted-domains" : ["only-show-to-trusted.com"]
3. "trusted-domains" : ["mahdi-domain.org", "cloud-drive.dev", "only-show-to-trusted.com"]

I think we can remove trusted- from the attribute name too, do you agree?

Returned JSON in case of trusting everyone:

"federation": {
    "domains" : ["*"],
}

It can also have directories if the provider admin wants to indicate the provider's association with a federation (eg. government, public schools, etc)

"federation": {
    "domains" : ["*"],
    "directories": [
        "https://government.gov",
        "https://hospital.net",
    ]
}

Returned JSON in case of trusting closed networks:

"federation": {
    "domains": [
        "restricted"
    ],
    "directories": [
        "https://iop.sciencemesh.uni-muenster.de/iop/mentix/cs3"
    ]
}

or just:

"federation": {
    "domains": [
        "restricted"
    ]
}

[glpatcern]

RIght, you made a fair summary, and after all if the different options are described in terms of MAY statements, it's all fine - the whole block is optional anyway. There could possibly be a SHOULD: in case the requestor is a trusted EFSS, the response SHOULD contain the requestor's domain in the trusted-domains list.

Then whether to drop trusted- I'd actually prefer to keep it to convey the message that this section is about mutual trust. But no strong opinion here.

[michielbdejong]

in case the requestor is a trusted EFSS, the response SHOULD contain the requestor's domain in the trusted-domains list.

Hm, but until now we have always done requests to /ocm-provider with unauthenticated GET. If two servers are part of a federation the they should use that federation's directory anyway, like ScienceMesh uses gocdb, right? Aren't we overcomplicating things unnecessarily with this?

I think I like the original proposal of 'open'/'closed', and would even just stop there. If it says 'closed' then it means "don't expect me to accept your shares unless you have reason to believe otherwise", and if it says 'open' it means "go ahead, try me, unless you're blacklisted, your shares will probably arrive".

There may be a few other options, such as "open after invite", "open if signed", etc.

Requirements a receiving server may have:

• request should be signed
• sending server should not be blacklisted
• sending server should be whitelisted
• receiving user (shareWith) should have accepted an invite from sending user (sharedBy)
• ... (anything else?)

Note that a blacklisted spam server could still send unsigned request with a fake sender domain, so having a blacklist is only a partial measure unless you also block unsigned requests. OTOH servers will probably accept unsigned requests until all implementations have started signing their requests and servers in the wild have (almost) all been updated to that.

[michielbdejong]

So I would suggest federation types:

• open
• signed
• blacklist
• whitelist
• invite
• signed,blacklist
• signed,whitelist
• signed,invite
• signed,blackist,invite
• signed,whitelist,invite (this is the federation type of ScienceMesh)

And note that if federation type includes 'whitelist' then in theory there is no need for a /ocm-provider endpoint, the members of the whitelist could just receive the server config details directly via other means.

[glpatcern]

Hmm actually going down to just federation_type could make sense, and surely simplifies the implementation (no need to inspect the client's host etc.).

With the usual replace of black/white to deny/allow, we can just have an array of essentially any values out of open,signed,allowlist,denylist,invite,signed (with the obvious self-contradicting sets being excluded, but I'd assume they're obvious enough not to be spelled out one by one!)