Blockchain-Based Identity Management Systems in Health IoT: A Systematic Review

Identity and Access Management (IAM) systems are crucial for any information system, such as healthcare information systems. Health IoT (HIoT) applications are targeted by attackers due to the high-volume and sensitivity of health data. Thus, IAM systems for HIoT need to be built with high standards and based on reliable frameworks. Blockchain (BC) is an emerging technology widely used for developing decentralized IAM solutions. Although, the integration of BC in HIoT for proposing IAM solutions has gained recent attention, BC is an evolving technology and needs to be studied carefully before using it for IAM solutions in HIoT applications. A systematic literature review was conducted on the BC-based IAM systems in HIoT applications to investigate the security aspect. Twenty-four studies that satisfied the inclusion criteria and passed the quality assessment were included in this review. We studied BC-based solutions in HIoT applications to explore the IAM system architecture, security requirements and threats. We summarized the main components and technologies in typical BC-based IAM systems and the layered architecture of the BC-based IAM system in HIoT. Accordingly, the security threats and requirements were summarized. Our systematic review shows that there is a lack of a comprehensive security framework, risk assessments, and security and functional performance evaluation metrics in BC-based IAM in HIoT applications.


I. INTRODUCTION
E-Health is defined by the World Health Organisation (WHO) as the utilization of information and communication technology (ICT) in the health domain [1]. E-Health involves sub-domains like Electronic Health Records (EHR), Patient Health Records (PHR), and Mobile Health (m-Health). Health IoT (HIoT) technology is broadly used in e-Health fields. It is used in healthcare in different applications, such as health monitoring systems, real-time data, EHR, wearables, and many other applications [1]. HIoT is one of the targeted domains by attackers for its complexity, and the high sensitivity of data [2]. Thus, applying Privacy-Enhancing Technologies (PET) in HIoT-based systems is imperative. According to Cha et al. [3], there are seven different categories of PET, including personal data protection, control over data, and anonymous authorization. Identity and Access The associate editor coordinating the review of this manuscript and approving it for publication was Mehdi Sookhak . Management (IAM) systems (also referred to in the literature as ''identity management'') are deemed to be the primary safeguard for the access of any information system [4]. Therefore, using state-of-the-art technologies that have the potential to comply with data protection regulations, such as General Data Protection Regulations (GDPR), is paramount to enhancing data privacy and security. Ismail et al. [5], in a scoping review, studied the requirements of health data management systems in healthcare. They concluded that healthcare systems users need to be allowed to manage their data themselves, in accordance with GDPR. This study showed the transformation from traditionally using paper to record data to healthcare management systems, gradually moving through different stages that involve using emerging technologies like IoT, cloud and blockchain (BC). Such an evolution increases the importance of having functional, reliable, and secure IAM systems. The role of IAM systems involves using information security frameworks and technologies developed to provide secure access for legitimate users to the data assets. The significance of IAM in HIoT applications is high because of the kind and amount of data that HIoTs entail. Systems that are based on HIoT need to be studied carefully, as the system architecture differs from other typical systems [6].
BC technology was first invented in 2008 by Satoshi Nakamoto [7]. In 2013, BC 2.0 started by launching Ethereum BC and Smart Contracts. At that stage, BC was only used for financial applications. In 2017, there was a considerable rise in conducting research on BC technologies like Ethereum and Hyperledger in different domains like healthcare and for different purposes like IAM systems [8]. BC attracted researchers' attention to harness its advantages to develop decentralized IAM systems for HIoT applications. However, there is still a need for research on the standardization of this emerging technology and the security requirements for BC-based IAM of HIoT applications [9].
Our study, presented in this paper, has reviewed relevant primary studies proposing IAM solutions based on BC in HIoT applications. The aim is to explore the security threats and requirements, which are related to BC-based IAM systems in HIoT applications. Results from this systematic literature review will play a notable role in designing a security framework to be used as a guideline for developers and researchers who strive to harness BC for developing a decentralized IAM for HIoT.
The structure of the rest of this paper is as follows: Section II covers the background, Section III addresses the related works, Section IV describes the research methodology, Section V presents the analysis of the results, Section VI includes the discussion, limitations and future direction are covered in SectionVII, and Section VIII covers the article conclusion.

