Applied Science, Faculty of
Engineering, School of (Okanagan)
DSpace
UBCO
Huang, Yuhao
Master of Applied Science - MASc
University of British Columbia
Public Key Infrastructure (PKI), especially the X.509 standard, is the backbone of secure digital communication, providing essential services such as authentication, encryption, and digital signature verification. X.509 enables a certificate chain of trust, where Certificate Authorities (CAs) serve as the central trust anchors. While X.509 has proven to be effective in traditional centralized environments, it faces significant challenges such as single points of failure, vulnerability to CA breaches, and limited scalability in a globally distributed network. With the rise of decentralized technologies like blockchain, there is growing interest in developing Decentralized Public Key Infrastructure (DPKI) systems that eliminate these weaknesses by distributing trust across multiple entities. However, the majority of DPKI research either conflicts with X.509 standard, giving up CA as trust anchor, or focuses on general identity management. Especially, there are few research works concentrated on X.509 compatible DPKI systems designed for digital credentials. This thesis addresses the gap by investigating the integration of DPKI with X.509 specifically for managing digital credentials. A thorough literature review identified Trustchain as the most relevant and advanced stateof-the-art framework addressing this topic. Trustchain employs blockchain technology for digital credential management but also exhibits key design limitations. Using Trustchain as a foundational benchmark, this thesis introduces BCChain, a modified DPKI system that enhances identity validation, and incorporates a multi-root architecture, advancing blockchain-based DPKI compatibility with X.509 while improving security and scalability. This thesis also proposes a use case in education by simulation to further illustrate the application of my system.
Blockchain-based Decentralized PublicKey Infrastructure for DigitalCredentialsbyYuhao HuangB.Sc., Northwestern Polytechnical University, 2022A THESIS SUBMITTED IN PARTIAL FULFILLMENT OFTHE REQUIREMENTS FOR THE DEGREE OFMASTER OF APPLIED SCIENCEinThe College of Graduate Studies(Electrical Engineering)THE UNIVERSITY OF BRITISH COLUMBIA(Okanagan)September 2025© Yuhao Huang, 2025The following individuals certify that they have read, and recommendto the College of Graduate Studies for acceptance, a thesis/dissertation en-titled:Blockchain-based Decentralized Public Key Infrastructurefor Digital Credentialssubmitted by Yuhao Huang in partial fulfilment of the requirements ofthe degree of Master of Applied ScienceChen Feng, School of EngineeringSupervisorBabak Mohamadpmy Tosarkani, School of EngineeringSupervisory Committee MemberAhmad Al-Dabbagh, School of EngineeringSupervisory Committee MemberEric Li, Faculty of ManagementUniversity ExamineriiAbstractPublic Key Infrastructure (PKI), especially the X.509 standard, is thebackbone of secure digital communication, providing essential services suchas authentication, encryption, and digital signature verification. X.509 en-ables a certificate chain of trust, where Certificate Authorities (CAs) serveas the central trust anchors. While X.509 has proven to be effective in tradi-tional centralized environments, it faces significant challenges such as singlepoints of failure, vulnerability to CA breaches, and limited scalability ina globally distributed network. With the rise of decentralized technologieslike blockchain, there is growing interest in developing Decentralized Pub-lic Key Infrastructure (DPKI) systems that eliminate these weaknesses bydistributing trust across multiple entities. However, the majority of DPKIresearch either conflicts with X.509 standard, giving up CA as trust anchor,or focuses on general identity management. Especially, there are few re-search works concentrated on X.509 compatible DPKI systems designed fordigital credentials.This thesis addresses the gap by investigating the integration of DPKIwith X.509 specifically for managing digital credentials. A thorough litera-ture review identified Trustchain as the most relevant and advanced state-of-the-art framework addressing this topic. Trustchain employs blockchaintechnology for digital credential management but also exhibits key designlimitations. Using Trustchain as a foundational benchmark, this thesis in-troduces BCChain, a modified DPKI system that enhances identity valida-tion, and incorporates a multi-root architecture, advancing blockchain-basedDPKI compatibility with X.509 while improving security and scalability.This thesis also proposes a use case in education by simulation to furtherillustrate the application of my system.iiiLay SummaryThis thesis addresses the challenges in managing digital credentials se-curely using X.509, a widely used standard for online security and digitalsignatures. While X.509 relies on centralized certificate authorities (CAs),this centralization creates risks such as single points of failure and vulnera-bility to breaches, making it less suitable for global, decentralized applica-tions. Blockchain technology offers potential solutions by distributing trustacross multiple entities, but existing decentralized public key infrastructure(DPKI) systems often lack compatibility with X.509.To address this gap, this research builds on TrustChain, a blockchain-based credential management system, and identifies eight key challengesthrough a comprehensive literature analysis. Building on this analysis, thethesis introduces BCChain, a modified DPKI system designed to tackle theseeight challenges effectively. A simulated educational use case demonstratesBCChainâs capability to securely issue, manage, and verify digital creden-tials, highlighting its technical robustness and practical applicability.ivPrefaceThe work presented in this thesis was completed at the University ofBritish Columbia- Okanagan, between January 2023 to September 2025. Iassumed responsibility for devising the proposed modeling approach, imple-menting the algorithm of test cases, and validating simulation. The com-pleted manuscript was authored exclusively by myself. My supervisor, Dr.Chen Feng, guided me through my research and offered support and thought-ful recommendations.Generative Artificial Intelligence (AI), including ChatGPT and Claude,were only employed for grammar, spelling, and writing feedback. Thesetools provided support in refining the technical and written aspects of thethesis.vTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiiLay Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vList of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . xGlossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiAcknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiChapter 1: Introduction . . . . . . . . . . . . . . . . . . . . . . . 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem and Contribution . . . . . . . . . . . . . . . . . . . . 31.3 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . 5Chapter 2: Preliminaries . . . . . . . . . . . . . . . . . . . . . . 72.1 Blockchain Technology . . . . . . . . . . . . . . . . . . . . . . 72.1.1 Blockchain Definition and Significance . . . . . . . . . 72.1.2 Blockchain Components . . . . . . . . . . . . . . . . . 82.1.3 Property of Blockchain . . . . . . . . . . . . . . . . . . 142.2 Decentralized Identifier . . . . . . . . . . . . . . . . . . . . . . 182.2.1 Basic Concept . . . . . . . . . . . . . . . . . . . . . . 182.2.2 Components . . . . . . . . . . . . . . . . . . . . . . . 19Chapter 3: Public Key Infrastructure for Digital Credential . 223.1 Public Key Infrastructure . . . . . . . . . . . . . . . . . . . . 223.1.1 X.509 Certificate . . . . . . . . . . . . . . . . . . . . . 233.1.2 Certificate Chain . . . . . . . . . . . . . . . . . . . . . 263.1.3 Certificate Revocation List . . . . . . . . . . . . . . . 28vi3.2 Digital Credential . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.1 Definition of Digital Credential . . . . . . . . . . . . . 293.2.2 Usage of PKI in Digital Credential . . . . . . . . . . . 323.2.3 Key Limitations of Centralized PKI . . . . . . . . . . 333.3 Decentralized Public Key Infrastructure . . . . . . . . . . . . 353.3.1 Trust in DPKI of OpenPGP . . . . . . . . . . . . . . . 353.3.2 X.509 Compatible DPKI Systems . . . . . . . . . . . . 373.4 Trustchain and Potential Problems . . . . . . . . . . . . . . . 413.4.1 Trustchain Design Principles . . . . . . . . . . . . . . 413.4.2 Trustchain Structure . . . . . . . . . . . . . . . . . . . 433.4.3 Problems of Trustchain . . . . . . . . . . . . . . . . . 493.5 Summary of current systems . . . . . . . . . . . . . . . . . . . 51Chapter 4: BCChain: X.509 Compatible Blockchain Design . 564.1 BCChain Components . . . . . . . . . . . . . . . . . . . . . . 564.1.1 Main DID . . . . . . . . . . . . . . . . . . . . . . . . . 564.1.2 Multi-Root System . . . . . . . . . . . . . . . . . . . . 614.1.3 Sub DIDs . . . . . . . . . . . . . . . . . . . . . . . . . 714.2 Use Case: Education . . . . . . . . . . . . . . . . . . . . . . . 734.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Chapter 5: Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 955.1 Summary of Work . . . . . . . . . . . . . . . . . . . . . . . . 955.2 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . 95Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97viiList of FiguresFigure 2.1 Blockchain and Merkle Tree . . . . . . . . . . . . . . 9Figure 3.1 Certificate Chain Path . . . . . . . . . . . . . . . . . 27Figure 3.2 Using X.509 Certificates to establish the owner of aDID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Figure 3.3 Upstream and Downstream DIDs . . . . . . . . . . . 45Figure 4.1 Main DID Registration and Endorsement . . . . . . . 58Figure 4.2 Root DID Default Connection . . . . . . . . . . . . . 63Figure 4.3 CA DID Credit Endorsement and Vertical Reinforce-ment . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Figure 4.4 CA DID Credit Horizontal Reinforcement and Cre-dential Issuance . . . . . . . . . . . . . . . . . . . . . 67Figure 4.5 Root DID Addition and Revocation . . . . . . . . . . 69Figure 4.6 Educational Usage Illustration of BCChain . . . . . . 78viiiList of TablesTable 3.1 Comparison of Strongly Digital-Credential-Linked Sys-tems with BCChain. Red triangle (â³) indicates thatthe feature is average or has deficiencies; red cross (Ã)indicates the feature is completely missing or has sig-nificant vulnerabilities identified in research. . . . . . . 53Table 3.2 Comparison of Weakly Digital-Credential-Linked Sys-tems with BCChain. Red triangle (â³) indicates aver-age performance or deficiencies; red cross (Ã) indicatesfeature is missing or has significant vulnerabilities. . . 54ixList of AbbreviationsACL Access Control ListACME Automatic Certificate Management EnvironmentAML Anti Money LaunderingBCH Bitcoin CashBFT Byzantine Fault ToleranceCA Certificate AuthorityCBDC Central Bank Digital CurrencyCN Common NameCRL Certificate Revocation ListCRS Certificate Revocation SystemCS Computer ScienceDAO Decentralized Autonomous OrganizationdApps Decentralized ApplicationsdDID Downstream DIDDID Decentralized IdentifierDNS Domain Name SystemDoAi Department of Artificial IntelligenceDPKI Decentralized Public Key InfrastructureEHRs Electronic Health RecordsEVM Ethereum Virtual MachineGDPR General Data Protection RegulationHIPAA Health Insurance Portability and Accountability ActHSMs Hardware Security ModulesHTTPS Hyper Text Transfer Protocol SecureIBM International Business Machines CorporationION Identity Overlay NetworkIoT Internet of ThingsIPFS InterPlanetary File SystemISO/IEC International Standard OrganizationITU-T International Telecommunication UnionKMC Key Management CenterxKYC Know Ymy CustomerMD5 Message-Digest Algorithm 5MitM Man-in-the-MiddleNIST National Institute of Standards and TechnologyOCSP Online Certificate Status ProtocolOU Organizational UnitPBFT Practical Byzantine Fault TolerancePGP Pretty Good PrivacyPII Personally Identifiable InformationPIN Personal Identification NumberPKI Public Key InfrastructurePKIX X.509 Public Key InfrastructurePoA Proof of AuthorityPoS Proof of StakePoW Proof of WorkRA Registeration AuthoritySegWit Segregated WitnessSHA Secure Hash AlgorithmSPV Simplified Payment VerificationSSL Secure Sockets LayerSSI Self-Sovereign IdentityTLS Transport Layer SecurityTxid Transaction IDuDID Upstream DIDURL Uniform Resource LocatorURI Uniform Resource IdentifierW3C World Wide Web ConsortiumxiGlossaryPublic Key Infrastructure Public Key Infrastructure is a comprehen-sive framework of technologies, policies, and procedures designed to managecertificates and cryptographic keys.Certificate Authority A Certificate Authority is a trusted third-partyorganization responsible for issuing digital certificates.Certificate Revocation List Certificate Revocation List (CRL) is atime-stamped, digitally signed document issued by a Certifcate Authorityor designated CRL issuer that enumerates certificates revoked before expi-ration.Certificate Chain Certificate Chain or Certificate Path, refers to achain of multiple certificates that may be needed, comprising a certificate ofthe public key owner (the end entity) signed by one CA, and zero or moreadditional certificates of CAs signed by other CAs.Digital Credential Digital Credentials are the electronic equivalent ofphysical documents that citizens already had like a driverâs license or healthcard.Decentralized IdentifierADecentralized Identifier is a globally uniquepersistent identifier that is created, owned, and controlled by the subject ofthe identifer, which could be a person, organization, or device.Blockchain Blockchain is a shared, immutable ledger that facilitates theprocess of recording transactions and tracking assets in a business network.Identity Retention Identity Retention means the digital identity andits components should be directed to a unique entity without duplication orfake.xiiAcknowledgementsI would like to express my deepest gratitude to my supervisor, Dr. ChenFeng, for his unwavering support and encouragement throughout my re-search journey. His mentorship has significantly enhanced my research skillsand technical writing abilities. I am especially grateful for the opportunitieshe provided for me to participate in international conferences and collab-orate with industry partners, which have been instrumental in shaping astrong foundation for my future career.I am also sincerely thankful to Dr. Babak Mohamadpmy Tosarkani, Dr.Ahmad Al-Dabbagh, and University Examiner Eric Li for their invaluablecontributions as members of my supervisory committee. Their insightfulfeedback and constructive criticism have been essential in refining the qualityof this thesis.xiiiChapter 1Introduction1.1 BackgroundPublic Key Infrastructure (PKI) is a comprehensive framework thatencompasses technologies, policies, and procedures aimed at managing dig-ital certificates and cryptographic keys, which are essential for ensuring se-cure communication and verifying identities in a digital environment [1â3].At its core, PKI is predicated on asymmetric cryptography, utilizing a pair ofkeys: a public key and a private key. The public key is disseminated widelyand used for encrypting messages and verifying digital signatures, while theprivate key is kept confidential and is employed for decrypting messages andcreating digital signatures. A robust PKI relies on its certificate chain, com-prising several key components, including Certificate Authority (CA), Reg-istration Authority (RA), certificate, and key management system, whichI will explain in detail afterward. X.509 Public Key Infrastructure(PKIX) is the best-known framework for public-key and attribute certifi-cates upon which full services in a hierarchical authentication structure canbe based [3].The significance of PKI extends across various domains, including butnot limited to, financial services [4], healthcare [5], digital identity [6, 7] andthe mobile [8]. By implementing PKI, organizations can establish a trustedenvironment for conducting transactions, thereby enhancing the securityand integrity of sensitive information exchanged over potentially insecurenetworks. This trust is facilitated through the use of certificates, whichauthenticate the identities of users and entities involved in interactions.Digital credential, in this thesis, is defined as the electronic equivalentof physical documents following the Government of Canada [9]. These cre-dentials are designed to provide verifiable proof of identity, qualifications,or other personal information in an online format. They can include digitalversions of driverâs licenses, passports, academic certificates, or any otherform of identification traditionally issued in physical form.The application of PKI in digital credentials plays a crucial role in ensur-ing the authenticity, integrity, and security of these electronic documents.1PKI provides a framework that enables digital signatures and encryption,both of which are essential for creating trusted digital credentials. By usingcryptographic keys, PKI allows the issuer of a digital credential to sign thedocument digitally, ensuring that recipients can verify its legitimacy andconfirm that it has not been tampered with. Additionally, PKI enablesencrypted communications, ensuring that sensitive data, such as personalor biometric information, is transmitted securely when digital credentialsare used for verification or identification. The integration of PKI in digi-tal credential systems thus helps create a secure and efficient alternative topaper-based credentials, facilitating the transition to fully digital ecosystemswhile maintaining high standards of trust and security.While PKI is a foundational technology for securing digital credentials,it is not without its challenges. One of the most significant issues is thecentralization of trust in CA, which could create a single point of failure.CAs are responsible for issuing and verifying digital certificates, ensuring thelegitimacy of digital credentials. However, this centralized trust model hasproven to be vulnerable, as numerous incidents have demonstrated the risksof over-reliance on CAs. A prominent example is the DigiNotar incident, inwhich a CA was hacked, leading to the erroneous issuance of a certificatefor âgoogle.comâ. This breach compromised the integrity of Googleâs digitalidentity, highlighting the fragility of centralized PKI systems [10]. Similarly,in the TrustWave incident, the CA accidentally issued a subordinate rootcertificate to a customer, granting them the authority to act as a CA them-selves. Such errors or attacks can undermine the entire trust structure ofPKI, leading to widespread vulnerabilities across systems that rely on digitalcredentials [11].Without transparency, the Man-in-the-Middle (MitM) attack also poseda threat to PKI and PKIX. Huang et al. [12] implemented a method todetect the occurrence of SSL man-in-the-middle attacks on a top globalwebsite, Facebook. 0.2% of over 3 million real-world SSL connections to thiswebsite were tampered with forged SSL certificates, most of them relatedto antivirus software and corporate-scale content filters. Even governmentagencies can be involved in breaching the security and privacy of Internetusers [13]. State-level adversaries have tried to intercept Internet user trafficin Kazakhstan [14]. The traffic interceptions of Internet users by differentgovernments and other powerful adversaries set a dangerous precedent.These incidents underscore a critical weakness in traditional PKI: the riskthat a compromised CA can cascade trust failures throughout the entire sys-tem. Although this vulnerability raises serious concerns for the security andreliability of digital credential systems that depend on PKI, it necessitates2the exploration of more decentralized and resilient approaches.Decentralized Public Key Infrastructure (DPKI) is an emerging modelfor identity verification and data security designed to address the central-ization issues present in traditional PKI. The core principle of DPKI is todistribute trust and management authority among multiple entities, therebyreducing single points of failure and the risk of abuse. DPKI utilizes decen-tralized technologies such as blockchain to allow each participant to managetheir identity information and public keys, enhancing transparency and se-curity. Although early DPKI systems like Keychains have been proposedsince 2006, based on Pretty Good Privacy (PGP) published in 1991 [15],there is no united definition of DPKI. PGP and similar software follow theOpenPGP standard (RFC 4880), an open standard for encrypting and de-crypting data which builds up a system that makes authentication entirelydecentralized. Each user in the system acts as an authority aiming to ensurelots of bindings between other users and their public keys. DPKI systemshave always developed along with PGP criteria, such as Certcoin [16, 17],Authcoin [18], and Instant Karma PKI (IKP) [4].However, these systems cannot avoid malicious users who generate largenumbers of false keys and connections. Trust in these DPKI systems shouldbe tested through time and cost without initial credit endorsement. What ismore, the missing incentives and the lack of punishments to motivate usersin the opposite make the system stick in the narrow range [19].1.2 Problem and ContributionDespite significant advancements in Decentralized Public Key Infras-tructure (DPKI), its application to digital credentials while adhering toX.509 standards remains underdeveloped. X.509, the widely used standardin traditional Public Key Infrastructure (PKI), relies on the certificate chainmodel to ensure authentication and integrity.Through a comprehensive survey of decentralized identity managementsystems and the implementation of PKI in blockchain technologies, it isevident that CA remains the central trust anchor in most PKI systems[20]. This also demonstrates the challenge of completely decentralizing iden-tity management while maintaining compliance with X.509 standards. Al-though there have been efforts to bridge this gap, such as the development ofProofchain [21], a blockchain-based DPKI system that follows X.509âs cer-tificate chain, its application to digital credentials is not mentioned. Limitedto a certain field, a system for mobile devices was presented [22], where the3identity of each device is predefined by the manufacturer or acquired bythe device from a CA based on some identity feature like the IP of the de-vice. This system, based on X.509v3 certificates, has several types of nodes,differentiating from validators to transactional nodes. Furthermore, whilesome decentralized systems like DeTract [23] attempt to use Ethereum-basedidentity platforms to create X.509-compliant certificates, they remain exper-imental and have yet to see widespread adoption.Although some research works attempted to combine X.509 and DPKIfor digital credentials, few related works are providing official and completeanalyses with concrete results. Trustchain, published by the Alan TuringInstitute [24], is an advanced state-of-the-art in this research gap. I furtherdive into this research gap and propose some potential solutions targeted atproblems remaining in the Trustchain baseline. Finally, I propose BCChainin this paper, which could alleviate 8 challenges classified from existing PKIsystems.BCChain is a blockchain-based, X.509-compatible decentralized publickey infrastructure (DPKI) designed to address critical challenges in digitalcredential management. Inspired by prior frameworks such as TrustChain,BCChain improves on existing designs by providing strong resilience againstkey security threatsâincluding CA compromise, man-in-the-middle attacks,and Sybil attacksâwhile maintaining interoperability with hierarchical PKI.The system enforces robust identity binding and uniqueness, ensures trans-parency through auditable on-chain credential records, and reduces opera-tional costs via a consortium-based embedded model. By integrating thesecapabilities, BCChain offers universities and credential-issuing institutions asecure, scalable, and practical solution for issuing, verifying, and managingdigital academic credentials, addressing both technological and administra-tive challenges. I will further explain the situations in Section 3.5.Thus, in my thesis, I summarize the research problems as follows. Cur-rent PKI and DPKI systems face multiple challenges. First, in terms ofresilience against attacks, they must address threats such as CA compro-mise, man-in-the-middle (MitM) attacks, and Sybil attacks. Second, re-garding X.509 compatibility, key considerations include the preservation oftrust anchors, the degree of decentralization, and transparency in creden-tial issuance and verification, ensuring that the system both aligns with es-tablished hierarchical trust models and leverages the benefits of distributedledgers. Third, for practical digital credential applications, challenges centeron strong identity binding and operational cost efficiency, emphasizing theneed for verifiable associations between real-world entities and their digitalidentifiers, as well as economically sustainable system deployment.4My thesis contribution can be concluded as:â I make a literature review on PKI systems, especially a detailed anal-ysis of Trustchain, and summarized 8 challenges faced with these sys-tems, which is underlined in Section 3.3 to Section 3.5.â I propose a new X.509-compatible DPKI framework BCChain, to filla research gap and advance the practical and secure deployment ad-dressing the 8 challenges, which is explained in Section 4.1.â I also provide an educational use case as a particular example to illus-trate and validate the potential of BCChain, shown in Section 4.2 &4.3.Due to the scope of this thesis, I only present a simulation of the appli-cation field and leave a full-scale prototype as my future work. The docu-mented and executable prototype describes the education use case shown inSection 4.3. The repository includes source code, simulation data, and step-by-step instructions for replicating the scenario where decentralized identi-fiers and blockchain-based credentials are used to manage academic recordsacross multiple institutions. The source code and implementation details ofthe proposed system can be found in the following GitHub repository, whichwill stay in update: BCChain GitHub Repository.1.3 Thesis OrganizationThe rest of the thesis is structured into fmy chapters that provide a com-prehensive exploration of the PKI and its applications in digital credentials,focusing on the shift towards DPKI.Chapter 2 provides a foundational overview of blockchain technology,detailing its components, consensus mechanisms, and the concept of de-centralized identifiers (DID), which are crucial to understanding how PKIcan be implemented in a decentralized system. Chapter 3 delves intothe PKI framework for digital credentials, explaining key components suchas the X.509 certificate structure, certificate chain model, and CertificateRevocation List (CRL). It also reviews the limitations of centralized PKIsystems when applied to digital credentials, highlighting challenges such ascentralization and vulnerability to single points of failure. Building on theselimitations, the chapter explores how DPKI can establish trust, with a focuson the few systems that are compatible with X.509 standards. Additionally,5Trustchain, a state-of-the-art system specifically designed for managing dig-ital credentials, is introduced in the latter part of the chapter. Finally, Isummarized 8 challenges of selected systems in two tables, evaluating theirperformance. According to their connection to digital credentials, they aredivided and analyzed in detail. Chapter 4 proposes a system called BC-Chain for implementing a decentralized identity solution based on DPKI.This chapter explains the system architecture, including the roles of MainDID, Sub DIDs, and a multi-root system, which could address the challengesin Chapter 3 to enhance the process of registration and trust building. Thischapter also provides a specific use case in the field of education to demon-strate the applicability of BCChain. Chapter 5 concludes the findings ofthe thesis and discusses future research directions.6Chapter 2Preliminaries2.1 Blockchain TechnologyBlockchain, initially introduced as the underlying technology behind Bit-coin in 2008 by an anonymous individual (or group) under the pseudonymSatoshi Nakamoto [25], has since evolved into a revolutionary frameworkfor distributed computing. Blockchain provides a decentralized, immutableledger where transactions or events are recorded chronologically and pub-licly without the need for intermediaries. Blockchainâs core innovation isits capacity to enable trustless interactions in a digital environment, thuseliminating the need for centralized authorities.Blockchainâs primary structure comprises blocks, which are batches ofdata, and a chain that links these blocks together via cryptographic hashes.Each block typically contains a collection of transactions, a timestamp, anonce, the hash of the previous block, and a cryptographic signature ensur-ing the integrity of the data. The system is resistant to tampering due tothe inherent difficulty of altering any information without simultaneouslyrehashing all subsequent blocks in the chain.2.1.1 Blockchain Definition and SignificanceâBlockchain is a shared, immutable ledger that facilitates the processof recording transactions and tracking assets in a business networkâ [26].This is one of the most popular definitions published by International Busi-ness Machines Corporation (IBM). From the academic angle, Stanford de-picts blockchain as âBlockchain, as its moniker suggests, is blocks of datalinked into an uneditable, digital chain. This information is stored in anopen-source decentralized environment, in which each blockâs informationis confirmable by every participating computerâ [27]. MIT Sloan assis-tant professor Christian Catalini, an expert in blockchain technologies andcryptocurrency, also says: âAt a high level, blockchain technology allows anetwork of computers to agree at regular intervals on the true state of adistributed ledger. Such ledgers can contain different types of shared data,7such as transaction records, attributes of transactions, credentials, or otherpieces of information. The ledger is often secured through a clever mix ofcryptography and game theory and does not require trusted nodes like tra-ditional networks. This is what allows Bitcoin to transfer value across theglobe without resorting to traditional intermediaries such as banks.â [28]But does blockchain really matter? The maintenance of peer-to-peer(P2P) ledgers for cryptocurrencies has become blockchainâs first breakthrough,or killer application of the technology. Following Bitcoinâs exponential risein market capitalization, thousands of cryptographic tokens, or coins, haveentered the public market. However, this rapid growth also gave rise toâair coinsââfraudulent projects that damaged blockchainâs reputation dueto the lack of legal regulation and auditing. This led to widespread skep-ticism regarding the true value of cryptocurrencies. Notably, billionaireinvestor Warren Buffett has been a vocal critic, predicting that cryptocur-rencies would âend badlyâ and famously describing Bitcoin as ârat poisonsquared.â [29]Rather than focusing solely on cryptocurrencies, rapidly evolving indus-tries are increasingly being shaped by the growing capabilities and trajec-tory of blockchain innovations [27, 28], especially developing decentralizedapplications (dApps), a novel software paradigm that harnesses the powerof blockchain [29]. Based on dApps, blockchain has been used in healthcare[30, 31], supply chain [32, 33], Internet of things (IoT) [34, 35], and even forAI [36]. Blockchain provides valuable decentralization, trust, transparency,security, and many other potentials in these applications.2.1.2 Blockchain ComponentsAlthough blockchain is born in Bitcoin [25], its technical roots are tiedto earlier developments in cryptography and distributed computing. In thissection, I look back on the components in a blockchain from their originto development, including block, node, consensus, hash function and smartcontract.Block:A block is the basic data structure in a blockchain that stores transac-tion data, a timestamp, a cryptographic hash of the previous block, and anonce. As shown in Figure 2.1, I introduce a block of the longest Proof-of-Work chain provided by Bitcoin. The transactions stored in a block are thecore of the blockchainâs functionality. Each transaction records the transfer8Figure 2.1: Blockchain and Merkle Tree, adapted from 25Note. Adapted from Bitcoin: A Peer-to-Peer Electronic Cash System, byS. Nakamoto, 2008, p.5. https://bitcoin.org/bitcoin.pdf. Copyright 2008by Satoshi Nakamoto. Reprinted with permission.of assets or data between participants and contains data fields such as thesender, receiver, amount, and any associated smart contracts. The times-tamp records when the block was created. It ensures that the blockchain ischronologically ordered and helps resolve issues such as double spending byensuring that transactions are processed in the correct sequence. The times-tamp feature of blockchain was derived from early cryptographic timestamp-ing systems developed in the 1990s. Haber and Stornettaâs work on securetimestamping laid the foundation for blockchainâs temporal verification sys-tem [37]. Each block contains the cryptographic hash of the previous blockin the chain. This forms a linked list of blocks, with each block referencingits predecessor. This chain structure ensures that any attempt to alter thecontent of a block would invalidate all subsequent blocks. The cryptographichash function used in Bitcoin (SHA-256) ensures that any small change inthe input data (such as a transaction) results in a completely different hash,making it computationally infeasible to alter the data without detection.The use of cryptographic hashes in a linked structure dates back to Merkletrees, which are used to organize and verify data efficiently [38]. The nonceis a variable number used in the Proof of Work (PoW) consensus algorithm[25]. Miners must find a nonce that, when combined with the block header,produces a hash that meets the networkâs difficulty target.9The concept of a block was integral to the original design of Bitcoinâsdistributed ledger. The first ever block, known as the Genesis Block, wasmined by Satoshi Nakamoto on January 3, 2009 [25]. This block marked thebeginning of the Bitcoin blockchain and contained a reward of 50 bitcoins,which remain unspent to this day. As blockchain technology has evolved,so too has the structure and complexity of blocks. Bitcoin introduced thesimplest block structure: a list of transactions secured by cryptographichashes. Each block is mined approximately every 10 minutes and contains apredefined block reward along with transaction fees as an incentive for min-ers. With the launch of Ethereum, blocks evolved to store not only financialtransactions but also smart contracts and dApp data. Ethereum blocks aremined every 10-15 seconds, and the addition of Gas as a measure of com-putational work has significantly altered how blocks handle data execution[39].The development of block size [40] in blockchain technology has evolvedsignificantly since Bitcoinâs introduction in 2009. Initially set at 1 MB tomitigate network abuse and maintain node efficiency, this limit became aconstraint as Bitcoinâs popularity surged, leading to congestion and risingtransaction fees. In response, the community explored various solutions,such as BIP 101, which proposed increasing the block size to 8 MB but lackedsupport. The introduction of Segregated Witness (SegWit) in 2017 allowedfor more transactions per block by separating transaction data. This periodalso saw the emergence of Bitcoin Cash (BCH), which raised the block sizelimit to 8 MB. In contrast, Ethereum uses a âGasâ mechanism rather thana fixed block size, enabling flexible transaction inclusion. Current trendsinclude the exploration of dynamic block sizes and sharding techniques innewer blockchain projects, aiming to enhance scalability without simplyincreasing block size limits.Node:A node refers to any active electronic device that participates in the net-work, contributing to its maintenance and functionality. Nodes are criticalcomponents of blockchain architectures, as they store, propagate, and vali-date transaction data. They can be classified into various types, includingfull nodes, light nodes, and mining nodes, each serving distinct purposeswithin the network. Full nodes maintain a complete copy of the blockchainledger. They validate and relay transactions and blocks, ensuring that allnetwork rules are followed. Full nodes enhance the network security and de-centralization, as they contribute to the overall consensus mechanism. Light10nodes [41], also known as SPV (Simplified Payment Verification) nodes,do not store the entire blockchain but instead maintain a subset of theblockchain data. They rely on full nodes for transaction verification and arecommonly used in mobile and lightweight applications due to their lowerresource requirements. Mining nodes are specialized nodes that competeto solve complex cryptographic puzzles, a process known as mining. Uponsuccessfully mining a block, they propagate the new block to the network,receive block rewards, and validate transactions within the block.As blockchain technology evolved, different types of nodes were devel-oped to address specific needs. The launch of Ethereum in 2015 expandedthe notion of nodes beyond simple transaction validation. Ethereum nodesalso support the execution of smart contracts, requiring additional resourcesand capabilities. Ethereumâs Unique Gas mechanism incentivized the devel-opment of diverse node types, including full nodes, light nodes, and miningnodes, with different responsibilities in executing smart contracts and main-taining the network [39]. With the rise of permissioned blockchains, suchas Hyperledger Fabric [42] and R3 Corda [43], the concept of nodes un-derwent further specialization. These blockchains introduced nodes withpredefined roles, including endorsing nodes, ordering nodes, and commit-ting nodes, each serving a specific function within a consortium network.This evolution highlights the adaptability of node architecture to meet therequirements of various use cases.Consensus Mechanism:A consensus mechanism is a protocol used in blockchain networks toachieve agreement among distributed nodes on the validity of transactionsand the state of the blockchain. It ensures that all participants in the net-work have a synchronized version of the blockchain, enabling trustless col-laboration without the need for a central authority. The choice of consensusmechanism directly influences the security, scalability, and decentralizationof a blockchain, making it a crucial aspect of blockchain design [44, 45]. Iwill introduce fmy kinds of the most famous consensus algorithms in the the-sis: Proof of Work (PoW), Proof of Stake (PoS), Byzantine Fault Tolerance(BFT), and Proof of Authority (PoA).The concept of PoW was introduced by Cynthia Dwork and Moni Naorin their paper âPricing via Processing or Combatting Junk Mailâ where theyproposed using computational work as a way to deter spam [46]. Adam Backintroduced the first implementation of PoW with his invention of Hashcash,a system designed to limit email spam by requiring proof of computational11effort [47]. Based on their research, Satoshi Nakamoto published the Bitcoinwhite paper, outlining the use of PoW as a consensus mechanism to securethe Bitcoin network and validate transactions [25]. As cryptocurrenciesgained popularity, PoW faced criticism for its significant energy consump-tion and environmental impact, leading to discussions about alternative con-sensus mechanisms. Meanwhile, the emergence of mining pools highlightedcentralization issues within PoW systems, as a small number of pools beganto dominate the mining landscape [44].The idea of PoS was introduced by Sunny King and Scott Nadal in PP-coin, proposing an energy-efficient alternative to PoW [48]. Vitalik Buterinutilized the new consensus, with an initial focus on using PoW but later tran-sitioning to PoS as part of its long-term vision for scalability and sustainabil-ity. Ethereum was launched as the first cryptocurrency to fully implementPoS, allowing users to validate transactions based on their stake rather thancomputational power [39]. However, due to the drawbacks in smart con-tracts, scandals like the DAO forced Ethereum to transit to Ethereum 2.0,moving from PoW to a hybrid PoW/PoS model, aiming for improved scal-ability and reduced energy consumption.Even before blockchain, the Byzantine Generalsâ Problem has been widelyacknowledged as a foundational concept in distributed computing, high-lighting the inherent challenges of achieving consensus among unreliablenodes [49]. To address these challenges, Practical Byzantine Fault Toler-ance (PBFT) was proposed, providing a robust framework for consensus indistributed systems, even in the presence of malicious actors [50]. PBFT canachieve consensus as long as less than one-third of the nodes are faulty, andfaced with arbitrary failures such as nodes behaving maliciously or send-ing conflicting information. PBFT has gained significant traction withinthe blockchain community, particularly in permissioned blockchains wherethe participants are known and trusted. Notably, Hyperledger Fabric hasadopted BFT concepts to enhance its security and reliability. Subsequently,the introduction of Tendermint, a BFT consensus algorithm, marked a crit-ical advancement by combining the benefits of PBFT with blockchain tech-nology, thereby facilitating faster finality and improved scalability [51]. Ad-ditionally, Tezos has utilized BFT algorithms to achieve consensus whileemphasizing the trade-off between decentralization and scalability [52].PoA emerged as a consensus mechanism primarily for private and con-sortium blockchains [53], where a limited number of trusted nodes (author-ities) validate transactions. The concept was popularized by projects likeEthereumâs Clique and Aura consensus algorithms. PoA relies on a limitednumber of trusted validators to secure the network and validate transactions.12Unlike PoW and PoS, which depend on computational power or economicstakes, PoA operates on the principle of trust and identity, as validators areknown entities with reputations to uphold. This mechanism enables hightransaction throughput and low latency, making it more energy-efficientcompared to PoW. However, PoA raises concerns about centralization, asa small group of validators controls the consensus process. It is commonlyused in permissioned blockchains and private networks where trust amongparticipants is established, making it suitable for applications requiring fastand efficient transaction processing. In Proofchain [21], an X.509 compatibleDPKI designed for IoT, it introduced Proof of Issuance, where CertificateAuthorities function as the trusted miners similar in PoA.Cryptographic HashingCryptographic hashing is a fundamental process in computer science andinformation security that transforms input data of arbitrary size into a fixed-length string of characters, known as a hash value or digest. This uniqueoutput is intricately linked to the input data; even the slightest modificationto the inputâsuch as changing a single bitâproduces a completely differenthash. This property, known as the avalanche effect, is crucial for ensuringdata integrity and security in various applications.The concept of cryptographic hashing was first formalized in the 1970s,with early algorithms such as MD5 (Message-Digest Algorithm 5) [54] andSHA-1 (Secure Hash Algorithm 1) [55] emerging during this period. How-ever, as vulnerabilities in these algorithms were discovered, particularly re-garding collision resistance (the likelihood that two different inputs producethe same hash), the need for more secure alternatives became evident. Thisled to the development of enhanced hashing algorithms, such as SHA-256,which is part of the SHA-2 family and is widely utilized in Bitcoin and otherblockchain technologies due to its robust security features and resistance topre-image and collision attacks [55].Cryptographic hashing serves multiple purposes in securing blockchaintransactions. It plays a pivotal role in maintaining data integrity, as anyalteration to the original data will yield a different hash, thereby signalingpotential tampering. Furthermore, cryptographic hashes are essential for thecreation of digital signatures, which authenticate the identity of the senderand ensure that the message has not been altered during transmission. Insmart contracts, hashing is employed to securely store and verify contractstates and transaction history on the blockchain.13Smart ContractSmart contracts are self-executing contracts with the terms of the agree-ment directly written into code, enabling automatic execution when pre-defined conditions are met [56]. The concept of smart contracts was firstintroduced by Nick Szabo in 1996, who envisioned them as a means to facil-itate, verify, or enforce the negotiation or performance of a contract throughcomputer code, thereby reducing the need for intermediaries and enhancingefficiency in various transactional processes [56]. In other word, a smartcontract is a self-executing program that automatically enforces rules andagreements between parties on a blockchain, without requiring intermedi-aries.Despite Szaboâs pioneering work, it was not until the launch of Ethereumin 2015 that smart contracts transitioned from a theoretical framework to apractical reality [39]. Ethereum introduced the Ethereum Virtual Machine(EVM), a decentralized computing environment specifically designed to ex-ecute smart contracts on the blockchain. The EVM allows developers towrite complex contracts using high-level programming languages, such asSolidity, which are then compiled into bytecode that the EVM can interpretand execute. This innovation not only facilitated the creation of decentral-ized applications (dApps) but also enabled the automation of various pro-cesses across industries, from finance to supply chain management. SinceEthereumâs introduction, smart contracts have been implemented across nu-merous other blockchain networks, such as EOS [57], Binance Smart Chain[58], and Polkadot [59]. Each of these platforms has sought to enhance thefunctionality and efficiency of smart contracts, addressing challenges suchas scalability, security, and interoperability. For instance, EOS focuses onhigh transaction throughput and low latency, while Polkadot aims to enableseamless communication between different blockchains through its uniquearchitecture.2.1.3 Property of BlockchainBlockchain technology is characterized by several fundamental attributesthat collectively enhance its functionality and appeal across various sectors.These attributesâDecentralization, Transparency, Immutability, Security,and Anonymityâplay critical roles in establishing trust, enhancing dataintegrity, and ensuring privacy within the network. By understanding thesecharacteristics, I can appreciate how blockchain distinguishes itself fromtraditional systems and enables innovative applications [29] in fields such14as finance, supply chain management, healthcare, and more. Each of theseattributes contributes to the overarching goal of creating a more efficient,secure, and trustworthy digital ecosystem, making them essential to theongoing evolution and adoption of blockchain technology.DecentralizationDecentralization refers to the distribution of authority, control, anddecision-making across a network rather than relying on a central authority[18, 29]. In the context of blockchain, this means that no single entity hascontrol over the entire network; instead, power is shared among all partici-pants, who validate transactions and maintain the integrity of the ledger.Blockchain applies a distributed ledger, where copies of the entire blockchainare maintained by multiple nodes across the network. Each node partici-pates in the validation of transactions, contributing to a consensus mech-anism (e.g., Proof of Work or Proof of Stake) to agree on the state of theblockchain. This ensures that even if some nodes go offline or become com-promised, the overall network remains operational and secure. The decen-tralized nature of blockchain also prevents censorship and reduces the risksassociated with a single point of failure, enhancing the systemâs resilience.Decentralization fosters trust among participants. Since there is no cen-tral authority, users do not need to place their trust in a single entity;instead, they can rely on the collective agreement of the network. Thiscan lead to greater transparency and fairness, particularly in systems wherepower dynamics can lead to corruption or abuse. Additionally, decentral-ization can enhance privacy by allowing users to interact directly with oneanother without intermediaries, thereby reducing the risk of data breachesor misuse of personal information.TransparencyTransparency in blockchain refers to the principle that all transactionsand data stored on the blockchain are visible and accessible to all partici-pants in the network [25]. This characteristic allows stakeholders to audittransactions, verify the integrity of the data, and foster trust among users.In the public ledger system, where every transaction is recorded in a waythat can be viewed by anyone with access to the blockchain. For instance, inpublic blockchains like Bitcoin and Ethereum, all transaction histories areavailable for anyone to inspect. This feature is facilitated by cryptographichashing and the structure of blocks, which link together in a chronological15chain. Once data is added to the blockchain, it cannot be altered or deletedwithout altering all subsequent blocks, making any fraudulent changes easilydetectable. It enhances accountability by allowing stakeholders to track theprovenance of assets, such as tracking supply chains to verify the authen-ticity of products [32, 33]. It also plays a crucial role in reducing fraud andcorruption [7], as the immutable nature of the blockchain ensures that oncea transaction is recorded, it cannot be modified without consensus from thenetwork. Furthermore, transparency fosters user trust, as individuals canindependently verify the legitimacy of transactions without needing to relyon a third party, which is particularly beneficial in industries such as finance,healthcare, and logistics.ImmutabilityImmutability means once data has been recorded on the blockchain, itcannot be altered or deleted. This characteristic is fundamental to the trustand reliability that blockchain technology offers [25, 39].Through a combination of cryptographic hashing and the decentralizednature of the blockchain network. Each block in a blockchain contains aunique hash of the previous block, along with a timestamp and transactiondata. This creates a chain of blocks that is inherently linked. If someoneattempts to alter a blockâs data, it would change the blockâs hash, thusbreaking the chain. Because the majority of nodes in the network mustagree on the validity of the blockchain (a process often referred to as con-sensus), any unauthorized changes would require altering all subsequentblocks and gaining control over a majority of the network, which is compu-tationally infeasible in large public blockchains. Immutability is significantin various applications. For instance, in financial transactions, the inabilityto alter transaction records prevents fraud and unauthorized modifications.In supply chain management, immutability ensures that records of prod-uct provenance remain intact, providing consumers with confidence in theauthenticity of goods. Furthermore, immutability can play a vital role inlegal contexts, where maintaining accurate records is crucial for regulatorycompliance and dispute resolution.SecurityBlockchain technology embodies a strong commitment to security, whichis fundamental to its function and acceptance across various sectors [5, 55].At its core, security encompasses a range of measures designed to safeguard16data and ensure that operations are conducted without interference or unau-thorized access. This security is achieved through advanced cryptographictechniques, robust consensus mechanisms, and a decentralized architecture.Cryptography plays a pivotal role, enabling secure data encryption thatprotects sensitive information from unauthorized access. Public key cryptog-raphy, for instance, allows users to create a unique pair of keysâone publicand one private. The public key can be shared freely, while the private keyremains confidential, and used solely for signing transactions. This mech-anism ensures that only the intended recipient can access the information,enhancing trust in the system.Moreover, consensus mechanisms such as PoW and PoS further bolstersecurity by requiring network participants to validate transactions beforethey can be added to the blockchain. This validation process mitigatesthe risk of manipulation, as any malicious actor would need to control asignificant portion of the networkâs computational power or stake, makingit increasingly difficult to execute fraudulent activities.The decentralized nature of blockchain also contributes significantly toits security. Data is distributed across numerous nodes, ensuring that nosingle entity can exert control over the entire network. This redundancyimplies that even if some nodes are compromised, the overall integrity of theblockchain remains intact. Such a distributed approach not only enhancessecurity but also fosters greater trust among users.The implications of blockchain security are profound, influencing vari-ous industries. In finance, for example, secure transaction protocols reducethe risk of fraud and identity theft, thereby instilling confidence in digi-tal currencies and decentralized finance platforms. In healthcare, securedata management systems protect patient information, ensuring compliancewith regulations like the Health Insurance Portability and AccountabilityAct (HIPAA) [31]. Additionally, in supply chain management, enhancedsecurity measures facilitate accurate product tracing, helping to preventcounterfeiting and improve transparency.AnonymityAnonymity in blockchain refers to the degree to which the identities ofparticipants in a transaction can be concealed. This attribute is particularlyimportant in ensuring privacy and protecting usersâ identities in a decentral-ized environment. Unlike traditional financial systems, where transactionsare tied to identifiable accounts, blockchain can provide a level of anonymityby using cryptographic techniques that obscure user identities while still al-17lowing for secure transactions.In blockchain networks, transactions are typically recorded with a publicaddress rather than personal information, making it difficult to trace theidentity of the individual behind a transaction. For instance, in Bitcoin,transactions are recorded on a public ledger that anyone can access, but theaddresses used in these transactions do not reveal the identities of the users.This pseudonymous nature offers a degree of anonymity, allowing users toconduct transactions without disclosing their personal information.The significance of anonymity in blockchain extends beyond individ-ual privacy concerns. It also plays a vital role in fostering trust amongusers, particularly in contexts where participants may not know each other.Anonymity can encourage participation in decentralized applications andfinancial services, as users feel more secure knowing their identities are pro-tected. However, this characteristic can also be a double-edged sword, as ithas raised concerns about facilitating illicit activities such as money laun-dering and fraud.To enhance anonymity, some blockchain protocols have implemented ad-vanced cryptographic techniques. For example, privacy-focused cryptocur-rencies like Monero and Zcash utilize technologies such as ring signaturesand zero-knowledge proofs to ensure that transactions remain confidential,making it nearly impossible to link them to specific users or addresses.2.2 Decentralized Identifier2.2.1 Basic ConceptDecentralized Identifiers (DIDs) represent a new class of identifiers de-signed to enable verifiable, self-sovereign digital identities. Unlike traditionalidentifiers, which are often tied to centralized authorities (like government-issued IDs or social media accounts), DIDs function independently of theseentities. They provide individuals with control over their own identities,allowing them to create, manage, and share their identifiers without relyingon a central authority.The W3C (World Wide Web Consortium) defines DIDs as A globallyunique persistent identifier that does not require a centralized registrationauthority [60]. A DID is a globally unique identifier that is created, owned,and controlled by the subject of the identifier, which could be a person,organization, or device. This design empowers users to manage their ownidentity data securely and privately.18The concept of DIDs has evolved alongside advancements in blockchaintechnology and the increasing need for privacy and security in digital inter-actions. The notion of self-sovereign identity (SSI) began gaining tractionin the early 2010s as a response to growing concerns about data privacy andsecurity in centralized systems. Influential work by thought leaders suchas Dr. Christopher Allen emphasized the importance of user control overidentity [61]. In 2019, the W3C formed a Decentralized Identifiers WorkingGroup to standardize DIDs and related technologies. This initiative aimedto provide guidelines for implementing DIDs in a way that fosters interoper-ability across different platforms and use cases [60]. Since the introductionof the W3C specification, various projects and organizations have startedimplementing DIDs, including Hyperledger Indy [62], Sovrin [63], and Mi-crosoftâs Azure Active Directory [64]. These implementations demonstratethe versatility of DIDs in various applications, from digital identity verifica-tion to supply chain management.2.2.2 ComponentsAccording to W3C criteria, a Decentralized Identifier (DID) system pro-vides a framework for self-sovereign identity management on distributedledgers, enabling entities to control their identifiers and credentials withoutreliance on centralized authorities. At the core of a DID system is the DIDsubject, which can represent an individual, organization, or device. EachDID uniquely identifies its subject in a globally resolvable manner. Asso-ciated with each DID is a DID document, a structured JSON-based dataobject that contains essential metadata and cryptographic material. TheDID document typically includes public keys for authentication and digitalsignature verification, service endpoints through which the DID subject caninteract with other entities, and defined authentication methods specifyinghow control over the DID can be demonstrated.The DID registry or ledger acts as the underlying distributed database,storing mappings between DIDs and their corresponding DID documents.This ledger provides immutability, transparency, and tamper resistance, sup-porting operations such as creation, updates, and deactivation of DIDs.Within the system, verifiers or relying parties utilize the DID registry toretrieve DID documents and validate the associated cryptographic proofs,ensuring the authenticity of credentials or identity claims. Issuers, on theother hand, are organizations or individuals that provide verifiable creden-tials to DID subjects; these credentials are cryptographically signed andmay be stored off-chain while their integrity is verifiable via the DID doc-19ument. Underlying all interactions is a cryptographic layer, which ensuresauthenticity, integrity, and privacy through digital signatures, encryption,and optionally zero-knowledge proofs.DID and DID URLA Decentralized Identifier, or DID, is composed of three parts: thescheme did, a method identifier, and a unique, method-specific identifierspecified by the DID method. DIDs are resolvable to DID documents. ADID URL extends the syntax of a basic DID to incorporate other standardURI components such as path, query, and fragment to locate a particularresourceâfor example, a cryptographic public key inside a DID document,or a resource external to the DID document.DID SubjectThe DID subject refers to the entity (an individual, organization, orthing) to which the DID refers. This is the entity whose identity is beingrepresented in the decentralized system.DID DocumentThe DID document contains metadata about the DID subject, includ-ing cryptographic material such as public keys, authentication methods, andservice endpoints. These elements help in verifying the DID subjectâs iden-tity and establish trust between parties interacting with the DID. The DIDdocument is an essential part of DID architecture, as it provides the infor-mation necessary to perform cryptographic verifications and enable secureinteractions.DID ControllersThe DID controller is the entity (or entities) with the authority to controland update the DID document. This may or may not be the same as theDID subject. A DID controller can rotate the keys associated with the DID,revoke or re-issue credentials, and update the service endpoints listed in theDID document.Verifiable CredentialsVerifiable credentials are digital representations of claims made by anissuer about a subject. They contain cryptographic proofs and allow the20verification of identity or specific attributes without compromising privacy.These credentials are attached to DIDs and are used in many decentralizedidentity systems to enable trust without involving third parties.DID RegistryThe DID registry is the mechanism through which a DID is resolved to itscorresponding DID document. DID registries are the decentralized systems(often blockchain-based) that store and manage DIDs. The resolver ensuresthat when a DID is queried, the appropriate DID document is retrievedfrom the network, allowing other parties to interact with the DID subjectsecurely.21Chapter 3Public Key Infrastructure forDigital Credential3.1 Public Key InfrastructurePublic Key Infrastructure (PKI) was introduced in 1988 by the Inter-national Telecommunication Union (ITU-T, formerly CCITT). Since thesecond edition of the X.509 Recommendation in 1993, PKI is based on animproved version 2 by ITU-T and ISO/IEC. However, the most widely rec-ognized definition of PKI is articulated in its third version [1â3], whichpresents PKI as a comprehensive framework encompassing the technologies,policies, and procedures necessary for the management of digital certifi-cates and cryptographic keys. This definition has an updated version inother authoritative agencies. The National Institute of Standards and Tech-nology (NIST) describes PKI as the combination of software, encryptiontechnologies, and services that enables enterprises to protect the securityof their communications and business transactions on networks [65]. TheInternational Organization for Standardization defines PKI as a structureof hardware, software, people, processes, and policies that employ digitalsignature technology to facilitate a verifiable association between the publiccomponent of an asymmetric public key pair with a specific subscriber thatpossesses the corresponding private key [2].PKI plays a critical role in securing communication, verifying the identi-ties of users and entities, and safeguarding the integrity and confidentialityof data in a networked environment. PKI relies on asymmetric cryptography,which employs a pair of keys: a public key and a private key. The public keyis widely distributed and used for encryption and verification of digital sig-natures, while the private key, kept confidential, is used for decryption andthe creation of digital signatures. Key concepts and functionalities withinPKI include certificates, certificate authorities, and the secure exchange ofcryptographic keys. The necessary concepts and functionalities of PKI are:Key Pair Generation: The process begins with the generation of a cryp-22tographic key pair, which consists of a public key and a corresponding privatekey. The public key is designed for open distribution, allowing it to be sharedfreely with others, while the private key is kept confidential by the user orentity. This key pair serves as the foundation of secure communicationswithin the PKI framework.Certificate Authority (CA): A Certificate Authority (CA) is a trustedthird-party organization responsible for issuing digital certificates. Thesecertificates bind the public key to specific entities, providing crucial infor-mation about the certificate holder, including their identity and the cer-tificateâs expiration date. To ensure the integrity and authenticity of thesecertificates, the CA digitally signs them, establishing trust in the associationbetween the public key and its owner.Certificate Distribution: Digital certificates are disseminated to users orentities within the PKI ecosystem. When one party intends to communicatesecurely or verify another partyâs identity, they refer to the recipientâs publickey contained within the certificate. This distribution mechanism is essentialfor establishing secure connections and trust relationships among users.Encryption and Digital Signatures: Public keys are employed for twoprimary security functionalities: encryption of sensitive information andverification of digital signatures. Data encrypted using the recipientâs pub-lic key can only be decrypted with the corresponding private key, ensur-ing confidentiality during transmission. Additionally, digital signatures aregenerated using the senderâs private key, allowing recipients to verify thesignature using the senderâs public key. This process guarantees both theintegrity of the message and the authenticity of the sender.Revocation and Renewal: Digital certificates possess a finite validity pe-riod, necessitating mechanisms for revocation and renewal. If a private keyis compromised or lost, the associated certificate must be revoked to preventunauthorized access. Certificate Revocation Lists (CRLs) and the OnlineCertificate Status Protocol (OCSP) are employed to ascertain the validitystatus of certificates, providing a way to check whether a certificate is stillvalid or has been revoked. Additionally, certificates can be renewed uponexpiration to maintain continuity in secure communications.3.1.1 X.509 CertificateThe X.509 standard proposed by ITU is the best-known framework forpublic-key and attribute certificates upon which full services in a hierar-chical authentication structure can be based [3]. It plays a significant rolein interconnecting open systems and allows, with a minimum of technical23agreement outside of this standard, the interconnection of information pro-cessing systems from different manufacturers, under different managements,of different levels of complexity, and of different ages [3].X.509 Public-Key Infrastructure (PKIX) is also known as the InternetPKI/Web PKI. The necessary components consist of X.509 certificate struc-ture, certificate chain, and certificate revocation list (CRL). An X.509 cer-tificate should possess version, serial number, signature, issuer, validity, sub-ject, subject public key info, signature algorithm, optional unique ID, andextensions.Version: This field indicates the version of the X.509 certificate formatbeing used. It is crucial as it defines the structure of the certificate andwhich features are available. X.509 currently has three versions (v1, v2, andv3), with v3 being the most widely used due to its support for extensions.Serial Number: A unique identifier assigned by the certificate authority(CA) to each certificate it issues. The serial number serves to uniquely iden-tify the certificate within the CAâs domain and is essential for the revocationprocess, allowing users and systems to identify and manage certificates ef-fectively.Signature Algorithm: This specifies the algorithm used by the CA to signthe certificate, including both the hashing algorithm (e.g., SHA-256) andthe encryption algorithm (e.g., RSA). This field is critical for ensuring theintegrity and authenticity of the certificate, providing a method for verifyingthat it has not been tampered with and is indeed issued by the trusted CA.Issuer: This field contains the distinguished name (DN) of the CA thatissued the certificate, providing information such as the common name (CN),organization (O), and country (C). The issuer field identifies the authoritythat vouches for the identity of the certificate holder, establishing the trustrelationship between the user and the CA.Validity: This section consists of two fields: Not Before, which indicatesthe date and time when the certificate becomes valid, and Not After, whichspecifies the expiration date and time of the certificate. The validity periodis essential for maintaining the security of digital communications, ensuringthat certificates are periodically renewed, and mitigating risks associatedwith expired or outdated certificates.Subject: This is the DN of the entity that the certificate represents,which may include attributes like CN, O, OU (organizational unit), and C.The subject field associates the public key contained within the certificatewith a specific entity, thereby verifying the identity of the owner.Subject Public Key Info: This section provides the public key of thesubject and the algorithm associated with it, including the public key algo-24rithm (e.g., RSA, DSA) and the actual public key itself, encoded in a formatspecified by the algorithm. This field is fundamental for establishing securecommunication, allowing other parties to encrypt messages for the subjector verify signatures generated by the subjectâs private key.Issuer Unique Identifier (optional): A unique identifier for the issuerincluded in versions 2 and 3 of the X.509 standard. This field helps differen-tiate between different issuers that may have similar names, enhancing thespecificity of the issuer identification.Subject Unique Identifier (optional): A unique identifier for the subject,also included in versions 2 and 3. This field provides additional specificity,particularly useful in cases where the subjectâs DN may change over time.Extensions (optional): In X.509 version 3, certificates can contain var-ious extensions that provide additional information or constraints on thecertificate. Examples include Key Usage, which specifies the intended pur-poses of the public key (e.g., digital signature, key encipherment); ExtendedKey Usage, which refines the key usage to specific applications (e.g., serverauthentication); Subject Alternative Name, which lists alternative identi-fiers for the subject (e.g., DNS names, IP addresses); and Basic Constraints,which indicates whether the certificate is a CA certificate and the maximumdepth of valid certification paths. Extensions enhance the functionality andusability of the certificate, allowing for more specific applications and provid-ing a mechanism for conveying additional policies or requirements associatedwith the certificate.Signature: The digital signature generated by the CAâs private key,which covers the entire certificateâs content. This field is vital for ensur-ing the integrity and authenticity of the certificate, allowing recipients toverify that it has not been altered and that it was issued by a legitimateCA.X.509 certificates play a pivotal role in securing digital communicationsand are widely applied across various industries to ensure authentication,encryption, and data integrity. One of the most common and visible usesin securing HTTPS connections, which are essential for web browsing. Forinstance, Google uses X.509 certificates to enable encrypted but transpar-ent communication between users and its services [66]. The SSL/TLS cer-tificates based on X.509 standards allow web browsers to authenticate theGoogle server, ensuring that users are securely connected to the legitimatesite and that data transmitted between the user and Google is encrypted.This prevents attackers from intercepting sensitive information like logincredentials or personal data.In addition to web security, X.509 certificates are fundamental in other25real-world applications, such as email security [67], where they are used tosign and encrypt emails, ensuring the senderâs identity and the messageâsconfidentiality. Large corporations, including Microsoft [68] and Apple [69],rely on X.509 certificates for securing internal communications and verify-ing software integrity via code signing certificates, which ensure that down-loaded software is from a trusted source and has not been tampered with.X.509âs flexibility and widespread support in securing both internet com-munications and internal enterprise environments make it a foundationalcomponent in modern digital security infrastructure.3.1.2 Certificate ChainThe initial definition of Certificate Chain in X.509 originated from cer-tification paths and trust [1], where a chain of multiple certificates may beneeded, comprising a certificate of the public key owner (the end entity)signed by one CA, and zero or more additional certificates of CAs signedby other CAs. Such chains, called certification paths, are required becausea public key user is only initialized with a limited number of assured CApublic keys.Certificate paths share the meaning of certificate chain which has beenresearched since 2001 [70]. Consider the following typical scenario: A client,Alice, attempts to access a resource, unaware that it is protected by anaccess control mechanism. The server responds, indicating that access willonly be granted if Alice can prove her membership in one of the predefinedgroups, specifically G1, G2, or G3. In this case, the access control list (ACL)governing the resource stipulates that access is restricted to members of thesegroups. Alice possesses a set of certificates that she can use to establish hercredentials. She locates two relevant certificates: the first, C1, asserts thatall members of group H are also members of group G2, and the second, C2,attests that she, identified by her public key, is a member of group H. Bycombining these certificates, Alice constructs a certificate chain, (C1, C2),which serves as proof of her eligibility to access the protected resource. Shetransmits this certificate chain to the server, signing the request with herprivate key, thereby authenticating her identity and gaining the necessaryaccess [70].DigiCert Knowledge Base, a leading CA trusted globally for issuing dig-ital certificates, is widely recognized for its security expertise. It providespractical guidance on certificate installation, troubleshooting, and under-standing various aspects of digital security. In their definition, A certificatechain is an ordered list of certificates, containing an SSL/TLS Certificate26and CA Certificates, that enables the receiver to verify that the sender andall CAs are trustworthy. As shown in Figure 3.1, it illustrates the processfrom the certificate owner to the Root CA, and the chain terminates with aRoot CA Certificate. The signatures of all certificates in the chain must beverified up to the Root CA Certificate. In their illustration, they also men-tioned a definition called chain of trust, which is also used as a substitutefor certificate chain [20, 71]. This figure provides an intuitive understandingof how trust is established, propagated, and verified in traditional PKI sys-tems, which is particularly valuable for the present study, as BCChain aimsto retain compatibility with X.509 while transitioning to a decentralizedframework. Understanding the conventional chain of trust enables readersto appreciate how BCChain modifies and extends this model by distributingtrust across a consortium of DID roots, enhancing resilience against singlepoints of failure and unauthorized issuance. Consequently, the figure is notmerely illustrative; it serves as a conceptual anchor, linking the traditionalhierarchical trust mechanisms with the innovations introduced in BCChain.Figure 3.1: Certificate Chain Path, adopted from 72Note. Adopted from How certificate chains work, by Digicert, 2023.https://knowledge.digicert.com/solution/how-certificate-chains-work.Copyright 2023 by Digicert. Reprinted with permission.273.1.3 Certificate Revocation ListA CRL is a time-stamped, digitally signed document issued by a CAor designated CRL issuer that enumerates certificates revoked before theirexpiration [1]. Each revoked certificate is uniquely identified within theCRL by its serial number. In systems that rely on certificates for securitypurposes, such as verifying digital signatures, the certificate-using systemmust not only validate the signature and ensure the certificate is withinits validity period but also consult a recent CRL to ensure the certificateâsserial number is not listed as revoked. The term âsuitably recentâ is gener-ally defined by local security policies but typically refers to the latest CRLavailable. CRLs are generated and published at regular intervalsâsuch ashourly, daily, or weeklyâto ensure up-to-date information about revokedcertificates. When a certificate is revoked, its serial number is added to thenext scheduled CRL update. Importantly, once a certificate is added to theCRL, it must remain on the list until the certificateâs validity period hasexpired and it has appeared on at least one regularly issued CRL after thisexpiration. This ensures the thoroughness and reliability of the revocationprocess.In addition to CRLs, there are various structures designed to handle cer-tificate revocation: Certificate Revocation System (CRS), Certificate Revo-cation Trees (CRT), and Online Certificate Status Protocol (OCSP). CRSwas introduced by Silvio Micali in 1995 [73]. This system employs onlineand offline signatures to provide certificate status updates. In 1996, Micalirefined the CRS concept to focus on revocation status [74] and was awardeda patent for the system in 1998 [75]. CRS operates by mixing both posi-tive and negative lists, offering direct evidence regarding certificate validity.When a user queries the status of a certificate, they receive a short, individ-ualized response concerning that specific certificate. The system is versatileand can function either online or offline, depending on the scheduling andthe need for up-to-date information. Another structure is CRT, introducedby Paul Kocher in 1998 [76, 77]. CRTs utilize hash trees to maintain neg-ative lists of revoked certificates while also supporting information aboutcertificates that remain valid, creating a hybrid approach. Valid certificatesare mapped to specific validity intervals, offering direct evidence of theirstatus. Lastly, OCSP, developed by the IETF [78], is a widely used pro-tocol for checking the real-time validity of X.509 certificates. OCSP allowsfor faster, more timely revocation status updates than CRLs, and it can beused as a standalone solution or in conjunction with CRLs. The protocol isdesigned specifically for X.509 certificates but may also support other cer-28tificate types. The status query information is often embedded within theextension fields of the X.509 certificate itself.These systemsâCRS, CRT, and OCSPârepresent diverse approachesto improving the efficiency and reliability of certificate revocation processes.3.2 Digital CredentialThe focus of this work on digital credentials, rather than other PKIapplications, is motivated by both practical and theoretical considerations.Digital credentials enable the verifiable binding of cryptographic identitiesto real-world entities, providing a robust mechanism for authentication, au-thorization, and trust management across diverse domains such as highereducation, professional certification, and governmental services [9]. Unliketraditional PKI, which primarily facilitates secure key exchange, digital cre-dentials convey semantic information about an individualâs qualifications orrights, making identity binding and uniqueness critical. Existing systemsoften exhibit significant deficiencies in this regard, including vulnerabilityto Sybil attacks, insufficient transparency, and high operational costs, whilesimultaneously struggling to maintain compatibility with established trustmodels such as X.509. These limitations are particularly salient in the con-text of education and credential verification, where the integrity, authentic-ity, and auditability of digital identities directly impact institutional trustand operational efficiency. By addressing these challenges, the proposedBCChain framework provides a secure, auditable, and cost-efficient infras-tructure for issuing, verifying, and managing digital credentials, therebyoffering clear value to universities, employers, and regulatory bodies thatrely on trustworthy digital identity assertions.3.2.1 Definition of Digital CredentialDigital Credentials are defined in different meanings according to fields.The Government of Canada defined digital credentials [79] as âthe electronicequivalent of physical documents that citizens already had like driverâs li-cense or health card. Citizens would be able to use them during servicetransactions without having to show up in person or rely on partially paper-based processes, such as taking a photo or scanning important documentsâ.International Business Machines Corporation (IBM) is one of the largestand most influential technology companies globally, known for its extensiverange of products and services in computing, artificial intelligence, cloud29computing, and cybersecurity. IBM Verify proposed that âDigital Creden-tials, also known as verifiable credentials, offer a secure and instant way toverify identity without the hassle of paper documentsâ [80].In academia, Brands [81] provided a technical overview of digital creden-tials in 2002, defining them as the digital equivalents of paper documents,plastic tokens, and other tangible objects issued by trusted parties.Despite the long-standing public acceptance of digital credentials, theterm is rarely used in conjunction with PKI. Researchers often favor alter-native definitions, such as digital identity, verifiable credentials, or digitalcertificates [6, 7, 19, 24].Digital Credential versus Digital IdentityâDigital Identity contains data that uniquely describes a person or thing(called the subject or entity in the language of digital identity) but alsocontains information about the subjectâs relationships to other entities.â[82]Digital identity and digital credentials exhibit a complex, symbiotic re-lationship within modern digital trust frameworks. While digital identityserves as the foundational layer that establishes the unique existence of anentity within digital ecosystems, digital credentials function as the dynamicattestation layer that enriches and validates this identity through verifiableclaims. This hierarchical yet interconnected relationship manifests in severalcrucial ways: First, digital identity acts as an anchor point for credentialissuance and verification, providing the necessary context and trust foun-dation upon which credentials can be meaningfully assigned and validated.Conversely, digital credentials enhance and elaborate upon the base iden-tity by providing granular, verifiable attestations about specific attributes,qualifications, or entitlements of the identity holder. This complementaryrelationship creates a robust framework where identity provides persistenceand uniqueness, while credentials offer flexibility and context-specific verifi-cation capabilities.The integration of these two elements enables sophisticated identity man-agement systems that can support both persistent identity verification anddynamic attribute attestation. For instance, when a digital identity is es-tablished through a DID, it can serve as the persistent subject for multiplecredentials, each attesting to different aspects of the entityâs capabilitiesor characteristics. These credentials, while independently verifiable, de-rive their fuller meaning and trustworthiness from their association witha well-established digital identity. Furthermore, the aggregation of creden-30tials associated with an identity can, over time, contribute to the identityâsreputation and trust level, demonstrating how credentials can recursivelystrengthen the underlying identity framework. This is why I also need toconsider works using digital identity with PKI.Digital Credential versus Verifiable CredentialIn W3C [60], verifiable credentials refer to a credential that can be veri-fied by a verifier, and the credential should represent all of the same informa-tion that a physical credential represents. Due to its application field, VCsare always seen as the digital credentials especially used in decentralizedscenarios [83].While digital credentials encompass all forms of digitally represented at-testations, VCs specifically adhere to the W3C Verifiable Credentials DataModel, which ensures standardized formatting, cryptographic verifiability,and decentralized verification capabilities. This distinction is particularlysignificant in decentralized scenarios, where verifiable credentials have emergedas the predominant implementation of digital credentials due to their inher-ent support for trustless verification and privacy-preserving features. Therelationship between these credential types reflects the evolution of digitalattestation systems from simple digital representations toward more sophis-ticated, cryptographically secured formats that enable autonomous verifi-cation without relying on centralized authorities. As the digital identitylandscape continues to evolve, verifiable credentials have become increas-ingly synonymous with digital credentials in decentralized contexts, thoughthe broader category of digital credentials still encompasses various otherforms of digital attestations that may not incorporate the same level ofcryptographic verifiability. Under this circumstance, VCs are also necessaryduring my research.Digital Credential versus X.509 CertificateDigital credentials and certificates are often confused due to their sharedpurpose in proving identity and facilitating trust in digital environments.Both serve as verifiable attestations of identity, associating an entity witha specific piece of information, such as a public key or identity claim. Be-cause certificates are well-established and standardized in systems like PKI,researchers often use certificates as a more tangible and familiar examplewhen discussing digital credentials, even when the broader term encom-passes more flexible, non-standardized forms of identity verification. In other31words, digital credentials are used to secure the identity or attribute of anentity in the practical world, while X.509 certificates only serve for securecommunications (such as HTTPS and TLS) and authentication (for clientand server authentication in SSL/TLS), playing a crucial role in ensuringdata transmission security and identity verification.My PositionIn this thesis, I distinguish digital credentials from certificates, as myapplication domain specifically focuses on contexts where paper documentstraditionally serve as proof of identity or authorization. The term âdigi-tal credentialâ in my framework following the Government of Canada refersto the electronic equivalent of these paper-based forms, encompassing morethan just the public key binding found in certificates. This distinction iscrucial because the scenarios I are addressing often require the digital trans-formation of documents like licenses, diplomas, or identification cards, whichhave historically been issued in physical form. Meanwhile, I will also con-sider systems targeted at digital identity or verifiable credentials since theyare highly connected to digital credentials and are always used in researchworks.3.2.2 Usage of PKI in Digital CredentialPKI plays a foundational role in securing digital credentials by provid-ing a trusted framework for authentication, integrity, and encryption. PKIâscryptographic methods allow digital credentials to be securely issued, ver-ified, and revoked, ensuring the same level of trust as traditional physicaldocuments. Its widespread adoption across various sectors has transformedhow identities and qualifications are managed digitally.One of the most prominent uses of PKI in digital credentials is in digitalidentity systems. For example, Al-Khouri [7] introduced the UAE PKI Pro-gram, which has two strategic objectives: (1) to enable verification of thecardholderâs digital identity through authentication services, which includeverifying the PIN code, biometric data, and signature certificates; and (2)to provide credibility through validation services by establishing a CentralCertification Authority. This Central Certification Authority also referredto as the Government Root Certification Authority, serves as the highest-level authority in the hierarchical structure of the UAEâs government PKIsystem. The architecture encompasses a root CA and multiple subordinateCAs that operate according to the UAEâs PKI policy.32The architecture was designed to support two operational models forimplementing a third-party subordinate CA. In the first model, an eGovern-ment authority can implement its own CA, including the necessary softwareand hardware, and rely on the existing PKI infrastructure to certify itspublic CA with its root certificate. In its second model, the eGovernmentauthorityâs CA is set up as part of the same PKI infrastructure, but a virtualpartition is created on the Population CA. This virtual partition isolates theeGovernment CA and ensures that its key pair and corresponding certificatesare separated from the root keys by creating a virtual key container on thehardware security modules (HSMs). This ensures the cryptographic sepa-ration of the subordinate CAâs keys from those of the root CA, enhancingsecurity and compartmentalization.In the healthcare sector, PKI is also employed to protect sensitive dataand ensure that only authorized individuals can access patient records.X.509 certificates are used in compliance with standards such as the HealthInsurance Portability and Accountability Act (HIPAA) in the United Statesor the General Data Protection Regulation (GDPR) in Europe to safeguardElectronic Health Records (EHRs) and medical communications. In the re-view work by Fernandez [5], A total of 49 articles were selected, of which26 used standards or regulations related to the privacy and security of EHRdata. The most widely used regulations are the HIPAA and the EuropeanData Protection Directive 95/46/EC. A total of 11 articles propose the useof a digital signature scheme based on PKI (Public Key Infrastructure) and13 articles propose a login/password (seven of them combined with a digitalcertificate or PIN) for authentication.Another growing use of PKI is in issuing digital diplomas and academiccertificates. Universities are increasingly turning to PKI-backed digital cre-dentials to provide verifiable, tamper-proof certificates to their graduates.This helps combat issues such as degree fraud while making it easier foremployers and institutions to verify credentials [84, 85].3.2.3 Key Limitations of Centralized PKIHowever, the centralized hierarchical architecture of traditional PKIplaces significant trust and control in a single entity, namely the root CA.This root CA serves as the cornerstone of trust, issuing and validating sub-ordinate CA certificates and website certificates, which could create a singlepoint of failure. If the root CA is compromised or acts maliciously, the en-tire trust chain collapses, rendering all certificates issued under its authorityuntrustworthy [21].33There have been several notable instances where the compromise of aroot CA led to widespread security breaches, underscoring the vulnerabil-ity of centralized PKI systems. A prominent example of such vulnerabilityis the DigiNotar incident in 2011, where the Dutch CA was hacked [10].The attackers exploited the system to issue fraudulent certificates for ma-jor domains, including google.com. This breach effectively compromised theintegrity of Googleâs digital identity and undermined user trust across theinternet. DigiNotarâs role as a trusted authority was called into question,leading to its collapse, with all certificates issued by DigiNotar being re-voked. The incident highlighted how the compromise of a single CA canhave devastating consequences for the broader digital ecosystem, emphasiz-ing the fragility of centralized PKI systems.Another notable example is the TrustWave incident [11], in which a CAaccidentally issued a subordinate root certificate to a customer, effectivelygranting them the power to act as their own CA. This mistake allowed thecustomer to issue certificates as if they were a trusted root authority, openingup the possibility for unauthorized or fraudulent certificates to be issued.This type of error demonstrates the cascading impact that a compromisedor misused CA can have on the trust structure of the entire PKI system.Other similar breaches further illustrate the risks inherent in centralizedPKI [86]. In 2008, StartCom experienced a security incident that raisedconcerns about its certificate issuance practices [87]. In 2011, Comodo, oneof the worldâs largest CAs, was hacked, resulting in the issuance of roguecertificates for several major websites, including Google, Yahoo, and Skype[88]. The GoDaddy breach from 2017 to 2018 also compromised millions ofcertificates, once again highlighting the dangers of a single entity controllingsuch a vital security infrastructure [89].These incidents collectively demonstrate that the current centralized PKImodel, with its single point of trust in the root CA, is inherently fragile. Eachbreach calls into question how sustainable this model is in the long term andemphasizes the urgent need for exploring decentralized alternatives. DPKIoffers a promising solution by distributing trust among multiple entities,thus mitigating the risk posed by compromising a single point of control.In addition to concerns over the compromise of CAs, Man-in-the-Middle(MitM) attacks pose a significant threat to the PKI ecosystem, especiallyin cases where there is a lack of transparency and accountability. A MitMattack occurs when an attacker secretly intercepts and potentially alters thecommunication between two parties without their knowledge. This type ofattack can severely undermine the integrity of SSL/TLS connections, evenif proper encryption protocols are in place.34One notable study by [13] implemented a method to detect SSL MitM at-tacks on global websites, including Facebook, one of the largest platforms inthe world. Their analysis revealed that 0.2% of over 3 million real-world SSLconnections to Facebook were tampered with using forged SSL certificates.A significant portion of these MitM attacks was traced back to antivirussoftware and corporate content filters, which often install their certificatesto inspect SSL traffic. Although these are not typically malicious actors,they demonstrate how easily legitimate mechanisms can be exploited forsurveillance or data tampering.Even more concerning, government agencies and state-level adversarieshave been implicated in intercepting and manipulating user traffic, raisingsignificant privacy and security concerns. For example, in Kazakhstan [14],the government attempted to enforce the installation of a state-issued rootcertificate, allowing it to intercept all HTTPS traffic passing through its na-tional network. This forced compliance essentially enabled the governmentto perform MitM attacks on a nationwide scale, undermining user privacyand setting a dangerous precedent for other state-level actors.Such incidents highlight a broader issue: without transparency and strongsecurity measures, MitM attacks can compromise the trust and functionalityof PKI systems. The risk extends beyond just individual hackersâcorporations,security vendors, and even governments can abuse this vulnerability tomonitor and control user communications. These attacks demonstrate thefragility of relying on a centralized authority to issue and manage certifi-cates, where the misuse of a single certificate can lead to widespread securitybreaches.3.3 Decentralized Public Key InfrastructureDue to problems in centralized PKI systems, research in DPKI has beenconducted to address these issues. There are various research works in DPKIstudies: based on OpenPGP criteria or compatible with X.509 criteria.3.3.1 Trust in DPKI of OpenPGPDPKI is rooted in the desire to overcome the limitations of traditionalPKI, which centralizes trust in a small number of CAs. As early as 2006,Keychains were introduced as a DPKI system based on Pretty Good Privacy(PGP), which was originally developed in 1991. PGP was revolutionaryin decentralizing the authentication process, enabling users to create their35public-private key pairs without relying on centralized authorities. This laidthe groundwork for future DPKI systems to evolve.Building on the OpenPGP standard (RFC 4880) [90], PGP allowed forthe âWeb of Trust,â where individual users can authenticate each other.However, as this approach matured, it became clear that scaling such asystem, especially for institutional applications, would require further inno-vation. New DPKI approaches began to explore blockchain-based solutions,as seen with Certcoin [16, 17], Authcoin [18], and Instant Karma PKI (IKP)[4]. These systems used the immutability and decentralization of blockchainto ensure that identity records and public keys are transparently verifiableby any participant in the network.Certcoin [16]: Built on Bitcoinâs blockchain, Certcoin provides a decen-tralized PKI without a single trusted authority. It stores key registrationsand revocations on a blockchain and allows anyone in the network to querythe ledger. The use of blockchain ensures a tamper-proof audit trail, butthe system faces challenges with scalability and key management.Authcoin [18]: Authcoin extends the idea of DPKI by introducing a pro-tocol that enables decentralized authentication via blockchain and allows fora more dynamic and customizable trust model. In this model, the strengthof trust is based on the number of users who endorse a key binding.Instant Karma PKI [4]: IKP offers an incentive-based approach to decen-tralized PKI. By integrating smart contracts, IKP creates a reward systemthat penalizes malicious behavior and encourages honest participation in thevalidation process. This model aligns incentives for participants and helpsmitigate risks of malicious actors exploiting the system.While DPKI based on OpenPGP offers many advantages, it also faces asignificant challenge compared with X.509 systems [20, 91]. OpenPGP pro-vides a more decentralized alternative but at the cost of trust consistencyand scalability. Both models exhibit weaknesses regarding trust anchors,with X.509 facing risks due to centralization and OpenPGP encounteringchallenges due to its peer-based, subjective trust mechanisms. OpenPGPâspeer-based model uses peer endorsements (signing keys) as trust anchors.However, without a centralized authority, trust propagation is highly sub-jective, and users must manually verify key signatures, which can result inan uneven or incomplete trust network. The absence of a unified trust an-chor means that trust can be more difficult to establish or scale across largenetworks.363.3.2 X.509 Compatible DPKI SystemsDesign for general usage or non-digital credentialsIn the evolution of DPKI systems that are compatible with the X.509standard, several approaches have been explored to decentralize identitymanagement while maintaining the integrity and reliability of traditionalCAs. These systems are also considered as hybrid solutions, which aimto bridge the gap between the hierarchical trust model of X.509 and thedecentralized nature of blockchain-based environments, providing innovativesolutions to overcome the limitations of centralized PKI.Mobile Device Identity System, one notable system introduced by Yan[22], proposed a DPKI model for mobile devices, where each deviceâs identitycould be predefined by its manufacturer or obtained from a CA based oncertain identity features like the deviceâs IP address. This system leveragesX.509 v3 certificates and involves different types of nodes, ranging fromvalidators to transactional nodes. While the system retains traditional PKIelements, including reliance on CAs for identity verification, it omits criticalfeatures like CRLs, limiting its ability to revoke certificates dynamically.Another significant proposal was proposed by Cecoin [19]. It models theinteraction of certificates issued by CAs as currency-like transactions on aBitcoin-based blockchain. In this system, Merkle Patricia trees are used tostore certificates, allowing users to possess and modify multiple certificates.The system provides decentralized verification of each certificateâs validitythrough transaction records and revocation status, reducing the reliance ona centralized CA for identity validation.Guo [92] introduced a theoretical DPKI system that used a Key Manage-ment Center (KMC) as the trust anchor. In this model, users generate keypairs and store the public keys on a blockchain, leveraging the blockchainâsimmutability and security to safeguard the KMC-signed public keys. Theprivate keys remain with the users, ensuring that only the key owners cancontrol their identity.Recent developments have also explored the automation of certificateissuance through decentralized means. ACME (Automatic Certificate Man-agement Environment) [93, 94] is one such technology, where the integrationof multi-signature blockchain transactions allows for decentralized validationof DNS names and certificate issuance. These systems use blockchain as thestorage medium for certificate transactions, eliminating the need for tra-ditional CRLs by generating new certificates upon renewal. In one case,94 developed a system on Ethereum that uses smart contracts to manage37X.509 certificates for web domains. This system allows certificates to be is-sued by either web servers or registered CAs, with all transactions recordedon a blockchain for transparency. Smart contracts also enable a new type ofCRL where revocations are tracked through Ethereumâs native gas currency.The DeTract system, proposed by 23, enabled web servers to createtheir own X.509 certificates using uPort, an Ethereum-based identity storageplatform. In this approach, blockchain is used to store hashes of certificatesand their associated identities, while the actual certificates are kept off-chain. Transactions are performed via Ethereum gas, removing the need forcentralized certificate revocation mechanisms.Yakubov [95] proposed transforming smart contracts into virtual CAs,where the blockchain network itself became the source of trust. In thismodel, smart contracts issue, store, and revoke certificates in a decentral-ized manner. The CRL is implemented as a smart contract, listing validcertificates in an allowlist structure, ensuring that only valid certificates aretrusted by the network.Design for digital credentialsAlthough few published works are directly related to digital credentials,there exist some attempts to combine X.509 with blockchain, or further withDID, to inherit trust in digital credentials or digital identities.Bastian et al. identified six types of hybrid approaches that integrateX.509 with DIDs and verifiable credentials (VCs) [96]. While their anal-ysis is somewhat preliminary and lacks sufficient references, it is evidentthat their focus lies in achieving interoperability between existing X.509systems and emerging DID frameworks. The primary objective across allproposed options is consistent: to enhance trust and security by leveragingthe strengths of both X.509 and DID systems. This dual approach aims tobuild trust while simultaneously safeguarding privacy.A typical dual approach example is eIDAS Bridge [97], developed bythe European Commission to establish a legally compliant link between SSIbased on DID/VC and existing digital identities based on X.509. The eI-DAS Bridge works by embedding DIDs into X.509 certificates as extensions.This allows DIDs to be associated with legal entities that have already beenverified through the eIDAS Qualified Trust Service Providers (QTSPs). TheQTSPs play a crucial role in verifying identities before issuing certificatesthat include DIDs. Once a DID is linked to an X.509 certificate, it can beused to issue VCs, which serve as attestations of various attributes. TheseVCs are signed using both the private key of the X.509 certificate and the pri-38vate key associated with the DID, providing a dual system of trust. The eI-DAS Bridge establishes an interoperability layer that allows users to presenta single credential for verification. The verifier can check both the X.509 cer-tificateâs trust chain and the DIDâs validity in a decentralized ledger. Thisprovides a hybrid trust model, leveraging the centralized trust of eIDASwith the decentralized trust of blockchain. The European Digital IdentityWallet (EUDI) is an essential part of the architecture. It allows users tomanage both X.509-based digital identities and SSI-based credentials in oneplace. Users control their data, while PID providers (trusted entities) andQTSPs ensure legal compliance and trustworthiness.Trust over IP (ToIP) [98] proposed a unique solution by embedding DIDsdirectly as extensions within X.509 certificates. This integration is designedto function without requiring any additional infrastructure, making the sys-tem efficient and user-friendly. The process of creating and resolving a DIDis executed locally and takes advantage of existing X.509 certificate chainvalidation. This ensures that elements of the DID are consistent with theproperties in the certificate chain. A key feature of this approach is its stip-ulation that a certificate chain must be included during the DID resolutionprocess, enhancing the interoperability between traditional identity frame-works and decentralized systems. This method ultimately aims to improvetrust and security across identity verification mechanisms.Another preliminary work [99] shown in Figure 3.2 also utilized X.509certificates to establish provenance for Decentralized Identifiers (DIDs). Thisis one of the simplest structures of combining two systems. It requires theattestor organization to create a DID and then verify it from CA. Users canthen use verified DIDs in common activities.Although these systems try to anchor their trust in both X.509 and DIDsystems, they still rely on centralized methods to provide initial trust. If aroot CA is compromised, it could still lead to forged DIDs being linked tofraudulent identities, breaking the trust chain in the centralized part. Mean-while, these systems are either in their preliminary stages or focusing oninteroperability between two architectures. Since there is no evidence thatthe X.509 system must be independent in blockchain-based designs, someresearch works also try to integrate X.509 functionality into the blockchain.For example, Proofchain [21] proposed a design, especially for IoT whichmaps the original X.509 architecture onto a blockchain framework, whichstores, issues, and verifies X.509 format certificate content rather than cre-ating its custom implementation. Proofchain also implemented the smartcontract on a private testbed of the Ethereum network to evaluate variousreal-world scenarios.39Figure 3.2: Using X.509 Certificates to establish the owner of a DIDNote. Adopted from Using X.509 Certs for DID Provenance, by PhilWindley, 2024, Technometria,https://www.windley.com/archives/2024/04/using x509 certs for did provenance.shtmlCopyright 2024 by Technometria. Reprinted with permission. This is atypical example of bi-systems, which is still in theory.40In fields of digital credentials or synonyms, Trustchain [24] is state-of-the-art and also tries to establish a DPKI as a digital twin of real-worldhierarchical trust relationships.3.4 Trustchain and Potential ProblemsTrustchain [24] is an advanced work with an elaborate literature review,clear design principles, complete system components, and convincing imple-mentation results, thus becoming state-of-the-art in this area. Trustchainis motivated by the potential for decentralization in digital identity, encom-passing several critical aspects: privacy (mitigating user profiling), agency(empowering users to control their data), security (preventing the estab-lishment of new centralized data repositories), resilience (ensuring uptimeand accessibility), and interoperability (facilitating connections between cen-tralized systems). Additionally, they emphasize applications of particularinterest, such as selective disclosure through verifiable credentials and thefederation of foundational or functional identity systems. Building uponthese principles, their papers propose alternative designs and offer a com-parative analysis of my work with that of Hobson et al. in the context ofPKI processes.3.4.1 Trustchain Design PrinciplesThe design of a trustworthy digital identity system is paramount in en-suring the protection and empowerment of users in a digital landscape in-creasingly characterized by data breaches, privacy violations, and central-ized control. The foundational principles outlined below, derived from thework of Goodell and Aste, provide a framework for constructing such sys-tems, emphasizing user rights and system integrity. These principles notonly guide design choices but also serve as benchmarks for evaluating anyproposed solutions.TrustTrust is a cornerstone of any credentialing system, particularly in digitalidentity management. However, the design must minimize the reliance ontrust in the underlying data infrastructure. Users should have clarity onwhere their trust is placed, avoiding synthetic trust relationships that areestablished for technological purposes rather than through genuine personalrelationships and reputations. Furthermore, institutional identities should41be unique and publicly accessible, while individual identities need not ad-here to the same public requirement. Trust relationships among systemparticipants should be achievable without necessitating permission from acentralized authority, thus fostering a more decentralized and user-centricapproach.TransparencyTransparency is crucial for the credibility of digital identity infrastruc-ture. The system should be open to scrutiny, requiring all code to be open-source and compliant with open standards. Each component of the systemmust be identifiable and realizable, eliminating hypothetical dependencies.Users must be informed whenever personally identifiable information (PII)is shared or stored. Furthermore, authorities should not be granted excep-tional access or âbackdoorsâ into the system, ensuring that users maintaincontrol over their data.Permissionless AccessibilityA robust digital identity system must promote inclusivity by allowingall participants equal access without needing permission from a central au-thority. This approach favors open protocols over proprietary platforms,mitigating the risk of monopolistic practices. Participation in the systemshould be voluntary and free from coercion, and while opting out may leadto reduced convenience, it should not incur penalties. This principle ensuresthat users have the freedom to engage with the system on their own terms.PrivacyPrivacy is fundamentally recognized as a human right, and any digitalidentity system must prioritize privacy protections at its core. Individualsshould have control over their identity and personal information across var-ious contexts, including the ability to create multiple, unrelated identities.The infrastructure must be designed to prevent mass surveillance, ensuringthat users can manage their data without undue intrusion.Data MinimizationData minimization is essential for protecting user privacy and enhancingsecurity. The system should collect and retain only the necessary personal42data for specific purposes. The design should encourage the sharing of veri-fiable attributes rather than complete identities, thereby limiting exposure.In cases where strong non-transferability of credentials is required, it shouldbe enforced interactively and at the edge of the network. Additionally, roleswithin the system should be clearly defined and isolated to prevent un-necessary data sharing, particularly between credential issuers and serviceproviders.3.4.2 Trustchain StructureVerifiable Data RegistryVerifiable Data Registry serves to store identifiers in the form of Decen-tralized Identifier (DID) documents and their associated metadata [60], asshown in section 2.2.2. Importantly, the specific nature of this registry is leftas an implementation choice, meaning that there are no explicit guidelineson what must be verifiable or the mechanisms for verification. In the con-text of Trustchain, they identified specific properties that the data registrymust possess, which differentiate it from standard DID frameworks. Theseproperties are:Universal and Permissionless Read/Write Access: This requirement alignswith my design goal of open accessibility, ensuring that the registry is avail-able for adoption by any user community and at any scale.Independently-Verifiable Timestamping : This feature plays a crucial rolein Trustchainâs security model, ensuring that all recorded information canbe trusted based on a verifiable timeline.Effective Immutability : This property guarantees that once informationis written to the registry, it remains unchanged over time. Without im-mutability, the significance of the first two properties diminishes, as theywould be compromised by the potential for unauthorized alterations.Scalability : Given the potential increase in DID operations, the registrymust efficiently handle growth in throughput, which is often a commonchallenge in decentralized systems.Iterability : This allows users to traverse the entire registry, scanningfor DID operations. This feature, combined with verifiable timestamping,ensures users have access to the most up-to-date information, including no-tifications for DID revocations.They emphasized that the timestamps produced by the registry must beindependently verifiable. The verification mechanism should be accessibleto anyone without requiring special knowledge or trust in third parties, such43as specific public keys. This concept was built on the foundational work ofHaber and Stornetta [37], who introduced timestamping through a linkedsequence of cryptographic hash digests. This idea gained traction with theadvent of Bitcoin, which integrated continuous proof of work (PoW) andaligned economic incentives to create a fully decentralized timestamp serverfunctioning as a self-perpetuating distributed system.The mechanisms proposed have already been utilized in tools like OpenTimestamps and adapted for specific DID method implementations. Trustchainproposed a novel application of verifiable timestamping to facilitate a usercommunityâs ability to reliably share and agree on a particular DID, estab-lishing the root of a hierarchical trust network.Downstream DIDs and Upstream DIDsA downstream DID (dDID) is a W3C Decentralized Identifier that incor-porates metadata including a signature from an entity attesting to both theidentity of the dDID subject and the validity of the information containedin the corresponding DID document. The entity providing this attestation,referred to as the attestor, is represented by an upstream DID (uDID). Thisrelationship enables the establishment of public key networks of trust thatare digitally represented on decentralized infrastructure.Figure 3.3 illustrates the relationship between a downstream DID andits essential information content. To obtain a dDID, the subject must firstcompile their public key and service endpoint information into a candidatedDID document. A service endpoint refers to a network address, such as theURL of an HTTP API, that facilitates communication or interaction withthe DID subject.Once the candidate document is prepared, the subject shares it with theupstream entity, which then conducts a challenge-response procedure to ver-ify that the subject possesses the private key counterparts to the providedpublic keys. This procedure assumes that a well-established relationshipexists between the two entities, ensuring that appropriate communicationchannels are readily available. To enhance convenience and ensure accuracy,the Trustchain client software supports the challenge-response protocol uti-lized by both parties, with identity verification also conducted through theexisting communication channels.Upon satisfactory verification of the candidate dDID document, the up-stream entity computes its hash (digest), signs the hash, and embeds thesignature into the DID document metadata. This metadata also includesan update commitment, which consists of the hash of a secret value held by44Figure 3.3: Upstream and Downstream DIDsNote. Adopted from Trustchainâ Trustworthy Decentralised Public KeyInfrastructure for Digital Credentials, by Tim Hobson, 2023, CADE 2023,p.34. Copyright 2023 by CADE .Reprinted with permission. This is thecore mechanism of Trustchain that realizes the digital twin of chain trust,which could be referred and advanced by BCChain.45the attestor. For any updates to the DID document to be considered valid,they must be accompanied by the pre-image of this hash, thereby grantingthe attestor the authority to revoke the dDID and perform renewals.The dDID subject holds a separate secret value used to generate a recov-ery commitment, which is included in the dDID document metadata alongwith the update commitment. This mechanism enables the subject to re-gain full control of the DID identifier at any time, without requiring furtherattestation.The result is a shared responsibility model, where both the subject andattestor function as DID controllers. This arrangement permits both partiesto make certain changes to the dDID document: the attestor retains theauthority to revoke, renew, and update the document, while the subjectmaintains ultimate control of the identifier via the DID recovery mechanism.By distributing controller responsibilities in this manner, the model ensuresself-sovereignty for the dDID subject while providing the attestor with aunilateral mechanism for revocation and renewal. This hierarchical structureallows for the construction of chains of trustworthy DIDs, thereby enhancingthe integrity and reliability of decentralized identity systems.Root DIDThe Root DID serves as the foundational element of a trust hierarchy,akin to a root certificate in traditional Web PKI. This Root DID refers to oneor more real-world entities recognized as authorities by all users within thesystem. For example, if Trustchain were to be implemented on a nationalscale, a central government entity would be a logical choice as the rootauthority.This concept relates to the broader oracle problem, which arises when-ever a data registry is relied upon as a single source of truth for real-worldinformation. While the integrity of the registry may be verifiable, the ac-curacy of the data at the point of entry remains uncertain. Therefore, anadditional source of trust is required to ensure confidence in the informationitself. Notably, to establish a root of trust, this assurance cannot solely relyon digital signatures, as doing so would undermine the entire framework.In Trustchain, they proposed a solution to this specific manifestationof the oracle problem by leveraging the data registryâs capacity for verifi-able timestamping. This approach assumes that the verification process isachieved through continuous and cumulative proof of work (PoW), as noother known mechanism supports fully independent verification.The proposed mechanism is as follows:46DID Document Creation: Prominent and trusted members of the com-munity, represented in the Root DID, create a DID document containinga collection of their public keys. Each member must control at least onecounterpartâs private key.Publication of the DID Document : The DID document is published onthe verifiable data registry, making it universally accessible and endowing itwith a verifiable timestamp.Public Awareness: To establish the Root DID, the existence and publi-cation date of the DID must be widely publicized to the community. Thiscan be accomplished through various communication channels, includingelectronic and non-electronic means such as television, radio, newspapers,billboards, and word of mouth. The shared calendar date of publicationbecomes a recognizable point of reference.Once the Root DID is established, the entities represented can begin issu-ing downstream DIDs to subordinate community members. These membersmay serve as credential issuers themselves or delegate further by publishingadditional downstream links in a DID chain.Before the system is activated, it is critical to allow a sufficient waitingperiod to ensure the Root DID becomes effectively immutable. Although anyPoW chain can theoretically be modified retroactivelyâeither by chance ordeliberate attackâthe cost of such an attack can be estimated based on thenetworkâs aggregate hash rate, which is regularly published in PoW digests.As the work is cumulative, the cost of potential attacks has increased lin-early over time since the Root DIDâs publication. Therefore, an appropriatewaiting period can be selected to render the cost of an attack prohibitive.After this waiting period, any of the entities represented within the net-work of DIDs emanating from the Root can issue credentials. A relyingparty can verify a credential through the following steps:1. Resolving the issuerâs DID to obtain their public key.2. Tracing back through the chain of downstream DIDs, verifying the at-testation signature at each step using the public key from the next upstreamDID until reaching the root.3. Verifying the timestamp on the Root DID.4. Verifying the signature on the credential using the issuerâs public key,which is now established as trustworthy.It is crucial that all participants within the trusted networkâincludingcredential issuers, holders, and verifiersâcan accurately identify the RootDID. Failure to do so could result in the acceptance of erroneous public keysand fraudulent credentials. In a decentralized environment where anyone canpublish their DIDs, ensuring users can confidently identify the genuine Root47DID becomes paramount.TimeStamp MechanismFor implementation, Trustchain utilizes the Identity Overlay Network(ION), a DID method managed by the Decentralized Identity Foundation,alongside DIDKit, a cross-platform toolkit for verifiable credentials (VCs)and DIDs developed by SpruceID. ION relies on two peer-to-peer systemsfor its decentralized infrastructure: the Bitcoin network and the InterPlane-tary File System (IPFS). Together, these systems provide a data layer withthe necessary features for robust functionality. The Bitcoin network offerscontinuous and cumulative proof of work and permissionless write access,which are essential for supporting independently verifiable timestamping. Asingle Bitcoin transaction can include up to 80 bytes of arbitrary data, suf-ficient for embedding an IPFS content identifier (CID), which ION uses toreference the location of DID document data and metadata. Once stored onIPFS, these files become immutable, as the CID serves as a cryptographichash of the content itself. Trustchain thus delegates DID operations to alocally-running node on the Identity Overlay Network (ION), which itselfcontains a client on each of the Bitcoin and IPFS peer-to-peer networks.In their implementation, timestamps serve as a crucial mechanism forvalidating the sequence and timing of transactions or events. The times-tamp ensures that every action, such as credential issuance or identity veri-fication, is recorded chronologically, making it easier to track when certainoperations occurred. In Trustchain, timestamps were used to record theissuance, verification, and revocation.The process described takes two inputs: i) a DID document and ii) a4-byte integer representing Unix time as the timestamp. The process beginsby retrieving three files from IPFS: the chunk file, the provisional index file,and the core index file. The chunk file contains the actual DID content, andthe first step is to verify that all public keys and endpoints referenced in theDID document are present within the chunk file. This file is then hashedusing the IPFS hashing algorithm to generate its content identifier (CID).The CID serves both as a retrieval address on IPFS and as a cryptographiccommitment to the fileâs content, making it computationally infeasible tocreate any different content that would result in the same CID when hashed.The next step is to ensure that the chunk fileâs CID is included in theprovisional index file. Once confirmed, the provisional index file is hashedto produce its own CID. The core index file is then checked for the presenceof the provisional index fileâs CID before hashing it to obtain its CID. If all48checks are successful, the CID of the core index file serves as a commitmentto the original DID documentâs content.When ION publishes a DID operation, it records the core index fileâs CIDwithin a Bitcoin transaction by embedding the data. The verifier retrievesthis transaction from the Bitcoin blockchain, verifies that it contains thecore index fileâs CID, and hashes it (twice) using SHA-256 to obtain thetransaction ID (Txid).To efficiently verify that the transaction is included in a specific Bitcoinblock, a Merkle proof is employed. This proof can be obtained directly fromthe Bitcoin client encapsulated within the ION node. The Merkle proofincludes a branch of the Merkle tree of transactions, where the leaf node isthe previously computed Txid. By performing pairwise SHA-256 hashingon the commitments in the Merkle branch, the verifier eventually arrives atthe Merkle root, which confirms the transaction and thus the original DIDcontent from the ION chunk file.Finally, the Merkle root is found within the Bitcoin block header, which,when double-hashed with SHA-256, produces the blockâs PoW hash digest.Any Bitcoin network node can verify that this hash exists within the cu-mulative PoW chain of the Bitcoin blockchain, as it must meet the strictdifficulty criteria established by the Bitcoin protocol. Along with verifyingthe inclusion of the Merkle root in the block header, a check is made for thecandidate timestamp. If both the Merkle root and timestamp are present,and the block header is successfully hashed to yield a valid digest that existsin the PoW chain, the verifier can confidently establish that the transaction,which committed to the DID document content, was published in the blockwith the specified timestamp.3.4.3 Problems of TrustchainAlthough Trustchain tried to provide a measurement of X.509 compat-ible DPKI for digital credentials, it still has some challenges remaining tofinish. I analyze two problems in my thesis: identity management and creditendorsement.Identity ManagementIn identity management, it will involve registration, update, revocation,and other operations.In identity registration, Trustchain could validate the owners and theirDIDs based on W3C criteria [60]. However, it did not consider the trust49anchor in DID issuance. If the issuer in a chain is not reliable, the identityretention can not prove itself. Trustchain managed to build Root DIDs,uDIDs, and dDIDs to map the hierarchical architecture in the real world,and Root DIDs could be published through time and money to attract usersâtrust. However, it does not define whether the authority is restricted ingovernment or public for any entity. If Trustchain allows any DID owner tocollaborate and establish the Root DID, it can not guarantee compliance inthese DID issuers when they only form small groups and engage in illegalinteractions. Meanwhile, Trustchain did not consider the problem of anentity generating plural DIDs or public keys, which will probably increasemanagement complexity, violate compliance, or undermine credits for theuser.To avoid the risks of exposing the private key of their DIDs or life track,users tend to register several key pairs and DIDs to keep anonymity. How-ever, the proliferation of DIDs introduces substantial key management com-plications. As users accumulate multiple key pairs, the probability of losingaccess to one or more increases significantly. Traditional key recovery mech-anisms may become unwieldy when applied across numerous DIDs. Main-taining secure backups for multiple private keys requires sophisticated keymanagement strategies and it increases the risk of security breaches. Thecognitive load of managing multiple identities and their associated creden-tials can lead to user friction and potentially compromise security throughhuman error.Meanwhile, the anonymity afforded by multiple DIDs creates significantchallenges for regulatory oversight. Supervisors face increasing difficulty inidentifying and tracking entities that violate regulations, as multiple DIDscan obscure the connection between digital activities and real-world identi-ties. The inability to definitively link multiple DIDs to a single entity com-plicates the enforcement of Know Ymy Customer (KYC) and Anti-MoneyLaundering (AML) regulations [100]. Traditional accountability frameworksmay prove insufficient when dealing with entities operating through multi-ple, seemingly unrelated DIDs.Credit EndorsementAnother problem lies in the credit endorsement. As I know from theX.509 criteria, the certificate should be published obeying the certificatechain. Trustchain managed to realize the concept through downstream DIDand upstream DID, as shown in Figure 3.3. A dDID is a W3C DecentralisedIdentifier whose metadata includes a signature from an entity attesting to50both the identity of the dDID subject and the validity of the informationcontained in the corresponding DID document. The attesting entity (orattestor) is itself represented by an uDID, through which its public keys aremade available. This mechanism enables chains of trustworthy DIDs to beconstructed, thereby allowing hierarchy.Meanwhile, Trustchain added the ingredient Root DID, which representsthe root of a trust hierarchy (analogous to a root certificate in the Web PKI).The real-world entity (or entities) to which this Root DID refers is assumedto be some authority that is recognizable to all users of the system. How-ever, as the Trustchain said, Root DID owners should first anchor it in theblockchain and then widely publicize the fact by informing the whole com-munity of its existence and of the calendar date on which it was published.Trustchain has no direct connection between Root DIDs in timestampas depicted [60], and the relationships between Root DIDs are more clearin architecture. Trustchain lies its trust in the connection between DIDsand each DID will have the right to publish a certificate when users needto manually rely on current connections and practical broadcasts to judgewhether a DID is reliable. It requires time and cost to make a Root DIDaccepted by the community and it could not effectively trace back the RootDID if its private key was stolen or forgotten.3.5 Summary of current systemsTo provide a clear overview of existing systems and their resilience tovarious attacks and challenges, I constructed a comparative table focusingon selected digital credential-related and traditional PKI systems, as shownin Table 3.1 & Table 3.2. In the tables, I also compared them with mydesigned system BCChain, which will be introduced in Section 4.The systems included in the table were not intended to cover every sys-tem discussed in the preceding literature review, but rather to highlightrepresentative systems that perform well across key features or security as-pects. The selection was guided by their relevance to the digital credentialsapplication domain, allowing a structured comparison between strongly andweakly associated systems.The challenges addressed in this study can be broadly categorized intothree interrelated groups. First, resilience against attacks encompasses threatssuch as CA compromise, man-in-the-middle (MitM) attacks, and Sybil at-tacks, which target the integrity, authenticity, and uniqueness of digitalidentities. Second, considerations related to X.509 compatibility involve51the preservation of trust anchors, the degree of decentralization, and trans-parency in credential issuance and verification, ensuring that the systemaligns with established hierarchical trust models while leveraging distributedledger benefits. Third, practical concerns in digital credential applicationsfocus on the strength of identity binding and operational cost efficiency,highlighting the need for verifiable connections between real-world entitiesand their digital identifiers, alongside economically sustainable deployment.This tripartite classification provides a structured framework for evaluatingBCChainâs design choices and its effectiveness in mitigating both securityand operational challenges.In order to ensure clarity and avoid misinterpretation, each feature andsecurity concern presented in the comparative table warrants explicit defini-tion.The category CA Compromise refers to a systemâs resilience againstthe misuse or breach of a single Root Certificate Authority (CA), particu-larly its ability to withstand mass unauthorized certificate issuance or ma-licious revocation once the CA is compromised. MitM attack describesthe risk whereby an adversary intercepts and potentially alters communi-cation between two parties; the corresponding table entry evaluates a sys-temâs ability to prevent or mitigate such intrusions. Sybil Attack involvesan adversary generating a large number of pseudonymous identities to gaindisproportionate influence or disrupt operations; the table considers the sys-temâs defensive measures against such manipulations. The Decentraliza-tion dimension captures whether the systemâs core control and whatâs themain decentralized component. Identity Binding & Uniqueness assessesthe degree to which digital identifiersâsuch as miners, decentralized iden-tifiers (DIDs), or user accountsâare verifiably linked to unique real-worldindividuals, while preserving privacy, in order to reduce the feasibility ofSybil attacks and to enhance accountability. Trust Anchor â Chain ofTrust addresses the origin and structure of trust within the system, iden-tifying whether the trust model adheres to the hierarchical structure de-fined in X.509âs chain-of-trust principle. While full conformance to X.509is not inherently superior, this classification helps distinguish systems thatpreserve hierarchical trust from those that adopt entirely distributed trustmechanisms. Finally, Transparency measures the openness of the systemâsrecords and processes, particularly regarding certificate issuance, revocation,and identity verification. Cost refers to the overall resource expenditure re-quired for system deployment and ongoing operation, including infrastruc-ture, maintenance, and incentive mechanisms. Together, these dimensionsprovide a comprehensive framework for evaluating the robustness, efficiency,and applicability of existing systems in the context of digital credentials.52Table 3.1: Comparison of Strongly Digital-Credential-Linked Systems withBCChain. Red triangle (â³) indicates that the feature is average or hasdeficiencies; red cross (Ã) indicates the feature is completely missing or hassignificant vulnerabilities identified in research.Feature Proofchain Trustchain OrgBook BCChainCACompromise -UnauthorizedIssuanceResistant tosingle pointof failure, butneed robustcheck by CAminersResistantthroughdistributedledger recordsâ³ Lowrisk due toconsortiumgovernance,but initiallySingle rootCA - BCregistriesConsortiumDID rootsprovidedistributedtrustMitM Attack â³ Resistantbut requireextraverificationfor CRT initialand revoke.N/A dueto thetransparentDIDs bindingStrongcontrol withconsortiumvalidationReal-timeon-chainvalidationpreventionSybil Attacks Ã Rely onTrusted groupof CA Minersà No explicitdefendingmechanismsStrongSybil attackresistancedue to realityverificationStrongprotectionsby identitybinding anduniqunessDecentralization Decentralized DecentralizedIdentifiersAlliance chaindecentralizationFullydecentralizedconsortiumchainIdentityBinding &Uniquenessà No bindingfor CA minersà No bindingMechanismsâ³ Onlyused forentrepreneurOffline orlicense bindingwith strongconnection tothe real personTrust Anchor -Chain of Trustà Distributedledger byminers (notrust chain)Chain ofTrust throughupDIDs anddownDIDsâ³ Consortiumledger, buthigh weight ofBC RegistriesConsortiumDID rootswith chain oftrustTransparency Public ledgertransparencyTransparencyin DIDs.Hightransparencywith auditablelogsFullytransparentand auditableCost â³ Moderateto high dueto blockchainmaintenanceâ³ Moderateto high due onProof of WorkRelatively low Relatively low,free for users53Table 3.2: Comparison of Weakly Digital-Credential-Linked Systems withBCChain. Red triangle (â³) indicates average performance or deficiencies;red cross (Ã) indicates feature is missing or has significant vulnerabilities.Feature CeCoin DeTract ACME TraditionalPKIBCChainCACompromise-UnauthorizedIssuanceâ³ Relies onsome realcentral CA,moderate riskà Relies oncentral CA,high riskLow risk Ã High risk ConsortiumDID rootsprovidedistributedtrustMitM Attack Low risk Low risk Low risk Ã High risk Real-timeon-chainvalidationpreventionSybil Attacks Low risk withlimits to be aminerLow risk dueto uPort IDâ³ LowresistanceN/A Strongprotectionsby identitybinding anduniqunessDecentralized DPKI system Decentralized Decentralized Centralized FullydecentralizedconsortiumchainIdentityBinding &UniquenessStrongbinding withno duplicateminers in realworldUport IDverificationand bindingà Weak Ã Weak ConsortiumDID rootswith chain oftrustTrust Anchor â³DistributedCA miners(no trustchain)Distributedledger onBitcoinDistributedledger onEthereumChain ofTrustFullytransparentand auditableTransparency High High High Ã Low High,auditableCost â³ Low forcertificatestorage, butno incentivemechanismâ³Transactionfees onBitcoinâ³Transactionfees onEthereumâ³CentralizedServersRelativelylow, free forusersDuring the comparative analysis of the surveyed systems, several salientpatterns and limitations were identified. First, with regard to Identity Bind-ing and Uniqueness, the majority of digital credential frameworks exhibitinsufficient mechanisms for establishing strong, privacy-preserving associa-tions between digital identities (e.g., miners, DIDs, or end-users) and theircorresponding real-world entities, while simultaneously ensuring uniqueness.By contrast, systems originating from other application domainsâsuch as54Cecoin and DeTractâtend to integrate design features that inherently mit-igate the risk of Sybil attacks and enhance governance capabilities. Thisdiscrepancy underscores a critical shortcoming in current digital credentialinfrastructures, where the absence of robust identity binding may compro-mise both trustworthiness and regulatory effectiveness.Second, from a Cost perspective, most blockchain-based identity sys-tems incur moderate to high operational expenses, primarily due to theneed for consensus incentives and transaction processing. Notably, the Org-Book platform illustrates an alternative design choice, leveraging a dedicatedblockchain to decouple identity operations from high-throughput incentivemechanisms, thereby achieving a favorable balance between transparencyand low operational overhead. This approach suggests that architecturalspecialization can serve as an effective cost-control strategy without com-promising accountability.Finally, in terms of X.509 Compatibility, while certain proposalsâsuchas Proofchainâdeclare interoperability with conventional hierarchical PKI,their trust establishment processes in practice adopt a fully decentralizedmodel. Although this divergence from the traditional chain-of-trust paradigmis not inherently detrimental, it necessitates careful scrutiny regarding thelogical guarantees and security assurances such systems provide, particularlywhen compared to the well-defined semantics and trust anchors of X.509-based infrastructures.In summary, while my survey provides a structured synthesis of existingsystems, significant research gaps remain in the domain of blockchain-basedDPKI for digital credentials, particularly with regard to X.509-compatiblearchitectures. The reviewed systems, though diverse in design and capabil-ities, do not comprehensively address the set of challenges I have identified,including identity binding, cost efficiency, and trust model consistency. Thisunderscores the need for a novel approach that not only bridges these gapsbut also integrates the strengths of prior work while mitigating potentialvulnerabilities and attack vectors. In the subsequent section, I introduceBCChain, a new X.509-compatible DPKI framework designed to more ef-fectively close these gaps and advance the practical and secure deploymentof digital credentials.55Chapter 4BCChain: X.509 CompatibleBlockchain DesignTo compensate for the problems that arose in Trustchain, I make somemodifications to the system design, and the proposed solution is called BC-Chain.4.1 BCChain ComponentsTo deal with problems appearing in Trustchain: credit endorsement for aDID and easier but more reliable DID management, I propose BCChain, anX.509-Compatible Blockchain-based Public Key Infrastructure for DigitalCredentials. Key components include: Main DID, Multi-Root System, andSub DIDs. This thesis will follow the rest mechanism used in Trustchain toenhance trust, security and transparency.4.1.1 Main DIDTo build credit endorsement initially after registration, I present MainDID, as shown in Figure 4.1. In this figure, visual elements are deliber-ately differentiated to convey distinct roles within the BCChain registrationand credential endorsement process. Solid rectangular boxes, such as User,Agency in Real World, User Key, Main DID, and Blockchain Registry, repre-sent active entities or components that directly participate in the workflow,including users, agencies, cryptographic keys, and blockchain infrastructure.Diamond-shaped boxes, such as If correct? and If Inactive?, denote decisionpoints where conditional logic is applied, guiding operations based on veri-fication results or status checks. Dashed rectangular boxes, such as AgencyDatabase, indicate internally stored data maintained by an entity, includingofficial records, certificate status, and user identity bindings. The dashedstyle differentiates internal storage from active components and highlightsthat these data remain off-chain under agency control. Regarding arrows,solid arrows indicate primary operational flows, such as data submission,56credential issuance, or DID generation, whereas dashed arrows denote indi-rect or supporting flows, for example, the linkage between stored data andsubsequent verification steps. This visual distinction separates backgroundor supporting information from the main procedural workflow. Together, thecombination of box shapes, line styles, and arrow types clarifies both the op-erational process and the relationships among entities, decision points, andstored data. This explanation has been incorporated into the figure captionand main text to ensure comprehensive understanding.In my design, the practical users (not CA) must make a credit endorse-ment for their DIDs. Attempts to combine X.509 and the DID system havealready considered the official validation before registering a DID [96â99].Algorithm 1 outlines the core procedure for identity verification, while Algo-rithm 2 defines a supporting subroutine to validate the authenticity of sub-mitted official documents. The two algorithms are therefore interdependent,with Algorithm 2 serving as a functional component that operationalizes acritical step in Algorithm 1âs workflow.Step 1: The process begins with the user submitting verifiable officialdocuments to a recognized agency (always the publisher of the documents)in the real world. These documents likely include key pieces of personalinformation, such as a government-issued ID, passport, or other forms ofidentification. The purpose is to provide proof of identity that enables theagency to authenticate the applicant. This initial step ensures that themain DID is tied to a verified real-world identity, establishing a foundationfor trust in subsequent digital interactions.Step 2: Upon receiving the userâs documents, the agency verifies theirauthenticity by cross-referencing them with records in its internal database.This process ensures that the documents are valid, up-to-date, and associ-ated with a legitimate individual. The database contains individual infor-mation and the current status of any existing certificates (only the status).The agency assesses whether the provided documents align with its storedrecords.Step 3: The verification process moves to a decision point: whether thesubmitted documents are correct and accurate. If Incorrect: The agencydeclines the userâs request for a DID. The process terminates here if theinformation is found to be invalid, ensuring that only users with accuratecredentials proceed further. If Correct: The next step is to check the statusof any certificates already associated with the user. If the user has previ-ously been issued a certificate, the agency checks whether that certificate iscurrently inactive or revoked. If the agency finds that the userâs documentsare correct and there is no active certificate or the prior certificate has been57Figure 4.1: Main DID Registration and Endorsement58Algorithm 1 Main DID Application Process1: Input: User, OfficialDocuments, Agency2: DocumentCheckResult â CheckDocuments(Agency, OfficialDocu-ments)3: if DocumentCheckResult = Incorrect then4: return "Request declined: documents failed verification"5: end if6: CertificateStatus â GetCertificateStatus(Agency, User)7: if CertificateStatus = Inactive then8: Certificate â GenerateCertificate(Agency, User)9: Certificate.Status â Active10: else if CertificateStatus = Active then11: return "Request declined: active certificate alreadyexists"12: else13: return "Request declined: certificate revoked orinvalid"14: end if15: UserKey â GenerateKeyPair(User)16: MainDID â GenerateMainDID(UserKey.PublicKey)17: BlockchainRegistry â GetBlockchainRegistry18: UploadDIDCertificate(BlockchainRegistry, MainDID, Certificate)19: return "Main DID successfully generated and registered"59Algorithm 2 Supporting Functions for DID Application1: function CheckDocuments(Agency, OfficialDocuments)2: Verify authenticity with issuing authority3: Validate expiration date and data integrity4: if verification fails then5: return Incorrect6: else7: return Correct8: end if9: end function10: function GetCertificateStatus(Agency, User)11: Query Agency database for the Userâs certificate record12: Return status â {Inactive, Active, Revoked}13: end function14: function GenerateCertificate(Agency, User)15: Create new digital certificate bound to Userâs verified identity16: Sign certificate with Agencyâs private key17: Return issued certificate18: end function19: function GenerateKeyPair(User)20: Create asymmetric key pair (sk, pk) for User21: Store sk securely in Userâs local environment22: Return (sk, pk)23: end function24: function GenerateMainDID(PublicKey)25: Construct DID from PublicKey according to DID method specifica-tion26: Return DID27: end function28: function GetBlockchainRegistry29: Return interface to blockchain-based DID registry30: end function31: function UploadDIDCertificate(Registry, DID, Certificate)32: Publish DID and associated certificate to Registry33: Confirm successful registration34: end function60marked as inactive, the agency generates a new certificate for the user. Thiscertificate serves as a formal confirmation of the userâs identity, tied to theinformation provided in Step 1. At this point, the agency also updates itsdatabase to reflect the status of the newly generated certificate, marking itas active. This ensures that the userâs digital identity is recognized in anyfuture interactions that require credential verification.Step 4: Once the certificate has been issued, the user creates a crypto-graphic key pair consisting of a public key and a private key. The publickey is used in this step to generate the userâs main DID. The DID is cryp-tographically linked to the public key, and the user retains control over theprivate key, which acts as a form of digital signature. The generation of themain DID forms the basis of the userâs digital identity, which can be usedin decentralized networks without revealing personal information.Step 5: Finally, the newly generated main DID, along with the cer-tificate issued by the agency, is registered on the blockchain. This publicledger ensures that the connection between the userâs DID and their veri-fied certificate is immutable and publicly verifiable. The process guaranteestransparency and traceability without compromising the userâs privacy. Theblockchain entry contains a reference to the certificate but does not includesensitive personal information. Instead, it relies on cryptographic proofs tomaintain security and integrity.4.1.2 Multi-Root SystemThis section introduces the core architecture of a multi-root system,where Root DIDs act as the primary entities for validating and endorsingcredit for CA. The concept of Root DID not only mirrors the role of tradi-tional CA but also extends the functionality by incorporating decentralizedprinciples. In this context, a Root DID can be understood as a type of CADID (except for the registration part). CA DID is derived from a Main DID,which is responsible for issuing, managing, and revoking credentials withinthe network. By decentralizing the control over identity verification andcredential issuance, this model enhances the security and trustworthiness ofthe digital ecosystem. Through the Root CA Sets, multiple authoritativeDIDs collaborate to ensure the integrity of the identity management pro-cess, effectively minimizing the risks of central points of failure. Algorithm3 basically explained the struct of DID and global parameter BCChain torecord the information.The CA admission process could be illustrated in Figure 4.2, 4.3, 4.4,&4.5.61Algorithm 3 Basic: DID Data Structure and Blockchain Dictionary1: Struct: DID2: Field: id # Unique identifier for this DID3: Field: endorsements # List of DIDs that this DID endorses4: Field: endorsedBy # List of DIDs that endorse this DID5: Field: publicKey # Associated public key6: Field: metadata # Other relevant information (e.g., creation time,status)7: Method: AddEndorsement(targetDID)8: endorsements.append(targetDID)9: Method: ReceiveEndorsement(fromDID)10: endorsedBy.append(fromDID)11: Method: UpdateMetadata(info)12: metadata.update(info)13:14: Struct: BCBlock15: Field: timestamp # Time of block creation16: Field: endorsements # Dictionary mapping Root DID ID to CA DIDID17: Field: metadata # Other relevant information (optional)18: Method: AddEndorsement(rootDID, caDID)19: endorsements[rootDID] â caDID20: Method: UpdateMetadata(info)21: metadata.update(info)22:23: Struct: BCChain24: Field: blocks # Dictionary mapping timestamp to BCBlock25: Method: AddBlock(block)26: blocks[block.timestamp] â block27: Method: GetBlock(timestamp)28: return blocks[timestamp]29: Method: GetLatestBlock()30: return blocks[max(blocks.keys())]31: # Initialize global blockchain32: Global: BC â BCChain()62Figure 4.2: Root DID Default ConnectionIn the beginning, a multi-root DID structure will be established andrecorded in the genesis block, which serves as the foundation for the DIDmanagement process. This multi-root structure is a collection of Root DIDs,each representing a trusted authority or node within the system, collectivelyforming the Root DID Set. The genesis block is recorded independently, asshown in Algorithm.463Algorithm 4 Initialization and Genesis Block Creation1: Input:2: Set of initial Root DIDs:3: {RootDID1, RootDID2, . . . , RootDIDn}4: Output:5: Genesis block represented as a mapping from Root DID to its set6: Procedure:7: GenesisBlock â {} # empty dictionary8: for all root â RootDIDs do9: GenesisBlock[root] â RootDIDs10: end for11: return GenesisBlockStep 1: One or more Root DIDs provide endorsement or validation forthe CA DID e1. The endorsement from these Root DIDs indicates thatthe CA DID e1 has been authenticated by a recognized, trusted authority,ensuring its legitimacy. This step is critical as it builds the foundationaltrust layer for the subsequent issuance of credentials.Step 2: Once the CA DID e1 is endorsed by a subset of the Root DIDset, it can request further credit or authorization for more extensive op-erations. This step typically involves additional validations, checks, andpotentially securing more endorsements from other Root DIDs within theset to strengthen its credibility. This process ensures that the CA DID hassufficient trust from the networkâs core authorities, facilitating its role inissuing credentials to users.64Algorithm 5 Credit Endorsement for CA DID e11: Input: CA DID object e1, Root DID set R, Block object LatestBlock2: Output: Updated e1 with endorsements, updated blockchain BC3: timestampâ CurrentTime() # Record the current timestamp4: EndorsementRecord â {} # Initialize dictionary to store endorsementsand credit5: for all Root â R do6: if Root decides to endorse e1 then7: Root.AddEndorsement(e1) # Root gives endorsement to e18: e1.ReceiveEndorsement(Root) # Update e1âs endorsedBy list9: EndorsementRecord[Root.id]â e1.id # Record this endorsementin the block10: end if11: end for12: # Get latest block for this endorsement operation13: LatestBlock â BC.GetLatestBlock()14: for all Root â R do15: if Root decides to endorse e1 then16: Root.AddEndorsement(e1)17: e1.ReceiveEndorsement(Root)18: LatestBlock.AddEndorsement(Root.id, e1.id)19: end if20: end for21: Return: Updated e1, updated LatestBlock65Figure 4.3: CA DID Credit Endorsement and Vertical Reinforcement66Step 3: After the endorsement is complete, the CA DID e1 establishesconnections with other CA DIDs (such as CA DID e2 and CA DID e3).Before connection, each CA DID will check the credit endorsed by RootDIDs. To enhance security, each CA DID is suggested to accept the otherone recognized by a few Root DIDs. This step forms a distributed networkof credential authorities, where each CA DID can interact with and verifythe credentials issued by others. Linking with other CA DIDs enhancesthe networkâs interoperability, enabling a decentralized exchange of verifiedcredentials across different authorities.Figure 4.4: CA DID Credit Horizontal Reinforcement and Credential Is-suanceStep 4: At this stage, the endorsed CA DID e1 issues a credential forthe Main DID u1, representing a user in the system. This credential serves67as proof that the Main DID u1 has been authenticated and granted certainrights or permissions by the CA DID e1. The issuance of the credentialrelies on the trust established in the previous steps, ensuring that the MainDID u1 is recognized as valid within the blockchain ecosystem.Algorithm 6 Horizontal Reinforcement and Credential Issuance1: Input: CA DID object e1, set of CA DIDs {e2, e3, . . . }, Main DIDobject u1, Blockchain object BC2: Output: Updated connections for e1, credential issuance recorded onblockchain3: # Horizontal reinforcement: verify endorsements and establish connec-tions4: for all e â {e2, e3, . . . } do5: Verified â True6: for all Root â R do # assume R is global Root DID set7: if Root has not endorsed e then8: Verified â False9: break10: end if11: end for12: if Verified then13: e1.AddEndorsement(e) # Establish connection between e1 and e14: e.ReceiveEndorsement(e1)15: else16: # Connection denied due to missing endorsements17: end if18: end for19: # Credential issuance by e1 to u120: e1.AddEndorsement(u1) # Issue credential (represented as endorse-ment)21: u1.ReceiveEndorsement(e1) # Main DID receives credential22: # Record issuance on blockchain23: LatestBlock â BC.GetLatestBlock()24: LatestBlock.AddEndorsement(e1.id, u1.id) # Log credential issuance25: Return: Updated e1, u1, and blockchain BC68Step 5: Finally, to maintain a robust and trustworthy network, new RootDIDs may be added to the Root DID set through consensus. For this tooccur, the existing Root DID set must achieve over two-thirds support forthe inclusion of the new Root DID TBD. This consensus mechanism ensuresthe security and legitimacy of the Root DID set, preventing unauthorizedentities from being added to the network.Figure 4.5: Root DID Addition and RevocationStep 6: Conversely, if a Root DID within the set (e.g., Root DID A)is found to be compromised or inactive, the Root DID set can be revoked.Similar to the process for adding a new Root DID, this action requires overtwo-thirds support from the Root DID set. This governance mechanismhelps maintain the integrity of the Root DID set, ensuring that only trustedentities remain in control of the endorsement and validation processes withinthe network.69Algorithm 7 Root DID Addition and Revocation1: Input: New Root DID object TBD, Existing Root DID objectRootDIDA, Root DID Set R, Blockchain object BC2: Output: Updated Root DID Set R, updated blockchain BC3: # â Adding a New Root DID â4: TBD requests addition to Root DID Set R5: AgreementCount â 06: for all Root â R do7: if Root agrees to add TBD then8: AgreementCount â AgreementCount + 19: end if10: end for11: if AgreementCount â¥ â2/3Ã |R|â then12: R.append(TBD) # Add new Root DID to set13: LatestBlock â BC.GetLatestBlock()14: LatestBlock.AddEndorsement(âAddRootâ, TBD.id) # Record addi-tion15: else16: # Addition rejected17: end if18: # â Revoking an Existing Root DID â19: if RootDIDA is compromised or inactive then20: AgreementCount â 021: for all Root â R do22: if Root agrees to revoke RootDIDA then23: AgreementCount â AgreementCount + 124: end if25: end for26: if AgreementCount â¥ â2/3Ã |R|â then27: R.remove(RootDIDA) # Revoke Root DID28: LatestBlock â BC.GetLatestBlock()29: LatestBlock.AddEndorsement(âRevokeRootâ, RootDIDA.id) #Record revocation30: else31: # Root DID remains active32: end if33: end if34: Return: Updated Root DID Set R, updated blockchain BC70In my multi-root system, the process of endorsement or issuance will berecorded in the blockchain to ensure transparency and immutability. Once asingle point of failure happens in the Root DID, CA DIDs and credentials canstill be effective for their endorsement from other Root DIDs. Meanwhile,the stolen Root DID can publish a new CA, but without endorsement fromother Root DIDs and CA DIDs, it can not be accepted widely in a shorttime, leaving time for Root DIDs to revoke the malicious node.4.1.3 Sub DIDsIn BCCoin, the use of sub-DIDs extends the utility and flexibility of themain DID. This section will focus on the rationale behind extending a mainDID to multiple sub-DIDs and the types of sub-DIDs that can be establishedto meet different user needs.The primary motivation for creating sub-DIDs from a Main DID is toprovide more granular control over the identity and credentials associatedwith different facets of an individualâs life. The main DID acts as a centralanchor for the userâs overall identity, while sub-DIDs are used to isolate anddifferentiate activities based on specific contexts. This separation enhancesprivacy, minimizes the exposure of sensitive information (especially the pri-vate key of Main DID), and allows for role-specific identities that cater tovarious use cases. For instance, an individual may not want to expose theiridentity in a professional setting, nor disclose work-related details in personalinteractions. By generating sub-DIDs, users can securely compartmentalizetheir identity while retaining overall control through the Main DID.To accommodate various identity needs but meanwhile limit the amountsof sub-DIDs, each Main DID in this system can generate three sub-DIDsthrough the Main DID, the private key of the Main DID, and a prescribedusage type.Individual Sub-DID: This sub-DID is intended for use in individual in-teractions, such as social networking, consumer transactions, and personalcommunications. It allows the user to maintain personal privacy while stillusing verifiable credentials. It helps in segregating personal data from otherprofessional or organizational aspects of life.Business Sub-DID: This sub-DID is used in the context of professionalactivities, such as job-related communications, tasks, or credentials. It en-ables the user to keep professional engagements distinct from personal ororganizational ones. For example, a professional sub-DID can store a userâswork credentials or be used to authenticate job-related transactions withoutinvolving personal information.71Organization Sub-DID: This sub-DID is created for interactions withorganizations or affiliations. It is particularly useful when users belong toa group, community, or institution that issues its credentials. The orga-nizational sub-DID is designed to manage interactions with such entities,allowing the user to engage with multiple organizations independently oftheir personal or professional identity.Algorithm 8 Generate Sub-DIDs from Main DIDInput: MainDIDOutput: IndividualSubDID, BusinessSubDID, OrganizationSubDIDfunction CreateSubDID(MainDID, Type, Private Key)SubDID â âSubDID-â + Type + â-â + Private Keyreturn SubDIDend functionIndividualSubDIDCount â 0BusinessSubDIDCount â 0OrganizationSubDIDCount â 0if IndividualSubDIDCount = 0 thenGenerate Individual Sub-DIDIndividualSubDID â CreateSubDID(MainDID, âIndividualâ, PrivateKey)IndividualSubDIDCount â IndividualSubDIDCount + 1end ifif BusinessSubDIDCount = 0 thenGenerate Business Sub-DIDBusinessSubDID â CreateSubDID(MainDID, âBusinessâ, PrivateKey)BusinessSubDIDCount â BusinessSubDIDCount + 1end ifif OrganizationSubDIDCount = 0 thenGenerate Organization Sub-DIDOrganizationSubDID â CreateSubDID(MainDID, âOrganizationâ,Private Key)OrganizationSubDIDCount â OrganizationSubDIDCount + 1end ifOutput: IndividualSubDID, BusinessSubDID, OrganizationSubDID724.2 Use Case: EducationTo evaluate the system, I conduct a preliminary simulation of its ap-plication in the context of educational digital credentials. This simulationdescribes a consortium of Canadian universities for decentralized credentialmanagement. Universities, including the University of British Columbia(UBC), the University of Toronto (UofT), and Simon Fraser University(SFU), act as root authorities, managing DIDs across the consortium. Theuse case focuses on Alice, a student navigating her academic journey throughthe system.Educational institutions worldwide also face challenges in issuing, veri-fying, and managing digital credentials in a secure, privacy-preserving, andinteroperable manner. The educational domain is selected as the primaryapplication context for this evaluation not only for its relevance to digitalcredential management, but also for its practicality and alignment with myown academic environment. As a student researcher, deploying and testingthe system within a university network is logistically more feasible than inother industries, due to the availability of institutional IT support, accessto relevant stakeholders, and the absence of strict commercial compliancebarriers. Moreover, the proposed BCChain architecture operates withouttransaction fees, making the cost of credential issuance, storage, and verifi-cation negligible â an important factor for non-profit educational institu-tions. Unlike in industrial or financial settings, where blockchain platformsoften incur high operational and maintenance costs and risk being perceivedmerely as cryptocurrency infrastructure, a fee-free, lightweight deploymentis well-suited for academic use. Additionally, universities typically foster amore open and experimental culture, with students and faculty being morereceptive to adopting innovative, no-cost systems. This combination of lowoperational barriers, minimal financial overhead, and high acceptance po-tential makes the educational sector a uniquely favorable environment fordemonstrating and refining BCChain.The feasibility of this use case is reinforced by the technical, organi-zational, and cultural characteristics of the academic setting. Technically,the BCChain framework can be deployed on a permissioned blockchain net-work managed by the participating universities, with minimal infrastructurerequirements compared to industrial-grade systems. Organizationally, theconsortium modelâhere represented by UBC, UofT, and SFUâmatchesexisting inter-university collaborations in Canada, ensuring that governanceprocesses are realistic and well-supported. Culturally, the academic commu-nityâs openness to trial technologies and the relatively small scale of initial73deployments lower both the technical and social risks of implementation.Furthermore, the absence of transaction fees removes a common barrier toblockchain adoption, enabling frequent credential exchanges without finan-cial concerns. These factors collectively ensure that the simulation scenariois not only technically sound, but also socially and economically practicalfor the intended stakeholders.EnvironmentThe simulation environment is implemented in Python 3.9, with prereq-uisites provided in the ârequirements.txtâ. Although a real blockchain isnot implemented, the environment mimics blockchain transactions by main-taining a list of credentials within the DID class. The simulation includesmethods that replicate the operational flow outlined in the use case steps,allowing for credential issuance, verification, and status updates. It canbe tested using Pythonâs built-in unit testing framework, enabling valida-tion of individual components and their interactions. The simulation runsin a controlled environment without connecting to external systems or realblockchain networks, ensuring a safe and isolated testing framework for de-veloping the proposed model. This setup allows for effective evaluation andrefinement of the DPKI system, facilitating the exploration of various sce-narios before any real-world deployment.The implementation of BCChain is realized within a simulated environ-ment rather than a fully operational blockchain, due to several practicalconstraints. Notably, existing frameworks such as Hyperledger Indy havebeen deprecated, and alternative systems like Trustchain involve hundredsof interdependent files, making real deployment infeasible within the scopeof this work. Additionally, key components of platforms such as OrgBookare difficult to reproduce accurately, further complicating any direct imple-mentation. By contrast, Pythonâa language familiar to the developmentteamâprovides a flexible and accessible platform for building the simula-tion. The environment, implemented in Python 3.9 with dependencies listedin ârequirements.txtâ, mimics blockchain transactions by maintaining cre-dential records within DID objects, while supporting all operational flowsdefined in the use case, including issuance, verification, endorsement, andstatus updates. This setup ensures a safe, isolated, and manageable testingframework, enabling thorough evaluation and iterative refinement of BC-Chainâs DPKI model prior to potential real-world deployment.74Enrollment and Credential Endorsement:Alice is admitted to DoAI at UBC. Upon enrollment, UBC generatesAliceâs main DID, serving as her primary digital identity. Her academicstanding is validated and recorded on the BCChain consortiumâs blockchain.UBCâs CA endorses Aliceâs initial credits, establishing a foundational recordwithin the system. Since digital credentials should be sent and received inthe use case, I have modified DID structure to better describe the situation,as shown in Algorithm.9Course and Departmental Credentials:As part of her program, Alice takes a course within the Machine Learningbranch of DoAI. To manage her interactions in academic life, she generatesa Sub-DID (Alice1) derived from her primary DID. Upon successfully com-pleting a required course, DoAI issues her a course completion credentialtied to her Sub-DID.Graduation and Credential Transfer:After completing her masterâs program, Alice receives her graduate cre-dentials from DoAI, which are anchored to her main DID. These credentialsare enriched with detailed academic data, making them portable across in-stitutions. Alice then applies for a PhD in Computer Science at UofT, whereher credentials are verified through BCChainâs decentralized infrastructure.75Algorithm 9 Updated DID and Block Structure with Digital CredentialSupport1: Struct: DID2: Field: id # Unique identifier for this DID3: Field: endorsements # List of DIDs that this DID endorses4: Field: endorsedBy # List of DIDs that endorse this DID5: Field: publicKey # Associated public key6: Field: metadata # Other relevant information (e.g., creation time,status)7: Field: credentials # List of received Digital Credentials8: Method: AddEndorsement(targetDID)9: endorsements.append(targetDID)10: Method: ReceiveEndorsement(fromDID)11: endorsedBy.append(fromDID)12: Method: UpdateMetadata(info)13: metadata.update(info)14: Method: SendCredential(targetDID, credential, BC)15: targetDID.ReceiveCredential(credential)16: LatestBlock â BC.GetLatestBlock()17: LatestBlock.AddTransaction(self.id, targetDID.id, credential)18: Method: ReceiveCredential(credential)19: credentials.append(credential)20:21: Struct: BCBlock22: Field: timestamp # Time of block creation23: Field: endorsements # Dictionary mapping Root DID ID to CA DIDID24: Field: metadata # Other relevant information (optional)25: Method: AddEndorsement(rootDID, caDID)26: endorsements[rootDID] â caDID27: Method: UpdateMetadata(info)28: metadata.update(info)29: Method: VerifyTransaction(transaction)30: # Returns True if transaction exists in endorsements or metadata31: return transaction.id in endorsements.values() or transaction.id in metadata76Cross-Institutional Transition:Upon successful admission to UofT, Aliceâs academic credentials are up-dated and transferred within the BCChain network. Her DID is recognizedand updated by UofTâs Certificate Authority, preserving the integrity andcontinuity of her academic record as she transitions to a new institution.Through this scenario, BCChain ensures seamless, secure, and privacy-preserving credential management, supporting Aliceâs progression acrossmultiple academic institutions while maintaining the trust of both CAs andDID users in BCChain. The whole process is shown in Figure 4.6.Step 0:Before initiating the event-driven simulation, the blockchain in-frastructure must be established, ensuring that the system operates withina secure and decentralized framework. In Algorithm.4, the blockchain is ini-tialized by creating a genesis block, which defines the fundamental configu-ration for the network. This genesis block sets up the Root DID Document,which outlines the core entities within the consortiumâsuch as universitieslike UBC, UofT, and SFUâthat will act as Root DIDs. Each one is grantedspecific permissions, including the ability to issue, validate, and revoke cre-dentials. In step 0, I also regulate some basic functions of BCChain thatsupport the whole process.To maintain the integrity and security of the decentralized credentialingsystem, a consensus mechanism is employed to regulate changes to the RootDIDs. Any additions or removals of Root DIDs require the approval of apredefined threshold of existing Root DIDs. For instance, when a new RootDID is proposed, it must receive approval from two-thirds of the currentRoot DIDs in the form of digital signatures. Similarly, to remove a RootDID, a consensus vote must be achieved. This ensures that no single entitycan unilaterally control the networkâs core identity management functions,preserving trust and decentralization across the consortium.It then outlines the process of generating and issuing an X.509 CA cer-tificate within the context of a decentralized identity (DID) system. Theprocedure begins by creating a certificate template and populating it withthe necessary X.509 components (e.g., subject name, issuer, public key).Permissions relevant to the certificateâs functionality are incorporated asextensions to the X.509 standard, which allows for a flexible specification ofthe certificateâs role. These permissions include actions such as issuing cre-dentials, validating credentials, and setting specific constraints on the CAâscapacity to delegate further certificate issuance, as defined by the Path Con-straints. The final certificate is signed using the issuerâs private key, ensuringits authenticity and integrity. It is then published on the blockchain, which77Figure 4.6: Educational Usage Illustration of BCChain78guarantees immutability and decentralized verification.Next step details how to validate a userâs information and subsequentlypublishing a digital credential on the blockchain. The key focus of thisprocedure is flexibility in handling various types of user-submitted data,such as encrypted information, zero-knowledge proofs (ZKProof), or existingdigital credentials. Depending on the validation type, the algorithm decryptsand verifies the information or directly checks the blockchain for credentialvalidity. If the validation is successful, the system proceeds to generate anew digital credential, linking it to the issuing DID and the userâs DID.Algorithm 10 Step 0: Initialize Blockchain and Generate Aliceâs Main DID1: Input: Root DID set {UBC,UofT, SFU}, User Alice2: Output: Initialized blockchain BC, Genesis Block GenesisBlock, MainDID object AliceDID3: # â Initialize blockchain â4: GenesisBlock â BCBlock()5: GenesisBlock.timestamp â CurrentTime()6: for all Root â {UBC,UofT, SFU} do7: RootDID â DID(id = Root) # Create Root DID object8: RootDID.UpdateMetadata({âpermissionsâ: [âissueâ, âvalidateâ,ârevokeâ]})9: GenesisBlock.AddEndorsement(RootDID.id, âRootâ) # RecordRoot DID in genesis block10: end for11: BC â BCChain()12: BC.AddBlock(GenesisBlock)13: # â Generate Aliceâs Main DID â14: AliceDID â DID(id = âAliceâ)15: AliceDID.UpdateMetadata({âcreationTimeâ: CurrentTime(), âstatusâ:âactiveâ})16: # â Record Aliceâs DID on blockchain â17: LatestBlock â BC.GetLatestBlock()18: LatestBlock.AddEndorsement(âGenesisâ, AliceDID.id) # Link AliceDID to genesis block19: Return: BC, GenesisBlock, AliceDIDThe credential includes a timestamp and any specified requirements (e.g.,expiration date, access permissions). After the credential is signed by theissuerâs private key, it is published on the blockchain, ensuring that thecredential is both verifiable and immutable. This approach offers a robust79mechanism for maintaining trust in decentralized credential systems, en-suring data privacy through flexible validation methods and security viablockchain-backed credentials. The use of flexible validation types and com-prehensive credential requirements makes this system adaptable to variousdecentralized identity use cases, particularly those requiring enhanced pri-vacy features like zero-knowledge proofs. A ZKProof is a cryptographicmethod that enables one party (the prover) to demonstrate to another (theverifier) that a given statement is true, without revealing any additionalinformation beyond the validity of the statement itself. This approach isparticularly valuable in decentralized identity systems where data privacy iscrucial, as it allows for validation without exposing sensitive user informa-tion [101].Algorithm 11 Step 1: Endorse Credit (UBC Root to DoAI)1: Input: Root DID object UBC Root, CA DID object DoAI, Blockchainobject BC2: Output: Updated DoAI with endorsement from UBC Root, updatedblockchain BC3: # â Step 1.1: Validate UBC Root within Root DID set â4: if UBC Root.id not in R then # R is the Root DID set from genesisblock5: return Error(âUBC Root validation failed.â)6: end if7: # â Step 1.2: UBC Root endorses DoAI â8: UBC Root.AddEndorsement(DoAI) # Record that UBC Root endorsesDoAI9: DoAI.ReceiveEndorsement(UBC Root) # Update DoAIâs endorsedBylist10: # â Step 1.3: Record endorsement on the blockchain â11: LatestBlock â BC.GetLatestBlock()12: LatestBlock.AddEndorsement(UBC Root.id, DoAI.id) # Link endorse-ment in blockchain13: Return: Updated DoAI, updated BCStep 1: The process begins with the endorsement of credits within theCanadian University Consortiumâs blockchain infrastructure. UBCâs RootDID validates DoAI and generates an initial credit endorsement. This servesas formal recognition of DoAIâs academic status and its authorization to is-sue credentials within the consortiumâs distributed ledger. The endorsement80is represented as an X.509 CA certificate, ensuring it is verifiable and se-curely recorded on the blockchain. UBC Root functions as one of the RootDIDs published in the Root Document, which has the right to formalize subCAs with regulated permissions and path constraints.Algorithm 12 Step 2: Enhance Endorsement (DoAI)1: Input: CA DID object DoAI, Root DID object TargetRootDID,Blockchain object BC2: Output: Updated DoAI with additional endorsement, updatedblockchain BC3: # â Step 2.1: Validate Target Root DID exists â4: if TargetRootDID.id not in R then # R is Root DID set from genesisblock5: return Error(âTarget Root DID validation failed.â)6: end if7: # â Step 2.2: Target Root DID endorses DoAI â8: TargetRootDID.AddEndorsement(DoAI) # Record endorsement9: DoAI.ReceiveEndorsement(TargetRootDID) # Update DoAIâs en-dorsedBy list10: # â Step 2.3: Record endorsement on blockchain â11: LatestBlock â BC.GetLatestBlock()12: LatestBlock.AddEndorsement(TargetRootDID.id, DoAI.id) # Link en-dorsement in blockchain13: Return: Updated DoAI, updated BCStep 2: DoAI at UBC enhanced its credit endorsement from the Univer-sity Consortium and peer CAs, which enriches the credential data with spe-cific academic context and departmental validations. UBC Main DID CArefers to another CA directly associated with UBC Root, which issues cre-dentials for students to register their DIDs. It is also equipped with anoffline agency that can validate the information of students and then pro-vide ZK credentials to protect the privacy and trust of their DIDs. Creditin this context encapsulates the initial credit endorsement received by DoAIlike the credential from UBC Root.81Algorithm 13 Step 3: Register Main DID Alice1: Input: CA DID object UBC Main DID CA, Main DID object Alice,Blockchain object BC2: Output: Registered Main DID Alice, updated blockchain BC3: # â Step 3.1: Validate the request for registering Alice â4: if Alice.id already registered in blockchain then5: return Error(âMain DID Alice is already registered.â)6: end if7: # â Step 3.2: CA DID endorses Main DID Alice â8: UBC Main DID CA.AddEndorsement(Alice) # Record endorsement9: Alice.ReceiveEndorsement(UBC Main DID CA) # Update endorsedBylist10: # â Step 3.3: Record registration on blockchain â11: LatestBlock â BC.GetLatestBlock()12: LatestBlock.AddEndorsement(UBC Main DID CA.id, Alice.id)13: Return: Updated Alice, updated BCStep 3: When Alice registers her Main DID, the UBC Main DID CA val-idates her admission and generates her primary registration certificate. Thiscertificate formally records Aliceâs Main DID on the blockchain, anchoringher digital academic identity within UBCâs ecosystem. The endorsementnot only confirms the authenticity of Aliceâs academic credentials but alsoensures that any future credentials, endorsements, or verifications can be re-liably linked to her Main DID. By integrating offline validation, blockchain-based recording, and hierarchical CA endorsements, this step constructs asecure, privacy-conscious, and verifiable foundation for Aliceâs ongoing aca-demic activities. The process exemplifies the combination of institutionalverification with blockchain immutability, enabling a scalable and trustwor-thy digital identity framework suitable for managing academic credentialsacross multiple departments and programs.82Algorithm 14 Step 4: Generate Sub DID Alice11: Input: Main DID object Alice, Blockchain object BC2: Output: Generated Sub DID Alice1, updated blockchain BC3: # â Step 4.1: Verify Main DID Alice â4: if Alice.id not registered in blockchain then5: return Error(âMain DID Alice verification failed.â)6: end if7: # â Step 4.2: Create new Sub DID object â8: Alice1 â DID() # Initialize Sub DID9: Alice1.id â GenerateUniqueID()10: Alice1.GenerateKeyPair() # Generate key pair11: # â Step 4.3: Record Sub DID registration on blockchain â12: LatestBlock â BC.GetLatestBlock()13: LatestBlock.AddEndorsement(Alice1.id, Alice.id) # Link Sub DID toMain DID14: Return: Alice1, updated BCStep 4: To manage specific academic interactions, Alice generates a sub-ordinate identifier (Sub-DID Alice1) from her main DID. This Sub-DIDallows her to engage in academic activities, particularly within the MachineLearning program, while preserving the privacy and security of her primaryacademic identity. The hierarchical link between her main DID and Sub-DIDensures proper credential management and authentication, which decreasesthe risks of exposing the private key of her Main DID. The Sub-DID Alice1follows the rules in Section 4.1.3, where Alice has no concern about forget-ting new key pairs. Alice1 will be generated from Aliceâs Main DID, UsageType regulated in this blockchain, and her private key, and thus flexible tomanage and recover. In Section 4.1.3, I mentioned the procedure to createSub DIDs. Sub DIDs do not have certificates to validate their authenticitysince they are produced totally from the Main DID without a nonce. Userscan only generate Sub DIDs when their Main DIDs are validated and theusage type of Sub DID is in coordination with the system requirement.83Algorithm 15 Step 5: Issue Machine Learning Program Credential for SubDID Alice11: Input: CA DID object DoAI, Sub DID object SubDID Alice1,Blockchain object BC2: Output: Updated SubDID Alice1 with endorsement and ML creden-tial, updated blockchain BC3: # â Step 5.1: Validate authority of DoAI â4: if DoAI.id not in authorized CA DID set then5: return Error(âDoAI validation failed.â)6: end if7: # â Step 5.2: DoAI endorses SubDID Alice1 (if not endorsed) â8: if DoAI.id not in SubDID Alice1.endorsedBy then9: DoAI.AddEndorsement(SubDID Alice1)10: SubDID Alice1.ReceiveEndorsement(DoAI)11: end if12: # â Step 5.3: Generate Machine Learning Program credential â13: mlCredentialData â {program: âMachine Learningâ, issueDate: Cur-rentTime()}14: mlCredential â CreateDigitalCredential(IssuerID=DoAI.id, Recipien-tID=SubDID Alice1.id, Data=mlCredentialData)15: # â Step 5.4: DoAI sends credential to SubDID Alice1 â16: DoAI.SendCredential(SubDID Alice1, mlCredential, BC)17: # â Step 5.5: Record endorsement and credential on blockchain â18: LatestBlock â BC.GetLatestBlock()19: LatestBlock.AddEndorsement(DoAI.id, SubDID Alice1.id)20: LatestBlock.AddTransaction(DoAI.id, SubDID Alice1.id, mlCredential)21: Return: Updated SubDID Alice1, updated BCStep 5: The Machine Learning program is authorized by DoAI, whichrequires the necessities for studentsâ graduation. The faculty-specific creden-tials enable Alice to engage with departmental resources while maintainingappropriate access controls. In Algorithm 16, DoAI will validate the Ma-chine Learning Program and submit the credentials and CA certification ifDoAI satisfies the authorization regulated by UBC Root.84Algorithm 16 Step 6: Issue Lecture Pass for Sub DID Alice11: Input: DoAI DID object DoAI, Sub DID object Alice1, Blockchainobject BC2: Output: Updated Alice1 with endorsement, updated blockchain BC3: # â Step 6.1: Verify Sub DID Alice1 â4: if Alice1.id not registered in blockchain then5: return Error(âSub DID Alice1 verification failed.â)6: end if7: # â Step 6.2: Check if DoAI has already endorsed Alice1 â8: if DoAI.id not in Alice1.endorsedBy then9: DoAI.AddEndorsement(Alice1) # Record endorsement10: Alice1.ReceiveEndorsement(DoAI) # Update endorsedBy list11: else12: # Already endorsed, skip endorsement13: end if14: # â Step 6.3: Record endorsement on blockchain â15: LatestBlock â BC.GetLatestBlock()16: LatestBlock.AddEndorsement(DoAI.id, Alice1.id)17: Return: Updated Alice1, updated BCStep 6: Through her Sub-DID Alice1, Alice obtains formal validation forthe successful completion of a course or module aligned with the MachineLearning program requirements. The issuance of a lecture pass representsa focused academic credential tied to a specific course, which supplementsAliceâs broader academic profile maintained under her Main DID. Beforerecording the endorsement, the system verifies whether Alice1 has alreadybeen endorsed by DoAI, ensuring idempotency and preventing redundantendorsements that could compromise data clarity or create inconsistenciesin the blockchain ledger. Once validated, DoAI adds the endorsement andAlice1 receives confirmation, thereby updating her list of endorsers. Theendorsement is then immutably recorded on the blockchain, guaranteeingthe integrity and traceability of the credential, supporting both auditabilityand trust in academic validation processes. This approach preserves privacyboundaries by associating credentials with a Sub-DID while maintaining ver-ifiable links to the Main DID, thereby ensuring that each credential can beindependently verified while remaining part of Aliceâs comprehensive aca-demic record.85Algorithm 17 Step 7: Issue Graduate Credential for Alice1: Input: DoAI DID object DoAI, Main DID object Alice, Blockchainobject BC2: Output: Updated Alice with graduate credential, updated blockchainBC3: # â Step 7.1: Validate authority of DoAI â4: if DoAI.id not in authorized CA DID set then5: return Error(âDoAI validation failed.â)6: end if7: # â Step 7.2: Generate graduate credential â8: gradCred â DoAI.SendCredential(Alice, GraduateInfo, Validation-Type, CredentialRequirements)9: Alice.ReceiveCredential(gradCred) # Alice adds credential to own DID10: # â Step 7.3: Record credential issuance on blockchain â11: LatestBlock â BC.GetLatestBlock()12: LatestBlock.addTransaction(gradCred)13: return gradCred, updated Alice, updated BCStep 7: Upon successfully completing her masterâs program, Alice re-ceives a graduate credential issued by the Department of Artificial Intel-ligence through her Main DID. The credential comprehensively encapsu-lates her academic achievements, including degree completion, course per-formance, and any additional validations required by the department. Be-fore issuance, the system verifies the authority of DoAI to ensure that onlyauthorized Certification Authorities can generate graduate credentials, pre-venting unauthorized or fraudulent certifications. The credential is trans-mitted using the SendCredential method, which guarantees secure deliveryto Aliceâs DID, while ReceiveCredential ensures that the credential is prop-erly integrated into her digital academic profile. Subsequently, the issuanceis immutably recorded on the blockchain, providing auditability, traceability,and tamper-evidence. This design maintains a verifiable, permanent recordof Aliceâs academic accomplishments, while linking her graduate credentialto her Main DID to preserve both privacy and institutional trust in thecredentialing process.86Algorithm 18 Step 8: Verify Credentials for PhD Application1: Input: University CA DID object UofT CS, Main DID objectMainDID Alice, Blockchain object BC2: Output: Boolean or evaluation result indicating credential validity andadmission eligibility3: # â Step 8.1: Retrieve latest block for verification â4: LatestBlock â BC.GetLatestBlock()5: for all credential â MainDID Alice.credentials do6: validOnChain â LatestBlock.verifyTransaction(credential)7: if validOnChain == False then8: return FALSE # Credential not found or invalid on blockchain9: end if10: if credential.isExpired() then11: return FALSE # Credential expired12: end if13: end for14: # â Step 8.2: Evaluate Aliceâs qualifications for PhD admission â15: // Note: This is a scenario-driven method, simulating UofTâs admissiondecision16: result â UofT CS.evaluateQualifications(MainDID Alice)17: return resultStep 8: When Alice applies for the PhD program at the Universityof Torontoâs Computer Science department, the university must verify theauthenticity, integrity, and validity of her academic credentials. Step 8ensures this process by iterating over all credentials stored within AliceâsMain DID and checking each against the blockchain using the verifyTrans-action method. This verification confirms that credentials were properlyissued, have not been tampered with, and are still valid in terms of expira-tion or revocation status. Once blockchain validation is complete, the sys-tem applies a scenario-driven evaluation through the evaluateQualificationsmethod, which simulates UofTâs admission decision based on her academicrecord, degree completion, and relevant performance metrics. By combin-ing blockchain-based validation with institutional evaluation, this step pro-vides a reliable, tamper-evident mechanism for assessing Aliceâs eligibilityfor further academic programs while preserving the integrity of her digitalcredentials.87Algorithm 19 Step 9: Issue Certificate for Registering Main DID Alice1: Input: UofT CS DID object UofT CS, Main DID object Alice,Blockchain object BC2: Output: Updated Alice with admission certificate, updated blockchainBC3: # â Step 9.1: Verify credentials for PhD application â4: if Step8 VerifyResult(UofT CS, Alice, BC) == FALSE then5: return Error(âCertificate issuance request validation failed.â)6: end if7: # â Step 9.2: Generate admission certificate â8: admissionCred â UofT CS.SendCredential(UofT CS, Alice, AliceInfo,ValidationType, CredentialRequirements)9: # â Step 9.3: Alice receives the admission certificate â10: Alice.ReceiveCredential(admissionCred)11: # â Step 9.4: Record the credential issuance on blockchain â12: LatestBlock â BC.GetLatestBlock()13: LatestBlock.addTransaction(admissionCred)14: return Updated Alice, updated BCStep 9: After successful verification of Aliceâs graduate credentials andeligibility for admission, the University of Torontoâs Computer Science de-partment proceeds to issue her formal admission certificate. Step 9 capturesthis process by generating a cryptographically signed credential through theSendCredential method and delivering it to Aliceâs Main DID via the Re-ceiveCredential mechanism. This ensures that Aliceâs new academic status issecurely linked to her existing digital identity while preserving the integrityand authenticity of the record. The issuance is then immutably recordedon the consortium blockchain by adding a transaction to the latest block,which allows future verification by both the university and external parties.By maintaining a tamper-evident history of credential issuance and bind-ing the new certificate to previously validated academic records, this stepestablishes a continuous and auditable academic identity for Alice acrossinstitutional boundaries.88Algorithm 20 Step 10: Update Main DID1: Input: UofT Main DID CA object UofT Main DID CA, Main DIDobject Alice, Updated Main DID object Alice Updated, Blockchain ob-ject BC2: Output: Updated Alice Updated with new certificate, updatedblockchain BC3: # â Step 10.1: Verify authority of UofT Main DID CA â4: if UofT.verify(UofT Main DID CA) == FALSE then5: return Error(âUofT Main DID CA validation failed.â)6: end if7: # â Step 10.2: Generate new certificate and send to updated DID â8: newCert â UofT Main DID CA.sendCredential(Alice Updated, Alice-NewInfo, ValidationType, CredentialRequirements)9: Alice Updated.receiveCredential(newCert)10: # â Step 10.3: Record the update on blockchain â11: LatestBlock â BC.GetLatestBlock()12: LatestBlock.addTransaction(newCert)13: return Updated Alice Updated, updated BCStep 10: In the final stage of the academic identity lifecycle, the Univer-sity of Torontoâs Main DID CA updates Aliceâs Main DID to reflect her newstatus as a PhD student. The process begins with verification of the CAâsauthority, ensuring that only an authorized institution can issue or updatecredentials. A new certificate is then generated and sent to Aliceâs up-dated Main DID using the sendCredential and receiveCredential methods,guaranteeing cryptographic integrity and direct binding to Aliceâs digitalidentity. This update is subsequently recorded as an immutable transac-tion on the consortium blockchain, maintaining a tamper-evident history ofcredential issuance and DID modifications. By either revoking the formerDID or appending a new certificate to the existing DID, the system pre-serves the continuity of Aliceâs academic identity while securely reflectingher progression. This approach enables auditable, verifiable, and institution-independent tracking of academic achievements, reinforcing trust and inter-operability across the consortium network.89In blockchain records, the procedure demonstrates the timestamp mech-anism to ensure transparency and immutability. This practical applica-tion describes the effective utilization of hierarchical DIDs and blockchain-based credentials in managing complex academic transitions within a multi-institutional consortium. The implementation successfully maintains theintegrity of academic credentials while facilitating secure and verifiable aca-demic progression across institutions.4.3 ValidationTo assess the effectiveness of BCChain in addressing the challenges out-lined in the previous sections, its mechanisms can be examined in comparisonto existing systems as summarized in Tables 3.1 and 3.2.In contrast to conventional PKI systems, BCChain mitigates this riskthrough a consortium-based DID root architecture, where multiple RootDIDs collectively manage the issuance of subordinate DIDs and associ-ated certificates. Each endorsement from a Root DID is recorded on theblockchain, ensuring that any certificate issued by a compromised node canbe detected and invalidated. Moreover, by decoupling the authority into adistributed set of Root DIDs rather than relying on a single CA, BCChaineliminates single points of failure and substantially reduces the likelihoodof large-scale unauthorized issuance. This approach contrasts with exist-ing systems such as Trustchain or OrgBook, which either rely on a singleroot authority or implement weaker verification mechanisms, thus provid-ing BCChain with a significant security advantage in maintaining certificateintegrity.MitM attacks pose a significant threat to the integrity and confidentialityof communications in digital credential systems, particularly when certifi-cates or DIDs are transmitted over insecure channels. BCChain addressesthis challenge by integrating on-chain verification for all credential endorse-ments and certificate transactions. Each Sub-DID or Main DID must obtainendorsements from authorized Root DIDs, and these endorsements are im-mutably recorded on the blockchain. When a verifier, such as an academicinstitution or service provider, queries a credential, it can validate both theauthenticity of the credential and the chain of endorsements in real-time.This ensures that any attempt by an adversary to intercept or modify cre-dentials is immediately detectable. Although most decentralized system canhandle MitM attacks, systems like Proofchain still face the question. BC-Chainâs on-chain endorsement mechanism provides continuous, automated90protection against MitM attacks, enhancing the reliability and trustworthi-ness of credential verification.Different from traditional attacks in centralized systems, decentralizedsystems always face the problem of Sybil Attacks, which occur when anadversary generates a large number of pseudonymous identities to gain dis-proportionate influence or disrupt the functioning of a network. In digitalcredential ecosystems, this can manifest as fraudulent credential issuanceor manipulation of trust relationships. BCChain mitigates such threatsthrough a combination of strong identity binding and consortium-basedDID root governance, referring to Orgbook, CeCoin and DeTract. EachDIDâwhether Main or Subâmust undergo identity verification that ties itto a unique, real-world entity. Endorsements are only granted by autho-rized Root DIDs, and every endorsement is recorded on-chain, creating anauditable trail that prevents the creation of multiple fraudulent identities.Unlike systems that rely solely on distributed ledger verification of min-ers (e.g., Proofchain) or loosely enforced identity binding (e.g., Trustchain),BCChain ensures that any attempt to issue multiple credentials for a singleentity is automatically detected and rejected. Furthermore, the consortiumgovernance model introduces cross-validation among multiple Root DIDs,further reducing the feasibility of coordinated Sybil attacks. Collectively,these measures provide robust protection against identity-based manipula-tions while preserving privacy and compliance with regulatory requirements.Various approaches exist to mitigate the risks associated with central-ized certificate authorities, each leveraging distributed or semi-distributedmechanisms. One common strategy is dual-system operation, wherein a tra-ditional PKI runs in parallel with a blockchain ledger that records all certifi-cate issuance and revocation events (such as DeTract). This configurationenhances transparency and enables auditable verification, but it does notfundamentally eliminate the single-point-of-failure risk inherent to the cen-tralized CA, as the issuance authority itself remains singular. Another ap-proach involves CA miners, in which multiple distributed entities participatein a consensus mechanism to approve certificate issuance (such as CeCoin,ProofChain). While this model increases resilience against unilateral com-promise, it incurs substantial operational cost due to consensus incentivesand computational overhead, which may limit scalability in practice. In con-trast, BCChain adopts an embedded consortium-based model, integratingtrusted DIDs within organizational governance structures while recordingendorsements and credentials on the blockchain (such as Trustchain, Org-book). This embedded design balances decentralization and efficiency, re-ducing reliance on expensive consensus mechanisms while maintaining high91assurance of certificate integrity and auditability. By selecting the embeddedmode does not necessarily mean better, BCChain only hopes to achieve apractical trade-off: it mitigates CA compromise risks more effectively thansingle-root systems, avoids the high cost of CA miners, and ensures thatcredential issuance remains verifiable and secure.The most critical challenges in Trustchain is ensuring that each digitalidentity, whether a primary DID or subordinate DID, is uniquely associ-ated with a real-world entity while maintaining privacy, which in contrast isconsidered in many other weakly digital-credential-linked systems. Existingdigital credential systems often fail to provide a robust mechanism for thismapping. Referring to Orgbook, BCChain addresses this challenge througha combination of multi-level identity verification and on-chain recording.Each subordinate DID registration is authorized by its corresponding mainDID, creating an embedded hierarchical relationship that enforces identityprovenance. Furthermore, BCChain integrates real-world verification meth-odsâsuch as license or credential checksâbefore associating a DID withan entity. Endorsements from trusted certificate authorities or consortiumnodes are then recorded on-chain, providing verifiable proof of authentic-ity that can be audited by any network participant. This hybrid approachensures that digital identities are uniquely bound to real individuals, signif-icantly reducing the risk of Sybil attacks while maintaining decentralizationand transparency. By embedding identity verification into the credentialissuance and endorsement workflow, BCChain achieves a practical balancebetween security, auditability, and privacy preservation.In traditional X.509 PKI, the trust anchor is typically a single root Cer-tificate Authority (CA), upon which the entire certificate chain depends.Any compromise or mismanagement of this root CA can result in widespreadtrust failures, representing an inherent vulnerability of centralized models.Some distributed attempts, such as Proofchain and CeCoin, weaken thenotion of a single trust anchor by leveraging distributed ledger records orhierarchical up/down DIDs. However, these approaches often lack cleartrust-level delineation or verifiable hierarchical relationships, complicatingthe logical assessment of overall trustworthiness. BCChain addresses thischallenge through an embedded multi-root trust anchor design, advancedon Trustchain. The system establishes multiple trusted consortium DIDroot nodes, each capable of issuing subordinate certificates or credentials,with all operations immutably recorded on the blockchain. This configu-ration preserves the verifiability of a chain-of-trust while mitigating singlepoints of failure. Compared to purely distributed or single-CA models, BC-Chain provides a trust model that balances both verifiability and resilience,92ensuring robust hierarchical trust without sacrificing decentralization bene-fits.Transparency constitutes another critical challenge for digital credentialsystems. Systems lacking transparency often fail to provide traceability forcertificate issuance, revocation, and update processes, potentially obscuringmalicious behavior or misconfigurations. As observed in the comparativeanalysis, conventional PKI systems exhibit limited transparency, whereasblockchain-based frameworks can employ public ledgers or other measure-ments to enhance transparency.Operational and maintenance costs should be a major concern for blockchain-based digital credential systems. Traditional DPKI implementations oftenrely on fully decentralized consensus mechanisms, such as Proof-of-Work ordistributed CA miners, which require significant computational resourcesand continuous network incentives. While these mechanisms enhance secu-rity and decentralization, they introduce substantial financial and energyoverhead, which may render the system impractical for routine credentialissuance and verification. Alternative designs, such as hybrid models thatuse separate blockchains solely for recording transactions while outsourcingcomputation to centralized servers, reduce immediate costs but reintroducevulnerabilities related to trust centralization and single points of failure.Referring to Orgbook, BCChain addresses the cost challenge by adoptingan embedded consortium model, in which a limited set of trusted DID rootauthorities manage verification and credential endorsement tasks, while allcritical credential and endorsement data are recorded on the blockchain.This architecture allows the system to maintain transparency, auditabil-ity, and identity uniqueness without incurring the high computational andincentive costs of fully decentralized mining. By embedding credential verifi-cation logic within the consortium nodes and using the blockchain primarilyfor immutable recording and verification of endorsements, BCChain achievesa practical compromise: operational efficiency and cost-effectiveness are pre-served, while the system retains strong guarantees of security, provenance,and decentralized trust. This embedded design demonstrates that carefularchitectural specialization can address cost constraints without sacrificingthe robustness of digital credential management.In summary, the validation of BCChain against the identified challengesdemonstrates its comprehensive robustness across multiple dimensions. Thesystem effectively addresses threats such as CA compromise, man-in-the-middle attacks, and Sybil attacks through a consortium-based multi-roottrust model, real-time on-chain verification, and strong identity bindingmechanisms. In terms of X.509 compatibility, BCChain preserves a veri-93fiable chain-of-trust via embedded consortium DID roots while maintainingdecentralization and full transparency through on-chain credential and DIDoperations. Moreover, BCChain provides practical solutions for digital cre-dential deployment, enforcing privacy-preserving identity binding and signif-icantly reducing operational costs compared to alternative blockchain-basedinfrastructures. Overall, BCChain achieves a balanced integration of secu-rity, trust verifiability, and operational efficiency, positioning it as a robustand practical framework for secure digital credential management.94Chapter 5Conclusion5.1 Summary of WorkThis thesis explored the potential of integrating Decentralized PublicKey Infrastructure (DPKI) with the X.509 certificate standard, focusingspecifically on its application in digital credentials. By identifying the gap inacademic research, I leveraged Trustchain as a baseline to address the short-comings in trust validation and revocation mechanisms, proposing modifi-cations to enhance the systemâs compatibility with X.509. my proposedsystem, BCChain, was designed to provide a more secure, decentralizedframework for digital credential management.Through simulation-based experiments, I demonstrated the theoreticalfeasibility of the system, validating its key features such as multi-root archi-tecture, timestamp-based validation, and revocation mechanisms. However,it is important to note that my work has not been tested on a real blockchainnetwork, meaning the systemâs performance in a live, decentralized environ-ment remains unverified. The simulations have provided valuable insights,but further research is required to evaluate its real-world scalability, security,and usability.5.2 Future DirectionsLooking forward, several avenues for future development arise. Onepromising direction involves the integration of AI agents into the systemto further enhance the automation, intelligence, and adaptability of DPKImanagement. AI agents could be used to dynamically manage digital cre-dentials, making real-time decisions about trust, validation, and revocationbased on contextual data. This would allow for more efficient handling ofidentity verification and fraud detection.AI agents refer to software systems that can perceive their environment,make decisions, and take actions autonomously to achieve specific goals[102]. In the context of DPKI, AI agents could be deployed to handle var-95ious tasks such as identity verification, fraud detection, and the automatedmanagement of certificates. They could dynamically analyze data streamsin real time, identifying suspicious behaviors or anomalies and taking ap-propriate actions to revoke or validate digital credentials. Combining AIâsdecision-making capabilities with the cryptographic security of blockchainwould improve the systemâs responsiveness and resilience. Trust anchors inthese circumstances are highly significant.Meanwhile, a future iteration of the BCChain system could also be de-ployed on a real blockchain platform such as Ethereum or Hyperledger toassess its performance in a decentralized, live environment. This real-worlddeployment would enable the evaluation of factors such as network latency,security robustness, and system scalability. The synergy between AI agentsand blockchain could open new possibilities for adaptive, intelligent, and se-cure decentralized identity management systems, ultimately improving bothuser trust and system efficiency.DPKI offers a promising alternative to traditional centralized PKI sys-tems, especially in the context of managing digital credentials with en-hanced security. If integrated with existing digital credential ecosystems andgovernment-backed identity systems, DPKI could significantly enhance trustand reduce vulnerabilities associated with centralization. As blockchaintechnology and decentralized identity frameworks continue to evolve, futureresearch can explore real-world implementations of DPKI, providing valu-able insights into its efficacy, scalability, and long-term impact on digitaltrust infrastructures.96Bibliography[1] D. Cooper, S. Santesson, S. Farrell, R. Boeyen, S.and Housley, andW. Polk. Internet X.509 Public Key Infrastructure Certificate andCertificate Revocation List (CRL) Profile. RFC 5280, 2008. Availableat: https://www.rfc-editor.org/info/rfc5280.[2] International Organization for Standardization. Information technol-ogy - Open Systems Interconnection - The Directory: Public key andattribute certificate frameworks, 2016.[3] International Telecommunication Union. X.509: Information technol-ogy - Open Systems Interconnection - The Directory: Public-key andattribute certificate frameworks. ITU-T, 2019.[4] Stephanos Matsumoto and Raphael M Reischuk. IKP: Turning a PKIAround with Decentralized Automated Incentives. In 2017 IEEE Sym-posium on Security and Privacy (SP), pages 410â426. IEEE, 2017.[5] Jose´ Luis Ferna´ndez-Alema´n, Inmaculada Carrio´n SenËor, PedroAÂ´ngel Oliver Lozoya, and Ambrosio Toval. Security and privacy inelectronic health records: A systematic literature review. Journal ofbiomedical informatics, 46(3):541â562, 2013.[6] Pongpayak Boontaetae, Akkarit Sangpetch, and Orathai Sangpetch.RDI: Real Digital Identity Based on Decentralized PKI. In 201822nd International Computer Science and Engineering Conference(ICSEC), pages 1â6. IEEE, 2018.[7] Ali M Al-Khouri. PKI in Government Digital Identity ManagementSystems. European Journal of ePractice, 4(4), 2012.[8] Yong Lee, Jeail Lee, and JooSeok Song. Design and implementa-tion of wireless PKI technology suitable for mobile phone in mobile-commerce. Computer communications, 30(4):893â903, 2007.97[9] Government of Canada. Digital Credentials. https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/digital-credentials.html.Accessed: 2024-10-16.[10] Steve Ragan. Hacker Had Total Control Over DigiNo-tar Servers, Report. https://www.securityweek.com/hacker-had-total-control-over-diginotar-servers-report/l,2012. Accessed: 2024-10-16.[11] Tom Espiner. Trustwave sold root certificate forsurveillance. https://www.zdnet.com/article/trustwave-sold-root-certificate-for-surveillance/l, 2012.Accessed: 2024-10-16.[12] Lin Shung Huang, Alex Rice, Erling Ellingsen, and Collin Jackson.Analyzing Forged SSL Certificates in the Wild. In 2014 IEEE Sym-posium on Security and Privacy, pages 83â97, 2014.[13] G. Greenwald et al. NSA Collecting Phone Records of Millions ofVerizon Customers Daily. Guardian, 6(6):13, 2013.[14] R. S. Raman, L. Evdokimov, E. Wurstrow, J. A. Halderman, andR. Ensafi. Investigating Large Scale HTTPS Interception in Kaza-khstan. In Proc. ACM Internet Measurement Conference (IMC),pages 125â132, 2020. [online] Available: https://doi.org/10.1145/3419394.3423665.[15] Ruggero Morselli, Bobby Bhattacharjee, Jonathan Katz, andMichael A Marsh. Keychains: A Decentralized Public-Key Infras-tructure. Technical report, Citeseer, 2006.[16] Conner Fromknecht, Dragos Velicanu, and Sophia Yakoubov. Cert-coin: A Namecoin based Decentralized Authentication System. Mas-sachusetts Inst. Technol., Cambridge, MA, USA, Tech. Rep, 6:46â56,2014.[17] Conner Fromknecht, Dragos Velicanu, and Sophia Yakoubov. A De-centralized Public Key Infrastructure with Identity Retention. Cryp-tology ePrint Archive, Paper 2014/803, 2014.[18] Benjamin Leiding, Clemens H Cap, Thomas Mundt, and SamanehRashidibajgan. Authcoin: Validation and Authentication in Decen-tralized Networks. arXiv preprint arXiv:1609.04955, 2016.98[19] Bo Qin, Jikun Huang, Qin Wang, Xizhao Luo, Bin Liang, and Wen-chang Shi. Cecoin: A decentralized PKI mitigating MitM attacks.Future Generation Computer Systems, 107:805â815, 2020.[20] Daniel Maldonado-Ruiz, Jenny Torres, Nour El Madhoun, and Mo-hamad Badra. Current Trends in Blockchain Implementations onthe Paradigm of Public Key Infrastructure: A Survey. IEEE Access,10:17641â17655, 2022.[21] Tania Saleem, Muhammad Umar Janjua, Muhammad Hassan, TalhaAhmad, Filza Tariq, Khadija Hafeez, Muhammad Ahsan Salal,and Muhammad Danish Bilal. ProofChain: An X.509-compatibleBlockchain-based PKI Framework with Decentralized Trust. Com-puter Networks, 213:109069, 2022.[22] Junzhi Yan, Xiaoyong Hang, Bo Yang, Li Su, and Shen He. BlockchainBased PKI and Certificates Management in Mobile Networks. In 2020IEEE 19th International Conference on Trust, Security and Privacy inComputing and Communications (TrustCom), pages 1764â1770, 2020.[23] Thomas Sermpinis, George Vlahavas, Konstantinos Karasavvas, andAthena Vakali. DeTRACT: a decentralized, transparent, immutableand open PKI certificate framework. Int. J. Inf. Secur., 20(4):553â570,August 2021.[24] T. Hobson, L. France, S. Greenbury, L. Hare, and P. Wochner.Trustchain â Trustworthy Decentralised Public Key Infrastructure forDigital Credentials. In International Conference on AI and the DigitalEconomy (CADE 2023), volume 2023, pages 31â40, 2023.[25] Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System.Satoshi Nakamoto, 2008.[26] International Business Machines Corporation. What is blockchain?https://www.ibm.com/topics/blockchain, N.D. Accessed: 2024-1-20.[27] Stanford University. How does blockchain work? https://online.stanford.edu/how-does-blockchain-work, N.D. Accessed: 2024-1-20.[28] Zach Church. Blockchain, explained. https://mitsloan.mit.edu/ideas-made-to-matter/blockchain-explained, 2024. Accessed:2024-1-20.99[29] Wei Cai, Zehua Wang, Jason B Ernst, Zhen Hong, Chen Feng, andVictor CM Leung. Decentralized Applications: The Blockchain-Empowered Software System. IEEE access, 6:53019â53033, 2018.[30] Abid Haleem, Mohd Javaid, Ravi Pratap Singh, Rajiv Suman, andShanay Rab. Blockchain technology applications in healthcare: Anoverview. International Journal of Intelligent Networks, 2:130â139,2021.[31] Cornelius C. Agbo, Qusay H. Mahmoud, and J. Mikael Eklund.Blockchain technology in healthcare: A systematic review. Health-care, 7(2), 2019.[32] Pankaj Dutta, Tsan-Ming Choi, Surabhi Somani, and Richa Butala.Blockchain technology in supply chain operations: Applications, chal-lenges and research opportunities. Transportation research part e: Lo-gistics and transportation review, 142:102067, 2020.[33] Davor Dujak and Domagoj Sajter. Blockchain Applications in SupplyChain. SMART supply network, pages 21â46, 2019.[34] Ana Reyna, Cristian Mart´ın, Jaime Chen, Enrique Soler, and ManuelDı´az. On blockchain and its integration with IoT. Challenges andopportunities. Future generation computer systems, 88:173â190, 2018.[35] Alfonso Panarello, Nachiket Tapas, Giovanni Merlino, FrancescoLongo, and Antonio Puliafito. Blockchain and IoT Integration: ASystematic Survey. Sensors, 18(8):2575, 2018.[36] Khaled Salah, M Habib Ur Rehman, Nishara Nizamuddin, and Ala Al-Fuqaha. Blockchain for AI: Review and Open Research Challenges.IEEE access, 7:10127â10149, 2019.[37] Stuart Haber and W. Scott Stornetta. How to time-stamp a digitaldocument. Journal of Cryptology, 3(2):99â111, 1991.[38] Ralph C Merkle. Method of providing digital signatures, January 51982. US Patent 4,309,569.[39] Vitalik Buterin et al. Ethereum white paper. GitHub repository, 1:22â23, 2013.100[40] Johannes Go¨bel and Anthony E Krzesinski. Increased block size andBitcoin blockchain dynamics. In 2017 27th International Telecommu-nication Networks and Applications Conference (ITNAC), pages 1â6.IEEE, 2017.[41] Yinqiu Liu, Kun Wang, Yun Lin, and Wenyao Xu. Lightchain: ALightweight Blockchain System for Industrial Internet of Things. IEEETransactions on Industrial Informatics, 15(6):3571â3581, 2019.[42] Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin,Konstantinos Christidis, Angelo De Caro, David Enyeart, ChristopherFerris, Gennady Laventman, Yacov Manevich, et al. Hyperledger Fab-ric: a Distributed Operating System for Permissioned Blockchains. InProceedings of the thirteenth EuroSys conference, pages 1â15, 2018.[43] Richard Gendal Brown, James Carlyle, Ian Grigg, and Mike Hearn.Corda: An Introduction. R3 CEV, August, 1(15):14, 2016.[44] C. Komalavalli, Deepika Saxena, and Chetna Laroiya. Chapter 14 -Overview of Blockchain Technology Concepts. In Saravanan Krishnan,Valentina E. Balas, E. Golden Julie, Y. Harold Robinson, S. Balaji,and Raghvendra Kumar, editors, Handbook of Research on BlockchainTechnology, pages 349â371. Academic Press, 2020.[45] Bahareh Lashkari and Petr Musilek. A Comprehensive Review ofBlockchain Consensus Mechanisms. IEEE access, 9:43620â43652,2021.[46] Combatting Junk Mail. Pricing via Processing. In Advances in Cryp-tologyâCRYPTOâ92: 12th Annual International Cryptology Confer-ence, Santa Barbara, California, USA, August 16â20, 1992. Proceed-ings, volume 740, page 139, 1993.[47] Adam Back. Hashcash - a denial of service counter-measure. 09 2002.[48] Sunny King and Scott Nadal. PPCoin: Peer-to-Peer Crypto-Currencywith Proof-of-Stake. self-published paper, August, 19(1), 2012.[49] Leslie Lamport, Robert Shostak, and Marshall Pease. The byzantinegenerals problem. ACM Trans. Program. Lang. Syst., 4(3):382â401,July 1982.101[50] Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance.In Proceedings of the Third Symposium on Operating Systems Designand Implementation, OSDI â99, page 173â186, USA, 1999. USENIXAssociation.[51] Ethan Buchman. Tendermint: Byzantine Fault Tolerance in the Ageof Blockchains. PhD thesis, University of Guelph, 2016.[52] Lisl Marburg Goodman. Tezos: A Self-Amending Crypto-Ledger Po-sition Paper. Aug, 3:2014, 2014.[53] Stefano De Angelis, Leonardo Aniello, Roberto Baldoni, FedericoLombardi, Andrea Margheri, Vladimiro Sassone, et al. PBFT vsProof-of-Authority: Applying the CAP Theorem to PermissionedBlockchain. In CEUR workshop proceedings, volume 2058. CEUR-WS,2018.[54] Ronald Rivest. RFC1321: The MD5 message-digest algorithm, 1992.[55] Fips Pub. Secure Hash Standard (SHS). Fips pub, 180(4), 2012.[56] Nick Szabo. Smart Contracts: Building Blocks for Digital Markets.EXTROPY: The Journal of Transhumanist Thought,(16), 18(2):28,1996.[57] Gavin Wood. POLKADOT: VISION FOR A HETEROGENEOUSMULTI-CHAIN FRAMEWORK. White paper, 21(2327):4662, 2016.[58] BNB Chain. BNB Smart Chain. https://www.bnbchain.org/en/bnb-smart-chain, 2024. Accessed: 2024-2-19.[59] Tama´s Ille´s and Szabolcs Somoskeo¨y. The EOSâ¢ imaging systemand its uses in daily orthopaedic practice. International orthopaedics,36:1325â1331, 2012.[60] Drummond Reed, Manu Sporny, Dave Longley, Christopher Allen,Ryan Grant, Markus Sabadello, and Jonathan Holt. Decentralizedidentifiers (dids) v1.0. Draft Community Group Report, 2020.[61] Christopher Allen. The Path to Self-Sovereign Identity. 2017.[62] Shubhani Aggarwal and Neeraj Kumar. Hyperledger. In Advances incomputers, volume 121, pages 323â343. Elsevier, 2021.102[63] Sovrin. Sovrin Basics. https://sovrin.org/library/, 2024. Ac-cessed: 2024-4-20.[64] Microsoft. What is Microsoft Entra ID? https://learn.microsoft.com/en-us/entra/fundamentals/whatis, 2024. Accessed: 2024-4-20.[65] National Institute of Standards and Technology. Recommendation forKey Management: Part 1 - General. NIST Special Publication, 2016.[66] Ben Laurie. Certificate transparency. Commun. ACM, 57(10):40â46,September 2014.[67] Ralph Holz, Johanna Amann, Olivier Mehani, Matthias Wachs, andMohamed Ali Kaafar. TLS in the Wild: An Internet-wide Analysisof TLS-based Protocols for Electronic Communication. In Proceed-ings 2016 Network and Distributed System Security Symposium, NDSS2016. Internet Society, 2016.[68] kgremban and KennedyDMSFT. X.509 certificates.https://learn.microsoft.com/en-us/azure/iot-hub/reference-x509-certificates, 2023. Accessed: 2024-10-17.[69] Apple. Manage digital certificates. https://developer.apple.com/documentation/security/certificates, 2024. Accessed: 2024-10-17.[70] Dwaine Clarke, Jean-Emile Elien, Carl Ellison, Matt Fredette, Alexan-der Morcos, and Ronald L Rivest. Certificate chain discovery inSPKI/SDSI. Journal of Computer security, 9(4):285â322, 2001.[71] Yannan Li, Yong Yu, Chunwei Lou, Nadra Guizani, and Lianhai Wang.Decentralized Public Key Infrastructures atop Blockchain. IEEE Net-work, 34(6):133â139, 2020.[72] Digicert. How Certificate Chains Work. https://knowledge.digicert.com/solution/how-certificate-chains-workl, 2023.Accessed: 2024-10-17.[73] Silvio Micali. Enhanced Certificate Revocation System. TechnicalMemo MIT/LCS/TM-542b, Massachusetts Institute of Technology,Laboratory for Computer Science, 2023.103[74] Silvio Micali. Efficient Certificate Revocation. Technical MemoMIT/LCS/TM-542b, Massachusetts Institute of Technology, Labora-tory for Computer Science, 1996.[75] United States Patent and Trademark Office. Patent No. US5666416:Certificate Revocation System. PDF file, 1998. Accessed: 2024-10-17.[76] Paul C. Kocher. On Certificate Revocation and Validation. In RafaelHirchfeld, editor, Financial Cryptography, pages 172â177, Berlin, Hei-delberg, 1998. Springer Berlin Heidelberg.[77] Paul Kocher. A Quick Introduction to Certificate Revocation Trees(CRTs). =http://www.valicert.com/company/crt.html, 1999. Ac-cessed: 2024-10-17.[78] X.509 Internet Public Key Infrastructure Online Certificate StatusProtocol - OCSP, author=Myers, Michael and Ankney, Rich and Mal-pani, Ambarish and Galperin, Slava and Adams, Carlisle, year=1999,howpublished==https://www.rfc-editor.org/rfc/rfc2560, note = Ac-cessed: 2024-10-17.[79] Government of Canada. Digital government innova-tion. =https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/digital-credentials.html,2024. Accessed: 2024-10-3.[80] IBM Verify. Letâs secure identity verification with Digital Creden-tials. =https://www.ibm.com/verify/digital-credentials, 2024. Ac-cessed: 2024-10-3.[81] Stefan Brands. A Technical Overview of Digital Credentials.=https://api.semanticscholar.org/CorpusID:18284690, 2002. Ac-cessed: 2024-9-7.[82] Phillip J Windley. Digital Identity. OâReilly Media, Inc., 2005.[83] Zolta´n Andra´s Lux, Dirk Thatmann, Sebastian Zickau, and FelixBeierle. Distributed-Ledger-based Authentication with DecentralizedIdentifiers and Verifiable Credentials. In 2020 2nd Conference onBlockchain Research & Applications for Innovative Networks and Ser-vices (BRAINS), pages 71â78, 2020.104[84] Stanford University. What is a digital credential?=https://online.stanford.edu/digital-credential, 2022. Accessed:2024-10-7.[85] Massachusetts Institute of Technology. Digital diplomas.=https://registrar.mit.edu/transcripts-records/diplomas/digital-diplomas, 2017. Accessed: 2024-10-7.[86] SSLMate. Timeline of Certificate Authority Failures. https://sslmate.com/resources/certificate_authority_failures, 2018.Accessed: 2024-10-15.[87] Mike Zusman. Criminal charges are not pursued: Hacking PKI. DE-FCON 17, 2009.[88] Johnathan Nightingale. Comodo Certificate Issue â Fol-low Up. =https://blog.mozilla.org/security/2011/03/25/comodo-certificate-issue-follow-up/, 2011. Accessed: 2024-10-15.[89] Lucian Constantin. GoDaddy revokes nearly 9,000SSL certificates issued without proper validation.=https://www.csoonline.com/article/559639/godaddy-revokes-nearly-9-000-ssl-certificates-issued-without-proper-validation.html,2017. Accessed: 2024-10-15.[90] Jon Callas, Lutz Donnerhacke, Hal Finney, David Shaw, and RodneyThayer. RFC 4880: OpenPGP message format, 2007.[91] Hou Liping and Shi Lei. Research on Trust Model of PKI. In 2011Fourth International Conference on Intelligent Computation Technol-ogy and Automation, volume 1, pages 232â235, 2011.[92] Li Guo and Caihui Lan. A New Signature based on Blockchain. In2020 International Conference on Intelligent Computing, Automationand Systems (ICICAS), pages 349â353. IEEE, 2020.[93] Lukasz Dykcik, Laurent Chuat, Pawel Szalachowski, and Adrian Per-rig. BlockPKI: An Automated, Resilient, and Transparent Public-KeyInfrastructure. In 2018 IEEE International Conference on Data Min-ing Workshops (ICDMW), pages 105â114. IEEE, 2018.[94] Elie F Kfoury, David Khoury, Ali AlSabeh, Jose Gomez, JorgeCrichigno, and Elias Bou-Harb. A Blockchain-based Method for De-centralizing the ACME Protocol to Enhance Trust in PKI. In 202010543rd International Conference on Telecommunications and Signal Pro-cessing (TSP), pages 461â465. IEEE, 2020.[95] Alexander Yakubov, Wazen Shbair, Anders Wallbom, David Sanda,et al. A Blockchain-based PKI Management Framework. In TheFirst IEEE/IFIP International Workshop on Managing and Managedby Blockchain (Man2Block) colocated with IEEE/IFIP NOMS 2018,Tapei, Tawain 23-27 April 2018, 2018.[96] Paul Bastian, Carsten Sto¨cker, and Steffen Schwalm. Combination ofx509 and DID/VC for inheritance properties of trust in digital identi-ties. In Open Identity Summit, 2022.[97] Oscar BURGOS. SSI eIDAS Bridge - Integration Guidelines.https://joinup.ec.europa.eu/collection/ssi-eidas-bridge/document/ssi-eidas-bridge-integration-guidelines, 2024.Accessed: 2024-10-15.[98] Trust Over IP Foundation. did:x509 Method Specification. https://trustoverip.github.io/tswg-did-x509-method-specification/#subject-policy, 2024. Accessed: 2024-10-15.[99] Phil Windley. Using X.509 Certs for DID Provenance.https://www.windley.com/archives/2024/04/using_x509_certs_for_did_provenance.shtml, 2024. Accessed: 2024-10-15.[100] Internation Business Macines Corporation. Central Bank DigitalCurrency (CBDC) and blockchain enable the future of payments.https://www.ibm.com/think/topics/blockchain-for-cbdc, 2023.Accessed: 2024-4-5.[101] S Goldwasser, S Micali, and C Rackoff. The knowledge complexity ofinteractive proof-systems. In Proceedings of the Seventeenth AnnualACM Symposium on Theory of Computing, STOC â85, page 291â304,New York, NY, USA, 1985. Association for Computing Machinery.[102] Anna Gutowska. What are AI agents? https://www.ibm.com/think/topics/ai-agents, 2024. Accessed: 2024-10-15.106
Thesis/Dissertation
eng
Electrical Engineering
Vancouver : University of British Columbia Library
Attribution-NonCommercial-NoDerivatives 4.0 International
Graduate
Feng, Chen
Blockchain-based decentralized public key infrastructure for digital credentials
Text