## 4 HMBAC Design and Implementation
### HMBAC Access Model  
At a high level, the goal of HMBAC is to allow users belonging to different stakeholders (authorities) from different domains to have controlled access to data owned by multiple stakeholders. Moreover, the model must support interoperable use of credentials issued by different authorities, while the inter- and cross-domain policy management must be controlled at a domain level.  
Hierarchical multiblockchains (Section 3.2) play a central role in the HMBAC model. The Proxy Blockchain layer answers the first goal by allowing the interoperable use and verification of credentials issued and managed independently by different authorities and domains. Then, the various Domain Blockchains answer the second goal by allowing authorities belonging in different domains to define inter- and cross-domain policies for their data and to manage the authority membership in their domain, without affecting other domains.  
Following the approach of [54], we define the HMBAC mo-del by representing the logical relations among the access control components, as shown in Figure 3. A user (U) belonging to one or more authorities (Au) (for example, a hospital) is assigned attributes from a pool of attributes (UA). One or more authorities may issue attributes to users, which is depicted as the attribute authority (AA) relation in Figure 3. Each authority is associated with a single domain (D) and each domain contains multiple Au. A key element in the HMBAC model is the hierarchical multi-blockchain presented in Section 3.2. All domains, and thus all authorities, constitute the proxy blockchain (PBc), i.e., these are the stakeholders for the first layer of the multi-blockchain. Then, at the second layer, various domain blockchains (DBc) may be constructed. Each group of authorities with similar characteristics  
Figure 2: Hierarchical Multi Blockchain architecture [9].  
form a different Dbc (e.g., one Dbc is constructed by the hospital stakeholders, while another Dbc is constructed by the manufacturers). Objects (OB), representing data or services accessible by users and operated by subjects (S), are encrypted with attribute keys (AK) created by the UA pool. With the terms user attribute authorities (UAA) and subject attributes (SA), we represent the logical connection between users and subjects with the UA pool.  
For a user to gain access to encrypted data, three checkpoints must be met. First, an _attribute verification function_ (AVF) executed on the PBc will verify the validity of the user attributes. Then, the _authorization function_ (AF), placed on the Dbc, will verify whether the presented user's attributes are sufficient, based on the relevant inter-domain (IDP) and cross-domain (CDP) policies, to authorize the access request. Finally, the _decryption function_ (DF) also executed in the relevant Dbc of the data owner, will partially decrypt the data, which will be fully decrypted by the user, with the proper user attribute keys.  
Table 2, summarizes the basic sets and functions of the proposed HMBAC model, as well as a formal analysis of the three functions specified for data access and decryption. Users, objects, and keys can be assigned attribute values directly from an attribute function _att_ from a set of values in the range, denoted \(Range(att_{u})\), \(Range(att_{OB})\), \(Range(att_{K})\), respectively. Users are assigned to multiple authorities (defined by many to many functions \(direct_{UAu}\)) and also authorities are assigned to one domain (defined by one to many functions \(direct_{DAu}\)).