II. BACKGROUND
A. IDENTITY AND ACCESS MANAGEMENT IAM systems are crucial for the security of data in IoT applications [4]. IAM can be defined as a security system used for managing the life-cycle of digital identities to ensure that only authenticated identities can be authorized to access data assets in a system. An IAM system consists of two primary operations. The first is authentication (AuthN), a process which verifies identity, thus preventing malicious access to a system. AuthN ensures that a claim of identity ownership using either digital (e.g., public-key cryptography) or physical (e.g., biometrics) authentication methods. The second is authorization (AuthZ), a process ensuring that only legitimate users can access specific data assets using access control mechanisms. After authenticating an identity, there is a need to control the access to process data. The AuthZ operation is responsible for denying or granting user access to data, which is achieved by first defining policies (set of rules) and then using and applying access control methods [10].
There are five access control models that manage user access rights to data in traditional IAM: mandatory access control, discretionary access control, role-based access control, attribute-based access control, and capacity-based access control. Based on these models, rights are given to identities or users according to their roles and attributes. There are a number of access management standards used to fulfil the access control AuthZ and AuthN processes, such as OpenID-Connect, open authorization, security assertion markup language, and extensible access control markup language [11].
Based on these two operations, IAM guarantees secure access to systems. Identities are managed in the whole life-cycle of the IAM system based on the IAM model category. There are four IAM models: 1) isolated, 2) centralized, 3) federated, and 4) user-centric (e.g., self-sovereign which is a BC-based IAM model) [12].
There are a number of digital identity standards and data protection laws which strive to organize the process of IAM. For example, ISO 27001 is an international standard for maintaining Information Security Management Systems (ISMS) in organizations. It focuses on providing the required framework for the implementation, enhancement, and maintenance of information security management systems. It involves a variety of aspects, such as data asset management, access control, change management, and business continuity. At the same time, ISO9798 focuses more on AuthN techniques in the ISMS [13].
GDPR, is the EU standard that focuses on user data protection regulations for organizations that deal with EU residents' data. GDPR includes eight fundamental rights for the data subject: 1) the right to access data, 2) the right to be forgotten, 3) the right to restrict data processing, 4) the right to be informed, 5) the right to object, 6) the right to data portability, 7) rights related to automated decision-making, and 8) the right to rectification [14].
Recently, BC has been used widely for proposing IAM systems, which are based on two IAM models, Self-Sovereign Identity (SSI) and decentralized trusted identity [15]. According to Taylor et al. [16], in a systematic review conducted on using BC for security purposes, 45 percent of studies focused on IoT applications for AuthN purposes. IAM plays a role in managing data in IoT and cloud-based applications to ensure secure access to data assets. Although there are standards and best practices that need to be followed to develop secure IAM systems, centralization is still a critical issue in cloud-based systems [10]. The concept of IAM is different for IoT-based systems than other systems, because, in IoT, identities are not only users. There are subjects or ''things'' that need to be managed in order to secure access to data. Using different emerging technologies like cloud computing, IoT, and BC in developing information systems causes some IAM systems to be outdated for reasons, such as overheat rate, scalability, and data privacy. As a result, IAM systems are transforming to account for these changes [17].

B. HEALTH IoT APPLICATIONS
E-Health is an umbrella for various systems, such as EHR, PHR, and m-Health applications. It has many definitions in VOLUME 10, 2022 the literature. However, it is agreed that it is an integration of information and communication technologies to improve healthcare services [18]. The term e-Health was coined in 1999-2000 with the beginning of ''the Internet bubble.'' At that time, it covered a few ICT technologies. However, with the revolution of digital technologies, technologies like cloud computing, HIoT, and Big Data can be used and play a significant role in improving e-Health services [1]. E-Health aims to provide digital and smart health services that are economical, secure, and efficient. E-Health positively impacts not only individuals but also nations. It can play an influential role in facilitating receiving health services in developing countries by utilizing HIoT technologies [19].
Although HIoT has revolutionized healthcare services, HIoT comes with drawbacks as they are resource-constrained in memory, performance, and computational power, which increases the complexity, and security concerns of HIoT applications. HIoT architecture characteristics need to be considered in HIoT applications in order to build secure applications [20]. There are four layers in HIoT systems: HIoT device, networking, cloud computing technologies, and application layer. In the HIoT device layer, the HIoT device is connected to the HIoT user. The networking layer is responsible for connecting the sensor data to the cloud layer where data is processed using WiFi or other communication technologies. The application layer is where the data is presented to the health system stakeholders, such as patients and healthcare providers. Health data is transmitted through these layers, and so it is vulnerable to data breaches and security attacks [21]. HIoT system architecture is shown in Figure1. HIoT devices are widely used in the healthcare domain. The taxonomy of HIoT is shown in Figure 2. There are four main types of HIoT: health and well-being sensors, diagnosis sensors, prognostic sensors, and assisting sensors. There are various sub-types of these four branches. These devices are used for different purposes, such as for collecting parameters like blood pressure, heart rate, and blood glucose. Some of these HIoT devices are used in hospitals; patients can use others from their homes [1]. HIoT devices are connected through the Internet to servers where data are stored, analyzed and accessed by healthcare stakeholders based on the privileges given in the IAM system. Although HIoT is similar to IoT in terms of architecture, they are different in terms of characteristics. HIoT differs from generic IoT based on the health environment needs in characteristics like the device power consumption, network bandwidth, device mobility, network protocol used, memory, security, and cryptography technologies [21].

