A Blockchain-Based Consent Mechanism for Access to Fitness Data in the Healthcare Context

Wearable fitness devices are widely used to track an individual's health and physical activities to improve the quality of health services. These devices sense a considerable amount of sensitive data processed by a centralized third party. While many researchers have thoroughly evaluated privacy issues surrounding wearable fitness trackers, no study has addressed privacy issues in trackers by giving control of the data to the user. Blockchain is an emerging technology with outstanding advantages in resolving consent management privacy concerns. As there are no fully transparent, legally compliant solutions for sharing personal fitness data, this study introduces an architecture for a human-centric, legally compliant, decentralized and dynamic consent system based on blockchain and smart contracts. Algorithms and sequence diagrams of the proposed system's activities show consent-related data flow among various agents, which are used later to prove the system's trustworthiness by formalizing the security requirements. The security properties of the proposed system were evaluated using the formal security modeling framework SeMF, which demonstrates the feasibility of the solution at an abstract level based on formal language theory. As a result, we have empirically proven that blockchain technology is suitable for mitigating the privacy issues of fitness providers by recording individuals' consent using blockchain and smart contracts.


I. INTRODUCTION
Due to the recent growth in the use of wearable fitness devices, such as smartwatches, individuals are now exposed to vast quantities of their own sensitive health data [l]. These wearables track a variety of data, including health and physical activities such as sleep, steps, and blood pressure [2]. Although individuals, clinicians and clinical researchers benefit from adopting these technologies for accurate diagnosis, some privacy challenges have emerged [3], [4]. The European Union's (EU's) General Data Protection Regulation (GDPR) [5], which came into effect in May 20 18 [5], enforces data protection regulations on data processors, giving subjects more control over their fitness data by mandating that they provide consent. The GDPR's [5] consent standards place a substantial burden on fitness providers to comply in an The associate editor coordinating the review of this manuscript and approving it for publication was Pedro R. M. InacioG>. attempt to address the privacy concerns raised by experts [l], [6]- [13].
Consequently, several solutions that preserve privacy [14]- [16] have been offered, but they either rely on a single trusted authority or are not transparent to users, e.g., offering only one-time consent without the right to withdraw. Users expect these devices to protect their data and respect their privacy [ 17] . These challenges in the current wearable fitness device privacy policy urge us to further elevate the privacy level of fitness data sharing based on the user's consent. Hence, our solution brings together advances from the fields of consent management, legal frameworks, and advanced fitness data-sharing control by maintaining consent in an immutable legal archive.
This study addresses privacy issues in fitness providers' privacy policies by recording all data subjects' consent in immutable storage and giving the user more transparency about the parties with whom their data have been shared. The main goal of this research is to build a secure system model VOLUME IO, 2022 This work is licensed under a Cteatille Commons Anribution 4.0 License. For more infonnation, see hnps:{/aeatillecommons.org/licenses/by/ 4.0/ that improves data subjects' control over the processing and collocating of their data while simultaneously enabling data controllers and processors to comply with GDPR obligations. Although we can repose of the ultimate trust in a single central control system, there are associated risks of doing so. Therefore, the built-in features of blockchain make it a suitable candidate for addressing identified problems. Hence, these two contributions are based on the blockchain, which acts as a dynamic consent mechanism. The proposed approach leverages smart contracts for all automated processes, such as managing users' consent by granting or denying requests for access to their fitness data and utilizing smart contracts to detect any misbehavior by fitness providers. The following is a list of the benefits of moving fitness provider consent management to a blockchain platform: • Transparency: All consent processes are visible to all parties, including the user.
• To improve security, blockchain can ensure that all consent-related transactions are authentic and originate from an indented agent (authenticity), have not been tampered with (integrity), consent transactions are handled in a nonrepudiable manner (proof of authenticity), and can control joint parties by choosing a permissioned network (authorization).
• Scalability utilizing blockchain can provide a scalable service to a growing number of users and nodes, including consent requests and response actions generated by different agents.
• Records' immutability can help audit records and minimize dispute cases by tracing the history of records organized in a specific sequence with timestamps. It serves as a piece of ordered evidence.
• Consent and processing/collecting fitness data validity checks are predefined in a logical manner in the form of a smart contract.
This study aims to make two contributions to the preservation of privacy among fitness tracker providers. The key contributions of this study are as follows.
1) The design and description of all aspects of the proposed framework for dynamic consent, including system design and architecture, and all potential system action sequence diagrams, show the consent-related data flow and algorithms to demonstrate how decisions are created and executed.
2) The validation of the proposed framework's security properties, including a formal abstract description of the required properties of blockchain and smart contracts, authentication, and proof of authentication, using a rigorous formal representation through the formal security modeling framework SeMF proposed by [18].
Together, these two contributions aim to address privacy issues in fitness providers' privacy policies by providing a comprehensive framework and validating the proposed system using SeMF [18].
The remainder of this paper is organized as follows. In Section II, we briefly present related work and identify the gaps related to preserving the privacy of fitness data followed by the proposed system's objectives. Section III presents the methodology used in this study. Section IV provides a refined and formal description of the system's requirements. Section V explores potential security concerns that motivate our proposed system framework and then Section VI describes the proposed system framework, including the system design and architecture, action sequence diagrams, and algorithms that demonstrate user decisions. Section VII presents our assumptions regarding the built-in security properties of blockchain. Section VIII formalizes and validates the security requirements. Finally, Section IX concludes the study with a brief discussion.

