oCIS cannot receive OCM shares from other EFSS

[MahdiBaghbani]

oCIS to oCIS

Let's assume that the invitation process is already done and the contact is establishied.

Share Sender

oCIS 2

user: marie

share payload:

{
  "shareWith": "4c510ada-c86b-4815-8820-42cdf82c3d51@https://1.ocis.cloud.test.azadehafzar.io",
  "name": "test-einstein-1.md",
  "description": "",
  "providerId": "RED-ACTED",
  "owner": "ZjdmYmY4YzgtMTM5Yi00Mzc2LWIzMDctY2YwYThjMmQwZDljQGh0dHBzOi8vMi5vY2lzLmNsb3VkLnRlc3QuYXphZGVoYWZ6YXIuaW8=@2.ocis.cloud.test.azadehafzar.io",
  "sender": "ZjdmYmY4YzgtMTM5Yi00Mzc2LWIzMDctY2YwYThjMmQwZDljQGh0dHBzOi8vMi5vY2lzLmNsb3VkLnRlc3QuYXphZGVoYWZ6YXIuaW8=@2.ocis.cloud.test.azadehafzar.io",
  "ownerDisplayName": "",
  "senderDisplayName": "Marie Skłodowska Curie",
  "shareType": "user",
  "expiration": 0,
  "resourceType": "file",
  "protocol": {
    "name": "multi",
    "options": {},
    "webdav": {
      "sharedSecret": "RED-ACTED",
      "permissions": [
        "read"
      ],
      "url": "https://2.ocis.cloud.test.azadehafzar.io/dav/ocm/RED-ACTED"
    }
  }
}

Problems:

1. The "shareWith": field is supposed to have OCM Address type, spec,
   the https:// is not part of specification for OCM Address, spec

Share Receiver

oCIS 1

user: einstein

Logs:

1. Finds out about the sender provider from "sender":

2025-10-15T09:43:08Z DBG Determined Mesh Provider '2.ocis.cloud.test.azadehafzar.io' from req.Sender 'ZjdmYmY4YzgtMTM5Yi00Mzc2LWIzMDctY2YwYThjMmQwZDljQGh0dHBzOi8vMi5vY2lzLmNsb3VkLnRlc3QuYXphZGVoYWZ6YXIuaW8=@2.ocis.cloud.test.azadehafzar.io' line=github.com/cs3org/reva/v2@v2.27.7/internal/http/services/ocmd/shares.go:91 pkg=rhttp request-id=46075842a68b/58Z5gnwZ0Q-000062 service=ocm traceid=f0fecb57eeb72250f6bf84bc14f3a310

2. Gets the user the share is intended for from the payload's "shareWith": field, it only reads the opaque_id part of OCM Address:

2025-10-15T09:43:08Z DBG GetUser id={"opaque_id":"4c510ada-c86b-4815-8820-42cdf82c3d51"} line=github.com/cs3org/reva/v2@v2.27.7/pkg/user/manager/ldap/ldap.go:101 pkg=rgrpc service=users traceid=b68e974c7f051f00175bca4fcd69775f

3. Do 3 LDAP searches

2025-10-15T09:43:08Z DBG LDAP Search backend=ldap basedn=ou=users,o=libregraph-idm filter=(&(objectclass=inetOrgPerson)(ownclouduuid=4c510ada-c86b-4815-8820-42cdf82c3d51)) line=github.com/cs3org/reva/v2@v2.27.7/pkg/utils/ldap/identity.go:217 pkg=rgrpc scope=2 service=users traceid=b68e974c7f051f00175bca4fcd69775f

2025-10-15T09:43:08Z DBG Calling boltdb search attrs=["displayname","ownclouduuid","mail","uid","uidNumber","gidNumber","ownCloudUserEnabled","ownCloudUserType"] basedn=ou=users,o=libregraph-idm binddn=uid=reva,ou=sysusers,o=libregraph-idm filter=(&(objectclass=inetOrgPerson)(ownclouduuid=4c510ada-c86b-4815-8820-42cdf82c3d51)) line=github.com/owncloud/ocis/v2/ocis-pkg/log/logrus_wrapper.go:50 op=search service=idm

