CCDigital: protection of digital citizenship folder based on DLT-blockchain

Introduction

Digital citizenship has become a strategic priority in contemporary public-sector transformation, particularly in countries seeking to expand secure, transparent, and citizen-centered digital services. However, the implementation of digital citizenship infrastructures still faces persistent structural limitations, including fragmented institutional architectures, weak interoperability among agencies, dependence on centralized repositories, and low public trust in the handling and verification of personal information. In practice, these conditions often produce duplicated identity records, inconsistent validation pathways, and data-management models that increase exposure to breaches while undermining citizen confidence in digital interaction with the State. In the Colombian context, these challenges are especially significant because digital citizenship is not limited to administrative digitization, but is closely linked to broader objectives of secure authentication, service integration, accountability, and citizen control over digital records and interactions (Cagigas et al., 2021; Ramírez López et al., 2025; Kassen, 2022; Rodriguez Müller et al., 2024; Alotaibi et al., 2025).

Against this background, the literature on digital identity has progressively moved away from purely centralized and federated models toward architectures that emphasize decentralization, verifiability, and user agency. Self-sovereign identity (SSI) has been one of the most influential formulations of this shift, proposing that individuals should be able to hold and present digitally signed credentials while verifiers can confirm authenticity without persistent dependence on a single central authority. This transition is important because it reframes identity not as a static institutional record, but as a verifiable set of claims mediated by issuers, holders, and verifiers in a distributed trust architecture. Foundational and review-based studies consistently show that SSI is not a single technology, but rather a coordinated assemblage of identifiers, credential layers, registries, storage models, and verification processes whose effectiveness depends on coherent architectural design and governance alignment (Wang and De Filippi, 2019; Mühle et al., 2018; Liu et al., 2020; Singla et al., 2023; Yan et al., 2024; Xian et al., 2025).

Importantly, decentralized digital identity and Self-Sovereign Identity (SSI) now constitute an active and rapidly evolving field of research, with a growing body of empirical work examining architectural choices, governance arrangements, implementation pathways, and adoption challenges across different domains. However, productive SSI applications remain scarce, particularly in the public sector, which means that evidence on how public organizations can successfully innovate with SSI to redesign existing processes is still limited. Recent public-sector research explicitly notes that, despite strong institutional interest and experimentation, a deeper understanding of SSI’s value and actual utilization remains lacking, thereby creating uncertainty in the design and implementation of SSI-based applications. At the same time, SSI has also been framed as embodying the fundamental right to own and control a digital identity that enables access to public, social, and financial services, while available analyses suggest that evaluated SSI implementations in Latin American contexts remain limited. In this sense, the challenge is not only to demonstrate technical feasibility, but also to understand how SSI can be translated into organizationally viable public-service innovation (Feulner et al., 2025; Pava-Díaz et al., 2024).

This challenge becomes even more relevant when SSI is operationalized through a combination of permissioned blockchain infrastructure, verifiable credentials, and off-chain storage. Rather than constituting a purely technical arrangement, this combination has direct implications for privacy by design, public data governance, and institutional interoperability, all of which remain recognized as open scientific challenges in recent literature. From a privacy perspective, current work shows that selective disclosure and zero-knowledge-based approaches may strengthen data minimization, but also raise unresolved questions regarding implementation trade-offs, cryptographic maturity, and practical usability (Flamini et al., 2024; Zhou et al., 2024). From a governance perspective, research on blockchain in the public sector makes clear that decisions concerning permissioning, accountability, interoperability, and control are inseparable from broader institutional and regulatory arrangements (Tan et al., 2021). Accordingly, combining permissioned blockchain, verifiable credentials, and off-chain storage is not only relevant for secure document verification, but also for examining how privacy-preserving identity systems can become operationally viable within real public-service environments.

This conceptual shift has become more operational through the growing use of verifiable credentials. In these systems, authenticity and integrity rely on cryptographic signatures, whereas privacy may be improved by allowing users to disclose only the attributes required for a given interaction instead of exposing complete identity records. This feature is especially relevant in digital citizenship environments, where verification frequently involves sensitive personal information and inter-institutional exchange. However, the literature also makes clear that privacy is not an automatic consequence of adopting blockchain or SSI terminology. Rather, it depends on deliberate design decisions related to selective disclosure, credential presentation logic, minimization of on-chain exposure, and avoidance of unnecessary centralized data retention. Cryptographic analyses of selective disclosure mechanisms and surveys on zero-knowledge approaches show that privacy-preserving identity requires trade-offs among maturity, performance, unlinkability, and proof expressiveness, while applied studies demonstrate that even technically sound SSI workflows may fail to protect users if organizations do not redesign their storage and validation practices accordingly (Pöhn et al., 2024; Naicker and Moodley, 2024; Flamini et al., 2024; Zhou et al., 2024; Salah et al., 2025; Wijesundara et al., 2025).

Beyond privacy, the public-sector relevance of digital identity infrastructures also depends on interoperability, auditability, and institutional trust across organizational boundaries. Domain-specific implementations in transportation, healthcare, digital credentials, and cross-domain authentication show that decentralized identity becomes particularly valuable when multiple institutions need to verify attributes without reproducing redundant databases or forcing users to manage incompatible credentials across services. In that sense, interoperability is not merely a technical feature, but a condition for scalability and service continuity in complex ecosystems. Studies on cross-domain trust models, decentralized access control, credential-sharing infrastructures, and identity authentication schemes suggest that operational viability depends on trust registries, governance lists, signature verification models, and carefully defined inter-organizational validation rules (Stockburger et al., 2021; Careja and Tapus, 2023; Pulmano et al., 2023; Zhang and Zhao, 2023; Agarkar et al., 2024; Henderson Johnson Jeyakumar and Kubach, 2025; Zhang et al., 2025). Likewise, comparative credential platforms and decentralized certificate-verification systems indicate that portability and automated validation are feasible, but that their institutional meaning depends on how trust anchors, issuance authority, and revocation are formally organized (Franklin et al., 2025; Tran et al., 2025).