C. BLOCKCHAIN
BC is defined as a distributed digital database shared between a number of network participants based on cryptography and consensus mechanisms and protocols. Characteristics such as decentralization, anonymity, immutability, transparency, and audibility distinguish it from other technologies and paradigms. The first application that was based on BC was Bitcoin, which was initially pioneered when Satoshi Nakamoto published a white paper in 2008 titled ''Bitcoin: A Peer-to-Peer Electronic Cash System.'' The paper described how it would be possible to transfer money from one user to another without a third party using a cryptographic mechanism to fulfil this task. After one year, an open-source software implementing Bitcoin was launched [7].
Although BC is now used outside of financial applications where digital transactions are exchanged, its core technology is very much related to Bitcoin and cryptocurrency concepts. The Bitcoin decentralized payment system is based on a cryptographic proof mechanism instead of relying on trusted third parties. This mechanism uses a public/private key AuthN process for validation. After the transaction is shared with all other nodes in the network and gets validated, it is added to the public ledger. There are two steps to validate such a transaction; first, to ensure the sender owns the cryptocurrency and second, to ensure that the sender has a sufficient balance in their account. In order to avoid duplication in spending cryptocurrencies, there needs to be a mechanism that helps Bitcoin to organize and ensure this process. To solve this issue, Bitcoin made use of the concept of BCs where a group of chains are connected with each other by hashes creating the BC network. Every block has a group of transactions that are meant to be added to the network at the same time. However, there is still a need for a mechanism in charge of organizing the process of mining the blocks in a timely manner. From here, the role of Proof-of-Work (PoW) consensus mechanism starts. PoW is based on a mathematical puzzle where nodes are tested by other nodes to be allowed to add their transactions in the right order in a process called mining [22].
Ethereum BC and Smart Contracts were launched in 2013, paving the way for using BC in non-financial applications. In more recent years, the attention of developers and researchers shifted to propose applications based on BC in different domains. Recently, some big technology companies like Microsoft and IBM have offered BC as a service [23]. There are two main categories of BC: (a) public or permissionless BC and (b) private, or permissioned BC. A hybrid of public and private BCs is the consortium BC. There are a number of BC platforms besides Bitcoin and Ethereum; the Hyperledger Fabric BC is one of the most attractive BC platforms recently used for non-financial applications [24]. On the other hand, there are other distributed-ledger technologies like IOTA, which is similar to BC technology but different in that it is based on the Tangle data structure rather than blocks and uses a different validation process to add new transactions. IOTA is an evolving peer-to-peer network based on consensus protocols, which has potential benefits in IoT applications. However, it is under development and does not support Smart Contract at the moment [25].
BC is a disruptive technology that, for its profound benefits, is widely used in different domains and applications. The trend shows that it attracted researchers' attention after its platforms became available beyond financial and cryptocurrency applications. According to Zou et al. [8], since 2017,  the application of BC in different domains like healthcare and IoT has increased dramatically. In particular, applications of BC in the healthcare domain are increasing significantly because it is stated to be a better choice for managing sensitive data [26]. However, there is still a shortage of studies which address the challenges around BC [27].
According to Wang et al. [28], as the number of BC application studies is rising, the number of attacks on BC-based applications are also increasing, leading to a huge economic loss. These attack incidents are categorized based on the BC layers, (the application layer, smart contract layer, incentive layer, consensus layer, network layer, and data layer).

III. RELATED WORKS
The considerations of IAM and the complexity of BC and HIoT applications stated in the previous sections motivated a number of secondary studies on IAM in general and SSI in particular for IoT applications, e-Health applications, and other domains. These studies cover IAM mechanisms, BC-based IAM opportunities, solutions, issues, and future directions. Some studies focus on a particular aspect of IAM, VOLUME 10, 2022 (i.e., AuthN or AuthZ) for a specific application, like IoT or industrial IoT. Others focus on specific healthcare applications like EHR, as discussed in the following paragraphs.
Indu et al. [10], conducted a comprehensive study on IAM mechanisms and models in cloud environments. In addition, security analyses have been conducted on a number of mainstream IAM attacks, such as a man-in-the-middle attacks, insider attacks, replay attacks, and session/cookie attacks. Cremonezi et al. [17], conducted a survey study on conventional IAM systems covering AuthN, AuthZ operations, and IAM models in IoT environments, where the IoT system architecture and characteristics are considered. Other researchers have conducted studies on the AuthZ part of IAM for IoT. For example, Qiu et al. [29], analyzed the challenges and issues of access control in IoT environments and proposed conceptual and technical guidelines to open the door to developers and researchers for building reliable access control solutions. Ouaddah et al. [4], proposed a framework to evaluate the proposed AuthZ mechanisms for IoT systems. Ravidas et al. [30], analyzed AuthZ issues found by previous surveys and tested the current access control solutions against them. The researchers then proposed a requirement framework and guidelines for building an access control mechanism tailored to chosen IoT applications.
A number of studies have investigated using BC to develop IAM solutions. Kuperberg [31], conducted a survey study on the functional and non-functional requirements for BC-based IAM. The requirements and considerations included data protection laws and BC pitfalls, such as overhead aspects and standards. The study did not focus on specific applications or domains. However, it developed 75 criteria to evaluate qualitative offerings, such as regulatory compliance in the BC-based IAM solutions in general. Liu et al. [32], reviewed the existing BC-based identity management systems, focusing on three: Sovrin, uPort, and ShoCard BC-based IAM systems. They reviewed these three systems and the AuthN, privacy, and trust related works.
Decentralized access control mechanisms for IoT that are based on BC are surveyed by Butun and Osterberg [33]. In this study, varied AuthZ, AuthN, and revocation mechanisms in permissioned and permissionless BC-based systems from proposed solutions were studied. The researchers concluded that there are specific requirements that should be considered when using peer-to-peer networks for access control solutions in IoT applications. They stated that permissioned BC is the best option for IoT security, which should involve specific mechanisms in the main three operations; AuthN, AuthZ, and revocation. The authors also concluded that cost, performance, and scalability are challenges that need to be considered in order to build a reliable BC-based IAM for IoT applications. Zhu and Badr in a similar study [12], explored the IAM system requirements in some proposed solutions using BC with more focus on IAM challenges in IoT applications.
Regarding BC-based IAM systems in the healthcare domain, Houtan et al. [9], conducted a survey study on  [34], compared different BC-based IAM models against the IAM systems' seven laws, which are proposed by Cameron [35]. Based on an e-Health application scenario that involves healthcare regulators, healthcare providers, industry representatives, and healthcare consumers, they proposed a performance evaluation metrics for BC-based IAM. Mamdouh et al. in another study [21], conducted a survey on AuthN mechanisms for HIoT that are based on BC technology and Physical Unclonable Function (PUF) (i.e., a mechanism used for HIoT device AuthN). This study concentrated on security threats in all HIoT system layers. The researchers concluded that as HIoT are different from general IoT systems, and that these differences need to be considered when proposing any AuthN mechanisms. According to these studies, the current proposed applications are in beta or test stages and not ready to be developed in real-life applications. They concluded that there is still a shortage in standardization studies for using BC in HIoT applications for providing BC-based IAM systems. Therefore, our work contributes to this research direction and stands out from other studies in three aspects: 1) focusing on HIoT applications, 2) conducting a systematic review to get a better understanding of the security requirements for BC-based IAM in HIoT and to explore security threats, and 3) covering all proposed solutions concerning AuthN and AuthZ aspects.

