# Blockchain for Doping Control Applications in Sports: A Conceptual Approach
## 3 Blockchain-Based Approach for the AD Domain
### Design of a Decentralized Anti-Doping Ecosystem
#### 3.3.4 Membership, Access Control, and Confidentiality  
As discussed in the opening paragraph of Section 3.3, HLF is a permissioned platform where only pre-authorized stakeholders can participate. This functionality is assured by the chosen access mechanisms and channel settings; hence, it is the combination of a Membership Service Provider (MSP) and an Access Control List (ACL) that enables privacy and security in HLF [83]. The participating organizations connect with each other through the HLF network, and each organization has at least one peer node that must deal with membership services to their users. The standard implementation is not sufficient to guarantee the anonymization of users' data as envisioned in this proposed application; therefore, more sophisticated pluggable schemes can be proposed. Attribute-based encryption (ABE) and Identity Mixer (Idemix) are advanced techniques used to address privacy and confidentiality of users and users' data. The ABE scheme provides confidentiality and access control with a single encryption. In this paper, the distributed ABE framework proposed in [85] was used. The ABE scheme involves the following parties: the MSP, the User Application (data input), the Attribute Authorities (AAs), and the Distributed Ledger. AAs are implemented within the MSPs of trusted organizations only (in accordance with the governance hierarchy proposed in Section 3.3.1), which are responsible for verifying and issuing credentials for users based on their attributes. The distributed ABE scheme was chosen so as to avoid a single point of failure. In this case, different AAs issue credentials for users, allowing different sets of attributes to be monitored by different AAs. Figure 6 shows the ABE functionalities and a possible multiorganizational distribution considering the various organizations in the AD ecosystem and the proposed governance hierarchy. Figure 5: TUE request-asset lifecycle. References: [83; 84]. The ABE operational scheme is described by five protocols [85]:  
1. Setup: By this protocol, a predefined parameter of security is taken as input. The system parameters are the outputs generated by the Governing JV MSP and shared only with organizations with AA responsibility. 2. AA Setup: Using the system parameters obtained from setup, each AA organization can generate public and private keys for the attribute it maintains. 3. Key Issuing: Via an anonymous key issuing scheme, user (i.e., peers, orderers, and clients) and organizations interact so as to determine a set of attributes belonging to the users. Then, the AA organization generates decryption credentials for those attributes and sends them to the user. 4. Encryption: The encryption algorithm is used by the blockchain users at the application level. The user takes a set of attributes maintained by AAs and the different segments of the 'TUE request' data as inputs. Then, it outputs different ciphertexts of each data that will be appended in the transaction. 5. Decryption: The decryption algorithm is also used by blockchain users. After taking the decryption credentials received from AAs and the ciphertext from the blockchain transaction as inputs, the decryption will be successful if, and only if, the user attributes satisfy the access structure of the ciphertext. Figure 7 shows the input format of a TUE request, the structure of the initial blockchain transaction and examples of ABE policies for data decryption. At the user application side, the request is submitted via an electronic form that has three distinct segments of data: the athlete's personal data, the doctor's personal data, and the TUE-related details (i.e., sport, medical conditions, and prohibited substance(s)). Each segment of data in the form is encrypted with a specific ABE policy, and the appropriate set of attributes for each segment is defined in accordance with the TUE request criteria. The encrypted data are then appended to the blockchain transaction invoked via SC.