The promise of interoperability and verification, however, cannot be separated from the question of governance. Public-sector blockchain research has repeatedly shown that governance choices are not secondary implementation details, but central determinants of whether a system can become legitimate, sustainable, and compatible with legal and administrative expectations. A governance framework grounded in systematic review demonstrates that decisions concerning infrastructure architecture, interoperability, control, incentives, consensus, accountability, and governance organization operate across micro-, meso-, and macro-levels, making technical architecture inseparable from institutional alignment (Tan et al., 2021). Practice-oriented studies in government settings reinforce this view by showing that permissioned or hybrid approaches may strengthen traceability, integrity, and operational fit without fully disrupting existing policy and organizational cultures, although these models also introduce new coordination and oversight burdens (Shahaab et al., 2022; Polcumpally et al., 2024). Similarly, studies focused on auditing, public key infrastructures, and regulated credentials show that trust in digital identity systems is multi-layered: it depends not only on cryptographic guarantees, but also on threat models, revocation processes, consensus parameters, oversight roles, and accountability boundaries that determine how fraud attempts, misuse, and status changes are handled in practice (Zhai et al., 2022; Yawalkar et al., 2023; Nedaković et al., 2023; Zhang et al., 2025).

At the same time, the feasibility of blockchain-based identity systems cannot be established through conceptual reasoning alone. Several studies stress the importance of moving beyond architectural proposals toward disciplined validation and performance-oriented evidence. Work on student credentials, blockchain verification and validation, and permissioned-network benchmarking shows that latency, throughput, robustness, configuration sensitivity, and workload behavior can materially affect whether a digital identity design remains a theoretical contribution or becomes operationally credible (Mishra et al., 2021; Marijan and Lal, 2022; Ajwalia and Shah, 2025; Melo et al., 2025). Moreover, the literature increasingly warns that technical feasibility alone is insufficient if user experience and adoption conditions are neglected. Studies on civic blockchain, SSI adoption, and credential-layer usability indicate that digital identity systems may offer stronger security and privacy while still failing in practice if users experience excessive friction in key generation, wallet interaction, proof presentation, or process comprehension (Viano et al., 2023; Laatikainen et al., 2025; Seo and Park, 2025). This point is particularly relevant for digital citizenship, where citizens must be able not only to trust the back-end infrastructure, but also to understand the meaning and consequences of presenting credentials, validating documents, and interacting with digital public services.

Taken together, these strands of literature suggest that decentralized identity and verifiable credentials provide a strong technical basis for improving user control, privacy, and verifiability, while public-sector blockchain research shows that governance, interoperability, accountability, usability, and operational performance are decisive for institutional feasibility. Nevertheless, the literature remains fragmented in an important respect. Many studies address these dimensions separately or within specific domains such as healthcare, education, transportation, credential verification, or authentication protocols. What remains comparatively underdeveloped is controlled prototype evidence showing how a digital citizenship platform can combine permissioned blockchain infrastructure, verifiable credentials, off-chain storage, holder-mediated authorization, auditability, privacy-by-design, and usability considerations within a single evaluable workflow, particularly in contexts such as Colombia, where digital citizenship policy coexists with fragmented services, low public trust, and strong institutional constraints (Ramírez López et al., 2025; Naicker and Moodley, 2024; Tan et al., 2021; Marijan and Lal, 2022; Nedaković et al., 2023; Laatikainen et al., 2025).

In response to this gap, the present study examines whether a controlled digital citizenship prototype based on permissioned blockchain and verifiable credentials can support auditable document provenance, holder-mediated access authorization, privacy-aware verification, and preliminary operational continuity. The study does not claim to validate a production-ready national digital identity infrastructure. Instead, it evaluates a laboratory prototype designed to reproduce the main issuer-holder-verifier trajectory of document submission, administrative review, access request, citizen decision, authorized consultation, and blockchain-based audit recording.

Accordingly, the study is guided by three expectations. First, a permissioned blockchain and verifiable-credential architecture should strengthen auditability and traceability by preserving verifiable evidence of document-related events. Second, separating sensitive documents from on-chain records should reduce direct documentary exposure, although residual metadata risks must still be assessed. Third, under controlled conditions, repeated operational executions should provide diagnostic evidence on endpoint behavior and integration frictions, while recognizing that such evidence does not establish scalability, production readiness, or external validity in real institutional deployment.

Materials and methods

Structured literature synthesis strategy

To support the design and evaluation of the prototype, the study incorporated a structured literature synthesis on digital citizenship, digital identity, self-sovereign identity, blockchain-based identity management, verifiable credentials, privacy-by-design, interoperability, governance, usability, and performance evaluation. The purpose of this synthesis was not to conduct a meta-analysis, but to define the conceptual, technical, and methodological basis for the prototype and to identify design implications for a Colombian digital citizenship context.

The literature search was developed in two complementary blocks. The first block focused on digital citizenship and digital identity in public-sector environments. Searches were conducted in March 2025 in Scopus, Google Scholar, and EBSCOhost using combinations of “Identity management,” “Digital Citizenship,” “Digital Identity,” “Public Policies,” “Regulatory framework,” “Legislation,” “Regulations,” “Electronic Government,” and “Digital Administration.” The second block focused on blockchain and decentralized identity. Searches were conducted in March 2025 in Scopus, ScienceDirect, Core, and Google Scholar using combinations of “Blockchain AND Self-Sovereign Identity,” “Blockchain-based Identity AND Citizen Services,” “Blockchain AND Digital Identity,” and “Decentralized Identity AND Data Security”.

Inclusion criteria comprised peer-reviewed articles, indexed studies, structured or systematic reviews, prototype-based studies, empirical evaluations, and technical works addressing digital identity, blockchain-based identity management, public-sector verification, privacy, interoperability, governance, usability, or performance. Exclusion criteria included opinion pieces, non-archived blog posts, studies unrelated to identity management, cryptocurrency-only works without public-service relevance, duplicated records, inaccessible full texts, and publications without clear methodological contribution. The final synthesis prioritized studies that provided design, governance, regulatory, technical, or evaluation insights relevant to the CCDigital prototype. The evidence was organized thematically rather than statistically, with emphasis on how prior work informed the system architecture, evaluation dimensions, and limitations of the present study.

Regulatory and documentary basis

This study was grounded in a regulatory and documentary basis that defined the scope, constraints, and design criteria of the prototype. At the regulatory level, the main reference was Decree 767 of 2022, which establishes the Colombian framework for digital citizenship and sets principles related to interoperability, security, privacy, and data sovereignty for mechanisms such as Digital Authentication, the Digital Citizen Folder, the Digital Wallet, and the Digital Signature. In addition, Decree 620 of 2020 and related provisions on interoperability and strong authentication were considered because they establish minimum conditions for secure identity and document management in public digital services (Ramírez López et al., 2025).

