# EUDI Wallet and European Business Wallet Developer Docs and APIs | iGrant.io: full documentation Build on the European Digital Identity Wallet framework. Full support for OpenID4VC, SD-JWT, and ISO 18013-5 mdoc. This file concatenates the markdown of all 453 documentation pages. Install the iGrant.io Agent Skills with `npx skills add L3-iGrant/skills` to have an AI agent build these integrations. --- # Reference guide to EUDI Wallet abbreviations Source: https://docs.igrant.io/docs/abbreviations/ --- id: abbreviations title: Reference guide to EUDI Wallet abbreviations description: Browse common EUDI Wallet abbreviations and their meanings used across digital identity, verifiable credentials, and wallet documentation. hide_title: true sidebar_label: Abbreviations keywords: [abbreviations, EUDI Wallet, glossary, digital identity, verifiable credentials, eIDAS, OpenID4VC, acronyms, reference] slug: /abbreviations/ --- > **Build this with an AI coding agent.** Install the iGrant.io Agent Skills, then ask your agent to build the integration: > > ```bash > npx skills add L3-iGrant/skills > ``` | Abbr | Expanded form | | :--------- | :-------------------------------------------------------------------- | | ADA | Automated Data Agreements | | ARF | European Digital Identity Wallet Architecture and Reference Framework | | CAB | Conformity Assessment Body | | CRUD | Create / Read / Update / Delete | | DA | Data Agreement | | DCQL | Digital Credentials Query Language | | DDA | Data Disclosure Agreement | | DGA | Data Governance Act | | DID | Decentralized Identifier (according to W3C) | | DPIA | Data Protection Impact Assessment | | DS | Data Source | | DUS | Data Using Service | | EAA | Electronic Attestation of Attributes | | EBWOID | European Business Wallet Owner Identification | | ECDH | Elliptic-curve Diffie-Hellman | | EEA | European Economic Area | | eIDAS | electronic IDentification, Authentication and trust Services | | ETSI | European Telecommunications Standards Institute | | EU | European Union | | EUDI | European Digital Identity | | EUDIW | European Digital Identity Wallet | | FAQ | Frequently Asked Questions | | GDPR | General Data Protection Regulation | | HSM | Hardware Security Module | | IETF | Internet Engineering Task Force | | ISO | International Organization for Standardization | | JOSE | JSON Object Signing and Encryption | | JSON | JavaScript Object Notation | | JWE | JSON Web Encryption | | JWK | JSON Web Key | | JWS | JSON Web Signature | | JWT | JSON Web Token | | KA | Key Attestation | | LoA | Level of Assurance | | LoTL | List of Trusted Lists | | LPID | Legal Person Identification Data | | MAC | Message Authentication Code | | mDL | Mobile Driving Licence | | mdoc | ISO/IEC 18013-5 mobile document | | OAuth | Open Authorization | | OID4VC | OpenID for Verifiable Credentials | | OID4VCI | OpenID for Verifiable Credentials Issuance | | OID4VP | OpenID for Verifiable Presentation | | OP | OpenID Provider | | OpenID4VC | OpenID for Verifiable Credentials | | OpenID4VCI | OpenID for Verifiable Credential Issuance | | PID | Person Identification Data | | PKI | Public Key Infrastructure | | PoP | Proof of Possession | | PuB-EAA | Electronic Attestation of Attributes issued by a Public Sector Body | | QEAA | Qualified Electronic Attestation of Attributes | | QES | Qualified Electronic Signatures | | QTSP | Qualified Trust Service Provider | | RP | Relying Party | | SD-JWT | Selective Disclosure for JWT | | SD-JWT VC | SD-JWT-based Verifiable Credentials | | SDK | Software Development Kit | | SE | Secure Element | | SIOP | Self-issued OpenID Provider | | SSI | Self Sovereign Identity | | TAO | Trust Anchor Operator | | TEE | Trusted Execution Environment | | TI | Trusted Issuer | | TLS | Transport Layer Security | | ToIP | Trust over Internet Protocol | | TS3 | Technical Specification 3 (EUDI Wallet Unit Attestation) | | TSP | Trust Service Provider | | UC | Use case | | URL | Uniform Resource Locator | | VC | Verifiable Credential | | VCI | Verifiable Credentials Issuance | | VP | Verifiable Presentation | | W3C | World Wide Web Consortium | | WIA | Wallet Instance Attestation | | WSCA | Wallet Secure Cryptographic Application | | WSCD | Wallet Secure Cryptographic Device | | WUA | Wallet Unit Attestation | | ZKP | Zero-Knowledge Proof | --- # Agent Skills catalogue Source: https://docs.igrant.io/docs/agent-skills-catalogue/ --- id: agent-skills-catalogue title: Agent Skills catalogue description: Browse every iGrant.io Agent Skill for EUDI Wallet and European Business Wallet integrations, grouped by role, with what each skill does, its protocols and its dependencies. hide_title: false hide_table_of_contents: true sidebar_label: Skills catalogue keywords: [agent skills catalogue, SKILL.md, EUDI Wallet, European Business Wallet, OpenID4VCI, OpenID4VP, DCQL, DC API, consent management, iGrant.io skills] slug: /agent-skills-catalogue/ --- > **Build this with an AI coding agent.** Install the iGrant.io Agent Skills, then ask your agent to build the integration: > > ```bash > npx skills add L3-iGrant/skills > ```
npx skills add L3-iGrant/skills and your AI coding agent (Claude Code, Cursor, Codex, GitHub Copilot, or any SKILL.md agent) can build these API integrations for you. See Build with AI Agents.
| Security Scheme Type: | apiKey |
|---|---|
| Header parameter name: | Authorization |
| Security Scheme Type: | http |
|---|---|
| HTTP Authorization Scheme: | bearer |
| Bearer format: | JWT |
| Security Scheme Type: | apiKey |
|---|---|
| Header parameter name: | Authorization |
| Security Scheme Type: | http |
|---|---|
| HTTP Authorization Scheme: | bearer |
| Bearer format: | JWT |
| Security Scheme Type: | apiKey |
|---|---|
| Header parameter name: | Authorization |
| Security Scheme Type: | http |
|---|---|
| HTTP Authorization Scheme: | bearer |
| Bearer format: | JWT |
| Security Scheme Type: | apiKey |
|---|---|
| Header parameter name: | Authorization |
| Security Scheme Type: | http |
|---|---|
| HTTP Authorization Scheme: | bearer |
| Bearer format: | JWT |
| Security Scheme Type: | http |
|---|---|
| HTTP Authorization Scheme: | bearer |
| Bearer format: | JWT |
| EU Business Owner ID (EBWOID/LPID) Issuance Bolagsverket (Swedish Companies Registration Office) use case demonstrating Legal Person Identification Data issuance to Business Wallets using the iGrant.io Organisation Wallet Suite. |
|
| Linking EUDI Wallets to Bank Accounts Enabling Strong Customer Authentication for payments by linking a user's bank account to the EUDI Wallet via a trusted business process. |
|
| EUDI Wallet in Action: Prove ID, Apply Discounts, Pay Real-world ferry payment flow where the user proves identity, applies discounts, pays and receives a boarding pass and e-receipt in seconds. |
|
| EUDI Wallet for Hotel Check-in Hotel registration scenario from the EWC LSP pilot, showing how guests can check in using verifiable credentials from their EUDI Wallet. |
|
| EUDI Wallet at Buda Castle Age-based discount scenario from EWC LSP Phase 02, demonstrating selective disclosure for ticketing at a real-world tourist attraction. |
|
| Biometric Traveler Enrolment with EUDI Wallet Easy flight check-in scenario from EWC Pilot Phase 02, combining biometric enrolment with EUDI Wallet credentials for streamlined travel. |
| European Health Data Space with EUDI & Business Wallets CRANE dHDSI demonstration of the European Health Data Space, showing how patients can manage and share health data across borders using EUDI Wallets and Business Wallets. |
| Cross-border ODI Data Exchange in EBSI VECTOR Demonstrating cross-border Organisation Digital Identity data exchange using OpenID4VCI and OpenID4VP within the EBSI VECTOR project. |
|
| iGrant.io & Walt.id Enterprise Wallet Interoperability Cross-wallet interoperability demonstration between iGrant.io and Walt.id enterprise wallets, anchored to the EBSI trust infrastructure. |
iGrant.io offers organisations a consent management solution based on ISO 27560, seamlessly integrating with both Web 2.0 and Web 3.0 applications and optimised for use with digital wallets. Compliant with GDPR, CCPA, and other global data protection regulations, and adhering to MyData and FAIR data principles, iGrant.io equips organisations with the tools to ensure compliance and maintain a competitive edge.
In the digital era, effective data and consent management are crucial for ensuring regulatory compliance and safeguarding individual privacy. Many organisations face challenges in these areas due to regulatory and technical complexities. iGrant.io addresses these challenges with a robust Consent Management Microservice, designed to simplify the consent process through four distinct phases: Definition, Preparation, Capture, and Proof. This service not only captures end-user agreements and consent but also provides them with consent receipts for every data processing activity or transaction.
### Key Features
The key features of the iGrant.io consent management are summarised below:
- **Four-Phase Consent Process for easy onboarding and deployment**:
- **Definition**: Establish clear terms and conditions for user consent (Data Agreement with lawful basis consent).
- **Preparation**: Prepare the consent request in accordance with legal and ethical standards, aligned with ISO27560.
- **Capture**: Efficiently obtain user consent in a compliant manner.
- **Proof**: Provide irrefutable proof of consent (Consent Receipts or Data Agreement Receipts), ensuring both compliance and accountability.
- **Built on Three Pillars Inspired by Lessig’s Modalities of Regulation**:
- **Data Laws**: Complies with major data protection laws such as GDPR, CCPA, and DPDPA, incorporating principles from MyData, FAIR Data Principles, and Govstack based on ISO27560 agreements.
- **Ethics and Norms**: Adheres to ethical standards that respect user privacy and promote transparency.
- **Standards and Architectures**: Utilises advanced standards and architectures to support both Web 2.0 and Web 3.0 workflows and use cases.
- **Extentions to OAuth**:
- Data Agreements, enabling organisations to comply with advanced GDPR requirements (E.g. [GDPR Article 30](https://docs.igrant.io/regulations/reg-eu-gdpr/#article-30-records-of-processing-activities)).
This microservice is not just a tool; it is a forward-thinking solution that empowers organisations to innovate while complying with the latest regulations and upholding high standards of user privacy and digital rights management. Discover the future of consent management with the Consent Building Block microservice at iGrant.io. Empower your organisation, comply with regulations, and innovate responsibly. Because in the digital age, privacy matters more than ever.
For more information and to get started, visit the [Consent Github](https://github.com/decentralised-dataexchange/bb-consent-docs/wiki/).
### Deployment Option: On-Premise
| Feature | Default | Configurability |
|---|---|---|
| Identity Management | Pre-Built IDAM (KeyCloak) | OpenID Connect or SAML |
| Feature | Default | Configurability |
|---|---|---|
| Identity Management | Pre-Built IDAM (KeyCloak) | OpenID Connect or SAML |
name and email are optional fields. This allows for anonymous onboarding of individuals, with details being updated subsequently if collected.
| PATH PARAMETERS | |
| dataAgreementId | The data agreement ID (E.g. Process UCST payments) |
| REQUEST HEADERS | |
| X-ConsentBB-IndividualId | The individual ID whose consent record is being fetched |
| Category | Supported Options |
|---|---|
| Formats Supported |
|
| Issuance Protocols | OpenID4VCI 1.0 with HAIP 1.0 EWC RFC001: Issue Verifiable Credential - v2.0 |
| Issuance Features |
|
| Key Managements | Cryptographic key formats supported are: X.509, JWK, Decentralised Identifier (DID) did:keyThe key storage can be:
|
| Presentation Protocols | OpenID4VP 1.0 with HAIP 1.0, OpenID4VP (Draft 18) ISO/IEC 18013-7 Annex C and the W3C Digital Credentials API (see DC API overview) EWC RFC002: Present Verifiable Credentials - v1.0 |
| Presentation Features |
|
| Signing Algorithms | ECDSA (secp256r1/P-256) with SHA-256 (ES256) |
| Revocation Management | IETF Token Status List:
|
| Trust Managements | X.509 certificate chains, EU Trusted Lists as per ETSI TS 119 612 (XML), Lists of Trusted Entities as per ETSI TS 119 602 (JSON and XML), and trust anchors configured per organisation. See Trust in the Wallet Ecosystem |
| Wallet Provider |
|
| Holder (Organisation Wallet) |
|
| Payments (TS12) | Strong Customer Authentication (SCA) attestations as per TS12: Electronic payments, SCA implementation with the wallet: payment card, payment account, payment service user (issued without user claims, as the rulebook defines), and Strong User Authentication (SUA) user and IBAN credentials. SCA transaction data is validated at presentation. See the payment extensions below. |
presentationDefinitionId can be reused to send multiple verification requests (Step 6).
credentialDefinitionId can be reused to issue multiple credentials (Step 3).
presentationDefinitionId can be reused to issue multiple credentials (Step 4).
credentialDefinitionId can be reused to issue multiple credentials (Step 4).
credentialDefinitionId can be reused to issue multiple credentials (Step 3).
test-ca.pem if you want to keep the CA certificate.
presentationDefinitionId can be reused to issue multiple credentials (Step 5).
credentialDefinitionId can be reused to issue multiple credentials (Step 5).
chrome://flags#web-identity-digital-credentials.presentationDefinitionId can be reused to verify multiple credentials (Step 3).
expectedOrigins. The wallet compares the calling origin against that list and will reject a mismatch.presentationDefinitionId can be reused to verify multiple credentials (Step 3).
document-provider.mobile-document-types entitlement:
* **EU age verification** (`eu.europa.ec.av.1`)
* **EU personal ID (PID)** (`eu.europa.ec.eudi.pid.1`)
* **Photo ID** (`org.iso.23220.photoid.1`)
* **Japan MyNumber card** (`org.iso.23220.1.jp.mnc`)
* **Mobile driving licence, mDL** (`org.iso.18013.5.1.mDL`)
A document is only requestable if the holder has provisioned one of these types in a wallet on the device (for example a US state mDL under the mDL category, or the Japan MyNumber card). The set of categories is defined and gated by Apple, not open to arbitrary issuers. The two EU categories, age verification and PID, are the ones most relevant to European Digital Identity use cases.
Two further constraints apply. The verifier must obtain a signing certificate from Apple and use the Verify with Wallet mechanism, so the website is authenticated to the wallet through reader authentication (ISO 18013-5 and ISO 18013-7 Annex C) before any data is released. And because every requestable credential is an ISO 18013-5 mdoc, selective disclosure is supported, for example sharing only an "over 18" result, but the available set is fixed by Apple rather than open to any issuer.
### 4. Browser and OS support is recent and uneven
The API shipped in stable browsers only in late 2025: **Chrome 141** and **Safari 26** (September 2025). Same-device presentation on Android was available earlier, from Chrome 128, behind the flag at `chrome://flags#web-identity-digital-credentials`; cross-device presentation (a desktop QR scanned with an Android phone) arrived in Chrome 136. The DC API on Android also depends on Google Mobile Services: the cross-device flow requires Google Play services 24.0 or higher, and scanning its QR code was first available only on the Pixel camera, with other Android vendors now updating their camera apps to support it. Google Lens, reached through the Google or Chrome app, is one way to scan the code, but it is not itself the requirement. The dependency is Google Play services, not Google Lens, so devices without Google services are not supported for this flow. Firefox carries baseline code but Mozilla holds a negative standards position, so it should not be relied on. In short, coverage is improving quickly but is not yet universal, and older browser versions still need a flag.
### 5. The user experience has more friction than a redirect
Compared with a redirect-based OpenID4VP flow, the DC API adds steps and variability:
* The cross-device flow (verifier on one device, wallet on another) requires the user to scan a QR code shown by the verifier's browser, using the phone's camera or a supported QR scanner (Google Lens or a compatible camera app on Android, the Camera app on iOS), and then pass a Bluetooth proximity check between the two devices, so both must have Bluetooth on and be near each other. The camera or QR scan only appears in this cross-device case; it is the entry point for the hand-off, not a restriction on the API itself.
* The same-device flow, where the verifier and the wallet are on the same phone, shows an operating-system wallet chooser directly, with no QR code or camera step. Its appearance and behaviour still vary by platform and version.
* Until recently the API sat behind a browser flag, and the wallet invocation and consent screens are not identical across platforms.
For a first-time user this is less predictable than a single redirect, and it is worth testing the exact flow on each target platform rather than assuming a common experience.
### 6. Protocol and response-mode fragmentation
Even within the DC API there are several shapes to handle: OpenID4VP over the DC API, ISO 18013-7 Annex C (`org-iso-mdoc`), and encrypted response variants (`dc_api.jwt`). Signed and unsigned response modes behave differently, and signed requests require `expectedOrigins`. Getting a working end-to-end flow means matching the protocol, format, and response mode that the target platform and wallet actually support.
presentationDefinitionId can be reused to verify multiple credentials (Step 3).
presentationDefinitionId is autofilled in Step 3 automatically (and updated whenever Step 2 is re-run). You can also reuse the same presentationDefinitionId to issue multiple credentials.
presentationDefinitionId field below is autofilled automatically (and updated whenever Step 2 is re-run). If you are executing the APIs yourself, replace <presentationDefinitionId> with the ID obtained in Step 2. To create the verification request, execute the code block below using the **Run** button. Alternatively, you can manually copy the code block and use it in the body of the API request available [here](/docs/openid4vc-api/config-create-digital-wallet-open-id-verification-request-v-3).
After receiving the response, toggle the button provided to dynamically generate a QR code. The EUDI Wallet/Holder can then confirm the transaction using the Data Wallet (or any other EU Digital Identity Wallet) by either scanning the QR code or directly accessing the verification request on their mobile device, such as via a browser.
import Step3 from '@site/src/components/PaymentDataConfirmation/Step3';
| Security Scheme Type: | apiKey |
|---|---|
| Header parameter name: | Authorization |
| Security Scheme Type: | http |
|---|---|
| HTTP Authorization Scheme: | bearer |
| Bearer format: | JWT |