# 10. Terminology and Mappings for the Wallet In GovStack, the Digital Wallet Building Block is a generic credential container. In the EU setting, that component becomes the European Digital Identity Wallet (EUDIW) once it follows the ARF profiles, integrates with WSCDs, and implements the regulatory requirements described in this guide. GovStack uses Verifiable Credentials as a general term for attribute credentials. eIDAS 2.0 introduces Qualified Electronic Attestation of Attributes (QEAA) for regulated attributes issued under a qualified trust service. Every QEAA is an EAA, not every EAA qualifies as a QEAA. The human carrying the wallet appears under several labels across specifications: user, individual, data subject, and signatory in signing contexts. In this guide, wallet holder is used in user experience and technical sections, while GDPR and eIDAS terms appear where legal status matters. The wallet interacts with credential issuers and credential verifiers in GovStack language. The EU profile refines this into PID Providers, EAA/QEAA/puB-EAA providers, QTSPs, and relying parties. From the wallet’s perspective, these mappings matter mainly for trust decisions and error reporting; from a governance perspective they define liability and supervision. In addition GovStack introduces the notion of an electronic identity token as a hardware carrier for keys. eIDAS 2.0 uses Wallet Secure Cryptographic Device (WSCD) for hardware or hardware‑anchored environments that protect wallet keys. In practice, WSCDs are the platform facilities the wallet integrates with to fulfil its security duties. ## **10.1 Terminology mapping** | **Concept area** | **GovStack terminology (Identity / Wallet / Consent / eSignature specs)** | **EU profile terminology (this IG / eIDAS / EUDIW)** | **Relationship / notes** | | -------------------------- | ------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Core components | Identity and Verification Building Block / Identity Building Block | PID Provider | Same technical piece once profiled for EU. In the EU view it acts as PID Provider at LoA High and connects to authentic registers. | | | Digital Credential Wallet / Wallet Building Block | European Digital Identity Wallet (EUDIW) | Same wallet software. “EUDIW” is the label once it follows the ARF profile, stores PID/QEAAs, is certified and uses WSCD hardware. | | | Consent Agreement, Consent Record, Data Policy | Privacy & Transparency Dashboard | Consent BB is the engine behind the Dashboard. Consent Records and policies feed the user‑facing history and GDPR logic. | | | E‑Signature Building Block, eSignature / digital signature, Signature Creation Device (SCD) | Qualified Electronic Signature (QES) Creation Application, Signature Creation Device (SCD), Qualified Signature Creation Device (QSCD) | Same signing stack with extra eIDAS layers. EU profile focuses on QES, requires QTSP/QSCD, and treats the BB as a QES application. | | Credentials & attributes | Verifiable credential (generic identity or attribute token) | PID and QEAA/EAA | “Credential” aligns as a general term. PID and QEAAs are the regulated subset with strict formats and trust rules. | | | Verifiable Credentials | Qualified Electronic Attestation of Attributes (QEAA) | QEAA is the regulated form of EAA, issued under a qualified trust service and recognised under eIDAS. | | User (citizen) | Credential Holder (Wallet BB), Individual / Data Subject (Consent BB), Signatory / User (eSignature BB) | Wallet Holder, Data Subject, Signatory | All labels point at the same person. GovStack language varies by component, EU vocabulary varies by legal context (data protection vs signing). | | Actors & systems | Credential Issuer (manages issuance and revocation) | PID Provider, Attribute Provider, QTSP | Same protocol role. EU view splits issuers into distinct legal roles with different liability and certification needs. | | | Credential Verifier (validates credentials presented by holder) | Relying Party | Functionally equivalent. “Relying Party” is the policy‑heavy term for services that depend on PID/QEAAs. | | | Data Provider and Data Consumer (Consent BB) | Controller, Processor, Relying Party | Data Provider usually maps to a controller of a source system. Data Consumer typically maps to a relying party acting as controller or processor. | | Devices & security modules | Electronic Identity Token (hardware device for identity operations) | Wallet Secure Cryptographic Device (WSCD) | Both are hardware used to protect keys and operations. WSCD is the specific eIDAS label for wallet‑side cryptographic protection. | | | Signature Creation Device (SCD) | Qualified Signature Creation Device (QSCD) | QSCD is the certified subset of SCDs that meet eIDAS conditions for QES. | | Signatures | eSignature / electronic signature / digital signature (broad concept) | Qualified Electronic Signature (QES) | QES is the eIDAS‑defined subset of electronic signatures that reach full legal equivalence to handwritten signatures. | | Consent artefacts | Consent Agreement, Consent Record, Consent Reference (Consent BB) | Transaction history entries, logs / records in the Privacy Dashboard | Consent Records and references live under the hood. The Dashboard surfaces them as history entries, and logs carry the audit trail for GDPR and eIDAS checks. | --- # 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/10.-terminology-and-mappings-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.