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.

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.

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 does not live in a vacuum, it depends on a trust framework. It must process information from the EU List of Trusted Lists (LOTL), national trust lists as well as relying party registers or the registration certificates they have issued to understand which issuers and QTSPs are recognised. A local trust component, either built into the wallet or provided as a companion service, fetches and validates trust lists, caches them, and exposes trust decisions to the wallet.

Revocation and status checking are also essential. The wallet needs to check whether credentials are still valid, using status‑list mechanisms, OCSP, or other ARF‑aligned methods. It must cope gracefully with offline conditions: some checks can be deferred with cached status, while others may require the wallet to refuse certain operations until connectivity returns.