II. RELATED WORK
The preservation of individual privacy by fitness tracker providers has been a subject of interest for many researchers. Some researchers have highlighted privacy concerns resulting from the use of fitness apps. Sunyaev et al.'s [13], Mulder's [10], and Hutton et al.'s [1] linguistic assessments have revealed a gap between users' understanding of consent and subsequent data usage by service providers. Their findings suggest the need to adopt a more transparent human-centric system that clearly communicates the purpose of requesting data. Several studies that have focused on privacy risk analysis of health and fitness app behavior suggest that fitness apps involuntarily share user data with other entities [6]- [9], [11]. Their privacy risk and behavior analysis revealed that the involuntary sharing of data is due to unclear one-time consent and the absence of withdrawal rights.
Although some fitness applications such as Fitbit [15], Apple Watch [14] and Strava [16] have moved from traditional one-time consent to more flexible user consent management, privacy concerns associated with their consent practices remain. These three Fitness applications uses a traditional data management systems that rely only on policies in their solutions to comply with data protection regulations. Hence, the current fitness applications do not technically enforce a transparency system. In addition, these applications contain no interface for informing users about third-party data access and sharing. Therefore, our proposed system uses built-in blockchain properties that technically enforce transparency in fitness applications. The aforementioned literature, which includes linguistic, behavioral, and heuristic assessments, shows serious privacy concerns associated with the use of fitness apps. Researchers have identified several problems related to preserving the privacy of fitness data, including lack of system transparency, lack of privacy policy legibility, concerns with one-time consent, and noncompliance issues with new consent management. Although these studies thoroughly analyzed the privacy issues of fitness apps, none were found to have addressed concerns in terms of dynamic consent management that uses a transparent and legally compliant system.
Since privacy is a critical component for safeguarding an individual's data, it imposes a considerable burden on service providers [19]. For instance, in the case of data sharing, data controllers and processors must adhere to appropriate standards, such as GDPR or Australian Privacy Principles (APPs) [5], [20], which require individual consent before collecting, processing, or sharing personal data. In contrast to the GDPR [5] and APP [20], which protect all forms of personal information, the Health Insurance Portability and Accountability Act (HIPAA) [21] has a limited scope. For example, fitness applications are not obliged to comply with HIPAA because they are classified as ''noncovered entities''. However, they may be required to do so once they engage with ''covered entities'' such as insurance companies and healthcare professionals [21]. While legislators enact stricter data protection laws, individuals are often overwhelmed by lengthy, complex consent forms in which they may unwittingly accept the secondary usage of their data out of bewilderment. Furthermore, individuals have no transparency in knowing if the consent terms and conditions are adhered to by service providers [21]. Thus, there needs to be a solution that provides users more control over the use of their personal data by obtaining their consent while likewise maintaining the trust of different domains and preventing unlawful secondary use (also known as ''data double-spending'') [22]. Given the rapidly changing privacy rules adopted to give individuals more control over their data, consent management can be seen as the first step for preserving privacy in any system [23].
A blockchain is a ledger with distributed ownership that has a collection of transactions included in blocks [24]. In a blockchain, the same ledger is copied and synced among peers through a consensus mechanism [25]. The blockchain holds only accepted and validated transactions encapsulated in a block [24]. Each block in the blockchain is built on top of the previous block, such that a sequence of blocks with a timestamp is created [25]. It is equipped with cryptographic techniques and is tamper-resistant, append-only, and immutable. The greater the number of confirmations the block has, the harder it becomes to change [22].
Blockchain and related technologies, such as smart contracts, have the potential to gain the trust of different domains through a predefined and automated program to satisfy common contractual conditions [24], [26]. A smart contract guarantees that it is executed immediately once a condition is met. Smart contracts employ ''if/when. . .then. . . '' rules that govern transactions beyond the control of centralized authorities. Because smart contracts operate on a blockchain, they have many valuable features, such as managing smart assets, executing as written, avoiding central entities, and reducing human interference [26], [27].
The emergence of blockchain technology has prompted the rethinking of traditional solutions that depend on trust [28]. Its unique properties, particularly immutability and decentralized authority, have attracted considerable research attention [23]. Since the initiation of Bitcoin for cryptocurrency in 2008 [29], the possibility of using blockchain in nonfinancial applications has been proposed. The use of blockchain outside of finance has been investigated in a range of contexts, such as supply chains [30]- [33] and health care and consent management [17], [34]- [38].
Many studies in various domains have empirically proven that blockchain technology can mitigate privacy preservation issues by managing consent [17], [38]- [43]. Some of these consent scheme solutions leverage smart contracts to manage individual consent. For example, the work outlined in [17] involves the use of a consortium blockchain platform in the IoT ecosystem to manage users' personal data by obtaining their consent. Another solution proposed by the Orange Consent Management Service records consent in the blockchain through a consent management server, which has been demonstrated in the Hyperledger beta version [41]. A related work proposed by Dovetail leverages a blockchain to allow patients to consent to the sharing of their electronic medical records (EMRs) with other entities through a mobile application [44]. Dovetail's blockchain stores consent along with reference to the transferred data. Similarly, an EMR management solution named Ancile, proposed by [40], utilizes smart contracts to secure access to patients' EMRs through access permissions based on HIPAA. A blockchain and smart contract-based solution introduced by [38] proposed a novel privacy-preserving dynamic consent management for EMRs secondary use, in which they used Fast Healthcare Interoperability Resources' (FHIR) consent resource in their proposed design to avoid integration failures with EMRs.
Beyond the healthcare domain, blockchain for consent management solutions has been used in other research domains. For instance, Gilda and Mehrotra [42] proposed a blockchain solution that leverages smart contracts to guarantee consent privacy and access control by establishing a nested authorization process using Hyperledger Fabric and Hyperledger Composer. Another solution introduced by [39] uses a blockchain to record user consent and enable anonymous data sharing.
To that end, utilizing a blockchain-based solution in a consent management system has great potential and offers outstanding features, such as transparency, security, immutability, and auditability [45]. Therefore, in light of the potential of blockchain and in response to privacy issues in fitness apps, this study proposes a blockchain dynamic consent mechanism that uses a smart contract to preserve privacy in accessing fitness data, especially with regard to the management of consent.