These materials were used as direct design inputs rather than as background information only. More specifically, they informed the identification of requirements concerning authentication, interoperability, access control, traceability, and data protection within an institutional digital ecosystem. This documentary basis was complemented by internal project materials, including scope definitions, problem analysis, requirement matrices, module specifications, and traceability records produced during the planning and implementation of the prototype.

Accordingly, the regulatory and documentary review led the study to focus on three design needs from the outset: reducing dependence on centralized document-verification schemes, enabling auditable evidence of relevant interactions, and minimizing unnecessary exposure of sensitive information. Consequently, the solution was oriented toward a permissioned-record model with explicit separation between on-chain and off-chain data, access control mediated by holder authorization, and cryptographic support for identity verification.

Technical environment and system implementation

The prototype was implemented as a multi-layer web platform integrating application services, relational persistence, off-chain document storage, a blockchain-based traceability layer, and a verifiable-identity component (Figure 1 and Table 1). The main application was developed in Java 17 on Spring Boot 3.5.11, using Spring MVC for web logic, Spring Security 6.5.8 for access control, and Spring Data JPA with Hibernate 6.6.42. Final for persistence. The user interface was built with Thymeleaf 3.1.3. RELEASE, following a server-side MVC pattern. The transactional database was implemented in MySQL 8.0 and accessed through mysql-connector-j 9.6.0.

TABLE 1. Technical environment and software stack of the prototype.

The blockchain layer was implemented on Hyperledger Fabric 2.5.12, with Fabric CA 1.5.15 for network identity management. Interaction with Fabric was supported by Node. js integration scripts used for synchronization, block reading, document-reference queries, and access-event recording. In parallel, the verifiable-identity layer was implemented on a laboratory network based on Hyperledger Indy, deployed through von-network and operated with ACA-Py agents. Selected auxiliary issuance and support processes were implemented in Python. SSI interoperability was resolved through Aries present-proof 2.0 workflows, which delegated verifiable credential and proof-presentation logic to the ACA-Py/Indy infrastructure.

The Hyperledger Fabric network was configured with three defined organizations: OrdererOrg, Org1MSP, and Org2MSP. At the application level, the operational channel (mychannel) included two participating organizations, Org1MSP and Org2MSP, each represented by one peer (peer0.org1.example.com and peer0.org2.example.com), while transaction ordering was handled by a single ordering node (orderer.example.com). Consensus was implemented through RAFT, specifically using the etcdraft ordering service. The application logic relied on a custom chaincode named cddoc, which supported both document-related and audit-oriented operations, including createUser, addDoc, listDocs, setDocIssuer, recordAccessEvent, listAccessEvents, and listAllAccessEvents. No custom chaincode endorsement policy was explicitly defined during lifecycle commitment; therefore, endorsement followed the default channel application policy (/Channel/Application/Endorsement). In practical terms, because the application channel included only Org1MSP and Org2MSP and each organization defined endorsement through its peer, this policy was operationally equivalent to AND (“Org1MSP.peer,” “Org2MSP.peer”). Accordingly, transaction endorsement in the application workflow depended on peer0.org1.example.com and peer0.org2.example.com, whereas orderer.example.com was responsible only for block ordering and did not endorse chaincode transactions.

At deployment level, the prototype ran in a Linux environment. The application was packaged as a JAR file and managed as a system service, whereas MySQL was deployed in Docker. Controlled exposure of the validation environment was handled through tunneling and a front proxy. Since the purpose of the study was controlled prototype validation rather than production deployment, the environment was treated as a reproducible testing setup rather than as a definitive operational infrastructure.

Source code and reproducibility package

To improve reproducibility, the revised supplementary material includes the main technical artifacts required to inspect and partially replicate the prototype in a controlled environment. These artifacts include the Spring Boot backend structure, Hyperledger Fabric chaincode, Fabric network configuration files, Node. js integration scripts, Python/ACA-Py support scripts, database schema, sanitized Newman/Postman PDF reports, a controlled-load k6 script with supporting screenshot evidence, and deployment documentation. Executable request-level Postman/Newman collection files were not included because they contain or depend on session cookies, CSRF tokens, credentials, OTP values, proof-exchange identifiers, public endpoints, and other environment-specific artifacts. Personal information, registered-user data, private keys, credentials, institutional endpoints, and environment-specific secrets were removed or replaced with placeholders.

The reproducibility package supports technical inspection and controlled local replication of the main architecture. However, exact reproduction of all authentication and SSI-dependent flows requires environment-specific configuration, including ACA-Py agents, Indy wallets, proof-exchange identifiers, email/OTP services, local certificates, and active session orchestration. Therefore, the study provides implementation-level reproducibility artifacts while acknowledging that security-sensitive flows require controlled deployment conditions.

Study design

This study followed an applied, controlled prototype-validation design aimed at designing, implementing, and evaluating a functional digital citizenship platform. The study should be interpreted as a laboratory-based prototype assessment rather than as a production-scale experiment, longitudinal pilot, or national digital identity deployment. The unit of analysis was the execution of predefined role-based workflows within the CCDigital prototype.

The methodological process was organized into four sequential phases: (1) requirements elicitation, (2) architectural design, (3) prototype development, and (4) technical-operational evaluation. From a project-management perspective, Kanban was used to visualize tasks, monitor progress, and support iterative coordination. In parallel, software development followed a structured waterfall sequence composed of analysis, design, implementation, testing, and stabilization. These approaches supported traceability between requirements, design decisions, implementation artifacts, and validation evidence, but they were not treated as experimental variables.

From the research perspective, the study combined exploratory, descriptive, analytical, and applied components. The exploratory component helped delimit the digital identity problem in the Colombian context. The descriptive component characterized the regulatory and technological setting. The analytical component supported the interpretation of design decisions and their implications. The applied component was materialized in the construction and controlled validation of the prototype. Because the study did not involve randomization, production users, or a statistically representative sample, the analysis relied on scenario-based validation, expected-versus-observed comparison, descriptive operational indicators, and interpretive assessment rather than inferential statistical testing.

Requirement’s elicitation and design principles

The design process began with the elicitation and consolidation of functional and non-functional requirements. To this end, the study integrated regulatory inputs, problem analysis, scope definition, internal traceability matrices, and implementation records produced during the project. Functional requirements focused on user registration, authentication, document management, access-request generation and approval, authorized consultation, traceability, and system administration. Non-functional requirements addressed security, privacy, interoperability, integrity, availability, performance, and maintainability.