IV. RESEARCH METHODOLOGY
This systematic review used a search based on the Preferred Reporting Items for Systemic Reviews and Meta-Analyses (PRISMA) standards across multi-disciplinary databases [36]. As the research is interdisciplinary, the procedures and guidelines for conducting systematic literature reviews in software engineering by Keele [37] and Kitchenham [38] were also used. To ensure that a wide range of literature was analyzed, a backward and forward snowballing approach was used [39]. Performing a systematic literature review involves three main stages: planning, conducting, and reporting, as shown in Figure 3.  consider functional, but not non-functional requirements, for HIoT applications and BC limitations. Security requirements are not usually considered in the solutions. Some of the proposed solutions provide privacy preservation techniques and strive to comply with data regulations like GDPR. This systematic literature review aims to explore all the IAM solutions that are based on BC in HIoT applications in order to investigate the security threats and requirements in BC-based IAM in HIoT, thus providing a unified picture for designing a comprehensive security framework.

B. RESEARCH QUESTIONS
Based on the research aim and using the criteria structure recommended by Kitchenham [38] and Moher et al. [36], shown in Table 1, we defined three main research questions (RQs) as follows: • Q1: What are the methods used to ensure BC-based IAM in HIoT applications?
• Q2: What are the architecture components and required technologies in BC-based IAM systems?
• Q3: What are the architecture of BC-based IAM in HIoT applications, security threats and requirements, and other considerations?

C. DEVELOPING THE RESEARCH PROTOCOL
The research protocol is a main aspect of any systematic literature review. The following processes are planned in the research protocol: (a) research identification, which involves selecting the relevant databases chosen to be surveyed, choosing search strings, and inclusion/exclusion process, (b) selection of relevant studies and (c) quality assessment process.

D. RESEARCH IDENTIFICATION 1) RESEARCH SOURCES
In order to find all studies related to our research questions, there were seven databases chosen to be surveyed, as shown in Table 2. These databases were checked to review all published primary studies on BC-based IAM for HIoT applications between 2016 (when BC started to be used beyond financial applications) and 2021. Databases were chosen based on the research domain, which involves software engineering and health informatics.
After that, keyword synonyms and related terms are defined.
As IAM involves two main concepts, ''authentication'' and ''authorization'', these two keywords were considered as alternative keywords for ''identity'' and ''access,'' so they were added to the keyword list. Also, ''distributed-ledger'' was used as an alternative for ''blockchain.'' The backward and forward snowballing approach was used to find more related keywords to ''blockchain'' keyword and make sure all common alternative keywords are covered. Based on the two highest cited articles in BC-based IAM-related works, by Dunphy and Petitcolas [40], and Jacobovitz [41], it was discovered that the term ''Self-Sovereign Identity'' has been used recently to describe the BC-based IAM solutions, and it was therefore added to the keyword list. According to the above aforementioned definition of e-Health, which covers all ICT-based healthcare systems, and as our review study focuses on HIoT applications, we consider all studies covering IoT in healthcare fall under HIoT applications. Therefore, we checked databases for ''health'' and ''medical'' keywords with ''IoT'' keyword. The keywords and their alternatives used in our search process are as follows: • Blockchain: ''distributed-ledger,'' ''self-sovereign.'' • Identity: ''access,'' ''authentication,'' ''authorization.'' • Health: ''medical.'' • IoT.
As electronic databases allow the use of Boolean operators with keywords and their synonyms to conduct a sophisticated search to find the relevant articles, we used the strings shown in Table 3 with a number of selected databases (note, the structure of using Boolean operators can be different from one database to another). Table 4 shows the inclusion and exclusion criteria used in order to select only the relevant primary studies. All studies in the final list satisfied these criteria.

E. SELECTION OF RELEVANT STUDIES
The steps in Figure 4 depicts the article selection flowchart used in PRISMA standards. These steps were followed to select relevant studies. Initially, every database's relevant studies were added in a group using EndNote software. They were then combined into a library to exclude duplicates.   The number of records identified initially was 1493. The inclusion/exclusion criteria was applied. The first exclusion was based on the duplicate studies and reference types, which resulted in eliminating 341 records. Based on the screening of these studies, 1075 studies were excluded based on reading titles and abstracts. Secondary studies, concept papers, magazine articles, and studies outside the study scope were removed. The final step was to download and read the remaining 77 studies to assess them against the inclusion/exclusion and the quality assessment criteria.

