> For the complete documentation index, see [llms.txt](https://specs.govstack.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://specs.govstack.global/impl-eidas-wallet/development/6.-architecture-considerations-for-the-wallet.md). # 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://specs.govstack.global/impl-eidas-wallet/development/6.-architecture-considerations-for-the-wallet.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.