# DNS-IdM: A Blockchain Identity Management System to Secure Personal Data Sharing in a Network
## 7 Evaluation
### Security Analogy  
The blockchain framework can maintain identities and a vast number of nodes, away from centralization; therefore, concerns such as single-point failures can easily be addressed and do not affect the overall flow of the network. The probable phishing attacks also no longer exist in DNS-IdM, where the authenticating process does not include redirecting HTTPs. However, the same attack is very much feasible against the uPort system, since the private key is generated and stored locally. The private key controls the uPortID, and once it is compromised, no user authentication steps are in place to protect. This vulnerability makes it possible for the attacker to control all personal data permanently. Moreover, uPort lacks identity attributes validation, which implies that the attacker can make false claims. Phishing attacks might not be a threat to the Sovrin system, due to the fact that authentication  
\begin{table}
\begin{tabular}{l c c c c} \hline \hline
**Parameter** & **uPort** & **Sovrin** & **ShoCard** & **DNS-IdM** \\ \hline Protected Ownership & ✗ & ✗ & ✗ & ✓ \\ User Control and Consent & ✓ & ✓ & ✓ & ✓ \\ Directed Precise Identity & ✗ & ✓ & \(\approx\) & ✓ \\ Human Integration & ✗ & ✗ & \(\approx\) & ✓ \\ Validation Layer & ✗ & ✗ & ✓ & ✓ \\ Privacy Friendly & ✗ & ✗ & ✗ & ✓ \\ \hline \hline \end{tabular}
\end{table}
Table 2: The security comparison of DNS-IdM with 3 advanced identity management systems.  
cannot be replayed (random one-time nonce). With the Public Key Infrastructure (PKI)-no password infrastructure, there is nothing for attackers to steal and attempt a phishing attack. Countering this, authentication is done both ways, and the service provider's signature is matched to a well-known public key.  
In DNS-IdM, users can gain the ownership of their identity data and maintain them on a secure ledger, and by that, privacy concerns are addressed with the absence of a third party. It enables the control to be handed to the user and away from IdPs. Considering a similar scenario, other systems are not as robust as DNS-IdM. With the uPortID recovery schema, the user's uPortID is transparently linked to the trustees uPortID, meaning that it can be a vector of attack that targets the ownership and identity privacy. While the controller is compromised and the trustees of uPortID is replaced, the attacker simply gets full control over the user's identity. A similar concern might arise with Sovrin systems, as well. Due to users high reliance on agencies and stewards, confidential data can reach unauthorized parties, minimizing privacy and ownership. From the protected ownership aspect, ShoCard plays the role of the middle man, and that might lead to creating unreliability about whether the ShoCardID would still exist, while the company is non-existent. The users will not be able to make use of their certifications; hence, it puts the user's identity ownership at significant risk. From the privacy aspect, even though data stored in the ShoCard servers are encrypted, it may be possible to map a specific ShoCardID to a relying party.  
The significance of the validation layer and how it enhances security to DNS-IdM were already discussed in Section 5. However, while comparing other systems, we revealed that uPort offers no validation requirements to the identity attributes provided by the user. Although the Sovrin system relies on the web-of-trust as a sort of validation, it lacks a cut edge validation layer. As for ShoCard, credentials are bootstrapped with the user's identity as a validation method, such as a passport or driving license, which can provide validation. On the other hand, this approach does not ensure minimal disclosure of personal data, and the ShoCard seal can include more data than intended or needed.