F. QUALITY ASSESSMENT
According to Kitchenham [38], quality assessment is crucial to eliminate bias from chosen studies. The quality assessment criteria in Table 5 were used to make sure that all chosen primary studies addressed the research questions. In order to pass the quality assessment, the quality score for all checklist factors needed to be met with a score of 1.0. If a study did not get a 1.0 quality score in all quality assessment factors, it was then excluded. Uncompleted and theoretical studies, nonevaluated solutions, and studies that did not consider HIoT devices in the system architecture are excluded. Also, studies that did not include an implementation using BC technology were excluded. This process resulted in 24 studies that were included for further analysis and discussion.

V. RESULTS
The final list of included studies is shown in Table 6. Data from these studies were extracted, synthesized, and studied  critically in order to answer the three main research questions, determining research gaps and future direction.
BC technology has gained attention in recent years as a solution to provide decentralization in IAM systems, as shown in Figure 5. The figure shows there was an increase in studies on BC from 2018 to 2021. Data extracted from Table 6, which contains the final list of selected peer-reviewed conference and journal article studies, indicates that research studies about BC-based IAM for HIoT applications increased dramatically in last two years. Data in Table 7 shows the BC-based HIoT application details, including HIoT applications, proposed IAM methods, and BC technology details.
BC-based IAM solutions are proposed in eight different types of HIoT-based e-Health applications, as shown in   covered, the majority of which are medical. Nineteen of the 24 studies (i.e., 79 percent) focused on medical IoT devices, such as physiological biomedical IoT devices that are used for reading vital signs. Two studies did not specify the HIoT device used. One study focused on a fitness wearable, one study focused on m-Health using smart devices, and one focused on implanted medical devices, as shown in Figure 7.
The results show that Ethereum and Hyperledger Fabric are the most used BC technologies. Figure 9 shows that 50 percent of the studies used Ethereum BC as a foundation for solutions, whereas 42 percent used Hyperledger Fabric. Four percent used Ripple BC with Ethereum BC in their solution and Hyperledger Indy was used in 4 percent. IAM systems includes two main operations, however, not all proposed solutions include these two operations together. As shown in Figure 8, 50 percent of the solutions include AuthN and AuthZ operations, 33 percent cover AuthZ only, and 17 percent cover AuthN only. The IAM system should include Identity Management (IdM) operation besides AuthN and AuthZ operations in order to manage identities, which should include a revocation process. Not all solutions have considered IdM operations including the revocation process, as shown in Table 8.

VI. DISCUSSION
BC technologies are used for proposing IAM systems in HIoT. BC should not be used individually to develop an   IAM system. Thus, other technologies are utilized to store IAM systems' data and facilitate exchanging data between BC-based system layers and stakeholders. In this section we address the three main research questions, divided into three subsections.

A. ENSURING THE BC-BASED IAM IN HIoT APPLICATIONS
Solutions in the selected and reviewed studies can be divided into two categories: (1) IAM-focused studies in HIoT applications; (2) BC-based HIoT applications, which involve BC-based IAM systems. Both categories cover BC-based IAM systems for HIoT applications, however, the former is more focused on IAM aspects (AuthN and AuthZ), while the latter focuses on the BC-based proposed system and the IAM system is a part of the solution. Table 7 shows that studies in [42]- [48], focus on BC-based IAM for MIoT devices, while other studies [49]- [65], include IAM in BC-based solutions for different HIoT applications. Studies in, [47], VOLUME 10, 2022 [48], [63], [64], proposed AuthN solutions, while studies in [42], [43], [50], [54], [55], [58], [59], [65] proposed AuthZ solutions. The rest of the studies [44]- [46], [49], [51]- [53], [56], [57], [60]- [62] covered both AuthN and AuthZ solutions. A complete IAM system should involve AuthN and AuthZ operations, as well as covering the identity management (IdM) for the whole life-cycle of identities, from registration to deleting identity data when it is no longer belongs to a system. As shown in Table 8 there are sixteen studies among the reviewed studies that included IdM in the IAM system. Although, they covered registration and verification processes, only two studies [57], [60] covered the revocation process. The lack of the revocation process causes functional and security issues.

