Italian Wallet (IO App)

• Italian Wallet (IO app) is Italy's state-mandated digital interface that unifies public services with eIDAS-compliant authentication and credential management.
• It streamlines disparate governmental functions into a single gateway, facilitating efficient citizen-to-government interactions such as notifications and payments.
• Recent studies assess its technical backbone—including TEE-based attestations, zero-knowledge proofs, and sentiment analysis—to enhance privacy and user trust.

The Italian Wallet, known as the IO app, constitutes both the state-mandated mobile interface for digital public services in Italy and, since eIDAS 2.0, the national “IT-Wallet” for qualified digital credentials. Designed to provide a unified access point for a broad range of citizen-to-government interactions (e.g., notifications, payments, service requests), the IO app integrates eIDAS-compliant authentication modules, credential management pipelines, and—under recent research trajectories—extensible interfaces for Self-Sovereign Identity (SSI) workflows using advanced cryptographic primitives and Trusted Execution Environments. Both its effectiveness as a digital transformation tool and the technical/ethical challenges in managing user sentiment, privacy, and decentralized control have been the subject of comprehensive scrutiny in the scientific literature (Miracula et al., 2023, Sitouah et al., 27 Jan 2026).

1. Digital Transformation in Italian Public Administration

The IO app operationalizes the Italian Public Administration’s (PA) “single-point” digital interface, as mandated by Article 64 bis of the Digital Administration Code and specified in the 2019–2025 Three-Year Plan. It is architected to unify previously disparate digital services, providing authentication (via SPID/CIE protocols), payment workflows, and direct communication channels between citizens and public authorities.

The strategic intent is the reduction of fragmentation (“e-Government” to “smart government”), efficiency gains, and improved accessibility. The IO app is positioned as the Italian keystone of EU-wide interoperability efforts, especially under eIDAS and, more recently, within the European Digital Identity Wallet framework (Miracula et al., 2023, Sitouah et al., 27 Jan 2026).

2. Sentiment Analysis and User Adoption Challenges

Despite fulfilling critical requirements for PA digitization and serving approximately 95% of Italian mobile users (based on store coverage), the IO app has historically received predominantly negative feedback.

A corpus of 62,986 user reviews from the Apple App Store and Google Play Store (mid-2022 cutoff) reveals:

• 75.91% negative sentiment.
• 24.09% positive sentiment.
• Dominant negative emotions: sadness (34.3%) and anger (26.2%); positive emotion rates are lower but less precisely quantified (Miracula et al., 2023).

Fine-tuned Italian BERT models, trained to classify sentiment (binary) and emotion (joy, sadness, anger, fear), indicate that negative reviews often reflect broader user dissatisfaction with government policy (COVID-19 measures, “Green Pass,” “Cashback” program) and generalized distrust of public administration, rather than direct app quality or functional deficits. As a result, sentiment analysis in this context serves not only to highlight product-specific deficiencies but also to proxy for sociopolitical critique, complicating technical evaluations and adoption metrics.

Continuous NLP-driven meta-evaluation is recommended:

• Automated dashboards for policymakers,
• Feature segmentation to disentangle policy vs. implementation criticism,
• Iterative user feedback loops targeting the most negative clusters (e.g., authentication or service unavailability).

Embedding such mechanisms in development and deployment cycles enhances responsiveness to complex user experience signals (Miracula et al., 2023).

3. System Architecture and Cryptographic Foundations

The IO app, as the “IT-Wallet,” supports multiprotocol authentication (SPID/CIE), credential issuance by qualified authorities (QEAAs), and local storage of Selective-Disclosure JWT Verifiable Credentials (SD-JWT-VCs). To extend IO towards full self-sovereign interoperability compliant with eIDAS 2.0, research has defined a dual-wallet system:

• IT-Wallet (IO App): Handles native issuance, signing, and export of SD-JWT-VCs.
• SSI-Wallet: May be co-located or paired on-device, and includes:
  • Host-side logic,
  • TEE enclave (e.g., Intel SGX) to isolate keys and sensitive code,
  • ZK proof generation (on-device or through a confidential cloud operator).

Architectural trust boundaries are strictly enforced:

1. SD-JWT-VC export is one-way (user consent).
2. All sensitive logic executes inside the enclave.
3. Enclave-to-endpoint communication is TLS-protected with enclave-pinned certificates.
4. ZK proofs, when produced, are anchored to on-chain verifier contracts, enabling public but privacy-preserving auditability (Sitouah et al., 27 Jan 2026).

4. Selective Disclosure and Zero-Knowledge Protocols

To enable minimal disclosure and unlinkability, SD-JWT-VCs use Merkle-tree–based selective disclosure:

• Attributes $a_1,...,a_n$ are encoded as leaves $$L_i = H(\text{name}_i\ \Vert\ ":\ "\Vert\ \text{value}_i\ \Vert\ ":\ "\Vert\ \text{nonce}_i)$$.
• The credential Merkle root $R$ is signed by the issuer and included in the JWT payload.
• Selective disclosure is achieved by revealing $$(\text{value}_j, \text{nonce}_j, \text{MerklePath}(L_j \to R))$$; the verifier recomputes paths and checks issuer signatures.

Further, an attested verification protocol delivers additional assurances:

• The TEE enclave verifies the credential and generates a new JWT-VC containing $\text{originalDigest} = H(\text{SD-JWT-VC})$, a validation timestamp $t$, and an SGX remote attestation quote.
• ZK-SNARKs encode the NP-relation that attestation and verification were executed correctly inside a measured enclave:

  $$R = \{ ((VK_\text{PCKroot}, m^*, c_h), (\text{quote}, \text{cert\_chain}, ts, \text{code\_hash}))\ |\ VerifyQuote(\text{quote}, VK_\text{PCKroot}, m^*) = 1\ \wedge\ \text{code\_hash}=MRENCLAVE(\text{verified-binary})\ \wedge\ c_h = H(\text{attested-JWT-VC}) \}$$

• On-chain contracts implementing $Verify(vk, x, \pi)$ validate proof submission and emit succinct attestations (logging $c_h$, block, transaction hash) (Sitouah et al., 27 Jan 2026).

5. End-to-End Workflow and API Integration

A standardized workflow is prescribed for credential lifecycle management:

1. User authenticates with the IO App (SPID/CIE) and requests credential issuance (SD-JWT-VC).
2. On user request, $exportCredential()$ transfers the VC to the SSI-Wallet.
3. Off-TEE pre-validation (e.g., signature and revocation pre-checks) is performed.
4. The host calls into the TEE enclave for full verification and attested VC generation.
5. Optionally, a ZK proof is generated (either on-device or in a confidential cloud) and submitted to the blockchain.
6. For presentation, the user provides the attested VC, selectively disclosed attributes, Merkle paths, and (optionally) the on-chain proof reference.
7. Verifiers independently check all signatures, Merkle proofs, attestation data, and (optionally) consult the on-chain log for $ProofVerified$ status events.

Key API functions include:

• $$exportCredential(\text{issuerType}, \text{credentialType})$$
• $$verifyInEnclave(\text{SD-JWT-VC}, \text{endpoints}[], \text{anchorKey})$$
• $proveAttestation(\text{attestedVC}, \text{mode})$
• $submitProof(c_h, \pi)$
• $getProofStatus(c_h)$

TEE remote attestation typically requires 100–200 ms, endpoint queries 50–100 ms per call, and on-chain ZK verification using Groth16 circuits consumes approximately 200,000 gas (Sitouah et al., 27 Jan 2026).

6. Security, Privacy, and eIDAS 2.0 Compliance

The architecture ensures:

• Decentralized control: Users retain exported SD-JWT-VCs post-issuance, with evidence of revocation and status captured at the export time by the enclave.
• Minimal disclosure: The Merkle structure ensures only user-selected attributes are revealed.
• Unlinkability: Fresh nonces, attested credentials, and ZK proofs (anchored to hash $c_h$) prevent correlation of multiple presentations.
• Soundness: The combined guarantees of SNARK soundness, collision-resistant hashing, and hardware-backed attestation (SGX) make forgery computationally infeasible barring a compromise of underlying cryptographic primitives (Sitouah et al., 27 Jan 2026).

eIDAS 2.0 compatibility is preserved: all status endpoints and trust anchors remain under eIDAS governance, and export/import logic can be incorporated into future IO App releases per the “interoperability” mandate of eIDAS 2.0.

7. Implications for Policy, Technical Strategy, and Future Development

Continuous monitoring of both user sentiment (via NLP-driven meta-evaluation) and cryptographic traceability (via TEE and ZK workflows) is essential for adaptive, privacy-respecting public service delivery. At the technical layer, the architecture demonstrated for the IO App establishes a pattern for integrating legacy state-controlled credential schemes with decentralized, user-centric identity protocols, without violating regulatory compliance.

At the governance layer, understanding the distinction between app-specific dissatisfaction and macro-level policy critique is critical for effective resource allocation and iterative improvement. Embedding automated review analytics and cryptographic auditability into ongoing digital transformation ensures alignment with the guiding principles of speed, simplicity, and transparency in public administration (Miracula et al., 2023, Sitouah et al., 27 Jan 2026).