Spec rewrite #103
Spec rewrite #103
Conversation
|
I'm running into some versioning questions. Also, not all servers should be forced to implement support for multi protocol shares or for the shuffled single protocol format. So maybe we can announce that as capabilities too. And then at the same time, full compatibility with incoming |
|
It does feel weird then that the default minimal server discovery document describes a server that uses |
|
I now have the following sections, it's chronological in terms of what should happen before what, so I can actually create separate PRs to the existing README:
|
|
The goal of this rewrite should mainly be to talk more about how trust is established. Other than that I think the existing spec in the readme file does a pretty good job. So I'll create separate PRs with smaller changes. |
|
I'll clean up the text with the new section headers and make that a separate PR, then take it from there. |
|
Here is a dump of my abandoned rewrite, for cherry-picking: Open Cloud Mesh (OCM) is a server federation protocol that is used to notify a remote user that they have Establishing recipient detailsAn OCM share creation may start in various ways. Here is a non-exhaustive list of examples. The initiation ends with the sending server share withIn the simplest case, the sending user types in the receiving user or group id and the OCM FQDN. They may also select it from a list of contacts. The receiving server MAY expose a directory service for the sending server to discover potential recipient users and (federated) groups. invitesIf Alice (alice at sender.com) and Bob (bob at receiver.com) know each other, yet they may not have a mechanism to trust any received share request, as that may be similar to receiving spam. In this case, Alice may invite Bob to initiate a mutual trust relationship: on the provider side, the sender.com service MAY implement an interface for Alice to generate a single-use token and send it to Bob off-band (e.g. via e-mail). In addition, the sender.com service MAY integrate this interface with ScienceMesh, and only allow a curated white list of sites as receivers. On the receiving end, assuming that Bob wishes to accept the invitation, the receiving server MAY provide an interface for Bob to input the received token, or to interact with the ScienceMesh directory. In any case, the receiving server SHOULD make a HTTP POST request to the /invite-accepted endpoint of the sending server, sending the token and disclosing Bob's identity details such as bob at receiver.com. If the token matches the one created earlier by Alice, the response MUST include Alice's identity details such as alice at sender.com. Following this step, both services at sender.com and receiver.com MAY display, respectively, bob and alice as trusted or white-listed contacts, and enable sharing between them. Sites MAY enforce a policy to only accept shares between such trusted contacts, or MAY display a warning to users when a share from an unknown party is received. For further details on this concept, see also #54 and related issues. For a discussion about trust policies, see sciencemesh#196. Servers MAY also support the send a unique stringSay Alice wants to initiate a connection with Bob, with the goal of discovering Bob's user identifier and OCM server, and at the same time sending her own user identifier and OCM server server-to-server information exchangeThe string contains the fully qualified domain name of Alice's OCM server, so Bob's server can use server config discovery (see above) to contact Alice's server. It can then make an contacts interfaceNext time Alice wants to share a resource with Bob, she will not have to input Bob's full user identifier and OCM server FQDN into her OCM server's interface. Instead, she will be able to select Bob share withIt uses a specific implementation of GNAP notifications, and a specific implementation of GNAP client instance discovery in case the public link to resourceIn another scenario, Alice creates a public link for a resource on her account on server 1. The fact that Bob is allowed to do this means Bob is essentially a resource owner for this resource on server 1. So then it's not much different from the share-with flow. It can be interpreted as a client instance switching protocol: bob@server1 acts as an RO, registers server2 as a client instance, and grants bob@server2 access. public link to inviteLikewise, Alice could create a public link that doesn't expose the document, but just allows people to send access requests to it by entering their OCM address. Decision to sendIn the share-with flow, the sender is (in OAUth terms) the Resource Owner who vets and registers the receiving server as a client instance, and triggers a notification. Client instance registration may happen on the fly. Scenario 1: only pre-trusted receiving servers. dynamic client registrationAlthough OCM is useful in a closed community such as a continent-wide network of universities that mutually trust each other, it can also be used in open mode, To enable this, the sending server needs to:
server config discoveryFrom a fully qualified domain name, the sending and receiving servers could discover information about each other by fetching The resulting configuration document can contain the following fields:
Notification of share creationSuppose Alice has an account on a sending server (sender.com) and Bob has an account on a receiving server (receiver.com).
POST /ocm/shares
Host: receiver.com
Content-Type: application/json
[...]
{
"shareWith": "[email protected]",
"code": "123456",
"protocol": {
"webdav": {
"uri": "https://sender.com/webdav/some/folder/"
}
}
}
share creation request fieldsThe JSON object in the
OCM protocol registry
|
No description provided.