2025-10-15T09:43:08Z DBG boltdb search returned 3 entries attrs=["displayname","ownclouduuid","mail","uid","uidNumber","gidNumber","ownCloudUserEnabled","ownCloudUserType"] basedn=ou=users,o=libregraph-idm binddn=uid=reva,ou=sysusers,o=libregraph-idm filter=(&(objectclass=inetOrgPerson)(ownclouduuid=4c510ada-c86b-4815-8820-42cdf82c3d51)) line=github.com/owncloud/ocis/v2/ocis-pkg/log/logrus_wrapper.go:50 op=search service=idm

Notice the (ownclouduuid=4c510ada-c86b-4815-8820-42cdf82c3d51).

My understanding is that oCIS uses the opaque_id portion of the "shareWith" OCM address from the share payload directly in the LDAP user search, without any manipulation or base64 decoding.

4. The user for whom the share is intended is found:

2025-10-15T09:43:08Z DBG entries entry={"Attributes":[{"ByteValues":["QWxiZXJ0IEVpbnN0ZWlu"],"Name":"displayName","Values":["Albert Einstein"]},{"ByteValues":["ZWluc3RlaW5AZXhhbXBsZS5vcmc="],"Name":"mail","Values":["einstein@example.org"]},{"ByteValues":["NGM1MTBhZGEtYzg2Yi00ODE1LTg4MjAtNDJjZGY4MmMzZDUx"],"Name":"ownCloudUUID","Values":["4c510ada-c86b-4815-8820-42cdf82c3d51"]},{"ByteValues":["VFJVRQ=="],"Name":"ownCloudUserEnabled","Values":["TRUE"]},{"ByteValues":["ZWluc3RlaW4="],"Name":"uid","Values":["einstein"]}],"DN":"uid=einstein,ou=users,o=libregraph-idm"} line=github.com/cs3org/reva/v2@v2.27.7/pkg/user/manager/ldap/ldap.go:112 pkg=rgrpc service=users traceid=b68e974c7f051f00175bca4fcd69775f

Others (in this case CERNBox) to oCIS

Invitation flow:

CERNBox shares a token, oCIS accepts and sends this payload:

{
  "email": "einstein@example.org",
  "name": "Albert Einstein",
  "recipientProvider": "1.ocis.cloud.test.azadehafzar.io",
  "token": "ed305914-b7ea-4b4e-a889-41a7217053c7",
  "userID": "NGM1MTBhZGEtYzg2Yi00ODE1LTg4MjAtNDJjZGY4MmMzZDUxQGh0dHBzOi8vMS5vY2lzLmNsb3VkLnRlc3QuYXphZGVoYWZ6YXIuaW8="
}

So the CERNBox (and Nextcloud) store the NGM1MTBhZGEtYzg2Yi00ODE1LTg4MjAtNDJjZGY4MmMzZDUxQGh0dHBzOi8vMS5vY2lzLmNsb3VkLnRlc3QuYXphZGVoYWZ6YXIuaW8=@1.ocis.cloud.test.azadehafzar.io as OCM Address.

Also based on the spec, the "userID" field should not be manipulated in
any way by the receiver, it is supposed to be known at the token-receiver (payload sender) OCM server.

if we decode the base64 encoded "userID", we get: 4c510ada-c86b-4815-8820-42cdf82c3d51@https://1.ocis.cloud.test.azadehafzar.io

Share Sender

CERNBox

user: lopresti

The "shareWith" field is the OCM Address obtained during the invite process.
share payload:

