# 6. Architecture Considerations for the Wallet ## 6**.1 Wallet in the GovStack and eIDAS 2.0** In architectural terms, the wallet sits between the user and a network of issuers, relying parties, and trust services. The EUDI Wallet ARF does not require a central information-mediation bus. Instead, it standardises the wallet-facing exchange protocols. OpenID4VCI supports issuance from PID and attestation providers to the wallet. OpenID4VP supports remote presentation from the wallet to relying parties. ISO 18013-5/-7 supports proximity and offline-style presentation scenarios. In GovStack terms, these protocols provide the wallet-specific data-exchange layer, while broader service-to-service mediation remains in the GovStack Information Mediator domain. On one side, the wallet communicates with PID and attribute issuers through OpenID4VCI flows. It authenticates the user, usually via an external IdP connected to the Identity Building Block or OID4VP flow, and then receives credentials as SD‑JWTs ARF‑compliant formats. These credentials are stored inside the wallet, with associated keys held in a WSCD. On the other side, the wallet engages with relying parties using OpenID4VP. A service requests certain attributes, the wallet lets the user choose which attributes to share (within required constraints) and creates a verifiable presentation. That presentation is signed or otherwise cryptographically bound to keys in the WSCD and is sent to the relying party, which validates it using trust lists and the issuer’s registration certificate or the Registrar’s public API. Around this core interaction, it may also interface with the Signature Building Block to authorise QES creation, sending tokens that prove user intent to sign specific documents. ## **6.2 Credential Formats and Protocols** The wallet must be comfortable with several credential forms. PID may be issued as SD‑JWT VC or as an ISO mdoc. QEAAs may come as verifiable credentials in JWT or JSON‑LD form, or as mdocs as well. The wallet acts as a container that can handle all formats mandated by the EUDIW ARF, with a consistent user experience. In GovStack terms, part of the EUDI trust layer maps to Digital Registries and Registration functions. Trusted Lists, LoTEs, registrar services, relying-party registration, registration certificates, access certificates, and status or revocation information operate as trust registries for wallet ecosystem actors. This should not be confused with general business, licensing, or permit registries. For the wallet, the key question is whether an issuer, relying party, QTSP, or other ecosystem actor is registered, trusted, and authorised for the requested interaction. The wallet should use this trust evidence in a privacy-preserving way. It should not need to fetch a central trusted list for every presentation. A safer design is to use signed trust-anchor stores, cached registrar information, access certificates, registration certificates, and status mechanisms that allow the wallet to make trust decisions without creating a central record of where citizens use their wallet. OpenID4VCI is the main channel through which issuers provision credentials to the wallet. OpenID4VP is used for presentations. Both must follow the EU‑specific profiles defined in the EUDIW ARF and, where applicable, the OpenID4VC High Assurance Interoperability Profile (HAIP), including expected parameter sets, supported algorithms, and security properties. ## **6.3 Trust Framework and Revocation** The wallet depends on a trust framework, but it should not be described as fetching the full EU List of Trusted Lists for every transaction. In an EUDI deployment, trust is normally expressed through a combination of access certificates, registration certificates, registrar information, issuer metadata, trusted-list or LoTE-derived trust anchors, and revocation/status information. For issuer interactions, the wallet authenticates the PID or attestation provider by checking evidence such as access certificates and issuer metadata. For relying-party interactions, the wallet checks the relying party’s registration information, either through a registration certificate or through an online registrar service where that is the applicable model. The wallet then compares the requested attributes with the relying party’s registered purpose, intended use, and authorisation. Trusted lists and LoTEs remain important, but they should be implemented in a privacy-preserving way. A national wallet implementation may use a signed local trust store, cached trust anchors, or a companion trust component that updates independently of individual user transactions. The design should avoid per-presentation lookups that would allow the Wallet Provider or a central trust service to reconstruct which relying parties a person is visiting. Revocation must be treated at several levels. PID and attestations need status or revocation checks according to the relevant credential format and ARF profile. Relying parties verify whether presented PIDs or attestations are still valid. Wallet Unit evidence also has a lifecycle: a Wallet Unit Attestation can be revoked or invalidated by the Wallet Provider, and PID or attestation providers need to take wallet status into account during issuance and lifecycle management. The ARF also makes clear that relying parties do not normally verify the Wallet Unit directly; they rely on the issuer’s validation of the wallet at issuance time and on the ongoing validity of the presented PID or attestation. Offline behaviour must be explicit. Some low-risk operations may continue for a limited time using cached trust and status information. High-risk operations, QES initiation, onboarding, or presentation of credentials requiring fresh status may need connectivity. The wallet should show clear user-facing messages rather than silently accepting stale trust decisions. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://specs.govstack.global/impl-eidas-wallet/6.-architecture-considerations-for-the-wallet.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.