# DNS-IdM: A Blockchain Identity Management System to Secure Personal Data Sharing in a Network
## 6 DNS-IdM Use Case  
In this section, we elaborate on the use case of DNS-IdM architecture. We first define each of the phases of the proposed architecture and then put them in a real working scenario. The DNS-IdM design enables a third party to identify users and by that offer customized services, while still conserving users' ownership of the data. In the following, our proposed blockchain-based identity management system is composed of:  
* Account registration to gain access to the permitted ledger that holds the user's identity data.
* Identity attribute scalability, where different attributes can be added to the system.
* Users adding values to their identity data database.
* Verification of the attribute value by associated verification contracts.
* A permission-less ledger that holds the attribute-specific verification contracts.
* Conditioned access of service providers to the identity data ledger.  
While in a working scenario, we assume [PERSON] is 23 and wants to prove that to a third party server. [PERSON] does not want to reveal any other data other than that and wants to take control of her information. [PERSON] registers to the DNS-IdM, which allows her to gain access to the permissioned ledger so that she can promote her data. She will have an account entry that can ensure her access to her data.  
However, [PERSON] wants to maintain several attributes to her identities such as name, age, and profession by having the data written to the ledger. To minimize the freedom of erasing negative attributes or adding false information, a proxy contract takes charge throughout the validation process to approve attributes. Different attributes are stamped by smart contracts that can take advantage of different methods to validate information such as documents and biometrics. Those smart contracts  
Figure 8: Enhanced security of DNS-IdM with the validation layer.  
are maintained by different authorities depending on the type of attribute. Name and age can be validated by the \"e-ID validation provider\" smart contract, and the profession can be validated by a different node.  
Just like DNS, a similar approach is needed to know whom to contact and how to validate the attributes. Precisely, it is also required to determine why another permission-less ledger is maintained holding different addresses and keys. [PERSON] accesses the web application, claiming that her name is [PERSON] and she is 23. Automatically, a proxy is called to handle the validations. The proxy accesses the permission-less ledger to determine the address of the contract. The validator processes the claim and asks for the scanning of the e-ID, a way of authenticating data. After that, the claim is stamped, which sets the flag to one, and the transaction refers to the address of the validator. Signed data are sent back to the proxy, and [PERSON] is free to promote that on the Ethereum blockchain.  
After that, the service provider needs to know just two attributes, name and age, and a customized smart contract is coded based on the nature of the service that comes with the permission to access the ledger. The service gets to read off of the ledger certain attributes and can access the DNS-alike ledger to get the address to verify the stamp.  
The whole procedure ensures that privacy is maintained by keeping the permission exclusive to the user, and also, ownership is within the hands of the user. Even though the users are in full control of their data, that feature is being maintained, and the users cannot abuse this feature. Take into consideration that different attributes can be validated differently. For example, a university would find it sufficient to scan the ID to prove membership or a hospital would need biometric evidence. The whole working scenario comprises the concept of DNS, where entries can be added and updated. For example, if a service provider joins the network, it would like to customize and provide its validator contract that is feasible to accomplish, and by that, scalability is provided.