III. RESEARCH METHODOLOGY
This section covers the research methodology and motivates the selection of the methods used throughout the research. The primary goal of this research is to improve user control over the processing of their fitness data and foster transparent data processing to achieve both privacy and compliance. This improvement is achieved by designing and describing the high-level proposed framework for dynamic consent and validating the framework's security properties, which include a formal abstract description of the required properties of blockchain and smart contracts. We employed the design science research (DSR) paradigm proposed by Peffers et al. [46] to design and evaluate our framework for dynamic consent. The goal of DSR is utility, which implies that rather than researching an already existing artifact, it involves the discovery of a highly relevant problem through an iterative process of developing and assessing solution objects. This research makes use of the DSR approach to solve the issue of fitness providers' privacy because no existing solution has met all of our requirements; therefore, it involves an innovative discovery of system artifacts and evaluates them in formal abstract description using SeMF [18]. Hevner et al. [47] and Peffers et al. [46] emphasized the importance of the evaluation phase as a "crucial" component of a DSR contribution; therefore, we use SeMF, which serves as a tool for showing the trustworthiness of our proposed design model by providing an exact specification of the proposed architecture and properties and validating the architecture.
The DSR can be divided into four phases: literature review, solution design, demonstration, and evaluation, as depicted in Fig. l . Each phase consists of a different DSR paradigm activity. Below, we describe each phase and its activities.
(l) LITERATURE REVIEW PHASE: In this phase, we identify the relevant problem and motivation (as explained in Section II) and define our objectives. Below are the objectives that drove our research effort: 4 a) The system must closely follow GDPR valid consent criteria. b) Our proposed artifacts should not be allowed to overwhelm the capabilities of a typical fitness tracker's functionality. c) Auditing all system actions is crucial to achieving transparency and GDPR compliance requirements.
d) In addition, there were functions and features necessary to meet transparency, including an automated self-report data access check, making data available check, and an automated switch from valid to invalid consent based upon user decisions. e) The proposed design for storing and exchanging user consent data between different agents must be scalable. f) A security solution is one of the main requirements implemented in system design to provide secure and reliable communication.
(2) DESIGN AND DEVELOPMENT PHASE: This phase involves the use of objectives from the literature review phase to define the required design artifacts, which involves an iterative process between the created IT artifacts and the defined objectives. The artifacts in the proposed system are as follows: (l) system architecture (Section VI-A), (2) requirements specification (Section IV) and (3) formal model and proof (Section IV).
(3) DEMONSTRATION PHASE: This phase aims to demonstrate the utility of the design artifacts in solving our identified problems and then obtain preliminary results (as explained in detail in Section VI. This phase involves the implementation of (l) sequence diagrams, (2) detailed descriptions of activities, and (3) algorithms.
(4) EVALUATION PHASE: We evaluated how well the demonstrated artifacts supported our identified problem. This phase involves comparing the results from the demonstrated artifacts with the defined objectives. The evaluation is based on using SeMF and proof (as explained in detail in Section Vill). This process iterates back to refine the designed artifact and improve its effectiveness.

IV. REQUIREMENTS SPECIFICATION
As a subsequent iterative step of the DSR paradigm [46], this section provides a refined and formal description of the system's requirements from the problems and objectives identified in Section II, which is used in Section Vill for formal validation. Therefore, it is important to understand the VOLUME 10, 2022 requirements of the proposed system. The proposed solution requirements and the choices made provide the rationale for the model and mechanism properties of our proposed system, which are discussed in detail in Sections VI-A and VI-B.
The notations used throughout this study are listed in Table 1. This section discusses each of these requirements as follows: R1: level of transparency, R2: security requirements, R3: scalability, R4: auditability, R5: preservation of the original functionality of the fitness tracker, and R6: GDPR compliance.

A. R1: TRANSPARENCY
Transparency can be defined as a way of completing an agent's activities openly without any hidden activities such that users can see their data flow and trust that the agent is fair and honest. In any system, transparency is crucial to achieve both privacy and compliance. To enhance users' trust regarding the protection of their privacy, the GDPR [5] and APPs [20] ensure transparency in data processing practices. Three fundamental pillars of transparent systems can be defined: transparency, privacy, and compliance. Users must be provided transparency regarding what happens after they consent to the processing or collection of their data. To address this requirement, the proposed system ensures that all three fundamental pillars of a transparent system are considered when fitness providers share data-processing logs with users who have consented to the process.

B. R2: SECURITY
Security is an important part of the proposed system requirements and comprises a set of security properties that ensure the trustworthiness of our proposed system. This section presents the basic concepts of properties relevant to this study. Table 2 lists the security requirements of the proposed system. In Section VIII, we formalize the requirements in detail using SeMF.

C. R3: SCALABILITY
As the proposed system relies on enhancing consent management among different agents, having a scalable infrastructure is critical for achieving system requirements. The number of consensus nodes, agents, and transactions handled per second are the three key elements that determine the scalability of a blockchain [25]. Thus, in our proposed system, we utilize blockchain to provide a scalable service to a growing number of users and nodes, including consent requests and response actions generated by different agents. Although each full node maintains a copy of the entire blockchain, only the final settlement of self-report data access and available transactions are recorded in the chain, resulting in an overall higher throughput [25].

D. R4: AUDITABILITY
Auditability is a built-in blockchain feature that keeps all the data in a blockchain immutable and resistant to tampering. VOLUME  Explanation the individual user and the owner of fitness data. unique reference number for each consent. an agent in the system who requests consent to collect data, known as requester or collector. a set of agents in a system who request consent to process data, known as a processor or fitness provider. an agent in a system who governs the network, known as the regulatory authority. public key of i where i represents an agent.
private key of i where i represents an agent.

Description
Only specific agents are enabled to know the value of data D. To ensure that D is confidential, D cannot be disclosed to unauthorized parties or malicious agents if such disclosure might affect the privacy of U;, FP; or R;. D can include entity identities (identifiers), D in combinations that might reveal entity identities (quasi-identifiers), sensitive or generic D, and sequences of action

A1 ... An.
This ensures that the communicating agents are who they claim to be by verifying their identity. Communication usually occurs in the form of a set of actions A1 ... An. Thus, each time action A; occurs, it must be authenticated to the receiving agent that the action originated from that sender. For example, each time an agent receives data D, it must be authenticated to the receiving agent such that data D is indeed equal to the original data D sent by the sending agent. This denotes that the system should ensure a level of protection against any denial by any agents performing an action A; or a set of actions r.
The system should provide proof of authenticity that all actions A1 ... An originate from the intended agent. Nonrepudiation involves two communication pairs. First, a sent transaction cannot be denied. For example, agent A sent the transaction to agent B; thus, agent A cannot deny the sending behavior. Second, a received transaction cannot be denied. For example, agent A sends the transaction to agent B; thus, B cannot deny that it received the transaction. This denotes that the data D received by the receiving agent are equal to the data D provided by the sending agent. Any data D transferred during the occurrence of actions A1 ... An must not be changed during the transfer and must be assured of being tamper-free when received by another agent. This denotes that the system should prevent unauthorized agents from being part of the system and performing a set of actions A1 ... An.
This denotes that the agents in the system should always have access to the system's resources, and data D are needed to perform actions A1 ... An.
The consent recorded in the blockchain can be used to conduct audits by the regulatory authority RA to resolve disputes among untrusted agents. This auditability feature can also be used to prove the authenticity or nonrepudiation security requirements, which are discussed in detail in Section VII. Although auditability features might be violated due to a 51% attack in a public blockchain, the proposed system uses a permissioned network on which only authorized parties are allowed to validate blocks, with some fairness among the parties, depending on the choice of consensus algorithm (e.g., PoW, PoS, Byzantine fault tolerance, etc.).

E. R5: PRESERVE FITNESS TRACKER ORIGINAL FUNCTIONALITY
This is important because as fitness trackers rely heavily on fast processing, the proposed solution should not hinder or burden the original functionality of the system. Although GDPR imposes the need to obtain users' consent to process their fitness data, it is not sufficient to ask for users' consent every time the data are processed and recorded in the chain. Therefore, regardless of the privacy complexity it adds to our proposed system, we ensure a sufficient level of functionality by creating a flexible contract (e.g., ContractToPro-cessDataForTimePeriod() for one month or year) and giving users the choice to revoke that contract at any time using ConsentWithdraw(). Therefore, the privacy requirement of the proposed system is met, and the processing operation will not be sufficiently slowed such that individuals are deterred from using the system.
• Unambiguous. Consent must be given by means of 'a clear affirmative action' (e.g., preselected options are invalid).
• Informed. The subject of the data must be aware of all the information associated with processing their data before they are processed.
• Freely given. On a voluntary basis, without coercion. The subject of the data must be aware of all the effects of the consent.
• Specific. Consent's request must be granular with a specified purpose. Thus, the subject of the data must be fully aware of the purposes and methods used to process their data.
• Auditable. All consent information must be stored for future auditing and can later be used as valid proofs.
• Withdrawable. Consent requests should include a way to easily withdraw granted consent.
• Explicit. Consent should verify that it was given by the subject of the data and should include detailed informa- tion on the data to which the consent applies. It must be verifiable to be validated.

V. THREAT MODEL
A threat modeling phase to explore potential security concerns is the best practice for designing a secure system. Using such a model enables us to select countermeasures during the design process of our framework model. As the privacy policies of fitness providers present a variety of security threats, we concentrated on three types of threats: consent tampering, consent fabrication, and the unlawful processing/collection of fitness data without individual consent.

VI. PROPOSED SYSTEM MODEL
In this section, we introduce our system architecture design model for a blockchain-based consent mechanism to access fitness data. Our proposed design focuses on privacy in terms of the exchange and records all consent processes in the blockchain. This works as a proof of consent by leveraging built-in security properties of the blockchain. The three main functionalities of the system are recording consent requests and responses, data transmission logs, and user device privacy settings. These three main functionalities ensure that the system is in compliance with the GDPR requirement, as discussed in Section IV, by tracing all consent logs and preventing any potential malicious behavior on the system when the app runs in the phone's background. One way to prevent such occurrences (as shown in Fig. 2) is to record the user's device privacy settings in the blockchain, which ensures that all data acquisition is performed in a legitimate manner based on both user consent and device settings. The device settings serve as an additional privacy-preserving layer above the user's consent level.
The proposed system acts as a legitimate legal archive in which all consent and data-sharing-related activities are recorded on the blockchain for auditing purposes. In the case of dispute/conflict or noncompliance, this process automatically forces both fitness providers and data requesters to comply with the legal framework when they acquire consent from users to process or collect their fitness data. GDPR     fosters transparent data processing to achieve both privacy and compliance. In line with GDPR compliance, the proposed system provides transparency by sharing data transaction logs back to the user to give the user a transparent view of their data transmission and know more about the parties with whom their data have been shared and whether the data have been shared based upon granted consent. This approach ensures that every action performed by the entities in the proposed system remains transparent to all parties involved in the blockchain network. Although exchanging the data through blockchain provides a valuable solution, it creates a point of conflict between blockchain and one of the GDPR criteria, that is, " right to be forgotten". The immutability feature ofblockchain makes it impossible for data to be erased and reverses the concept to " right to be never be forgotten". Although individual privacy is a fundamental right, auditing mechanisms are essential to ensure that rules and regulations are obeyed. Therefore, the proposed system was built based on the idea of decoupling consent management from data sharing. Neither the data nor the pointer of the data are stored in the chain. Blockchain only manages and stores consent and data-sharing-related activities and does not exchange data through the blockchain. The blockchain operates as a middle consent management layer between the requester and the owner of the fitness data. Blockchain stores the following data: consent requests, consent responses (grant/denial), VOLUME 10, 2022 consent withdrawal, data transmission logs, legitimate report checks of data transmission, and user device privacy settings.

A. SYSTEM ARCHITECTURE
This section presents our design of the proposed framework for dynamic consent, including the system design and architecture, and all potential system action sequence diagrams that show the consent-related data flow and algorithms to demonstrate how decisions are created and executed. We consider the following system participants: fitness provider (FP i ), data requester (R i ), regulatory authority (RA i ) and user (U i ). As shown in Fig. 3, the proposed system is composed of four main entities that contribute differently to the system. Here, we analyze their local view, which is used later (in Section VIII) for the security proof.
• Fitness Provider (FP i ): The local view of FP i is the send and receive actions. FP i has three sending activities: consent requests to process data, self-report data access, and self-report making data available. In addition, FP i has one receiving action, which is a consent response to the process data.
• Data Requester (R i ): The local view of R i is the send and receive actions. R i has two sending activities: consent requests to collect data from FP i and self-report data access. In addition, R i has one receiving action, which is the consent response to collect data.
• User (U i ): The local view of U i is the send and receive actions. U i has three sending activities: consent responses to collect/process data and withdrawal of valid consent action. Additionally, U i has five receive actions: two consent requests from FP i /R i , three self-report data accesses or making data available to ensure transparency with the user. All the above actions are recorded in the blockchain to ensure secure and reliable communication among entities.
• Smart Contract (SC i ): The role of smart contract SC i is to automatically check the validity of the processing and collecting actions of FP i /R i . It is also used to automatically switch from valid to invalid consent based on the user's withdrawal action and expiration time.
• Regulatory Authority (RA): RA's role is to ensure that the authentication information provided by other entities is lawful. When entities first register on the blockchain platform, their identity is checked by the RA in which they enter their identity authentication details. The RA is the first line of defense to ensure the security of the proposed system. Therefore, unauthorized nodes cannot tamper with consent, forge transactions, or attack smart contracts.

B. PROPOSED SYSTEM SEQUENCE OF ACTIONS AND ALGORITHMS
The proposed system consists of a set of consent-related actions that are listed in Table 3 as (Action, Entity, Parameters). The entities FP i , R i , U i and RA are identified as agents acting in the system. To formalize the actions depicted in Fig. 3, we abstract the way in which fitness providers process the fitness data D i measured by user's U i wearable fitness devices and how the data are shared and processed by other agents based on U i 's consent. Hence, we use the actions listed in Table 3. Each agent in the system has its own local view denoted by λ P , in which an agent can see only its own sent actions or received actions A 1 . . . A n . We can summarize each agent P's λ P by identifying the send and receive actions performed by each agent P. Hence, the design goals of the proposed system can be informally stated as follows.
DG1 It must be authentic for an agent that the data shown on the agent device are the data transferred in the blockchain. DG2 It is authentic for agent B that the data received are the data that were sent by agent A.
The blockchain feature allows all actions A 1 . . . A n performed by agent P to be recorded on the chain and viewable to all agents P. This process can enable agent P to learn more about other actions and expand their λ P of system actions beyond sending and receiving actions. All the system actions A 1 . . . A n are listed in Table 3. Based on the aforementioned assumptions and our knowledge of blockchain mechanisms 8 VOLUME   such as immutability and smart contracts, we assume that they can be achieved through smart contracts. Fig. 4 shows an illustrative diagram of the smart contract SC; execution steps. In the proposed system, we have two automated processes in which we can employ our assumptions about smart contracts. These automated processes are as follows.
(A) Smart contract SC 1 -Granted consent decision is valid for a period of time OR invalid if it has been withdrawn: A smart contract enables us to bind time with granted consent by U;. Once the time has expired, the granted consent becomes invalid (as shown in Fig. 5). Therefore, the processing and collection of data by FPi or Ri after that set time would be unlawful. The smart contract SC1 's input parameters are SC1 's time expiry tv and the initiated withdrawal transactions from U;. The output of SC1 adds a new transaction to the blockchain to report the consent with that reference number RF; becoming invalid. Below, we describe design goals based on the properties of SC1 that provide authenticity to agents, which can be informally stated as follows (as formalized in Section Vill): VOLUME IO, 2022 ---3

Self-Execution
Once predefined conditions are met, the contract will execute the program and provide an output

D G3 It must be authentic for all agents that the granted consent is valid upon both the consent timeframe and
Vi 's withdrawal decision. (B) Smart contract SC2-Check the validity of storing, processing, and collecting data based upon U;'s granted/denied consent: A smart contract enables us to detect any misbehavior from FPi or Ri in processing, storing, and collocating U/s fitness data (as shown in Fig. 6). Misbehavior is detected through a conditional check. Once a triggering action is recorded in the blockchain, its validation and authenticity are checked based upon U;'s consent decision (granted/denied) previously made for that consent with RF;. SC2 depends on three input parameters: the initiated transactions from FP; or Ri, the output of SC 1 , and the recorded U;'s denial consent. The identifier of consent is the RF; reference number. Below, we express the design goals informally based on the properties of SC 2 (as formalized in Section Vill): DG4 The FP; processed data must be authentic for Ui based upon U; 's granted consent. DG5 The R; collocated data must be authentic for U; based upon U;'s granted consent. After agent P joins the system, its authenticity is verified by the system's regulatory authority RA. The agent can start using the blockchain to record consent actions by sending a consent request to user U i , the owner of the fitness data, and waiting for granting or denial of the consent request.
Below, we define all possible steps of the consent request/response process (as shown in Fig.7). The sequence diagram in Fig. 8 shows how participating agents are connected and how consent is created and recorded in the chain by showing the transaction flow among them.
• Steps 1.1a and 1.1b: FP i /R i creates a consent request that includes three main components: consent content, reference number RF i and time required to process or collect data t v . We use this information as an input for Step 2, where the user can make a decision based on these received details. This transaction is then sent to the target user through a blockchain network.
If consent is granted in Step 2, the user has the option to withdraw consent at any time. As noted in Step 2 and Algorithm 1, the user is provided with a time expiry t v for their granted decision RF i . Below, we explain all possible steps to withdraw from the granted consent RF i in line with the GDPR requirements (from Section VI). All possible withdrawal transactions steps are as follows: Inform the agents that the consent with RF i has become invalid by reporting the result to the chain via SC 1 .
The consent with RF i remains valid. return True; end if • Step 2.3w: SC 1 from Steps 2.1w and 2.2w ensures that the proposed system design goal DG 3 is held in the system. The results of SC 1 are reported as a new transaction (as formalized in Section VIII). SC 1 's transaction is recorded in the chain, following steps similar to those

Consent Request and Response Actions Withdraw Granted Consent Actions
Stepl Consent Request Step 5 Check the validity of processing  explained in Step 1.2. This step informs agents that consent to RF; has become invalid. Fig. 9 illustrates how the proposed system's steps to check the validity of storing, processing, and collecting data are VOLUME IO, 2022 based upon U;'s granted/denied consent. The following steps use the smart contract to ensure that properties DG 4 and DG 5 hold in the system. These steps aim to show that if ConsentToProcess/Collect() is granted, then FP;IR; can lawfully start processing/collecting data within the agreed time t v . This check uses a smart contract with predefined rules, that is, a self-executing and self-enforcing contract. Below, we define how all steps of checking the validity of storing, processing, and collecting data are based upon U i 's granted/denied consent.
The sequence diagram in Fig. 9 shows the transaction flow among the participating agents (as subsequent steps of Steps 3.3a and 3.3b in Fig. 8). The steps are as follows:

VII. TRUSTWORTHINESS OF PROPOSED BLOCKCHAIN SYSTEM
As a subsequent step in the DSR paradigm, this section discusses the assumptions that model the blockchain properties, which are later validated in Section VIII. The proposed design includes four main agents P: RA, FP i , R i , and U i . Each contributes differently to the blockchain and has its own λ P [18]. Therefore, the trustworthiness of the system is vital to ensuring that the given consent request or response is authentic, originates from a trusted entity, and is safely stored with a backup of all data in case of failure. Blockchain can guarantee the trustworthiness of our proposed consent management system by providing an immutable and transparent way to record transactions between nontrusting entities. Entities in a blockchain have a local view (λ P ) of the system and trust only  the results shown to them. Their trust in the shown results is based on a sequence of actions known as w (system behavior, i.e., consent sent/received). As Fuchs et al. [18] noted, trust in a technological system must always be perceived as trust in a system property. The proposed system relies on assumptions about the blockchain's built-in mechanism (entity knowledge about the system). In Section VIII, we formally validate the properties of the proposed system, including its behavior (discussed in Section VI), based on our assumptions of blockchain.
This section discusses what the blockchain can do to ensure the trustworthiness of the proposed system's desired behavior. Section VIII thereafter presents clear, formal semantics that ensure the traceability of the trust and security requirements through a sequence of actions. Establishing trust between parties is critical given that trust is strongly related to security and privacy. Although we can repose trust in a single authority, there are risks associated with doing so, such as malicious acts, lack of transparency, and forged consent. Moreover, users must blindly trust a single authority to handle their data rather than trust the technology behind it. Implementing a system that uses distributed technology rather than a centralized authority can resolve trust issues.

VOLUME IO, 2022
Blockchain technology introduces many built-in features that make it a suitable candidate for the proposed design. These features include authenticity, integrity, tolerance to node failure (availability), nonrepudiation, ledger immutability, and auditability.
Blockchain technology is vulnerable to potential attacks on data privacy, making it less suitable as a data-sharing platform. All transactions in the blockchain are recorded in blocks in plaintext, making it possible for sensitive information in transactions to be exposed to all agents, including opponents. Therefore, in our proposed solution, we carefully address these security and privacy issues using a blockchain as a consent management platform without sharing any data. We likewise impose encryption on some consent content, if required. We further introduce an additional security measure to increase the trustworthiness of the system by adding an access control layer to the blockchain's participants and ensuring confidentiality by using an encryption algorithm to avoid disclosing data to unauthorized agents.
The built-in cryptographic properties of blockchain provide security guarantees to any system. Each blockchain's built-in feature provides unique security properties. In Section VIII, we prove that the security requirements of the proposed system are met based on our assumptions of the blockchain's built-in security properties. Below are our assumptions, stated as formal descriptions of the model's blockchain properties.

Assumption 1: If an action A i is received from the blockchain, it must have been previously added via a ''Send'' action or generated by a ''Smart Contract'' (smart contract/authenticity).
Assumption 2: If an action A i is added to the chain from a ''Send'' action, the agent's ''Send'' action must have been authentic (authenticity/digital signature).

Assumption 3: If action A i is added to the chain and generated by a ''Smart Contract'', the agent's ''Send'' action must have been authentic (smart contract/authenticity).
Assumption 4: If the data are shown on the agent's blockchain account, they must have been authentic, i.e., previously transferred in the blockchain.
Assumption 5: Whenever agents ''Receive'' data from the chain, the ''Send'' action adding the data to the chain must have been authentic, i.e., no data has changed (authenticity/integrity).
Assumption 6: A smart contract is executed, triggered, and automatically enforces the agreement terms when certain predefined conditions are met (authenticity/smart contract).
Having evidence on record means that actions shown must have occurred sometime in the past in a specific sequence and originated by the intended agent, thereby ensuring authenticity. Below, this property of the blockchain is described in Assumptions 7 and 8.
Assumption 7: If action A i is added to the chain, A i is enclosed in a new block and added to the end of the longest chain, after which the blocks are organized in a specific sequence of order (timestamp/order evidence).
Assumption 8: A copy of the whole blockchain and its valid transactions are maintained and propagated through the network nodes (immutability/evidence record).

VIII. FORMALIZATION OF SECURITY REQUIREMENTS
We use SeMF, developed by [18], for formal system modeling and validation of the security properties of the proposed system. This framework is based on the foundation of formal language theory, which employs fine-grained notions to model the requirements and properties of the proposed system. A detailed description of SeMF, which is beyond the scope of this study, can be found in [18]. In this section, we use SeMF's formal definitions of the security requirements to formalize some of the proposed system model requirements. These security requirements are (A) authentication and (B) proof of authenticity (with integrity and authorization properties implied in the discussion).

A. AUTHENTICATION 1) DEFINITION OF THE PROPERTY
Authentication denotes that the communicating agents are who they claim to be by verifying their identities. We use Def-initions 1 and 2 from SeMF [18] to formalize the authenticity property introduced in Section IV.