These requirements guided both the architectural decisions and the definition of the prototype modules (Figure 2). In methodological terms, the analysis resulted in four design principles. First, the system adopted role separation, clearly distinguishing among citizen, issuing entity, administration, and verification-related components. Second, it adopted minimal on-chain exposure, using blockchain for references and auditable events rather than for direct storage of raw documents. Third, it maintained separation between verifiable identity and conventional web-session logic, so that proof-based verification could reinforce access decisions without overloading the core application model. Fourth, it implemented layered access control, requiring explicit holder authorization before third-party institutional consultation of documents.

Prototype architecture and operational workflow

The prototype was structured into six functional modules to support the operational workflow (Figure 3): administration/government, issuing entity, citizen user, verifiable identity, blockchain traceability, and persistence/storage.

The administration/government module centralized person management, document review, access control, technical synchronization, and reporting. The issuing-entity module allowed authorized institutions to upload PDF documents and generate access requests over citizen-linked records. The citizen module supported registration, authentication, document visualization, and approval or rejection of access requests. The verifiable-identity module orchestrated proof-presentation workflows supported by ACA-Py/Indy. The blockchain traceability module queried references registered in Fabric and recorded auditable access and consultation events. Finally, the persistence/storage module maintained the transactional state of the system in MySQL and preserved files in off-chain document storage.

From the data perspective, the architecture distinguished three domains (Figure 4). In the on-chain Fabric layer, the system stored document references, minimal metadata, and audit events related to consultation, verification, and status changes. In the off-chain layer, it maintained PDF files, transactional information on users, persons, requests, and states, as well as session logic, views, and security configuration. In the SSI layer, it managed agent connections, proof-exchange logic, and metadata associated with credentials and presentations.

Operationally, the implemented workflow followed an issuer-holder-verifier logic. First, an issuing entity submitted a document associated with a person. Second, the document was reviewed and approved in the administration module. Third, the issuing entity generated an access request over a previously approved document. Fourth, the citizen, acting as holder, explicitly approved or rejected the request. Fifth, once authorization was granted, the backend verified the access conditions, the presence of the document reference in Fabric, and the strengthened-authentication status of the user. Finally, when access was valid, the document was served from off-chain storage and the corresponding event was recorded in the blockchain traceability layer.

Evaluation design

The prototype evaluation was designed as an integrated validation strategy aimed at assessing technical and operational viability under controlled laboratory conditions. Five complementary dimensions were considered: functional testing, integration testing, security- and privacy-oriented validation, repeated operational runs for preliminary performance characterization, and formative usability assessment (Table 2).

TABLE 2. Evaluation dimensions and procedures applied to the prototype.

Functional testing verified whether predefined system operations could be completed according to the expected workflow. Integration testing assessed coordinated interaction among the web application, backend services, relational database, off-chain document storage, Hyperledger Fabric, and ACA-Py/Indy components. Security- and privacy-oriented validation examined whether the implemented controls were consistent with the privacy-by-design rationale of the system. Repeated operational runs were used to obtain preliminary diagnostic evidence on endpoint behavior, response patterns, execution continuity, and orchestration-dependent integration frictions. Formative usability assessment was used to identify workflow clarity and interaction frictions during internal role-based validation.

The test units were workflow operations rather than human-subject experimental units. These units included user registration, account verification, login, second-factor activation, password recovery, document upload, administrative review, access-request creation, citizen approval or rejection, authorized document consultation, blockchain synchronization, traceability retrieval, and SSI-supported proof verification. Success criteria were defined as completion of the expected workflow step, correct transition of system state, persistence of the corresponding database or file artifact, and, where applicable, generation or retrieval of blockchain or SSI-related evidence. For privacy-oriented validation, success required confirmation that PDF binaries remained off-chain, that access depended on explicit holder authorization, and that relevant access or verification events were auditable.

The data used in the evaluation corresponded to laboratory records and documents loaded for prototype validation, including document types such as tax-registration copies, certificates, licenses, residence documents, and related administrative files. These records were not obtained through an official production integration with Colombian government systems. Consequently, the evaluation should be interpreted as controlled prototype evidence, not as ecological validation in a real institutional deployment.

Role-based validation scenarios and evidence criteria

To improve procedural clarity, validation was organized into condensed role-based blocks covering the main issuer-holder-verifier workflow and its most relevant support functions (Table 3). Each block grouped representative scenarios and was assessed through observable evidence across the interface, relational persistence, file storage, blockchain records, and SSI-related interaction when applicable.

TABLE 3. Role-based validation scenarios and evidence criteria.

Functional and integration validation

Functional testing was derived from the critical flows defined in the system requirements. The objective was to determine whether the essential prototype processes could be executed consistently from end to end. The evaluated scenarios included user registration, account verification, login, second-factor activation, password recovery, document upload by the issuing entity, administrative review and approval, access-request generation, approval or rejection by the citizen, authorized document consultation, blockchain synchronization, and verifiable identity flows.

In parallel, the integration dimension examined coordinated behavior among the web application, relational database, document storage, Fabric network, and ACA-Py/Indy infrastructure. Thus, the study assessed not only isolated functionality, but also the operational continuity of the complete workflow and the interaction among heterogeneous components.

Validation evidence was collected through convergent observation of interface-level behavior, persisted relational records, off-chain file existence, blockchain query results, SSI-related guided interaction evidence, and repeated-run execution logs when applicable. Scenario interpretation relied on expected-versus-observed comparison, with emphasis on end-to-end coherence rather than isolated endpoint responses.

Security and privacy assessment

Security and privacy were evaluated as prototype-level validation of implemented controls and exposure boundaries rather than as a formal penetration test or independent cryptographic audit. The methodological objective was to determine whether the prototype incorporated measures coherent with its design principles, namely, off-chain preservation of sensitive documents, layered access control, holder-mediated authorization, strengthened authentication, and traceability of relevant actions.

The assessment considered the main assets involved in the workflow: citizen documents, identity and authentication data, access-request states, and blockchain-based audit evidence. The main risks considered were unauthorized document access, unauthorized modification of document state, exposure of raw documents on-chain, metadata inference from ledger records, misuse of access requests, compromised credentials, and failure of inter-component communication. These risks were assessed through implementation-level checks, including verification that PDF binaries remained outside the ledger, confirmation that document consultation required administrative validation and citizen approval, inspection of protected routes and security-related HTTP headers, and verification that relevant access and state-change events were recorded in the traceability layer.

