Use federatedCloudId instead of email for user identification between servers

[MahdiBaghbani]

This PR changes 2 things:

1. Renames userID to userId to be consistent with camelCase across the whole specification eg. providerId
2. Adds a field to the invite-flow called federatedCloudId.
3. Removes recipientProvider since it is redundant and is repeated on federatedCloudId.

---

Reason behind the new field Previously OCM used email as a way to identify remote users.

This is essential when a party tries to send a share or notification to another party because it is going to find the domain name of the recipient from their ID (which currently is set to email, look at Reva and ScienceMesh)

This becomes problematic when the user's email name or domain is different than the user's username or provider domain. for example:

1. Alice is on provider apollo.space with username alice1998 and has email alice1998@apollo.space -> OK
2. Bob is on provider nasa.space with username bob and has email bobby@gmail.com -> Problem

Vendors can overcome this problem by not providing the user's email and just returning username@provider-domain in the email field.

I think it is a good idea to make a distinction between email and federatedCloudId.

[MahdiBaghbani]

It seems, that the invite is being accepted by 51dc30ddc473d43a6011e9ebba6ca770@receiver.org

As implemented in ScienceMesh

So no need for the new filed in this PR.

[MahdiBaghbani]

I think this https:// (look at Test Suite) bug is originated from here.

The "recipientProvider": "https://receiver.org/" has the protocol schema instead of just the domain.

Proposal: Merge both userId and recipientProvider into cloudId = userId@recipientProviderDomain

[michielbdejong]

Proposal: Merge both userId and recipientProvider into cloudId = userId@recipientProviderDomain

That would be a breaking spec change with costs to implementers. What if instead we just improve how the existing userId and recipientProvider fields are documented? In particular, make it clear that recipientProvider should be an FQDN and not a URL?

[MahdiBaghbani]

That's right, that makes sense since it is already inside Reva and ScienceMesh, and they don't check if it is URL or FQDN.

PS. For future reference, this is the Reva code for accepting an invite.

[michielbdejong]

So do we want to close this PR without merging then?

[MahdiBaghbani]

Yes!

we just improve how the existing userId and recipientProvider fields are documented.

that would be in another PR.