{
  "shareWith": "NGM1MTBhZGEtYzg2Yi00ODE1LTg4MjAtNDJjZGY4MmMzZDUxQGh0dHBzOi8vMS5vY2lzLmNsb3VkLnRlc3QuYXphZGVoYWZ6YXIuaW8=@1.ocis.cloud.test.azadehafzar.io",
  "name": "shared_via_ocm.txt",
  "description": "",
  "providerId": "RED-ACTED",
  "owner": "lopresti@qa.cernbox.cern.ch",
  "sender": "lopresti@qa.cernbox.cern.ch",
  "ownerDisplayName": "",
  "senderDisplayName": "Giuseppe Lo Presti",
  "code": "",
  "shareType": "user",
  "resourceType": "file",
  "expiration": 0,
  "protocol": {
    "name": "multi",
    "options": {},
    "webapp": {
      "uri": "https://qa.cernbox.cern.ch/external/sciencemesh/RED-ACTED/{relative-path-to-shared-resource}",
      "viewMode": "",
      "sharedSecret": ""
    },
    "webdav": {
      "sharedSecret": "RED-ACTED",
      "permissions": [
        "read"
      ],
      "uri": "https://qa.cernbox.cern.ch/remote.php/dav/ocm/RED-ACTED"
    }
  }
}

Share Receiver

oCIS 1

user: einstein

Logs:

1. Finds out about the sender provider from "sender":

2025-10-15T10:00:55Z DBG Determined Mesh Provider 'qa.cernbox.cern.ch' from req.Sender 'lopresti@qa.cernbox.cern.ch' line=github.com/cs3org/reva/v2@v2.27.7/internal/http/services/ocmd/shares.go:91 pkg=rhttp request-id=46075842a68b/58Z5gnwZ0Q-000100 service=ocm traceid=4df953e7eaba2e5ecb0bac5f8b724800

2. Gets the user the share is intended for from the payload's "shareWith": field, it only reads the opaque_id part of OCM Address:

2025-10-15T10:00:55Z DBG GetUser id={"opaque_id":"NGM1MTBhZGEtYzg2Yi00ODE1LTg4MjAtNDJjZGY4MmMzZDUxQGh0dHBzOi8vMS5vY2lzLmNsb3VkLnRlc3QuYXphZGVoYWZ6YXIuaW8="} line=github.com/cs3org/reva/v2@v2.27.7/pkg/user/manager/ldap/ldap.go:101 pkg=rgrpc service=users traceid=34778013c46575d69193c8c7f8497cca

3. Do 3 LDAP searches

2025-10-15T09:43:08Z DBG LDAP Search backend=ldap basedn=ou=users,o=libregraph-idm filter=(&(objectclass=inetOrgPerson)(ownclouduuid=4c510ada-c86b-4815-8820-42cdf82c3d51)) 2025-10-15T10:00:55Z DBG LDAP Search backend=ldap basedn=ou=users,o=libregraph-idm filter=(&(objectclass=inetOrgPerson)(ownclouduuid=NGM1MTBhZGEtYzg2Yi00ODE1LTg4MjAtNDJjZGY4MmMzZDUxQGh0dHBzOi8vMS5vY2lzLmNsb3VkLnRlc3QuYXphZGVoYWZ6YXIuaW8=)) line=github.com/cs3org/reva/v2@v2.27.7/pkg/utils/ldap/identity.go:217 pkg=rgrpc scope=2 service=users traceid=34778013c46575d69193c8c7f8497cca

2025-10-15T10:00:55Z DBG Calling boltdb search attrs=["displayname","ownclouduuid","mail","uid","uidNumber","gidNumber","ownCloudUserEnabled","ownCloudUserType"] basedn=ou=users,o=libregraph-idm binddn=uid=reva,ou=sysusers,o=libregraph-idm filter=(&(objectclass=inetOrgPerson)(ownclouduuid=NGM1MTBhZGEtYzg2Yi00ODE1LTg4MjAtNDJjZGY4MmMzZDUxQGh0dHBzOi8vMS5vY2lzLmNsb3VkLnRlc3QuYXphZGVoYWZ6YXIuaW8=)) line=github.com/owncloud/ocis/v2/ocis-pkg/log/logrus_wrapper.go:50 op=search service=idm