2) FORMALIZE AUTHENTICITY OF ACTIONS
The blockchain type in the proposed system is a permissioned blockchain in which participants are added by RA. The process of adding participants is outside the proposed system model and involves RA verifying their actual identity and then issuing key pairs for blockchain accounts. In the proposed system model, we assume that all participants were authenticated and verified by the RA before they became part of the system. Whenever an agent wants to add something to the blockchain, the first transaction is signed with sk P . Later, the transaction is validated by the blockchain using its pk P . Therefore, the system does not need a global public key infrastructure (PKI ), where everybody trusts the key; only one agent, which is not a single entity but a distributed system (blockchain), checks the authenticity. Assumptions 7 and 8 enable all agents to know whether any action in the system is authentic and originates from the intended agent.

3) END TO END AUTHENTICATION TRUST
Agent P, as a person, is not able to validate a digital signature, which usually requires an end device or accounts to perform the validation. Therefore, the agent accounts, not the agents P or their end devices, validate the authenticity. Based on Assumption 4, the entity in the proposed system that performs the authentication validation check is a blockchain network. Therefore, the blockchain accepts only a signed valid transaction with the correct sk P and checks the origin of the transaction. For the blockchain to verify that the added action A i by agents P on the blockchain is authentic and in fact originated by that agent, every agent P in the system has a blockchain account or set of accounts that are composed of pk P and sk P pairs [25], as depicted in Fig. 10. To identify the owner of each account, the hash of agent P's pk P is used to form an address [25]. The address is then used to receive transactions from other agents P. Sk A is used to sign a transaction with a valid signature from sending agent A and sends it to another agent B's address to verify it using sending agent pk A . Hence, agent P in the system can claim ownership of their account using sk P if their sk P is kept secret on their end devices and has not been shared with any malicious agent P.
The blockchain's built-in features, such as the digital signature, ensure that the proposed system's design goals DG 1 and DG 2 hold in the system. Below, we formalize all system authenticity properties.
• All sets of actions within agents λ P . The authenticity of these actions is proven using Assumptions 1, 2, 5, and 7, which ensure that DG 1 and DG 2 hold in the system.
• All sets of actions beyond agents λ P are known as empty sequences, denoted by ε. The authenticity of ε is  proven using Assumptions 1, 3, 5, 6 and 7, which ensures that DG 3, DG 4 and DG 5 hold in the proposed system.

