Merge pull request #2 from 51nodes/modify-readme

Modify Readme: add more details for security and privacy. Ready for rereview

README.md

@@ -97,16 +97,39 @@ Alternatively, the schema could be loaded using the reference library function `
 
 #### Update
 
-A schema DID is implicitly updated by updating the corresponding file in the underlying storage network. It is assumed, though, that the schema hash provides a reference to an immutable set of data. This is the case in the IPFS networks where any change in a schema file would result in a new hash and thus a new DID.
+A schema DID is implicitly updated by updating the corresponding file in the underlying storage network. It is assumed, though, that the schema hash provides a reference to an immutable set of data. This is the case in the IPFS networks where any change in a schema file would result in a new hash and thus a new DID. That's why the reference library currently does not offer a distinct update operation and it is required to call the `registerSchema` operation again if the content of a schema is updated.
 
 #### Delete
 
-A schema DID is implicitly deleted by deleting the corresponding file from the underlying storage network.
+A schema DID is implicitly deleted by deleting the corresponding file from the underlying storage network. On IPFS networks, there is however no guaranteed way that a resource is actually deleted, since it may still be stored on some of the distributed nodes.
+
+Since the explicit deletion of a schema is not considered a mandatory requirement, the delete operation is currently not supported in the reference library.
 
 ## Security Considerations
 
 The basic purpose of this DID method is to store, identify and resolve schema definitions in a decentralized way. This is not considered to be a security critical mechanism. However, along the process of storing and accessing data, users of this DID method must take the usual common sense precautions to protect their accounts (e.g. to be used for pinning in IPFS networks) and do not expose any credentials or other security sensitive information in schema content.
 
+In addition, each Storage network has its own security aspects:
+### Public IPFS 
+One of the security considerations is evading. A node can easily generate a completely new [node identity](https://medium.com/textileio/how-ipfs-peer-nodes-identify-each-other-on-the-distributed-web-8b5b6476aa5e) making it impossible to exclude dishonest nodes, which could serve content that does not match the requested [CID](https://docs.ipfs.io/concepts/content-addressing/).
+
+Another consideration is using public or private [IPFS gateways](https://docs.ipfs.io/concepts/ipfs-gateway/#overview). A gateway can be malicious or have vulnerabilities that would allow a [man-in-the-middle attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) to intercept and manipulate communication between the client and the gateway.
+
+Therefore, recipients should verify that the received content matches the requested CID. In case of adding a new schema to IPFS through a gateway, the resulting CID should also be verified to match the added content.
+
+A [DDoS attack](https://de.wikipedia.org/wiki/Denial_of_Service) on the public IPFS network is difficult because of its distributed and peer-to-peer architecture. The content is spread over several nodes and can be accessed through the distributed storage network.
+
+### evan.network IPFS
+Since the IPFS of evan.network is a permissioned IPFS cluster accessed through a centrally managed endpoint, evading or man-in-the-middle-attacks should not be a security concern. However, the permissioned network is currently small and a DDos attack on the network is possible.
+
 ## Privacy Considerations
 
 Due to the fact that schemas are technical definitions of data structures that should never involve any personal information, privacy should not be much of a concern. In all supported storage networks, the data is stored anonymously and can not be traced back to any specific individual. It is the responsibility of the party providing the schema to make sure that no privacy sensitive data is contained in the schema content.
+
+Each storage network also has its own privacy considerations:
+### Public IPFS
+With a slight modification to the IPFS node, clients requesting content can be tracked and information like the IP address, node id or region could be collected and correlated. That happens because when a user running a node requests content from the network, each connected node receives a message asking for that content. Even if the user is not running an own node but uses a gateway, the provider of the gateway could also track the user's request and content.
+
+### evan.Network IPFS
+Because evan.network IPFS is permissioned, accessing the content for non participating users is only possible through gateways which are provided by evan.network or known node operators. Therefore, the privacy of user request data is the responsibility of the gateway provider.
+