The study did not include recoverable evidence of OWASP ZAP, Burp Suite, Nmap, Nikto, or comparable DAST/pentest execution. Likewise, it did not include an external audit of the cryptographic mechanisms, AnonCreds proofs, or zero-knowledge proof implementation. Cryptographic verification was delegated to the ACA-Py/Indy stack and assessed only at the workflow-integration level. Therefore, the results should be interpreted as prototype-level security and privacy validation, not as production-grade security certification.

Repeated operational runs and preliminary performance characterization

The repeated operational evidence consisted of the sanitized Newman/Postman diagnostic reports and the k6 controlled-load evidence preserved in the supplementary package. These artifacts complement the functional workflow evidence by documenting how selected automated executions behaved under repeated scripted conditions. They should be interpreted as diagnostic evidence of integration behavior and automation constraints rather than as proof of fully successful end-to-end automation.

The Newman/Postman reports document a diagnostic execution dated 27 February 2026. The execution comprised 50 iterations and 250 processed requests, with a total run duration of 35.9 s, 624.41 KB of data received, an average response time of 21 ms, zero skipped tests, and 50 failed tests or requests. The failed-report artifact localizes the failures in the SSI proof-polling step (“Poll proof”), where the reported error was “runtime: extensions ∼ request: request url is empty”.

This failure pattern indicates that the proof-polling step required a dynamically generated proof-exchange URL or context that was not preserved during blind repeated execution. Therefore, the Newman/Postman evidence is useful for identifying an orchestration-dependent limitation in the SSI workflow, but it should not be interpreted as a fully passed end-to-end smoke test.

The complementary k6 controlled-load evidence configured five virtual users and 50 iterations. The preserved evidence reports 250 checks in total, of which 200 succeeded (80%) and 50 failed (20%). Successful checks corresponded to administrator login-page access, CSRF extraction, login redirection, and document listing. Failed checks were concentrated in protected-file retrieval (“get file 200”: 0/50). This result indicates that protected document retrieval remained dependent on valid session, authorization, and access-context conditions under the scripted run.

Accordingly, the repeated operational evidence supports a bounded interpretation. It helps identify automation frictions in SSI proof polling and protected document retrieval, and it confirms the need for orchestration-aware testing in security-sensitive and context-dependent workflows. However, it does not establish production-scale load behavior, Fabric transaction throughput, full workflow automation, security certification, or production-readiness performance.

Usability-oriented formative assessment

Usability was considered as a formative dimension because SSI-based systems may introduce interaction complexity related to proof presentation, consent interpretation, key or credential management, multi-step authentication, and document-access decisions. The assessment was conducted internally during role-based functional validation and focused on whether the workflow was understandable and operable for the roles represented in the prototype.

The observed tasks included registration, authentication, navigation of the citizen folder, document consultation, access-request handling, citizen approval or rejection, and review of visible workflow states. The observations were used to identify interaction frictions and clarify whether users could follow the intended sequence of actions. However, no recoverable standalone usability dataset, SUS instrument, Likert-scale survey, interview protocol, checklist, or consolidated response base was available for formal empirical reporting.

Consequently, usability is reported as an internal formative assessment rather than as a quantitative user study. The absence of a formal usability dataset is treated as a limitation, and future work should include end-user evaluation with measurable indicators such as task-completion rate, time on task, error frequency, assistance requests, perceived ease of use, perceived trust, and perceived privacy control.

Outcome measures and analytical strategy

The study defined outcomes at three levels. The first level comprised technical-functional outcomes, including successful end-to-end workflow execution, continuity of interaction among modules, synchronization with the blockchain layer, and availability of traceability evidence. The second level comprised privacy- and security-oriented outcomes, including off-chain preservation of document binaries, access control based on explicit holder authorization, strengthened authentication, protection of role-gated routes, and auditable evidence for relevant events. The third level comprised operational and usability-related outcomes, including response times, transport-level stability, identification of integration frictions, workflow clarity, and observable interaction difficulties.

The analytical strategy combined descriptive, scenario-based, and interpretive procedures. Functional and integration evidence was analyzed through expected-versus-observed comparison across predefined validation scenarios. Security- and privacy-oriented evidence was analyzed by checking conformity between implemented controls and the design principles of data minimization, layered authorization, traceability, and separation between document content and ledger evidence. Repeated operational runs were interpreted through descriptive indicators such as processed requests, failed requests, response time, and endpoint behavior.

No inferential statistical testing was performed because the evaluation did not involve a representative user sample, randomized treatment conditions, or production workload. The purpose was not statistical generalization, but analytically grounded interpretation of prototype feasibility, implementation limits, and future validation requirements.

Ethical and data-protection considerations

The study adopted a privacy-by-design logic throughout the implementation and evaluation process. Full documents and transactional information were kept off-chain in order to reduce unnecessary exposure of personal data and to limit the use of blockchain to reference, integrity, and audit functions. Likewise, access to documentary information was conditioned by sequential controls that included administrative validation, holder authorization, and strengthened authentication.

From a methodological perspective, this approach made it possible to evaluate the system in a controlled environment without turning the blockchain infrastructure into a repository of directly readable personal information. In addition, the minimal-on-chain design was consistent with the Colombian regulatory context and with the privacy rationale of the proposed architecture.

Results

The results obtained from the prototype evaluation are presented at three complementary levels: functional and integration behavior of the issuer-holder-verifier workflow, security- and privacy-oriented findings consistent with the privacy-by-design rationale of the system, and preliminary operational behavior under repeated automated execution. Overall, the recoverable evidence showed that CCDigital executed the core documentary trajectory from document submission to authorized consultation and blockchain-based traceability. The strongest evidence was concentrated in document upload, administrative review and approval, access-request generation, citizen-side decision, authorized consultation, blockchain synchronization, traceability recording, and SSI-based proof verification. In parallel, the authentication segment showed an implemented multi-step design combining email verification, password-based access, SSI-supported proof exchange, and optional second-factor reinforcement. However, the complete authentication chain was only partially reproducible under blind automated execution because some stages depended on OTP values, active session context, and SSI-dependent orchestration conditions.

Functional and integration results

Across the reconstructed validation scenarios, the clearest empirical support was observed in the documentary workflow rather than in isolated endpoint-level behavior. The prototype showed direct evidence of successful document upload by the issuing entity, administrative review and approval, access-request generation, citizen approval or rejection, authorized document consultation, synchronization with Hyperledger Fabric, traceability recording, and SSI-based proof verification. Accordingly, the results indicate that the system did not remain at the level of interface simulation, but achieved an operational cycle in which documentary actions produced persistent state changes across storage, blockchain, and SSI-related components. A summary of these findings is presented in Table 4.