B. ARCHITECTURE COMPONENTS AND REQUIRED TECHNOLOGIES IN BC-BASED IAM SYSTEMS
There are specific BC platforms used to implement the BC-based IAM systems in the HIoT applications. Ethereum and Hyperledger Fabric BC technologies are the most used solutions. The main reasons why these BC technologies were chosen are for the decentralization advantage. There are other advantages, such as immutability, transparency, and audibility, additionally, Smart Contracts, which are crucial for BC-based IAM systems. The permissioned access policy feature in the Hyperledger Fabric BC distinguishes it from Ethereum, which makes it more suitable for health information systems. BC-based IAM systems commonly consist of a number of technical components [66]. Table 9 shows an analysis of the main components and technologies proposed by the reviewed studies, which are summarized as follows: • Blockchain: based on the reviewed studies, there are two different types of BC used for proposing IAM solutions: (1) Identity management BC, such as Indy Hyperledger, which was used in [45]. This type of BC is dedicated for IAM solutions; (2) Smart Contract-supported BC technologies, such as Hyperledger Fabric and Ethereum BC, which are the most used by the reviewed studies as shown in Table 9.
• Off-chain Protocol: as BC should not be used as a storage because of storage limitations and high-processing costs, offloading solutions proposed to allow scalability in the IAM system. InterPlanetary File System (IPFS) was the most used off-chain storage technology in the IAM solutions proposed in the reviewed studies. Nine out of 24 studies used IPFS system as an Off-chain protocol. Some studies used other Off-chain technologies such as CouchDB and Software Guard Extensions (SGX) as shown in Table 9.
• Smart Contracts: as shown in Table 9 SCs are used by all proposed IAM solutions mainly to build the IAM access control logic, which is applied using the BC technology.
• Identity Wallet and Database: applications and database technologies used in the BC-based IAM to allow users to manage identifiers and store identity credentials (i.e., key values) included in the BC. For example, in Hyperledger Fabric, LevelDB is used as an embedded database and CouchDB is used as an external database to store identity key values. Table 9 shows CouchDB technology used mostly in the solutions. There are other technologies were used for this purpose such as OrbitDB, mobile applications, Indy Plenum Repository.
• User Profile Management Methods: external protocols allow storing data in encrypted Off-chain storage that manage user profile data, such as settings and transaction history. For example, OrbitDB technology was used by [49] for this purpose.
• Data Exchange Methods: an identity's credentials are mostly exchanged between the technologies (e.g., BC, IPFS, and CouchDB) using data interchange format and model, such as JSON. JSON model technology was mostly used in solutions for exchanging data between the AIM system layers and components. VOLUME 10, 2022 • Applications and Libraries: applications are used to allow users to use the IAM systems to manage their data and credentials. Libraries and Application Programming Interfaces (APIs) are used to allow integration between applications and facilitate exchanging data between the IAM roles, such as requester, issuer, verifier, and Aforementioned components are essential to have a functional IAM system [66]. It is clear from Table 9 that Hyperledger Fabric-based IAM solutions reasonably include more components than Ethereum-based solutions. This gives credibility to Hyperledger Fabric BC in terms of the system orchestration.

