Glossary
This page provides definitions for key terms used throughout the Truvity EUDIW Connector documentation.
EUDI Wallet ecosystem terms
| Term | Definition | Example |
|---|---|---|
| PID | Personal Identification Data—government-issued digital identity | Digital national ID card |
| EAA | Electronic Attestation of Attributes—any other verified credential | Diploma, driver's license, bank account proof |
| QEAA | Qualified EAA—attestations from qualified trust service providers | Professional certifications, legally recognized documents |
| PuB-EAA | EAA published under a specific legal basis other than the QTSP framework. PuB-EAA Providers are listed in Trusted Lists alongside QEAA Providers. | Attestation issued under sector-specific legislation |
| Wallet Unit | The secure app on a user's device | EUDI Wallet app on phone |
| Wallet Instance | A specific installation of a wallet on a device | Your personal wallet on your phone |
| Wallet Holder | An EU citizen or resident who owns and controls an EUDI Wallet app, stores credentials received from attestation providers, and decides when and with whom to share them. | Person presenting a PID from their wallet during bank account opening |
| Attestation Provider | Organization that issues credentials. Also referred to as "issuer" in technical protocol contexts. | University, bank, government agency |
| Attestation Scheme | A specification that defines the logical organization of all mandatory and optional attributes within an attestation, including each attribute's identifier, encoding, allowed values, and serialization. The attestation scheme determines the granularity of selective disclosure—for example, whether "address" is a single attribute or broken into street, city, and postal code. | PID attestation scheme defining family_name, birth_date, and address attributes |
| Batch Issuance | Issuing multiple instances of the same credential to a wallet holder so the holder can use a different instance for each presentation, reducing the ability of Relying Parties to correlate presentations over time | Wallet receiving five PID instances and using a different one for each verification |
| Issuance | The process by which an attestation provider creates and delivers a credential to a wallet holder. Issuance happens outside the connector's scope—the connector verifies credentials that have already been issued. | A bank issuing an AOC to a customer's wallet during account creation |
| Relying Party (RP) | Organization verifying credentials | Your organization |
| Relying Party Instance | A combination of hardware and software that a Relying Party uses to interact with Wallet Units. A single Relying Party can operate multiple Relying Party Instances, each with its own access certificate. | Connector deployment handling credential verification for a bank |
| Registrar | An entity designated by a member state to register Relying Parties, PID Providers, and attestation providers. After successful registration, the Registrar triggers the issuance of access certificates and, where applicable, registration certificates. | National authority maintaining the registry of authorized Relying Parties |
| Provider of Registration Certificates | An entity authorized by a member state to issue registration certificates that describe an organization's registered intended uses and the attributes it has registered to request. Providers of Registration Certificates are listed in Lists of Trusted Entities (LoTEs). Not all member states designate a Provider of Registration Certificates. | Entity issuing registration certificates to registered Relying Parties |
| RPI | Relying Party Intermediary—a role defined by eIDAS 2.0 and the Architecture Reference Framework (ARF) that allows a third party to act on behalf of a Relying Party | Role described in eIDAS 2.0 Article 5b |
| Short-lived Attestation | A credential with a validity period brief enough (typically less than 24 hours) that it expires before meaningful tracking is possible. The ARF does not require revocation data for short-lived attestations because their brief validity period inherently limits the window of exposure. | PID credential valid for 12 hours, re-issued from a batch |
| Triangle of Trust | A trust model in digital identity where three roles—attestation providers (issuers), wallet holders, and Relying Parties (verifiers)—establish mutual trust through cryptographic proofs and a shared trust framework. The EUDI Wallet ecosystem extends this model with EU-specific regulations and infrastructure. | Government issues a PID, citizen stores it in a wallet, bank verifies it during account opening |
| SSI (Self-Sovereign Identity) | A model for digital identity where individuals control their own identity data without relying on a central authority. The EUDI Wallet ecosystem builds on SSI principles such as the Triangle of Trust, extending them with EU-specific regulations, standards, and infrastructure. | User stores credentials in a personal wallet and decides when and with whom to share them |
| AOC | Account Ownership Credential—a credential that links a user's wallet to an account in a Relying Party's system, enabling passwordless authentication through cryptographic key binding. The VCT value urn:eudi:aoc:1 is an example used in tutorials—in production, you define your own VCT for your authentication credential type. | Digital membership card proving account ownership |
| WSCD | Wallet Secure Cryptographic Device—the tamper-resistant hardware or software component inside a wallet that stores private keys and performs cryptographic operations. The WSCD ensures that private keys never leave the device, so key binding proofs cannot be forged. | Secure Enclave on a mobile phone |
| WUA (Wallet Unit Attestation) | A cryptographic attestation that certifies the security properties of a Wallet Unit, including its WSCD capabilities. WUAs are used within the EUDI Wallet ecosystem for wallet-to-issuer and wallet-to-infrastructure interactions. Wallet Units do not share WUAs with Relying Parties during presentation exchanges. | Attestation proving a wallet's secure hardware properties |
| KYC (Know Your Customer) | A regulatory process that requires organizations to verify the identity of their customers before providing services. In the EUDI Wallet ecosystem, KYC can be performed by requesting PID credentials from a user's wallet instead of traditional document scans or manual review. | Bank verifying a customer's identity during account opening using PID attributes from their EUDI Wallet |
| PID Provider | Organization authorized by a member state to issue PID credentials to wallet holders. PID Providers are responsible for verifying the holder's identity and for revoking the PID if the underlying Wallet Unit is revoked. | Government agency issuing digital national ID credentials |
| Wallet Provider | Organization that develops, operates, and maintains a Wallet Unit. The Wallet Provider is responsible for the security and certification of the wallet app. | Company providing the EUDI Wallet app |
Protocol and standards terms
| Term | Definition | Example |
|---|---|---|
| OID4VP | OpenID for Verifiable Presentations—the protocol for requesting and receiving credentials | Technical standard for wallet communication |
| OAuth 2.0 | An authorization framework defined in RFC 6749 that OID4VP extends for credential presentation flows | Authorization protocol underlying OID4VP |
| DCQL | Digital Credentials Query Language—format for specifying what credentials to request | Query syntax in presentation requests |
| Credential Set | A DCQL construct that defines alternative credential combinations satisfying a presentation request. Each option in a credential set lists credential query IDs that together fulfill the use case. | "Present a PID" or "present a national ID card and a proof of address" |
| HAIP | High Assurance Interoperability Profile—security requirements for OID4VP | Compliance standard for wallet compatibility |
direct_post.jwt | A JARM-based response mode where the wallet encrypts its presentation response and delivers it directly to the connector via HTTP POST. Mandated by the HAIP profile for all OID4VP flows. | Response mode in the connector's authorization request |
| ES256 | ECDSA using the P-256 curve and SHA-256, the signing algorithm mandated by the HAIP profile for authorization request JWTs and key binding proofs | Algorithm used to sign the connector's authorization requests |
| FIDO CTAP 2.2 | Client to Authenticator Protocol version 2.2—a FIDO Alliance specification that defines the hybrid transport for cross-device communication between a browser and a mobile authenticator. In the EUDI Wallet context, CTAP 2.2 establishes the secure tunnel used in cross-device OID4VP flows after the user scans a QR code. | Secure tunnel between a desktop browser and a phone wallet during cross-device verification |
| JARM | JWT-Secured Authorization Response Mode—response mode that encrypts credential delivery from wallet to Relying Party | Encrypted response in OID4VP presentation flow |
| JWT (JSON Web Token) | A compact, URL-safe token format defined in RFC 7519 for representing claims between two parties. JWTs are the foundation for SD-JWT, KB-JWT, and JARM in the EUDI Wallet ecosystem. | Signed token containing credential claims |
| Key Binding JWT (KB-JWT) | A signed JWT included in a presentation response that proves the presenter controls the private key bound to the credential. The connector verifies the KB-JWT and reports the result via kbSignatureIsValid in the callback. | JWT proving holder possession during credential presentation |
| SD-JWT | Selective Disclosure JWT—credential format enabling selective disclosure of attributes | JSON Web Token with privacy-preserving disclosure |
| SD-JWT VC | The Verifiable Credentials profile of SD-JWT, defining how SD-JWT is used to represent verifiable credentials with selective disclosure. The credential format identifier dc+sd-jwt refers to Digital Credentials using SD-JWT VC. | SD-JWT credential with vct claim and selective disclosure |
| SD-JWT+KB (SD-JWT with Key Binding) | SD-JWT VC credentials enhanced with a mandatory Key Binding JWT (KB-JWT) that proves the presenter controls the private key bound to the credential. Combines selective disclosure (SD-JWT) with proof of possession (Key Binding). See SD-JWT and Key binding. | PID credential presented with both selective disclosure and cryptographic proof of possession |
dc+sd-jwt | The credential format identifier for Digital Credentials using SD-JWT, as used in DCQL queries and OID4VP | Format value in "format": "dc+sd-jwt" |
| VCT (Verifiable Credential Type) | A URI that identifies the type of an SD-JWT VC credential, specified in the vct_values field of a DCQL query | urn:eudi:pid:1 for PID credentials |
| JWK Thumbprint | A deterministic hash of a JSON Web Key's parameters as defined in RFC 7638, used as a stable identifier for a key | The kbKeyId value in a callback payload |
| Nonce | A single-use random value included in an OID4VP authorization request to prevent replay attacks—the connector generates it automatically and the wallet includes it in its response | Session-bound value verified by the connector |
| Replay attack | An attack where a valid credential presentation is intercepted and resubmitted to impersonate the original presenter. OID4VP prevents replay attacks by including a unique nonce in every authorization request. | Resubmitting a captured presentation to gain unauthorized access |
| Replay protection | The set of mechanisms that prevent replay attacks in a credential presentation flow. In OID4VP, replay protection includes binding each presentation to a unique nonce and verifying that the response matches the current session. | Nonce-based session binding in an authorization request |
| Key Binding (KB) | Cryptographic proof that the presenter legitimately possesses the credential | Signature verification using credential's public key |
| Device Binding | The ARF term for key binding—cryptographically linking a credential to the holder's Wallet Secure Cryptographic Device (WSCD) so that only the device that received the credential can present it. See Device binding. | Credential bound to a phone's Secure Enclave |
| Status List | A published bitstring in which each bit or group of bits denotes the current revocation or suspension status of one credential. Issuers publish Status Lists so that Relying Parties can check revocation without querying the issuer about a specific credential. Defined in the IETF Token Status List specification. | Bitstring where index 42 = revoked |
| Status List Token | A compact, signed token that encodes the revocation or suspension status of one or more credentials using a bitstring. Credentials that support revocation include a reference to a Status List Token in their payload; the connector checks this token to determine whether a credential has been revoked. Defined in the IETF Token Status List specification. | Bitstring token checked during credential verification |
| TLS (Transport Layer Security) | A cryptographic protocol that provides encrypted communication between two parties over a network. In the EUDI Wallet ecosystem, TLS secures HTTP connections between the connector and callback endpoints, and between wallets and the connector's public interface. | HTTPS connection between the connector and a callback endpoint |
| mDoc | Mobile Document format based on ISO 18013-5 standard | ISO-compliant digital driver's license |
Regulatory and compliance terms
| Term | Definition | Example |
|---|---|---|
| AML (Anti-Money Laundering) | Regulations and procedures that require organizations to detect and prevent money laundering and terrorist financing. In the EUDI Wallet ecosystem, AML obligations are a key driver for KYC verification—Relying Parties request PID credentials to satisfy AML requirements without manual document review. | Bank verifying customer identity during onboarding to comply with the EU Anti-Money Laundering Directive |
| eIDAS 2.0 | European regulation establishing legal framework for EUDI Wallets | Regulation EU 2024/1183 |
| GDPR | General Data Protection Regulation—the EU regulation governing the processing and protection of personal data. In the EUDI Wallet ecosystem, GDPR's data minimization principle (Article 5(1)(c)) underpins selective disclosure: Relying Parties request only the attributes they need. | Regulation EU 2016/679 |
| Data Minimization | A GDPR principle (Article 5(1)(c)) requiring that personal data collection be adequate, relevant, and limited to what is necessary. In the EUDI Wallet ecosystem, selective disclosure enforces data minimization technically—Relying Parties request only the attributes they need, and the wallet ensures nothing beyond that is shared. | Requesting only name and date of birth instead of the full PID credential |
| ARF | Architecture Reference Framework—technical blueprint for EUDI Wallet interactions | Technical specifications document |
| RPI_10 | Requirement that RPIs shall not store transaction data | eIDAS 2.0 Article 5b(10) |
| SCA | Strong Customer Authentication—a PSD2 requirement mandating two of three authentication factors (knowledge, possession, inherence) for electronic payments | Multi-factor verification for a payment transaction |
| SUA (Secure User Authentication) | A credential issued to a wallet during a registration step with a Relying Party that authorizes the wallet to perform SCA-protected operations such as payment authorization. The SUA attestation is a prerequisite for the SCA use case of transactional data. | Attestation enabling a wallet to authorize payments on behalf of the user |
| PSD2 | Payment Services Directive 2—the EU regulation governing electronic payment services, requiring SCA for online transactions | Directive (EU) 2015/2366 |
| Attestation Rulebook | A specification defining the structure, semantics, and trust requirements for a specific credential type within the EUDI Wallet ecosystem | Rulebook for PID credentials or payment attestations |
| Commission Implementing Regulation (also called Implementing Acts) | Detailed regulations implementing eIDAS 2.0. Key regulations: CIR 2024/2977 (PID and EAA requirements), CIR 2024/2979 (wallet integrity and core functionalities), CIR 2024/2980 (member state notifications), CIR 2024/2982 (protocols and interfaces for the EUDI Framework), CIR 2025/848 (Relying Party registration). | CIR 2024/2977, CIR 2024/2979, CIR 2024/2980, CIR 2024/2982, CIR 2025/848 |
Technical terms
| Term | Definition | Example |
|---|---|---|
| Authorization Request | OID4VP request sent from RP to wallet | Presentation request with DCQL query |
| BLE (Bluetooth Low Energy) | A short-range wireless protocol used in the EUDI Wallet cross-device flow as a proximity check. After the user scans a QR code, the phone emits a BLE advertisement to confirm physical proximity between the phone and the desktop, mitigating relay attacks before the secure tunnel is established. | Proximity check during cross-device wallet verification |
| base64url | A URL-safe variant of Base64 encoding defined in RFC 4648 that replaces + with - and / with _, and omits padding. Used in the connector for encoding transactional data objects and representing hash values. | Transactional data hashes in the callback payload |
| Callback | The HTTP endpoint that receives verification result notifications from the connector. The connector delivers a Presented Credentials Event to the callback at the end of each presentation flow. | POST request to your callback endpoint |
| Cross-device flow | An OID4VP interaction pattern where the user scans a QR code on one device (for example, a desktop browser) with their EUDI Wallet on another device (for example, a phone). The connector returns a cross_device_request_uri for this flow. | User scans a QR code on a laptop screen with their phone wallet |
| Deep link | A URI that opens a specific app on a mobile device rather than a web page. In the EUDI Wallet context, the same_device_request_uri is a deep link that opens the wallet app directly when the user is on the same device. | openid4vp:// URI that opens the EUDI Wallet app |
| Digital Credentials API | A W3C browser API that mediates credential exchange between web applications and digital wallets. In the EUDI Wallet same-device flow, the browser uses this API to route the OID4VP presentation request to the user's wallet without the Relying Party needing to know which wallet is installed. The operating system handles wallet selection and session binding. | Browser API routing a presentation request to the EUDI Wallet app |
| Ephemeral Data Model | Architecture where credential data is never persisted | In-memory processing with callback delivery |
| Ephemeral Encryption Key | A single-use key pair generated per presentation request for encrypting the wallet's response, permanently deleted after verification completes. See Encryption and key management. | Per-session ECDH key pair for direct_post.jwt response encryption |
| Unlinkability | A privacy property ensuring that multiple presentations of the same credential cannot be correlated across sessions. In SD-JWT VC, unlinkability is achieved through unique random salts in each disclosure, so the same attribute produces a different hash in every issuance. | Different salt values preventing cross-session tracking |
| kbKeyId (Key Binding Key Identifier) | A stable identifier derived from a credential's proof-of-possession key, used to recognize returning users | Identifier for matching a returning user across sessions |
| kbSignatureIsValid | A boolean field in the callback credential object indicating whether the wallet successfully proved possession of the private key bound to the credential. Present in FULFILLED events when key binding was requested (inside the credentials map). Absent for all other statuses because credentials is not included. | "kbSignatureIsValid": true in a callback credential |
| signatureIsValid | A boolean field in the callback credential object indicating whether the credential's issuer signature is cryptographically valid. Present in FULFILLED events (inside the credentials map). Absent for all other statuses because credentials is not included. | "signatureIsValid": true in a callback credential |
| require_cryptographic_holder_binding | A connector API parameter in the DCQL credential query that controls whether the connector requests a key binding proof from the wallet. Defaults to true. When true, the callback includes kbKeyId and kbSignatureIsValid fields. When false, these fields are absent. | "require_cryptographic_holder_binding": true in a DCQL credential query |
| credentialsRaw | A field in the Presented Credentials Event payload containing credential data without verification flags: claims as a base64-encoded JSON object, plus issuer, validFrom, validUntil, kbKeyId, and transactionDataHashes. Present alongside credentials when status is FULFILLED. Absent for REJECTED, EXPIRED, PROCESSING_ERROR, and VERIFICATION_FAILED statuses. | "credentialsRaw": { "pid_auth": [...] } in a callback payload |
| Management API | The protected API on the connector's internal network interface that your systems use to create presentation requests and operate the connector. Not exposed to the internet. | POST /oidc4vp to create a presentation request |
| Passwordless authentication | An authentication method where users prove their identity by presenting a credential from their EUDI Wallet with cryptographic key binding, instead of using passwords | Login by scanning a QR code with a wallet app |
| Phishing | An attack where a malicious actor impersonates a legitimate service to trick users into revealing credentials or approving fraudulent requests. OID4VP prevents phishing through signed authorization requests that bind the request to the Relying Party's verified identity. | Fake login page that captures wallet approvals |
| Presentation Response | Wallet's response containing requested credentials | Encrypted verifiable presentation |
| Presented Credentials Event | The payload delivered to the callback containing verification status, credentials, and metadata | Event with FULFILLED status and verified PID data |
| QR code | A two-dimensional barcode that encodes the cross_device_request_uri from a presentation request. In cross-device OID4VP flows, the user scans this code with their EUDI Wallet app to initiate the credential presentation. | QR code displayed on a desktop screen for the user to scan with their phone wallet |
| responseCode | A 128-bit random correlation token included in the callback for same-device flows, used to correlate the browser redirect with the callback event | Token matching the response_code query parameter on the redirect URI |
| supportRevocation | A boolean field in the callback credential object indicating whether the credential includes a Status List Token for revocation checking. When true, the isRevoked field is also present. | "supportRevocation": true in a callback credential |
| supportTrustAnchor | A boolean field in the callback credential object indicating whether the credential was signed with an X.509 certificate chain (x5c header). When true, the isTrusted field is also present. | "supportTrustAnchor": true in a callback credential |
| isTrusted | A boolean field in the callback credential object indicating whether the issuer's X.509 trust chain is valid. Only present when supportTrustAnchor is true. | "isTrusted": true in a callback credential |
| errorDetails | An optional string field in the Presented Credentials Event payload containing error information. Present when status is REJECTED, PROCESSING_ERROR, or VERIFICATION_FAILED; absent for FULFILLED and EXPIRED statuses. For REJECTED, contains the wallet's OAuth 2.0 error code and optional description. For PROCESSING_ERROR and VERIFICATION_FAILED, contains a human-readable error description. | "errorDetails": "access_denied: User rejected" |
| isRevoked | A boolean field in the callback credential object indicating whether the credential has been revoked according to the Status List. Only present when supportRevocation is true. | "isRevoked": false in a callback credential |
| Same-device flow | An OID4VP interaction pattern where the user is on the same device as their EUDI Wallet. The same_device_request_uri opens the wallet app directly as a deep link, and the wallet redirects the user's browser to the redirect_uri after the flow completes. | User taps a button on their phone that opens the wallet app directly |
| Selective disclosure | A privacy mechanism where credential holders share only the specific attributes a Relying Party requests, keeping all other attributes hidden. Enabled by the SD-JWT VC format, where each attribute is salted and hashed at issuance so individual attributes can be disclosed or withheld independently. See Selective disclosure. | Sharing only name and date of birth from a PID credential while withholding address and photo |
| Session storage | Temporary storage for presentation request sessions with automatic cleanup after sessions complete or expire | In-memory session with time-to-live expiration |
| Signing Identity Key | The private key associated with a Relying Party's X.509 access certificate, used to sign authorization requests sent to EUDI Wallets. See Encryption and key management. | EC P-256 private key configured at deployment time |
| Transaction binding | A mechanism where the wallet signs over transactional data (for example, payment details) as part of the key binding proof, creating a cryptographic link between the user's consent and the specific action. This prevents a valid presentation from being replayed in a different context. | Binding a payment authorization to a specific amount and merchant |
| Transactional data | Optional contextual data bound to a presentation request | Data describing the context of a credential request |
| transactionDataHashes | An array field in the callback credential object containing base64url-encoded SHA-256 hashes of the transactional data items the wallet acknowledged during the key binding proof. Present when the presentation request included transaction_data and the wallet signed over it. | "transactionDataHashes": ["<base64url-encoded-sha256-hash>"] in a callback credential |
| Trust Anchor | A combination of a public key and the identifier of the associated entity, used as the root of trust for certificate chain validation. Access Certificate Authority trust anchors are published in Lists of Trusted Entities (LoTEs). See Certificates. | Public key of a national Access Certificate Authority published in a LoTE |
| Trusted List | A registry maintained by a member state that publishes trust anchors for QEAA Providers and PuB-EAA Providers. Defined by ETSI TS 119 612. See Trust lists. | National Trusted List of qualified attestation providers |
| validFrom | An optional timestamp field in the callback credential object indicating when the credential becomes valid, derived from the iat (issued at) claim. | "validFrom": "2026-01-15T10:30:00Z" in a callback credential |
| validUntil | An optional timestamp field in the callback credential object indicating when the credential expires, derived from the exp (expiration) claim. | "validUntil": "2026-07-15T10:30:00Z" in a callback credential |
| List of Trusted Entities (LoTE) | A registry maintained by a member state that publishes trust anchors for entities that are not trust service providers: PID Providers, Wallet Providers, Access Certificate Authorities, and Providers of registration certificates. See Trust lists. | LoTE publishing Access Certificate Authority trust anchors |
| Verifiable Credential (VC) | Digitally signed credential issued by an attestation provider | Government-issued PID credential |
| Verifiable Presentation (VP) | Container for one or more verifiable credentials | Cryptographically signed presentation |
| Access Certificate | X.509 certificate authenticating a Relying Party to wallets | X.509 certificate of a Relying Party in Authorization Request |
| Access Certificate Authority | An organization authorized by a member state Registrar to issue X.509 access certificates to Relying Parties. Access Certificate Authority trust anchors are published in Lists of Trusted Entities (LoTEs). | National authority issuing access certificates to registered Relying Parties |
| Certificate Authority (CA) | An organization that issues X.509 digital certificates, establishing trust in the identity of certificate holders. In the EUDI ecosystem, CAs issue access certificates to Relying Parties. | National CA issuing access certificates to registered Relying Parties |
| Certificate Transparency | A framework (RFC 6962) for publicly logging the issuance of X.509 certificates so that domain owners and auditors can detect erroneously or fraudulently issued certificates. CIR 2025/848 references Certificate Transparency logging for access certificates in the EUDI ecosystem. | Access certificate logged in a public Certificate Transparency log |
| Registration Certificate | Certificate proving Relying Party registration for specific purposes | Relying Party's official registration with member state |
Truvity-specific terms
| Term | Definition | Example |
|---|---|---|
| PresentationRequest | Connector API resource representing a credential request | API object with state, same_device_request_uri, and cross_device_request_uri |
Further reading
- Callback events—Presented Credentials Event statuses and payload fields
- Error codes—wallet-facing HTTP error responses
- Connector architecture—how the connector processes credentials and delivers results via callback
- Ephemeral data model—how the connector handles data without persistent storage