TABLE 4. Summary of functional and integration results.

At the documentary-ingestion level, the prototype provided consistent evidence of successful submission by issuing entities. File persistence records confirmed off-chain storage of documentary binaries, whereas the workflow state made uploaded files available for the administrative stage. Thus, the system materialized the deposit of citizen-linked documentary evidence within the operational environment. This stage is illustrated in Figure 5.

The second critical transition corresponded to the review and approval stage performed by the administration module. The recovered evidence showed that reviewed documents changed state and preserved review timestamps, thereby making them eligible for subsequent access-request processes. Therefore, documentary availability for consultation depended not only on file existence, but also on prior institutional validation. The administrative review interface corresponding to this stage is shown in Figure 6.

Once approved documents became eligible for downstream actions, the workflow continued through request generation and citizen-side decision. Operational evidence showed six access requests in the active environment, with four approved and two rejected. Hence, access to documentary information was not resolved as a unilateral action by the issuing entity, but through an intermediate authorization layer centered on the citizen as holder of the information. The citizen-facing decision point is presented in Figure 7.

The strongest end-to-end integration evidence emerged when approved requests were followed by effective document consultation and auditable blockchain records. In particular, requests 3, 4, and 6 linked a complete thread from document registration to request creation, citizen decision, authorized access, and blockchain-preserved event evidence. Accordingly, the prototype achieved end-to-end execution for the documentary verification workflow. The final user-facing stage of documentary access is represented in Figure 8.

The authentication segment should not be interpreted as absent. Instead, the recoverable evidence showed an implemented multi-step authentication workflow combining email verification, account creation, SSI-supported proof exchange, and optional second-factor reinforcement through mobile authenticator or email-based OTP. Guided operational documentation showed that the user received a verification code by email, validated the account, could configure a mobile authenticator, and then entered the initial citizen panel. Nevertheless, the complete authentication chain was not fully recoverable as an autonomous operational artifact in the current deployment, and some security-sensitive endpoints behaved differently during blind Newman execution. Therefore, authentication is most accurately reported as operationally evidenced in guided use, whereas its fully reproducible automated validation remained partial.

Security, privacy, and traceability results

The security- and privacy-oriented validation showed that the prototype preserved a functional separation between sensitive binaries and distributed-ledger records. Full PDF documents remained off-chain: file entries were stored as path-based references, binary content remained null in the database sample, and physical files were verifiably present in the storage layer. At the same time, Fabric preserved documentary references, integrity-related values, and auditable events rather than raw document binaries. Therefore, the implemented architecture did not use the blockchain as a repository for directly readable documentary content.

However, the on-chain state still included operational metadata and direct identifiers such as document identifiers, issuing entity, size, hash, creation date, and file path. For that reason, the results support a formulation based on off-chain preservation of sensitive binaries with on-chain integrity and operational metadata, rather than a stricter claim of near-zero descriptive exposure on-chain. These findings are summarized in Table 5.

TABLE 5. Security, privacy, and traceability findings.

In addition, the results showed that access control operated through a layered sequence rather than through a single authorization point. Third-party consultation depended first on document availability in the approved administrative state and then on explicit approval of the access request by the citizen. Operationally, approved requests were the condition preceding the emergence of DOC_VIEW_GRANTED events in Fabric. Likewise, Fabric preserved events such as REQUEST_CREATED, DOC_VERIFY_ON_REQUEST, DOC_VIEW_GRANTED, and USER_ACCESS_STATE_CHANGE, and valid transactions could be resolved directly from the ledger for both documentary registration and access-audit events. Consequently, the blockchain layer functioned as an evidence and traceability mechanism within the implemented workflow. The administrative traceability view associated with these results is shown in Figure 9.

Authentication-related security should still be interpreted with methodological caution. The prototype integrated password-based access, SSI-supported proof exchange, and second-factor options, and the recovered evidence confirmed TOTP enrollment in three of four final-user accounts. Even so, the evidence reconstruction also showed that a complete persistent record of the full successful login closure was not recovered from the active deployment, and that blind automation of selected authentication endpoints produced redirect behavior rather than the controller-level contract expected in code. Accordingly, the findings support the existence of layered authentication mechanisms in the prototype, but their validation is more accurately described as operationally evidenced in guided use and only partially reproduced in automated testing.

Repeated operational runs and preliminary performance characterization

To organize these findings, Table 6 consolidates the preserved repeated-run evidence into two complementary blocks: Newman/Postman diagnostic execution and k6 controlled-load exploration. The table separates the observed results from their interpretation because the two tools exercised different aspects of the prototype. Newman/Postman provided repeated request-based evidence and exposed a proof-polling limitation in the SSI workflow, whereas k6 explored a limited controlled-load scenario involving administrative access, document listing, and protected-file retrieval. Therefore, the table should not be read as a unified performance benchmark, but as a structured summary of the diagnostic evidence available for characterizing automation behavior, execution constraints, and orchestration-dependent workflow segments. The summary of these results is presented in Table 6.

TABLE 6. Diagnostic Newman/Postman and k6 repeated operational evidence.

The evidence summarized in Table 6 shows that repeated operational execution was useful primarily for identifying the boundary between directly scriptable operations and workflow segments that require preserved context. The Newman/Postman failures were concentrated in the “Poll proof” step and were associated with an empty request URL, which indicates that SSI proof polling depends on dynamically generated proof-exchange context rather than on a static endpoint that can be repeatedly invoked without orchestration. Similarly, the k6 failures were concentrated in protected-file retrieval, indicating that this operation depends on valid session state, authorization conditions, and access context.

Consequently, the repeated-run evidence does not support a claim of full end-to-end automation or production-level performance. Its value is diagnostic: it identifies which parts of the prototype behaved predictably under scripted execution and which parts require orchestration-aware validation. This distinction is particularly relevant for SSI-enabled document-verification systems, where proof exchange, polling, protected access, and authorization-sensitive file retrieval cannot be evaluated reliably through stateless repetition alone. The results therefore reinforce the methodological interpretation of CCDigital as a controlled prototype-validation exercise rather than as a production scalability or load-testing study.

Discussion