C. BC-BASED IAM IN HIoT ARCHITECTURE, SECURITY AND OTHER CONSIDERATIONS
Studies are reviewed to identify the main architecture layers of BC-based IAM in HIoT applications. Table 10 shows the architecture layers proposed by the reviewed studies. The User, Application, BC, Off-chain, Connectivity, and HIoT layers are the main layers in order to develop a functional system. The inclusion of these layers in the solutions was varied and the names were used differently. However, The concluded layered architecture of BC-based IAM in HIoT applications which fulfills the functional goals of the system is shown and explained in Figure 10.
There are a number of security threats in permissioned (e.g., Hyperledger Fabric) and permissionless (e.g.,Ethereum) BC-based applications [67]- [69], whereas there are security threats in IAM systems in HIoT applications [21]. A combination of the aforementioned security threats is shown in Table 11. Reviewed studies are analyzed to summarize the security threats in the BC-based IAM in HIoT applications. The main security threats are classified by the layered architecture of BC-based IAM in HIoT applications as shown in Figure 10. The layered architecture and related security threats are summarized as follow: • User Layer: this layer represents the stakeholders in the system who play functional roles, such as HIoT users, data consumers and system administrators. The identity VOLUME 10, 2022  management governance model is at the core of any IAM system. As shown in Table 8, all solutions are based on trusted authority models in the proposed systems. Trusted authority model might lead to insider threat when these trusted identities misbehave and breach the rules.
• Application Layer: this layer includes user interfaces, remote monitoring systems, wallets, and APIs work on a Blockchain network. Reviewed studies provided BC-based IAM solutions and as the focus was on harnessing BC for this purpose, not all security threats are considered. Security threats in the application layer were not focused on in these studies, however, according to [69] and as summarized in Table 11, there are some attacks which target the application layer. Additionally, misconfiguration of technologies such as APIs and wallets that include metadata related to identities in the BC-based systems could lead to privacy breaches [66].
• Blockchain Layer: this layer is at the core of the IAM system. The BC layer components such as consensus mechanisms play a vital role in BC technology. Identity management systems rely on these mechanisms in order to manage identities' data. Thus, selecting the strongest and most secure consensus mechanisms protect identities' data security. Otherwise, they might be a source of security threats and vulnerabilities exploited by hackers by adding malicious transactions in the BC network. Studies such as [50] and [61], used alternate consensus mechanisms such as Solo and Kafka, which might impact the core of the system security when are exploited by hackers. BC layer can be targeted by some of attacks such as spoof attacks, sybil, substitution, Denial of Service (DoS), replay, and impersonation attacks [42].Thus, the use of countermeasures is vital to protect HIoT users' identity data. For example, in [61], the endorsement, sorting, and verification mechanism was used to prevent replay attacks in order to secure identity data. Moreover, attacks that are based on powerful processing computing, like Quantum, is another vital concern for all cryptography-based systems. Quantum has a promising futuristic application, which can be used by hackers to break encryption and cryptography-based systems easily [42]. As BC technologies are mainly based on cryptography, this aspect needs to be considered as a threat and countermeasure solutions need to be taken into account for this long term concern. The Smart Contract is another essential key player in any BC-based IAM system. Smart Contracts format the rules and policies of access control that are used in AuthN, and, if not programmed securely, might breach confidentiality. Smart Contracts have limited storage capability and should not be used beyond it. They are vulnerable to reentrancy attacks [53]. Evaluation tools and formal methods techniques can help to reduce the risk that might form vulnerable Smart Contracts. Moreover, • Off-chain Layer: this layer is a complementary layer used to enhance the functionality of the BC-based system. Off-chain technologies are used to offload data from the BC network and to allow exchanging identity data between stakeholders and applications. Identity's data history and metadata are also stored Off-chain. Identity data should be stored securely to ensure integrity and privacy. In general, off-chain storage are less privacy-preserving than on-chain storage [66], thus security risks caused by using them need to be carefully studied. IPFS which relies on a distributed hash table was used widely in the solutions as an off-chain for storing data. Off-chain storage such as IPFS can cause security and privacy threats when it is misconfigured [70]. Similarly, privacy and security of other off-chain storage such as CouchDB which was used in [56], need to be considered in the BC-based IAM system.
• Connectivity Layer: the connectivity layer involves HIoT technologies, communications, and gateways used between layers in the system, such as cloud, fog, edge, Hypertext Transfer Protocol (HTTP), MQ Telemetry Transport (MQTT), and Constrained Application Protocol (CoAP). HIoT ecosystem is vulnerable to some attacks, such as Distributed Denial of Service (DDoS), Man-In-The-Meddle (MITM) attack [48], and it lacks standardized communication protocols [42].
• HIoT device Layer: this layer represents the HIoT device used in the system. HIoT devices as shown in Figure 2 are available in a wide range of forms. Medical IoT as shown in Figure 7 are the most HIoT devices used in the reviewed studies. AuthN of MIoT identities and ensuring HIoT ownership are crucial aspects in HIoT applications, as the number of counterfeited MIoT devices is rising. To tackle the counterfeiting of HIoT, HIoT AuthN and ownership issues, studies in [47], [48], and [65] covered the Medical IoT ownership issue and proposed proof-of-ownership solutions using Smart Contracts and Physical Unclonable Function (PUF) based AuthN mechanisms to tackle this security issue. Moreover, HIoT device layer is venerable to physical acces-sibility issues [42].
A number of non-functional requirements and considerations are discussed in the proposed solutions, such as confidentiality, integrity, availability, scalability, privacy, interoperability, trust, auditability, tracebility, unforgeability, relaibility, usability, service quality, and accountability as shown in Table8. Some of these considerations and requirements are related to IAM security, such as confidentiality, integrity, availability, privacy, unforgeability, and accountability. There are different concepts used to improve the quality of service, such as processing time, energy consumption, and memory usage in the IAM systems. For example, in [53], an offloading scheme was used to improve latency and decrease energy consumption. It is worth noting here that using solutions like this, which add additional layers in the system, open other security considerations in these new layers. Moreover, although, studies like [53], [62], [64], provided a distributed system between a number of hospitals and organizations for interoperability, it should be considered that they should use recommended interoperability standards like HL7/FHIR. HL7/FHIR standards recommend an understandable unified format for medical data to be exchanged, thus ensuring data availability.
Applying BC in HIoT is a complicated task. HIoT are resource-constrained devices that have specific standards and security requirements to work without faults and security breaches, so these aspects need to be carefully considered [53]. HIoT are prone to limitations like storage constraints, heterogeneity, privacy and security vulnerabilities, network complexity, and poor interoperability. BC also has limitations and security vulnerabilities [71]. Thus, data protection regulations like GDPR, health-related data protection standards like the US Health Insurance Portability and Accountability Act (HIPAA), and HIoT security requirements and threats [21], should be considered in the BC-based IAM HIoT applications. The proposed solutions strove to overcome and tackle some of these challenges. Although, the majority of studies did not consider the HIoT constraints, a number of studies built BC-based IAM systems with considerations to HIoT constraints. They mainly proposed additional hub layers between the BC layer and the HIoT layer to tackle the IAM operations. In [50] IEEE 802.15.6 WBAN security standards were used and the computation resource constrained issue was considered in HIoT by using multiple system layers. Researchers in [42] discussed the security challenges related to HIoT such as HIoT device heterogeneity, accessibility, lack of standardized communication protocols, and the vulnerability to attacks such as DDoS and data manipulations. Researchers in [43] discussed HIoT protocols, namely, MQTT and the need to lightweight AuthN solutions for the resource constrained reasons and proposed BC-based solution considering this issue. Also, [56] separated the HIoT device from the BC system considering the computation and security resource constrained in the HIoT device. In [48] PUF AuthN mechanism used to tackle the computation limitation of HIoT devices. While in [65] BC-based IAM system was proposed with a consideration to the security and the limited computation resource capability in the HIoT device. Moreover, although not all studies consider HIoT identities, studies in [42], [44], [46]- [49], [51], [52], [57], [62], and [65], consider HIoT identities in the AuthN operation which is essential for HIoT device security, as shown in Table 8.
Although the majority of the studies considered the privacy aspect, data protection regulations like GDPR and HIPAA are barely considered in the the solutions. Security and privacy requirements should be based on standards and regulations. The minimum privacy that can be provided is to develop a concrete access management system. Patients should control access to their medical data, but should not be able to edit them. When accessing data, privacy of data should be preserved, which includes personal information like name, address, phone number. Privacy techniques should preserve and not sacrifice data integrity. Additionally, HIoT user privacy should be preserved while sharing, uploading and auditing data. Examples of privacy preserving mechanisms that can be proposed for preserving medical data privacy are deferential privacy and K-anonymity [72]. Access control can preserve privacy to some extent. However, studies in [61], [63], and [47], proceeded to comply with HIPAA and GDPR regulations by proposing additional privacy mechanisms, i.e., pseudo-identity, zero-knowledge-based anonymity, and pseudo-identity mechanisms, respectively.
Another critical consideration that impacts the security and functionality of BC-based IAM systems is the consensus mechanism used in the BC. The consensus mechanism in Ethereum BC is PoW, which is based on a mining mechanism used in order to add new blocks to the chain. On the other hand, the consensus mechanism used in Hyperledger Fabric is Practical Byzantine Fault Tolerance (PBFT). In PBFT, an agreement is made between the participants in the network based on a specific number of bad nodes that can be tolerated. There are two main disadvantages to mechanisms like PoW that are based on cryptocurrency. First, they require mining, which takes considerable time to process new data and this does not satisfy the fast transmission that HIoT applications need. Second, they are based on the cryptocurrency concept, which might be costly in high-volume data systems like HIoT applications. On the other hand, a study conducted by Nguyen et al. [74], demonstrated that using PBFT can cause a delay in transmitting data in critical infrastructure systems. To eliminate these pitfalls, some developers use alternate consensus mechanisms [50], [61], which can allow malicious transactions to be mined in the BC network. This aspect should be considered when developing IAM BC-based solutions for HIoT.
Smart Contracts, which are programmable rules and polices used to provide AuthZ and access control in IAM systems, were used in all reviewed studies as shown in Table 8. Smart Contracts are used to implement the logic of the access control, which is then guaranteed by the BC technology. There are different programming languages used to program Smart Contracts, such as Solidity in Ethereum and Go and JavaScript in Hyperledger Fabric. According to Wang et al. [28], some of Smart Contracts programs are vulnerable to security attacks for bugs in the programs. Thus, choosing the best programming language and using evaluation tools to check Smart Contracts before using them in the BC are paramount.
The main advantage in using BC is the ability to eliminate the dependency on a single trusted third party. Although BC can provide two identity management models, SSI and decentralized trusted identity, the results show that all studies that proposed identity management adopted the decentralized trusted identity model as shown in Table 8.
Although a number of studies showed encouraging results based on the performance evaluations conducted in the studies, it is noticed that there are two critical points in the evaluation process: 1) the proposed solutions were mostly compared with other solutions based on other BC solutions. It is true that this might give an indication of the performance evaluation of the application, however, this does not mean the solution satisfies the IAM for HIoT security requirements, as these requirements are not considered fully in the first place in these BC applications, 2) there are no agreed metrics to evaluate the solution performance. Table8 shows a comparative analysis showing the functional performance, security requirements, and other considerations in the reviewed studies. The throughput and latency proprieties are used in the studies to evaluate the solution performance, however, the evaluation factors and units (e.g., Query, Read, Adding, Invoke, ms, and s) are different from study to study and from BC platform to another platform (e.g., Hyperledger Fabric and Ethereum). Moreover, the security aspect was not evaluated by the majority of studies. Hyperledger fabric-based solutions seemed more evaluated systematically than Ethereum-based studies as they use Hyperledger Caliper as a benchmark tool to measure the application performance. However, both lack a systematic security-based evaluation.

