Security & privacy considerations
Tyron DIDs operate on Zilliqa, a public blockchain platform that implements PBFT (practical byzantine fault tolerance) as the consensus protocol, as explained in the Zilliqa's whitepaper. Given the 'public' nature of the network, Tyron anticipates that messages could be read, or corrupted in case of chain-reorganization. However, as long as there is no 51% attack the ledger's immutability, on which DIDs rely on, remains uncompromised.
The tyronzil SSI client currently interacts with Zilliqa nodes hosted by Zilliqa Research Pte. Ltd. as can be seen in the open-source code. It is also possible to submit transactions to any other node.
To interact with the user's DID smart contract, the client MUST submit a blockchain transaction. All Zilliqa transactions require an increasing nonce, mitigating this way replay attacks. The user can check their DID smart contract on, e.g. Devex to confirm that their operation did not get delayed. Furthermore, timestamps are supported and coded into the DID contract.
Smart contract security
Key revocation, DID recovery & deactivation
If a key is compromised, it is possible to remove it through a DID Update operation with a 'RemoveKeys' patch-action. To perform a DID operation, the user MUST posess the private did_update_key that corresponds to the public did_update_key stored in the DID smart contract, ensuring that any insertion, deletion or modification happens under stipulated terms.
If the private did_update_key is compromised, the user can request a DID Recover operation to replace their DID State, completely.
The DID Deactivate operation is also supported as long as the private did_recovery_key is not compromised.
This DID Method focuses on principle #7 of Privacy by Design: "Respect for user privacy — keep it user-centric". As a consequence, the user as the DID Subject is the sole DID Controller of their Decentralized Identifier.
Keep Personally-Identifiable Information (PII) private
Given that Zilliqa is a public & decentralized network, personal data MUST NOT get included in the DID Document, ensuring the user's right to be forgotten All personal information MUST exist behind service endpoints, under the user's control.
The exchange of personal data MUST occur on private, peer-to-peer communication channels.
The user MUST be aware that if using their Tyron DID with more than one party, then they are implicitly authorizing correlation between those parties. To mitigate this, a user can have as many Decentralized Identifiers as needed to engage in pairwise interactions. Either way, correlation can still occur if the same keys or personal service endpoints get used in different DID documents. Unique endpoints allow traffic to be easily correlated, so a better strategy is to share an endpoint among many DIDs. Tyron assumes uncompromised endpoints.