4) AUTHENTIC COMMUNICATION
Each agent in the system has a different λ P and can see only their own sent actions or received actions A 1 . . . A n . The authenticity of sent and received actions A 1 . . . A n can be interpreted as Auth(a, b, P). In other words, if a particular action b has occurred in a sequence of actions ω, it must be authentic for agent P that action a has occurred before. Therefore, to validate the authenticity of these actions, a precise definition of what ''authentic'' means is required. Hence, we use the SeMF's [18] definitions 1 and 2.
Definition 1: A set of actions ⊆ is authentic for P ∈ P after a sequence of actions ω ∈ B with respect to W P if alph(x) ∩ = ∅ for all x ∈ λ −1 P (λ P (ω)) ∩ W P . Although Definition 1 allows sets of actions to be authentic, for the proposed system, a simplified definition for single actions is sufficient, as defined in the following definition from SeMF [18]: Definition 2: For a system S with behaviour B ⊆ * , agent P ⊆ P, and actions a, b ∈ , auth(a, b, P) holds in B if for all ω ∈ B, whenever b ∈ alph(ω), the action a is authentic for P.

Proposition 1: If agent B executes the ''received'' action (b), then the matching sent action (a) by agent A is authentic.
Note: The reference number RF i in the following description is used to identify the consent required to process action A i .
Proof of Proposition 1: In the proposed system, we can verify the authenticity of these actions using Assumptions 1, 2, 5, and 7. This proof shows the details for one ''receive'' action (b) in which the same proof also applies to all other receive actions in the proposed system. Fig. 11 shows that when agent A (FP i /R i ) sends consent request transaction a, its authenticity is verified by agent B (U i ) each time it executes the received action b (recvConsentRequest, U i ,(FP i /R i , ConsentToProcess/Collect, RF i )). Hence, the set of actions that will be authentic consists only of the send action a (sendConsentRequest, FP i /R i ,(ConsentToProcess/Collect, RF i )) and agent B (U i ), for which this action will be authentic. It is authentic for all sequences of actions ω that contain an action (recvConsentRequest, U i ,(FP i /R i , ConsentToProcess/Collect, RF i )).
As defined in Definition 1, it can be formally denoted as: For all sequence of actions ω ∈ S that (recvConsen-tRequest, This security property is provided by the proposed system with agent B's knowledge is equal to W B and agent B's local view equal to λ B . W B is equal to Assumptions 1, 2, 5, and 7, and λ B is equal to received action b (recvConsentRequest, U i , FP i /R i , ConsentToProcess/Collect, RF i )).
To that end, we can validate Proposition 1 with agent B's knowledge W B equal to the blockchain's Assumptions 1, 2, 5, and 7: • From Assumptions 1 and 7, we can conclude that if agent B receives action b ⇒ , then this implies that the matching send action a sent by agent A is recorded in the blockchain.
• From Assumption 2, we can conclude that if send action a is added by agent A ⇒ , then this implies that send action a is authentic.
• From Assumption 5, the action is authentic, meaning that the sent data are equal to the received data. 1 Hence, the proposed system design goal DG 2 is met and can be captured using the following formalization:   We use the fact that Proof 1 applies to all other received actions, such as from FP i /R i to U i , from U i to FP i /R i , and from FP i to R i , to satisfy DG 2. Below, we describe these actions as follows: • Fig. 12 illustrates the authenticity of sending and receiving update actions from FP i /R i to U i , which can be formalized as follows.
auth(sendSelfReportDataAccess(Processing/ CollectingUpdates, RF i ), recvSelfReportDataAccess (Processing/CollectingUpdates, RF i ), U i ) • Fig. 13 shows the authenticity verification of the sent and received consent response actions, which can be formally stated as follows.
• Fig. 14 However, there are some sets of actions in the proposed system beyond agents λ P , known as empty sequences, which are denoted by ε. It is difficult to guarantee the authenticity of these actions ε and prove that DG 3, DG 4, and DG 5 hold in the system. Below, we discuss the possible blockchain builtin mechanisms. Assumptions 6, 7, and 8 are used to ensure that DG 3, DG 4, and DG 5 hold in the system by addressing these difficulties. Blockchain's Assumptions 7 and 8 allow all sets of actions performed by agents P to be recorded on the chain in a secure and reliable way and be viewable to all agents P. This makes agent P learn more about other actions and expands their λ P of the system actions beyond the send and receive actions.
A smart contract's reliability and inevitability features can fulfil the proposed system's design goals DG 3, DG 4, and DG 5. Assumption 6 effectively proves that these three design goals hold in the proposed system. As stated before in Definition 2, we state our propositions and prove them using Assumptions 1, 3, 5, 6, and 7.
Proposition 2: If agent B executes the ''received'' action (b), then the matching sent action (a) by the smart contract is authentic.
Proof of Proposition 2: Following Proof 1, we can also validate Proposition 2 with agent B's knowledge W B equal to Assumptions 1, 3, 5, 6, and 7.
• From Assumptions 1 and 7, we can conclude that if agent B receives action (b) ⇒ , then this implies that the matching send action (a) sent by the smart contract is recorded on the blockchain.
• From Assumptions 3 and 6, we can conclude that if send action (a) is added by the smart contract ⇒ , then this implies that send action (a) is authentic.
• From Assumption 5, an action being authentic means that the sent data equal the received data. 2