2025-10-15T10:00:55Z DBG boltdb search returned 3 entries attrs=["displayname","ownclouduuid","mail","uid","uidNumber","gidNumber","ownCloudUserEnabled","ownCloudUserType"] basedn=ou=users,o=libregraph-idm binddn=uid=reva,ou=sysusers,o=libregraph-idm filter=(&(objectclass=inetOrgPerson)(ownclouduuid=NGM1MTBhZGEtYzg2Yi00ODE1LTg4MjAtNDJjZGY4MmMzZDUxQGh0dHBzOi8vMS5vY2lzLmNsb3VkLnRlc3QuYXphZGVoYWZ6YXIuaW8=)) line=github.com/owncloud/ocis/v2/ocis-pkg/log/logrus_wrapper.go:50 op=search service=idm

Notice the (ownclouduuid=NGM1MTBhZGEtYzg2Yi00ODE1LTg4MjAtNDJjZGY4MmMzZDUxQGh0dHBzOi8vMS5vY2lzLmNsb3VkLnRlc3QuYXphZGVoYWZ6YXIuaW8=).

Now we have a problem!

4. The user for whom the share is intended is NOT found:

2025-10-15T10:00:55Z ERR user not found error="user not found" line=github.com/cs3org/reva/v2@v2.27.7/internal/http/services/reqres/reqres.go:64 pkg=rhttp request-id=46075842a68b/58Z5gnwZ0Q-000100 service=ocm traceid=4df953e7eaba2e5ecb0bac5f8b724800

Conclusion

If oCIS sends a base64-encoded identifier to other EFSS systems, it should handle the decoding as well and not depend on the remote end to do it. For a remote system, the identifier is opaque, and any manipulation or decoding is outside of the OCM specification

[glpatcern]

To put things in context, these tests are being carried out in the scope of the EOSC Federation. #11736 is a related issue for the other way around.

[kobergj]

@glpatcern @MahdiBaghbani I am a bit confused.

You stated

Also based on the spec, the "userID" field should not be manipulated in
any way by the receiver, it is supposed to be known at the token-receiver (payload sender) OCM server.

and ocis is sending payload

"userID": "NGM1MTBhZGEtYzg2Yi00ODE1LTg4MjAtNDJjZGY4MmMzZDUxQGh0dHBzOi8vMS5vY2lzLmNsb3VkLnRlc3QuYXphZGVoYWZ6YXIuaW8="

Why are you using

"shareWith": "NGM1MTBhZGEtYzg2Yi00ODE1LTg4MjAtNDJjZGY4MmMzZDUxQGh0dHBzOi8vMS5vY2lzLmNsb3VkLnRlc3QuYXphZGVoYWZ6YXIuaW8=@1.ocis.cloud.test.azadehafzar.io",

in the create share request? Isn't this manipulating the userID?

Unrelated to this the two points are valid

• ocm address is not in the correct format
• ocis should decode the userid it receives before continuing

[glpatcern]

Hey @kobergj, shareWith is expected to be an OCM Address, i.e. <userID>@<providerID>, following the example in the spec. The <userID> is left as is (it's opaque), the <providerID> is appended.

At the same time, you have a point that the description in the spec may be confusing as it says Consumer specific identifier of the user, group or federation the provider wants to share the resource with, without explicitly mentioning that an OCM Address is expected, despite this being the practice since the very early days. Note that both ownCloud 10 and Nextcloud use a full OCM Address.

We shall amend the spec to be clear here that we want a full OCM Address. Edit: the latest version of the spec, that was thoroughly reviewed, spells this out correctly: https://github.com/cs3org/OCM-API/blob/develop/IETF-RFC.md#share-creation-notification