The present study provides controlled prototype-based evidence that a permissioned blockchain architecture combined with SSI/verifiable-credential workflows can support a digital citizenship process centered on document authenticity, traceability, holder-mediated authorization, and privacy-aware verification. The results showed that CCDigital executed the main issuer–holder–verifier trajectory, including document upload, administrative review, access-request generation, citizen approval or rejection, authorized consultation, and blockchain-based event recording. This finding is relevant because the system did not remain at the level of conceptual design or interface simulation; instead, it connected the web application, relational persistence, off-chain document storage, Hyperledger Fabric, and ACA-Py/Indy proof logic within a single operational workflow. Therefore, the contribution of the study lies in demonstrating a coherent prototype architecture for document-centered digital citizenship rather than in claiming production-level maturity or national-scale validation.

This contribution addresses a gap in the literature on blockchain-based digital identity. Prior research has extensively discussed blockchain, self-sovereign identity, verifiable credentials, privacy, interoperability, and public-sector governance, but these dimensions are often analyzed separately or within specific domains such as academic credentials, healthcare, transportation, or authentication protocols (Stockburger et al., 2021; Nedaković et al., 2023; Agarkar et al., 2024; Franklin et al., 2025; Tran et al., 2025). In contrast, CCDigital integrates document management, citizen-mediated access control, ledger-based traceability, and SSI-supported proof verification in a single evaluable workflow. The value of the prototype is therefore not only technical, but also methodological: it shows how a public-service digital identity architecture can be examined through functional, integration, privacy, security, operational, and usability-oriented dimensions under controlled conditions.

A central implication concerns auditability. In public digital services, institutional trust depends on the ability to reconstruct who submitted a document, whether it was reviewed, when access was requested, whether the citizen approved consultation, and whether subsequent access can be audited. CCDigital addressed this requirement by registering documentary references and relevant events in Hyperledger Fabric while preserving PDF binaries outside the ledger. This design confirms that the blockchain layer was not used as a general-purpose document repository, but as an evidentiary mechanism for traceability and integrity. In this sense, the prototype supports the view that blockchain contributes to public-sector digital identity when it is embedded in specific accountability workflows rather than adopted as a generic decentralization label (Tan et al., 2021; Shahaab et al., 2022; Kassen, 2022; Alotaibi et al., 2025).

At the same time, the privacy findings require careful qualification. The system reduced direct exposure by keeping full PDF documents off-chain and recording only references, hashes, operational metadata, and auditable events on-chain. This represents a meaningful privacy-by-design decision, especially in a digital citizenship context where documents may contain sensitive personal information. However, the results do not support a claim of complete metadata minimization. The on-chain state still included document identifiers, issuing entity information, file size, hash values, creation dates, and file paths. Consequently, the prototype should be interpreted as achieving partial minimization of sensitive content, not near-zero descriptive exposure. This distinction is important because privacy in SSI and blockchain-based systems is not automatic; it depends on what is stored, how records can be linked, and what inferences can be drawn from persistent metadata (Flamini et al., 2024; Zhou et al., 2024; Wijesundara et al., 2025).

The document-centered design also has implications for the positioning of CCDigital relative to alternative architectures. Compared with a conventional centralized repository, CCDigital adds holder-mediated authorization and ledger-based auditability rather than relying only on internal institutional logs. Compared with a blockchain-only document registry, it avoids storing raw documents on-chain and links access to citizen approval. Compared with SSI without a ledger-based audit layer, it adds an institutional traceability mechanism for document-related events. However, this hybrid design also introduces operational overhead because it combines web-session logic, relational persistence, off-chain storage, Fabric transactions, and SSI proof orchestration. Therefore, the architecture is most defensible in scenarios where document traceability, institutional accountability, and citizen-mediated access are central requirements. For simpler verification problems, a lighter centralized, federated, or SSI-only approach may be more efficient.

Interoperability must also be interpreted with precision. CCDigital demonstrates internal architectural interoperability among the web application, database, off-chain storage, Hyperledger Fabric, and ACA-Py/Indy infrastructure. The SSI component relied on Aries Present-Proof 2.0 workflows and Indy/AnonCreds credential structures, including a public did:sov issuer identifier, schema, credential definition, and proof-based attribute disclosure. This supports technical alignment with the issuer–holder–verifier model used in decentralized identity ecosystems. However, the prototype did not implement formal conformance testing against W3C DID Core, the W3C Verifiable Credentials Data Model, OpenID for Verifiable Credential Issuance, OpenID for Verifiable Presentations, or related certification processes. Accordingly, the manuscript’s interoperability claims should be read as prototype-level integration and partial SSI alignment, not as evidence of full cross-platform standards compliance.

Governance is another essential boundary of interpretation. In the prototype, the Hyperledger Fabric network was implemented in a laboratory environment using simulated organizations, including Org1MSP and Org2MSP, rather than real governmental or institutional node operators. This was sufficient for controlled validation of endorsement, ordering, chaincode execution, and event retrieval, but it does not establish an operational governance model for deployment. A real digital citizenship network would require explicit rules defining who may operate nodes, endorse transactions, update chaincode, issue credentials, request access, audit records, revoke permissions, and resolve disputes. A consortium model involving a governing public authority, authorized issuing entities, an audit or regulatory actor, and potentially neutral technical operators would be more appropriate for institutional deployment. Disputes involving incorrect documents, unauthorized requests, contested approvals, or revocation should be resolved through administrative and legal procedures supported by blockchain evidence, not by the ledger alone.

The security evaluation further supports a bounded interpretation of the results. The prototype incorporated layered access control, holder-mediated authorization, off-chain preservation of document binaries, security-related HTTP headers, authentication mechanisms, and traceability of access events. These controls provide prototype-level evidence that the architecture follows privacy and security design principles. Nevertheless, the study did not include a formal penetration test with tools such as OWASP ZAP, Burp Suite, Nmap, Nikto, or comparable DAST/pentest methods. It also did not include an independent audit of AnonCreds, zero-knowledge proofs, or the underlying cryptographic implementation. Cryptographic verification was delegated to ACA-Py/Indy and assessed only at the workflow-integration level. Therefore, the results should not be interpreted as production-grade security certification, but as evidence that the implemented prototype incorporates relevant security controls and exposes clear requirements for future security validation.

The authentication results illustrate the same methodological boundary. Guided operational evidence showed that the prototype implemented email verification, password-based access, SSI-supported proof exchange, and optional second-factor reinforcement. However, blind automated testing could not fully reproduce all authentication stages because several flows depended on OTP values, active sessions, proof-exchange identifiers, polling sequences, and signed or authorization-dependent URLs. This does not mean that authentication was absent, but it does show that SSI-enabled systems require orchestration-aware testing rather than simple stateless repetition of endpoints. Future validation should therefore combine repeated automation for stable endpoints, scenario-based testing for end-to-end workflows, and security-specific automation capable of preserving session and proof-exchange context.