5) PROOF USING SMART CONTRACT SC 1
This process aims to ensure that the granted consent decision is valid for a period of time OR invalid if it has been withdrawn. Based on Proof 2, the proposed system design goal DG 3 holds in the system. This can be expressed as follows.
auth(auth(sendWithdrawConsen(WithdrawConsent, RF i ), recvWithdrawConsen(WithdrawConsent, RF i ), Additionally, SC2 can prove that the data collected by R; are valid and authentic by checking R;'s report access to FP;'s database. This process covers Proposition 2 and validates that DG 5 holds in the system. This can be formalized as follows .
Finally, we formalized all system actions using SeMF and proved that l, DG 2, DG 3, DG 4, and DG 5, concerning authenticity and integrity, hold in the system. VOLUME IO, 2022

1) DEFINITION OF THE PROPERTY
This property involves two pairs of communication in which both sent and received transactions cannot be denied. We use the definition from SeMF [18] to formalize the proof of the authenticity property introduced in Section IV: Definition 3 ( Proof of authenticity): A pair (r S, r P) with r S S 1: and r P S 1: is a pair of sets of proof actions of authenticity for a set r S 1: on S with respect to (W p )PEIP' if for all w ES and for all PE ]p> with alph(rrp(w)) n r P =f. 0 the foUowing holds: ( 1) For P the set r is authentic after w and (2) for each R E ]p> there exist actions a E 1:/ P n rs and b E 1:/ R n r P with wab ES. Agent P E ]p> can give proof of authenticity of r S 1: after a sequence of actions w E S if 1 and 2 hold. Proposition 3: For the received actions (b), agent B must always be able to access evidence to show proof to other agents, which enables them to check the authenticity of the matching sent action (a) that occurred before the received action (b).

2) FORMALIZE ACTIONS PROOF OF AUTHENTICITY
Blockchain is an excellent solution to address this security property, which is used as an evidence recorder in which all transaction and activity logs of consent are submitted and settled permanently into a shared ledger. Based on Assumption 7, a blockchain is formed by a chain of blocks in which each block appends links to its direct predecessor until a block with index 0, which is known as the genesis block [25]. Based on Assumption 8, a copy of whole records is distributed among all entities, and it keeps chronologically nontamperable records that are linked via hash values. A digital signature scheme (asymmetric encryption), timestamp, and immutability of records, in which the system's actions can be tracked for authenticity proof, are all effective approaches to guarantee nonrepudiation [50]. Fig 15 depicts an overall view of blockchain's built-in approaches to guarantee nonrepudiation. For example, if there is any malicious modification in any block, all the blocks after that modified block must be recomputed because each block is tied to the hash value of the previous block's header, which proves that such malicious modifications cannot be performed in this case.
Proof of Proposition 3: As defined in Definition 3, we can validate Proposition 3 with agent B's knowledge W B equal to Assumptions 7 and 8.
• From Assumption 8, we can conclude that if agent B receives action (b) ⇒ , then agent B can access the evidence record.
• From Assumption 7, we can conclude that if agent B can access the evidence record ⇒ , then agent B can provide proof that the sent action (a) has occurred before the receive action (b). 3 To that end, after formalizing the proposed system actions and in relation to the blockchain's built-in features, we guaranteed nonrepudiation by proving Proposition 3 using Proof 3.