D. ADDITIONAL POINT
Brogan et al. [25] and Zheng et al. [75], proposed IAM solutions based on IOTA Distributed Ledger Technology (DLT) for HIoT applications, which is different than BC technology. IOTA is another kind of DLT. It has a different data structure. IOTA has potential as a decentralized technology for IAM solutions, however, it is in early stages. It is a worthwhile topic to be studied and considered as a solution for IAM in HIoT, particularly, as it is suitable for IoT-based systems.

VII. LIMITATIONS AND FUTURE DIRECTION
Although this literature review study followed a systematic approach to ensure accuracy and eliminate bias, there are some limitations worth noting: 1) this study focused on studies written in the English language between 2016 and 2021, 2) the functional performance of the solutions was not investigated in detail as our study focused on the security aspect, however, it was covered to gain insights about the evaluation metrics used, 3) this study focused on BC applications, other DLT applications like IOTA are out of the study scope, and 4) according to other review studies that cover different parts of the BC-IAM in HIoT, security requirements and threats which are identified do not cover all security requirements and threats in BC-Based IAM in HIoT.
As noted in our study, a unified security framework for BC-based IAM solutions for HIoT applications is required. Moreover, there is a lack of security risk assessments for BC-based IAM systems in HIoT applications. BC-based IAM solutions for HIoT need to be evaluated based on ISMS standards like ISO 27001, and to comply with data protection regulations like GDPR and HIPAA. Future work will address the development of a comprehensive security framework for BC-based IAM systems in HIoT applications.

VIII. CONCLUSION
BC-based IAM solutions for HIoT applications were evaluated in this systematic literature review. A total of 24 peerreviewed studies were investigated to explore the security aspect of the BC-based IAM solutions in HIoT applications to examine the security requirements and threats related to BC-based IAM systems in HIoT. Security, functional, and non-functional aspects of BC-based IAM were discussed, main architecture components and technologies, and the architecture of BC-based IAM systems in HIoT and related security threats were summarized. We outlined that there are some security and functional considerations that need to be considered in the chosen BC solution before implementation. In addition, the functional and security evaluation aspects of BC-based IAM systems require further investigation.