The repeated operational findings should also be interpreted cautiously. The preserved Newman/Postman reports documented a diagnostic execution with 50 iterations and 250 processed requests, including 50 failures concentrated in the SSI proof-polling step. Complementary k6 evidence documented 250 checks, with 200 successful checks and 50 failures concentrated in protected-file retrieval. These results are useful because they expose orchestration-dependent limitations in proof polling and protected document access under automated repeated execution. However, they do not constitute a full scalability study, production-like load test, Fabric throughput measurement, or production-readiness validation. Thus, the operational contribution of the study is best described as preliminary diagnostic evidence for integration behavior and friction detection, not as evidence of national-scale readiness.

Usability remains an important but underdeveloped dimension. The system was reviewed through internal formative assessment during role-based functional validation, and the observed tasks included registration, authentication, citizen-folder navigation, document consultation, access-request handling, approval or rejection, and interpretation of visible workflow states. However, no recoverable standalone dataset, SUS score, Likert-scale survey, interview protocol, checklist, or consolidated usability report was available for empirical reporting. This limitation is especially relevant because SSI systems may impose cognitive and procedural burdens related to key management, credential presentation, consent interpretation, and multi-step verification. Therefore, the present study can only claim formative usability insight, not quantified user-experience validation. Future work should evaluate CCDigital with end users and institutional actors using task-completion rates, time on task, error frequency, assistance requests, perceived ease of use, trust, and privacy-control metrics (Viano et al., 2023; Laatikainen et al., 2025; Seo and Park, 2025).

The Colombian context gives practical relevance to these findings. Digital citizenship in Colombia involves secure authentication, citizen-folder services, interoperability, privacy, data sovereignty, and trust in public digital services. In such a context, a model that combines off-chain document preservation, ledger-based traceability, citizen authorization, and SSI-supported verification offers a plausible design pathway. However, the prototype should not be interpreted as a replacement for the existing national digital citizenship infrastructure, nor as proof that a blockchain-based model is automatically superior. Its value is more specific: it shows how a privacy-aware and auditable document-verification workflow can be technically assembled and evaluated under controlled conditions aligned with Colombian regulatory and institutional concerns (Ramírez López et al., 2025).

Several limitations must therefore be acknowledged. First, the study was conducted in a laboratory environment and did not involve a production deployment, longitudinal pilot, or ecological validation with public institutions. Second, the strongest evidence was concentrated in the documentary workflow, while authentication and SSI-dependent flows were only partially reproducible through blind automation. Third, the evaluation was descriptive and scenario-based rather than inferential. Fourth, the repeated-run evidence corresponded to diagnostic Newman/Postman and k6 executions, including proof-polling and protected-file retrieval failures, rather than to a fully passed smoke test, scalability benchmark, or production load test. Fifth, usability was treated formatively and lacked a recoverable quantitative dataset. Sixth, privacy minimization was incomplete because on-chain metadata still carried descriptive and inferential value. Seventh, governance, revocation, dispute resolution, and standards conformance were identified as requirements for future deployment rather than fully implemented components.

These limitations define the scope of the contribution. CCDigital should be understood as a controlled prototype that demonstrates architectural feasibility and integration evidence, not as a mature privacy-preserving identity infrastructure. Its findings support conditional optimism: permissioned blockchain and SSI/verifiable-credential workflows can strengthen traceability, holder-mediated access, and privacy-aware document verification when they are carefully integrated with off-chain storage, role-based controls, and institutional review. However, moving from prototype to deployment would require stronger metadata minimization, formal threat modelling, penetration testing, independent cryptographic review, W3C/OpenID conformance testing, governance formalization, revocation and dispute mechanisms, larger-scale performance evaluation, and empirical usability studies.

Overall, the study advances the literature by moving from general claims about blockchain-enabled digital identity toward a more empirically grounded understanding of how such systems can be designed, implemented, and evaluated in a public-service context. The main contribution is not the announcement of a finished digital citizenship model, but the demonstration that an auditable, privacy-aware, and citizen-mediated architecture is technically plausible and methodologically researchable. In doing so, the study clarifies both the promise and the remaining maturity gaps of permissioned blockchain and verifiable-credential systems for digital citizenship services.

Conclusion

This study presented CCDigital, a controlled prototype that integrates permissioned blockchain, off-chain document storage, relational persistence, and SSI/verifiable-credential workflows for privacy-aware digital citizenship document verification. The prototype successfully executed the core issuer-holder-verifier workflow, including document upload, administrative review, access-request generation, citizen approval or rejection, authorized consultation, and blockchain-based event recording. The preserved repeated-run evidence consisted of diagnostic Newman/Postman and k6 artifacts rather than a fully passed smoke or load test. The Newman/Postman reports documented 50 iterations and 250 processed requests, with 50 failures concentrated in SSI proof polling because the request URL was empty. The k6 evidence documented 250 checks, with 200 successful checks and 50 failed checks concentrated in protected-file retrieval.

These findings provide preliminary evidence that permissioned blockchain and SSI-supported verification can strengthen traceability, holder-mediated access, and auditable document provenance in a controlled institutional setting. However, the results should not be interpreted as evidence of production readiness, national-scale deployment, or mature privacy-preserving identity implementation. The evaluation was limited by laboratory conditions, small workload volume, partial automation of authentication and SSI-dependent flows, absence of formal penetration testing, absence of independent cryptographic auditing, incomplete metadata minimization, lack of formal W3C/OpenID conformance testing, and absence of quantitative end-user usability data. Future work should prioritize production-like pilots, formal threat modelling, penetration testing, cryptographic review, standards conformance testing, governance formalization, revocation and dispute-resolution mechanisms, larger-scale performance evaluation, and empirical usability studies with citizens and institutional actors.

Generative AI statement

The author(s) declared that generative AI was not used in the creation of this manuscript.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher’s note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Supplementary material

The Supplementary Material for this article can be found online at: https://www.frontiersin.org/articles/10.3389/fbloc.2026.1845469/full#supplementary-material

Supplementary material Supplementary material at the source

Footnotes

Edited by: Diego Kreutz, Universidade Federal do Pampa - Campus Alegrete, Brazil

Reviewed by: Swapna Radha, University of Notre Dame, United States

Muharman Lubis, Telkom University, Indonesia

Javier Gamboa-Cruzado, National University of San Marcos, Peru