IX. CONCLUSION, LIMITATIONS AND FUTURE WORK
Sharing personal fitness data with third parties poses several privacy concerns. This study aims to address such concerns in the privacy policies of fitness trackers by improving user control over the processing of their fitness data. We designed a blockchain-based dynamic consent mechanism to mitigate privacy-preservation issues. The primary artifacts in the proposed system are the system architecture, requirements specification, and formal proof model. This study also evaluates the demonstrated artifacts using the SeMF tool and the identified blockchain assumptions. As a result, the SeMF evaluation proves that the system satisfies all our design goals. We conclude that the proposed system is suitable for preserving user privacy by improving user control over the processing of fitness data. However, further research is required to address the remaining gap: fitness trackers must honestly report their actual processing actions to the blockchain.

A. LIMITATIONS
Although the proposed model has proven its effectiveness in terms of security properties using SeMF [18], there are some limitations to consider.
• The proposed framework requires an experimental evaluation to show whether the solution is practical to use in terms of the computation, storage, and communication overhead of each entity.
• This research provides only an abstract level of the proposed solution discussing the feasibility of utilising the blockchain to improve users' control over their data in fitness apps by consent mechanisms.
• The FP i 's reported action in the proposed system still relies on FP i behaving and reporting honestly to the blockchain about the actual processing actions of U i 's fitness data. Although the proposed system is based on the idea of decoupling consent management from data sharing, there must be a way to prove that the exchange of data occurred upon user decision making without relying on FP i being honest, as they own the database.

B. FUTURE WORK
This study interprets the proposed system security requirements in verbal descriptions and then formalizes these requirements using the SeMF tool. The findings in this paper are just the first step in designing and developing blockchain-based consent management. In future work, we plan to conduct an experimental evaluation to demonstrate the effectiveness of the proposed model in terms of the computation, storage, and communication overhead of each entity. Additionally, further research is needed to determine the suitable choices of blockchain's technical details to the proposed solution, including but not limited to consensus algorithm, usage of tokens and their economy and the method for authenticating fitness devices.