# 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
Since the transaction is published in the ledger, it is visible to participants in the channel; however, as the sensitive personal data of involved parties and the details of the TUE request are encrypted with ABE, only the users possessing the right set of attributes can decrypt them. Members of TUECs, for example, will receive keys that only allow them to view the TUE-related data, but not the athlete's nor the doctor's personal details. Similarly, the personal information of both athlete and doctor could only be decrypted by specific authorities with auditing attributes, for example. Therefore, ABE encryption policies allow fine-grained access to sensitive data [85], guaranteeing privacy and confidentiality during the analysis of a TUE request, which is a considerable gain compared to the current semi-digitalized and centralized process and its vulnerabilities (as explained in Figure 1). Figure 7 only shows the application of ABE for the initial submission of the TUE request; however, it is important to highlight that analogous ABE criteria will be applicable to the following stages of the asset lifecycle. Figure 6: Mapping of ABE functionalities/AD organizations. Reference: [85]. To complete the proposed scheme, the MSP implementation counts with Idemix to play an important role. HLF's basic MSP implementation complies with a standard Public Key Infrastructure (PKI), which does not support users' anonymity and unlinkability. With Idemix, user anonymity and unlinkability are guaranteed and the transaction can be invoked without disclosing the transactor's identity. A single identity can transact several times without disclosing that the transactions were sent by the same identity [83, 86]. Issuer MSPs in the proposed scheme certify a set of user's attributes that are issued as digital certificates (also known as \"a credential\") [86]. The user later generates a zero-knowledge proof (ZKP) of possession of the credential, and only discloses the attributes previously chosen to be revealed. The proof, because it is zero-knowledge, reveals no additional information to the verifier, issuer, or to any other participant [86]. When a blockchain user needs to transact, a certificate must be obtained from a Certificate Authority (CA), so an MSP interacts with the CA to issue certificates, including an enrolment certificate. When a user in the blockchain network invokes a SC transaction, that transaction needs to be previously signed by the enrolment certificate [83]. With Idemix, the user can generate per-transaction certificates; in other words, certificates that are used just for one transaction. The same principle is valid for encryption keys, one-time-use keys are created, and the user can prove all keys were derived from the same enrolment certificate [83]. This guarantees to the user the desirable ability to generate multiple keys from the original enrolment certificate, but at the same time being able to prove to an auditor in the HLF network that all transactions were performed by a single user, while other entities in the network would not be aware that all transactions were performed by a specific user [83]. Considering the TUE request example, this means that the athlete's doctor can initiate the process by invoking the TUE request transaction, while keeping their identity anonymous to the other stakeholders via ZKP and encrypting all sensitive data with ABE. It is important to highlight that Idemix is not yet mature in the current HLF release [86], and ABE is not a standard feature; therefore, a complete functionality combining a decentralized ABE scheme and Idemix represents a considerable development effort. Figure 7: Data format (TUE request)/transaction structure/examples of ABE policies.