# Credenco > Credenco enables organisations to issue, verify, and manage digital credentials > securely, using verifiable-credential standards such as W3C VC, SD-JWT and > OpenID4VCI. English-language source copy of the site's main pages, generated > at build time so it cannot drift from the live site. Language index: > https://www.credenco.com/llms.txt ## Products ### Business Wallet Account https://www.credenco.com/product/business-wallet Business Wallet A business wallet account lets your organisation issue, hold, and verify digital credentials securely, all from one privacy-friendly, reusable platform. Current business processes are often still paper-based and inefficient, leading to almost 2 trillion in annual economic value lost from productivity and revenue. The Credenco Business Wallet provides a secure, interoperable, cloud-based identity solution. It reduces administrative burden, improves regulatory compliance, and makes your business competitive again. It is Credenco's implementation of the European Business Wallet. Features Issuance Service Create and issue trusted digital credentials directly into your partners' wallets. Define what gets attested — company registration, tax ID, or certifications — and deliver it in standards-compliant formats (OID4VCI). Holder Service Securely store and manage organizational credentials in your own portable vault. Share only the data a counterparty requires with privacy-preserving selective disclosure via OpenID for Verifiable Presentations. Verification Service Request and verify trusted credentials in real time. Validate cryptographic signatures and issuer trust against registered trust frameworks — without contacting the original issuer. Additional Features Besides these main features the Business Wallet also includes the following functions: Dashboard Workflow User Management Credential Catalogue HSM Integration Multiple Trust Anchors E-invoicing Multi-DID Wallet Standards & interoperability eIDAS 2.0 compliant DIIP v5 conformant WE BUILD ITB verified Deployment Deploy On-premise & SAAS The credential flow Today, proving who you are or what you own means contacting the original issuer. Your bank has to confirm your account. Your employer has to verify your employment. Your university has to check your degree. Every time you need proof, someone has to look it up and respond. It's slow, it's expensive, and it creates bottlenecks everywhere. The credential flow fixes this. Your bank issues a credential—a digitally signed statement about your account. You store it in your wallet. When a lender needs proof, you present it. They don't call the bank. They check the signature cryptographically. In seconds, not hours, they know it's real. The credential travels with you. The issuer's database is out of the loop. Speed, cost, and convenience all improve. Credential flow diagram showing Issuer, Holder, and Verifier roles connected via a Trust Registry How it works in practice Starting a company in the Netherlands today is like running an obstacle course. Visit a notary who draws up your deed. Send that deed to the KVK (Chamber of Commerce) to register your company. Wait for registration. Then visit the Belastingdienst (Tax Authority) with your KVK certificate to get a VAT number. Submit that to the Bank with your deed and KVK certificate to open a business account. Each organization asks for the same information in different formats. Each wants original documents or certified copies. Each takes days to process. The whole cycle takes six weeks. The Business Wallet eliminates the administrative maze. You visit a notary once. They issue your company deed as a credential—digitally signed and stored in your wallet. The Business Registry reads that credential and instantly registers your company, issuing a registration credential. The Tax Authority reads the registration credential and immediately grants your VAT number. The bank reads both credentials, trusts them immediately, and opens your account the same day. One source document. Multiple readers. Instant trust. What took six weeks and dozens of bureaucratic steps now takes days and requires minimal human intervention. Business Wallet flow diagram showing Notary, KVK, Belastingdienst, and Bank Book a meeting Talk to sales ### Credenco Wallet App for iOS and Android https://www.credenco.com/product/wallet-app An empty wallet A fresh install holds nothing. Scanning a QR code is how every credential arrives. The issuer makes an offer Tulip Trust Bank offers an IBAN credential. You see who is issuing and what the card is before anything is stored. Credentials side by side A Personal ID from the Rijksdienst, a driver's license from the RDW and the bank's IBAN, each signed by its own issuer. The verifier asks Wayfare Car Rental requests specific fields. The app lists every one of them, including derived answers such as an age check instead of a date of birth. Shared, and nothing more Only the fields you approved reach the verifier. The credentials themselves stay in the wallet. Credenco Wallet app Your digital credentials, on your own phone. Receive them, store them, and show them when someone needs proof. Free on iPhone and Android. Nothing leaves the device unless you approve it. Download Credenco Wallet on the App Store Get Credenco Wallet on Google Play Someone presenting a digital credential from the Credenco Wallet app on a phone Your own credentials, and the ones your company holds The Credenco Wallet is a holder wallet: it holds credentials that other organisations have signed for you. A diploma, a company registration, a proof of age, a certificate. Because every credential carries the issuer signature with it, whoever you show it to can check that it is genuine without calling the issuer back. You can also connect your Credenco Business Wallet account, so the credentials your organisation keeps in the cloud are available from the same app. Personal and organisational credentials sit side by side, and you pick which one to present. See it in action Our playground issues three test credentials to your wallet, then uses them to rent a car. Two minutes, start to finish. Credenco playground demo: credentials to car rental What the app does Receive credentials Scan a QR code or follow a link and the credential lands in your wallet, over OpenID4VCI. Store them on device Keys are generated and kept in the phone secure hardware, behind your screen lock. Present with consent Every verification request is shown in full before anything is sent, over OpenID4VP. Share one attribute Selective disclosure lets you prove you are over 18 without revealing your date of birth. How a credential moves What you are installing Privacy Data points collected by the developer Standards Availability Free iOS 18.2 or later, and Android Issuing to the app The app talks to any issuer or verifier that speaks the same standards, so you do not need Credenco on both ends. If you want to issue credentials into it, or verify credentials presented from it, start with the Business Wallet. The documentation walks through a worked example: the BIG Register issuing a credential from its own software. Your backend calls the API, shows the QR code, and the credential lands on the phone over OpenID4VCI. Business Wallet Holder Service ### Issuance Service https://www.credenco.com/product/issuance-service Issuance Service Issue trusted credentials to organisations and users. Configure once, then deliver Verifiable Credentials straight to any compliant wallet — ready to be reused across ecosystems. Issue trusted digital credentials at scale The Issuance Service lets you send official, tamper-proof digital documents — diplomas, employee badges, compliance certificates, supplier qualifications — straight into someone's wallet. Every credential is cryptographically signed, so anyone can verify it in seconds without calling you. How issuance works Configure your credential template and branding once. Issue credentials directly to a recipient's wallet. Any verifier can validate them in real time. Revoke instantly when something changes. Issuance steps: Configure, Issue, Verify, Revoke What does this really mean? A university issues diplomas digitally. Graduates receive them straight in their Business Wallet. When a graduate applies for a job, the employer scans the diploma and confirms its authenticity in seconds — no phone calls, no registries, no waiting. Why organisations use it Sharing important documents still means emails, PDFs, and follow-up calls to confirm they're real. The Issuance Service replaces that with tamper-proof digital records any organisation can verify instantly. Key capabilities Standards-based OpenID4VCI compatible. Works with any compliant wallet. Configurable Define credential types, attributes, and branding yourself. Revocable Revoke any credential in real time. Always current. API-first Integrate issuance into your systems via REST API. Interested in the technical details? The Issuance Service is built on open standards like OpenID4VCI and supports credential formats such as SD-JWT and mdoc. It covers the full lifecycle — from template configuration to secure delivery. Explore our technical documentation for integration guides and API references. Book a meeting Talk to sales Use cases Implementations Guides Step-by-step API Reference Explore API ### Holder Service https://www.credenco.com/product/holder-service Holder Service Receive and manage digital credentials securely. Store Verifiable Credentials in a privacy-preserving wallet that keeps you in full control of your own data. Manage your digital credentials with confidence The Holder Service is your organisation's secure digital wallet for Verifiable Credentials. Whenever a partner, authority, or platform issues you a credential, it arrives directly in your — cryptographically signed, tamper-proof, and instantly presentable. From compliance certificates to supplier approvals and employee IDs, everything is organised, private, and always under your control. How holding credentials works Receive credentials from issuers. Store them securely. Share them on demand — with selective disclosure, so only the requested attributes leave your wallet. You stay in control from start to finish. Holder Service steps: Receive, Store, Share, Control What does this really mean? A supplier receives an audit certificate from a compliance body. Instead of a PDF buried in an email, it lands in their Business Wallet. When a customer asks for proof, the supplier shares it in seconds — directly from their wallet. Why organisations use it Regulators, partners, and industry bodies keep sending new certifications and approvals. Managed via email, they get lost, re-requested, and slow down business. The Holder Service puts everything in one place — signed, instantly verifiable, and ready to share the moment it's needed. Key capabilities Secure storage Credentials live in your Business Wallet — encrypted, tamper-proof, and always accessible. Selective disclosure Share only the data a counterparty requires. Nothing more, never less than necessary. Standards-based OID4VP compatible. Works with any compliant verifier — no integration lock-in. Full control Accept, manage, and revoke credential sharing at any time — you decide. Interested in the technical details? The Holder Service is built on open standards like OpenID4VP and OpenID4VCI, and supports credential formats such as SD-JWT and mdoc. It manages the full lifecycle — from receiving and storing to selective disclosure and presentation. Explore our technical documentation for integration guides and API references. Book a meeting Talk to sales Use cases Implementations Guides Step-by-step API Reference Explore API ### Verification Service https://www.credenco.com/product/verification-service Verification Service Verify digital credentials instantly and reliably. Accept and validate Verifiable Credentials from any compliant wallet — trusted, automated verification without manual checks. Verify trusted credentials in seconds The Verification Service lets organisations instantly verify any Verifiable Credential — whether issued by Credenco or any compatible ecosystem. A holder presents a credential from their wallet, and your system receives a cryptographically verified result in milliseconds. No PDFs, no callbacks, no manual review. Built on open standards like OID4VP and W3C VC, it slots straight into your existing identity and compliance workflows. How verification works Send a presentation request. The holder responds from their wallet. Your system validates the cryptographic proof. You get a clear result — all in milliseconds. Verification steps: Request, Present, Verify, Confirm What does this really mean? A bank onboards a new corporate client. Instead of requesting paper documents and waiting days, it sends a credential request to the client's wallet. In seconds, the wallet returns a cryptographically signed credential. The bank confirms it's valid, unexpired, and from a trusted issuer. Onboarding that used to take 5 days now takes 5 minutes. Why organisations use it Manual document checks are slow, costly, and error-prone. Fraud is hard to spot, audits are a headache, and every check adds friction. The Verification Service replaces paper with instant cryptographic proof — valid or not, no ambiguity — and produces a tamper-proof audit trail on the side. Key capabilities Instant verification Results in milliseconds. No manual steps, no waiting. Trust chain validation happens automatically. Multi-credential support Verify credentials from any W3C-compliant wallet or issuer. Works across ecosystems and national identity frameworks. Selective disclosure Request only the attributes you need. Holders share the minimum — you still get the proof you require. Revocation checks Every verification checks in real time whether a credential has been revoked or expired. Full audit trail Every verification event is logged with timestamp, result, and credential metadata — ready for compliance and reporting. Interested in the technical details? The Verification Service is built on open standards like OpenID4VP and supports credential formats such as SD-JWT and mdoc. It covers the full verification flow — from presentation request to cryptographic validation. Explore our technical documentation for integration guides and API references. Book a meeting Talk to sales Use cases Implementations Guides Step-by-step API Reference Explore API ### KYC Onboarding with Verifiable Credentials https://www.credenco.com/product/kyc-onboarding Product Book a meeting Talk to sales How it works Key capabilities Compliance Built for eIDAS 2.0 compliance ## Solutions ### Digital Identity Solutions by Industry https://www.credenco.com/solutions Learn more Solutions Credenco delivers industry-specific solutions built on verifiable credentials and Business Wallet technology. By industry Supply Chain Track, verify, and exchange supply chain documents with trusted digital credentials. Reduce fraud, eliminate paper-based processes, and build verifiable trust between partners and regulators. Healthcare Healthcare providers use Credenco's products to securely issue, manage, and verify sensitive credentials. Government Government organizations use Credenco's products to deliver trusted digital services at scale. Finance Financial institutions use Credenco's products to enable secure, compliant, and verifiable digital workflows. ### Digital Credentials for Government https://www.credenco.com/solutions/government Certificate of Conduct (VOG) Digital certificates of conduct issued as verifiable credentials — instantly shareable, tamper-proof, and fully under the holder's control. BOA ID Digital identification for enforcement officers — verifiable on the spot, without paper passes or manual checks. Tax Splitter Automated tax credential splitting and verification — between taxpayer, advisor, and tax authority. Government Governments are at the heart of digital trust and digital identity. Yet today, many permits, certificates, and registrations are still exchanged on paper or as PDFs – slow to process, costly to handle, and vulnerable to fraud. Why should a citizen wait weeks for a certificate, when the same proof can be verified in seconds with a verifiable credential? The Opportunity With the Business Wallet issuance service, the local government issues the business registration as a verifiable credential directly to the entrepreneur's wallet. When applying abroad, the entrepreneur shares this credential instantly with the foreign authority, which can verify authenticity within seconds. No paperwork, no waiting. Just trusted, fraud-proof exchange of government-issued records that accelerates business and reduces administrative overhead. Why Credenco Credenco covers all three roles in the credential flow: issuing the record, holding it in a wallet, and verifying it on the other side. A public body does not have to assemble a trust chain from three suppliers. Everything is built on open European standards and runs on European infrastructure. Partners Partners & Demo's Cost reduction Lower administrative costs Products and Features Business Wallet Issue, manage, and verify your credentials from a central place. Privacy-friendly and reusable across organizations. Learn more Issuance Service Issue trusted credentials to organizations and users. Configure and issue Verifiable Credentials that can be securely stored in digital wallets and reused across ecosystems. Verification Service The Verification Service enables organizations to request specific credentials from people or other organizations and instantly verify their authenticity using OpenID for Verifiable Presentations. Compliance Built to meet eIDAS 2.0 and European compliance requirements, ensuring your credentials are legally recognized across borders. Data Sovereignty Your data stays yours. Credentials are stored in your own wallet, never on a central server — privacy by design. A Story from Business Registration An entrepreneur wants to register a new business across borders in Europe. Today, this often means printing out official extracts, sending notarized copies by post, and waiting weeks for manual checks by different authorities. Each document can be tampered with, each step adds delay. With the Business Wallet issuance service, the local government issues the business registration as a verifiable credential directly to the entrepreneur's wallet. When applying abroad, the entrepreneur shares this credential instantly with the foreign authority, which can verify authenticity within seconds. No paperwork, no waiting – just trusted, fraud-proof exchange of government-issued records that accelerates business and reduces administrative overhead. Benefits for All Stakeholders Citizens get fewer forms to fill in, more control over their data, and a secure place in their digital wallet. Businesses and organizations benefit from faster digital onboarding, instant trust, and strong fraud prevention. Think of a sports club that instantly checks a trainer's certificate, or a logistics company that onboards hundreds of drivers without weeks of waiting. Governments lower administrative costs, speed up service delivery, and build greater trust in digital public services. Building a Future-Proof Digital Ecosystem By adopting digital credential issuance, governments create the foundation for a scalable ecosystem. In the near future, diplomas, licenses, and permits can all be exchanged securely through the same Business Wallet infrastructure. It's more than digitization: it's governments leading the way in building trust in digital identity at scale. Check use cases See how verifiable credentials are already being used in government, public services, and adjacent sectors. View case Explore Real Case Example ### Healthcare Solutions https://www.credenco.com/solutions/healthcare BIG Register Healthcare professionals receive and share their BIG registration as a verifiable credential — instantly and tamper-proof. Certificate of Conduct (VOG) Digital certificates of conduct issued as verifiable credentials — essential for every new hire in care. Healthcare Healthcare runs on trust. Every doctor, nurse, or specialist who joins a new clinic must prove their qualifications again — BIG registration, diplomas, accreditations. Credenco turns that paperwork into a single, instantly verifiable digital credential. The Opportunity Healthcare organisations depend on fast, reliable proof of who is qualified to care for patients. Today that proof is scattered across paper certificates, PDF scans, and manual checks with registries like the BIG-register or KNMG. The sector needs one thing: a way to confirm a professional's qualifications in seconds, without compromising privacy or compliance. That is exactly what verifiable credentials deliver. Why Credenco Credenco connects the bodies that issue professional credentials with the care organisations that verify them. Credentials are issued once and stored safely in a Business Wallet. Any hospital or clinic can then verify them instantly — no phone calls, no paper, no doubt. Partners Partners & Demo's Faster credential verification Products and Features Business Wallet Issue, manage, and verify credentials from one central place. Privacy-friendly and reusable across organisations. Learn more Issuance Service Issue trusted credentials to professionals and organisations. Configure once, then deliver securely to any compliant wallet. Verification Service Request specific credentials from people or organisations and verify them instantly with OpenID for Verifiable Presentations. Compliance Built for eIDAS 2.0, NEN 7510, and the European Health Data Space. Credenco credentials are tamper-proof and audit-ready by design. Data Sovereignty Your data stays yours. Credentials live in your wallet — never on a central server. Privacy by design. A Story from Professional Onboarding A hospital network hires a cardiovascular specialist from another EU country. The old way: HR requests certified translations, contacts the KNMG, checks the BIG register, and screens for sanctions. The process takes two to four weeks and costs around €800 per hire. With Credenco, the specialist already carries their BIG registration, diploma, and specialist title as verifiable credentials in a Business Wallet. HR sends a request. The specialist approves it in their wallet. In under three seconds, HR has cryptographic proof — and the specialist can start the same week. Benefits for Healthcare Organisations Healthcare professionals carry verified credentials issued once and recognised everywhere across EU institutions. Hospitals reduce time-to-hire from weeks to days. Compliance teams receive automatic audit trails for every credential check. Regulators gain confidence that credential fraud — a direct patient safety risk — is cryptographically prevented. Practitioners stay in control: they decide who sees their credentials, with GDPR compliance built in. Building a Future-Proof Healthcare System Telemedicine, cross-border transfers, AI-assisted clinical workflows — all depend on trusted, instantly verifiable identity. Verifiable credentials are the foundation. Credenco delivers that foundation today, fully aligned with eIDAS 2.0 and the European Health Data Space. Check use cases See how verifiable credentials are already being used in healthcare and adjacent sectors. View case Explore Real Case Example ### Finance https://www.credenco.com/solutions/finance Establish a new company Incorporate a Dutch BV in minutes — company credentials issued by KVK and Belastingdienst, verified instantly by notary and bank. e-Invoicing Structured, verifiable invoices exchanged directly between business wallets — built on the Peppol network and EU standards. Tax Splitter Automated tax credential splitting and verification — between taxpayer, advisor, and tax authority. Finance Financial services run on verification. KYC, KYB, UBO checks, AML screening — every client onboarding means chasing PDFs and waiting weeks. Credenco replaces that with credentials that are issued once and verified in seconds. Opportunity Regulators demand faster, sharper, more auditable verification — while clients expect instant onboarding. Today's reality: PDF uploads, email chains, and weeks of manual checks before a client is approved. The sector needs one thing: a way to confirm who a client is, what their company stands for, and whether they're compliant — in seconds, with a full audit trail. Why Credenco Credenco lets clients share verified credentials — KVK registration, VAT certificate, UBO declaration, AML status — straight from their Business Wallet. Your compliance team validates the full set in seconds. No cross-checks, no third-party costs, and a full audit trail generated automatically. Partners Partners & Demo's KYB onboarding KYB onboarding time reduction Products and Features Business Wallet Issue, manage, and verify credentials from one central place. Privacy-friendly and reusable across organisations. Learn more Issuance Service Issue trusted credentials to clients and organisations. Configure once, then deliver securely to any compliant wallet. Verification Service Request specific credentials from clients or counterparties and verify them instantly with OpenID for Verifiable Presentations. Compliance Built on open standards like eIDAS 2.0, so Credenco connects cleanly to the frameworks financial institutions already rely on. Every verification is logged in a tamper-proof audit trail, giving your compliance team the evidence they need. Data Sovereignty Your data stays yours. Credentials live in your wallet — never on a central server. Privacy by design. A Story from Corporate Client Onboarding A fintech onboards an SME for invoice financing. The old way: upload a KVK extract, a UBO declaration, a VAT certificate, and proof of address — each manually checked by a compliance analyst. Typical turnaround: fifteen business days. With Credenco, those credentials already sit in the SME's Business Wallet — issued by KVK, the tax authority, and the notary. The fintech sends one request. The SME approves in one click. All signatures are validated in under four seconds, and onboarding is done the same day. Benefits for Financial Institutions Compliance teams process verifications in hours instead of weeks. Fraud risk drops sharply — credentials are cryptographically tied to their issuer. Audit trails are generated automatically for every verification event. Clients experience instant onboarding, reducing drop-off rates. Returning clients never have to re-submit the same documents. Building a Future-Proof Compliance Infrastructure EU frameworks like AMLD6, MiCA, DORA, and eIDAS 2.0 push for higher verification standards with lower friction. By adopting verifiable credentials now, institutions build the foundation they'll need to connect smoothly to those frameworks tomorrow — cross-border and API-first. Check use cases See how verifiable credentials are already being used in finance, compliance, and adjacent sectors. View case Explore Real Case Example ### Supply Chain https://www.credenco.com/solutions/supply-chain Digital Product Passport Verifiable product passports for the construction industry — tracking materials, origin, and compliance across the chain. Establish a new company Incorporate a Dutch BV in minutes — company credentials issued by KVK and Belastingdienst, verified instantly by notary and bank. e-Invoicing Structured, verifiable invoices exchanged directly between business wallets — built on the Peppol network and EU standards. Supply Chain Global supply chains still run on paper-based trust. Every container handoff relies on PDF authorisations and phone checks — slow, costly, and easy to forge. Credenco replaces that with cryptographic proof, verified in seconds. Opportunity Every container handoff — from cargo owner to freight forwarder to carrier to terminal — depends on manual checks of PDFs and phone calls. Duplicate and forged authorisations have enabled cargo theft worth millions at major ports. As part of the consortium — the EU Digital Identity Wallet project — Credenco is working with and on a better way: pickup authorisations issued as verifiable credentials, straight to the driver's wallet. How It Could Work Freight forwarders issue a digital pickup authorisation — container number, driver, transport company, pickup window — all cryptographically signed. When the truck arrives, the gate system verifies the credential in seconds. Valid? The gate opens. Tampered or expired? Access denied. Every step is logged automatically. Partners Partners & Demo's Gate clearance time Up to -70% Projected reduction in cargo fraud risk Products and Features Business Wallet Issue, manage, and verify credentials from one central place. Privacy-friendly and reusable across organisations. Learn more Issuance Service Issue trusted credentials to partners and drivers. Configure once, then deliver securely to any compliant wallet. Verification Service Request specific credentials from drivers, carriers, or partners and verify them instantly with OpenID for Verifiable Presentations. Compliance Designed to align with eIDAS 2.0 and EU customs standards. Credentials are cryptographically signed and tamper-proof, with full chain-of-custody logging that supports AEO and SAFE Framework audits. Data Sovereignty Your data stays yours. Credentials live in your wallet — never on a central server. Privacy by design. A Vision for the Port of Rotterdam A driver arrives at the Maasvlakte terminal to collect a container. Today: a PDF authorisation, emailed by the freight forwarder, manually checked by a terminal agent. The process takes 8–12 minutes per truck — and forged PDFs have been used to steal containers worth millions. In the use case explored within WE BUILD, that same authorisation becomes a verifiable credential in the driver's wallet. At the gate, the signature is validated in seconds. The gate opens. Cargo theft via duplicated authorisations becomes cryptographically impossible. Potential Benefits for Supply Chain Stakeholders Cargo owners get real-time visibility and tamper-proof transfer records. Freight forwarders eliminate the risk of forged or duplicated authorisations. Terminal operators reduce gate workload and shorten dwell times. Carriers and drivers experience faster, friction-free gate access. Customs authorities receive complete, unforgeable audit trails. Towards a Future-Proof Logistics Network The Port of Rotterdam handles 14.8 million TEU annually. Verifiable credentials can lay the foundation for automated, fraud-proof freight clearance — from gate access to cross-border tracking to customs pre-clearance. Through WE BUILD, Credenco is building the technical foundation together with Secure Logistics and Portbase. Check use cases See how verifiable credentials are already being used in supply chain, trade, and adjacent sectors. View case Explore Real Case Example ### Age-Restricted Commerce https://www.credenco.com/solutions/age-restricted-commerce Age verification at checkout Prove age in a single tap — no passport uploads, no selfies, no personal data shared beyond the minimum required by law. Responsible gaming limits Self-exclusion and spending limits carried as credentials — recognised across licensed operators, protecting players without re-registration. Proof of eligibility for age-restricted delivery Alcohol and tobacco couriers verify recipient eligibility at the door — age and residency confirmed cryptographically, in seconds. Age-Restricted Commerce Online gambling, adult platforms, alcohol and tobacco retail — every transaction runs into the same regulatory wall: verify the customer's age without scaring them off. Traditional checks kill conversion. Credenco replaces them with a one-tap credential exchange that proves eligibility without revealing a single unnecessary detail. Opportunity Regulators across Europe are tightening the rules. The Digital Services Act, national age-verification mandates and anti-money-laundering frameworks all demand stricter proof — while customers demand frictionless checkout. The industries caught in the middle pay for it twice: in compliance cost, and in every customer who drops off at the verification screen. Why Credenco Credenco turns verification into a one-tap confirmation. Customers prove they are of age, a resident of the right country, or eligible under local law — straight from their Business Wallet, without uploading a passport or taking a selfie. Platforms stay compliant with the DSA and national rules, keep full audit trails, and protect the conversion rates their revenue depends on. Conversion Passport uploads required Verification 1 tap From checkout to confirmed Products and Features Business Wallet Customers carry their eligibility credentials in one secure wallet — reusable across every platform that accepts them. Learn more Issuance Service Issue age, residency or eligibility credentials once — from a government wallet, a national registry, or your own issuing platform. Verification Service Request exactly the proof you need — age over 18, residency, self-exclusion status — and verify it in under a second at checkout. Selective Disclosure Customers share only what they must. "Over 18" means over 18 — not a birthday, not a name, not a passport number. Privacy-preserving by design, compliant by default. Compliance Meet the Digital Services Act, national age-verification laws and AML requirements with a full tamper-proof audit trail. Built on eIDAS 2.0. A Story from Age-Verified Checkout A customer visits an online alcohol retailer at midnight. The old way: upload a photo of an ID, wait for manual review, retry the selfie twice, abandon cart. Typical drop-off at this step: 35%. With Credenco, the customer taps once. An age credential already issued by their national identity wallet is shared with the retailer — signed, cryptographically verified, and revealing only "over 18". Checkout completes in three seconds. No ID upload. No selfie. No lost sale. Benefits for Regulated Operators Conversion rates stay high — verification is a tap, not a hurdle. with DSA, national age-verification laws and AML, built in. Privacy by design — share only the minimum required attribute. Fraud drops — credentials are cryptographically tied to their issuer. Audit trails are generated automatically for every transaction. Built for the Next Wave of Regulation The Digital Services Act, the EUDI Wallet rollout and upcoming national age-verification mandates will reshape how regulated consumer industries operate online. Credenco is built on exactly those standards — eIDAS 2.0, OpenID4VCI, OpenID4VP — so you're ready for what's coming, not scrambling when it arrives. Example use cases Concrete scenarios where verifiable credentials remove friction in age-restricted commerce. View case Explore Real Case Example ## Cases ### Verifiable Credential Use Cases https://www.credenco.com/cases Certificate of Conduct (VOG) Digital certificates of conduct issued as verifiable credentials. Establish a new company Incorporate a Dutch BV in minutes — company credentials issued by KVK and Belastingdienst, verified instantly by notary and bank. Digital Product Passport Verifiable product passports for the construction industry. Tax Splitter Automated tax credential splitting and verification. e-Invoicing Structured, verifiable invoices exchanged directly between business wallets — built on the Peppol network and EU standards. BOA ID Digital identification for enforcement officers. BIG Register Healthcare professionals receive and share their BIG registration as a verifiable credential — instantly, tamper-proof, and fully under their control. Mortgage Application All mortgage documents collected and verified in one scan — from municipality to pension fund to notary. Digital, instant, tamper-proof. Supplier onboarding (KYC) Supplier onboarding reduced from weeks to minutes. Business credentials issued by KVK, Belastingdienst, and banks — verified in one click. Use Cases Discover how organizations use our technology across real-world implementations and example scenarios. From identity verification to secure onboarding, these cases show how digital credentials create value in practice. Real Case Real Use Cases These are real implementations with our partners — proven in practice. Example Example Applications These examples illustrate what you can build with a Business Wallet. View case Explore Learn more ### BIG Register Healthcare Credentials https://www.credenco.com/case/big-register BIG Register The **BIG register** is the Dutch registry for healthcare professionals. Every doctor, nurse, physiotherapist, and pharmacist in the Netherlands must be registered before they can practice. For decades, this registration has lived on paper — certificates mailed to professionals, manually checked by employers, and filed away in cabinets. With **verifiable credentials**, the BIG register enters the digital age. Registrations become cryptographically signed digital credentials that professionals carry in their personal wallet — always available, instantly verifiable, and fully under their control. This use case follows **Sophie**, a physiotherapist, through two key moments in her career: **receiving** her BIG registration and **using** it to start a new job. Part 1: Sophie Receives Her BIG Registration Sophie has completed her training and passed all her examinations. She is ready to become a registered physiotherapist. She logs into the **BIG register portal** to complete her registration. After filling in her details, something new happens — instead of being told to wait for a letter in the mail, a **QR code** appears on her screen. Sophie pulls out her phone, opens her **personal wallet app**, and scans the code. Within seconds, a new credential slides into her wallet: her official **BIG registration**. It contains her name, her BIG number, her profession, and her specialism — all cryptographically signed by the BIG register. No envelope, no waiting, no paper. Her registration is digital, tamper-proof, and always with her. For Sophie She receives her registration instantly. It's stored safely in her wallet, always accessible, and she decides who gets to see it. For the BIG register Registrations are issued digitally via a simple API call. No printing, no postage, no delays. Every credential is cryptographically verifiable. Part 2: Sophie Uses Her Credential A few months later, Sophie applies for a position at **Amsterdam UMC**, one of the largest academic hospitals in the Netherlands. In the past, onboarding would have been a bureaucratic maze — printed copies of certificates, manual checks against government databases, days of waiting. But Amsterdam UMC has modernized their process. During the online application, the hospital portal asks Sophie to **prove her BIG registration**. A QR code appears. Sophie opens her wallet app, scans the code, and sees exactly what the hospital is requesting: her BIG registration credential. She reviews the request, taps **“Share”**, and that is it. Within seconds, the Amsterdam UMC system has **cryptographically verified** that Sophie is a registered physiotherapist. Her qualifications are confirmed. No phone calls, no paperwork, no waiting. Sophie is approved on the spot. She can start treating patients next Monday. She stays in full control. She sees exactly what is requested and chooses what to share. No one accesses her data without her consent. For Amsterdam UMC Credential verification is instant and cryptographic. No manual checks, no risk of forged documents, and onboarding takes minutes instead of days. Why Verifiable Credentials? Instant Issuance From registration to credential in the wallet — no postal delays User Consent Sophie decides who sees her credentials — full privacy control Tamper-Proof Cryptographically signed — impossible to forge or alter Standards Based Built on OpenID4VCI and OpenID4VP — works with any compliant wallet Interested in the technical details? This use case is built on open standards like OpenID4VCI and OpenID4VP. Explore our technical documentation for the full implementation guide. Use case Implementations Guides Step-by-step API Reference Explore API This use case is part of Credenco's broader supply chain solutions Real Case Example This is an example application of our technology. Book a meeting Talk to sales In collaboration with Sophie completes her BIG registration A QR code appears on the BIG register portal Sophie scans the QR code with her wallet app The credential is securely transferred Her BIG registration is now in her wallet BIG Registration Physiotherapist Name Profession Specialism Sports Physiotherapy Register Scan to receive your BIG credential Open your wallet app and scan Credential issued! Sophie's BIG registration is complete My Wallet No BIG credential yet Scan QR Code Scanning... Credential received! Tap to view Sophie applies for a position at Amsterdam UMC The hospital portal shows a QR code requesting her BIG credential She reviews and shares her BIG registration credential The hospital instantly verifies her qualifications — Sophie is approved Staff Onboarding Position Department Sports Medicine Provide BIG registration Scan to share your BIG registration We need to verify your BIG registration Verified! Sophie de Vries — Physiotherapist BIG registration confirmed Onboarding approved Amsterdam UMC requests: Share Deny Only selected attributes will be shared Shared with Amsterdam UMC ### Digital Income Verification for Mortgages https://www.credenco.com/case/mortgage Mortgage Application Applying for a **mortgage** in the Netherlands means gathering documents from half a dozen different sources — your municipality, your pension fund, your bank, DUO, BKR, and a notary. You download PDFs, scan paper statements, upload files to a portal, and wait days for manual verification. Documents get lost, formats differ, and the bank has no way to instantly confirm authenticity. With **verifiable credentials**, the entire process becomes digital. Each institution issues a cryptographically signed credential directly to the applicant's personal wallet. The bank verifies all documents in seconds with a single QR code scan — no uploads, no manual checks, no waiting. This use case follows **Thomas**, a software developer buying his first apartment, through two key moments: **collecting** his mortgage documents and **sharing** them with the bank. Part 1: Thomas Collects His Documents Thomas is buying an apartment in Utrecht for EUR 385,000. His mortgage advisor at Tulip Trust Bank gives him a checklist of six required documents. Thomas already has four of these as verifiable credentials in his **personal wallet** — collected over time from various institutions: **Identity document** — issued by Municipality of Utrecht **Pension overview** — issued via mijnpensioenoverzicht.nl **Purchase contract** — issued by the notary handling the sale **Student debt statement** — issued by DUO Two documents are still missing: **Savings statement** — to be collected from his bank (ING) **Loan overview** — to be collected from BKR (Bureau Krediet Registratie) Thomas visits each portal. A QR code appears, he scans it with his wallet app, and the credential slides in — cryptographically signed, tamper-proof, and instantly verifiable. Within minutes, his wallet is complete. For Thomas All his mortgage documents are in one place — his wallet. No more hunting for PDFs, no lost emails, no expired downloads. He controls who sees what. For the issuers Each institution issues credentials digitally via a simple API call. No printing, no postage, no helpdesk calls about missing documents. Part 2: Thomas Applies for His Mortgage With all six credentials in his wallet, Thomas goes to the Tulip Trust Bank mortgage portal. In the past, he would upload six separate files and wait days for the bank to manually verify each one. Now, the portal shows a single **QR code**. Thomas opens his wallet app, scans the code, and sees exactly what the bank is requesting: all six of his mortgage documents. He reviews the request, taps **"Share"**, and that's it. Within seconds, Tulip Trust Bank's system has **cryptographically verified** all six credentials. Thomas's identity is confirmed, his financial situation is clear, and the purchase contract is authentic. No phone calls, no paper, no waiting. The portal shows: **"All required documents received and verified"** — and a button to **view his mortgage offer**. One scan, one tap — all documents shared. He stays in full control and sees exactly what the bank receives. No data is shared without his explicit consent. For Tulip Trust Bank All six documents are verified instantly and cryptographically. No risk of forged documents, no manual checks, and the mortgage process takes minutes instead of days. Why Verifiable Credentials? Single Verification All mortgage documents verified in one scan — no more uploading files one by one User Consent Thomas decides which credentials to share — full privacy control Tamper-Proof Every document is cryptographically signed — impossible to forge or alter Standards Based Built on OpenID4VCI and OpenID4VP — works with any compliant wallet Interested in the technical details? This use case is built on open standards like OpenID4VCI and OpenID4VP. Explore our technical documentation for the full implementation guide. Use case Implementations Guides Step-by-step API Reference Explore API This use case is part of Credenco's broader financial services solutions Real Case Example This is an example application of our technology. Book a meeting Talk to sales In collaboration with Thomas has 4 of 6 credentials in his wallet — 2 still missing He visits ING to collect his savings statement Thomas scans the QR code with his wallet app Savings statement received — 5 of 6 collected He visits BKR to collect his loan overview All 6 credentials collected — ready to apply for a mortgage Scan to receive your Open your wallet app and scan Scan QR Code Scanning... Required documents: Identity document Pension overview Purchase contract Student debt statement Savings statement Loan overview Provide documents savings statement Credential issued! Savings statement sent to your wallet loan overview Loan overview sent to your wallet My Wallet Identity Document Pension Overview Purchase Contract Student Debt DUO Savings Statement Loan Overview Thomas applies for a mortgage at Tulip Trust Bank The bank portal requests all his mortgage documents He reviews and shares all 6 credentials at once All documents verified — mortgage offer ready Property Apartment, Oudegracht 42, Utrecht Purchase price EUR 385.000 Provide required documents Scan to share your mortgage documents We need to verify 6 documents All documents verified! 6 of 6 credentials received and verified Show mortgage offer 6 documents ready Tulip Trust Bank requests: Share Deny Share all 6 credentials Shared with Tulip Trust Bank ### Supplier Onboarding with Verifiable Credentials https://www.credenco.com/case/supplier-onboarding Supplier onboarding (KYC) Onboarding a new **supplier** in the Netherlands means requesting and validating documents from multiple sources — a Chamber of Commerce (KVK) registration extract, insurance certificates, tax authority statements, VAT registration, and bank account details. Today, these arrive as PDFs or scanned paper copies. Authenticity and origin remain uncertain, leading to delayed onboarding, compliance risks, and administrative overhead. With **verifiable credentials**, the entire process becomes digital. Each trusted authority issues a cryptographically signed credential directly to the supplier's **business wallet**. The broker or buyer verifies all documents in seconds — no uploads, no manual checks, no waiting. This use case follows **SecureStaff BV**, a staffing company registering on a procurement portal, through two key moments: **collecting** their business credentials and **sharing** them with the broker for verification. The Practical Example A supplier wants to register on a staffing procurement portal. Three parties are involved: Party Role Example Client (Buyer) The organization seeking staff Broker (Intermediary) Manages the procurement process and performs checks Supplier (Service Provider) Provides staff, must submit proof documents Part 1: SecureStaff BV Collects Its Credentials Before SecureStaff BV can register on FlexProcure's portal, it needs five verified business credentials. The company visits each authority's portal, authenticates, and the credential is issued directly to their **business wallet** in the browser — no app needed, no QR codes. **KVK Registration Extract** — issued by the Chamber of Commerce (KVK) **Tax Compliance Statement** — issued by the Tax Authority (Belastingdienst) **VAT Registration** — issued by the Tax Authority (Belastingdienst) **Bank Account Details** — issued by ABN AMRO **Insurance Certificate** — issued by Allianz SecureStaff BV visits each portal. After authentication, the portal redirects the browser to the business wallet. The credential appears, SecureStaff BV accepts it, and it's stored — cryptographically signed, tamper-proof, and instantly verifiable. Within minutes, all five credentials are collected. For SecureStaff BV All business credentials are in one place — the business wallet. No more emailing PDFs, no lost documents, no expired scans. The company controls what it shares and with whom. For the issuers Each authority issues credentials digitally via a simple API call. No printing, no postage, no helpdesk calls about missing documents. Part 2: SecureStaff BV Registers on the Procurement Portal With all five credentials in its business wallet, SecureStaff BV visits FlexProcure's procurement portal. In the past, the company would upload five separate PDFs and wait days for the broker to manually verify each one. Now, FlexProcure's portal requests all required credentials at once. The portal redirects SecureStaff BV's browser to their business wallet, which shows exactly what FlexProcure is requesting: all five business documents. SecureStaff BV reviews the request, clicks **"Share"**, and that's it. Within seconds, FlexProcure's system has **cryptographically verified** all five credentials. The company's registration is confirmed, its compliance is clear, and the insurance coverage is authentic. No phone calls, no paper, no waiting. The portal shows: **"All required documents received and verified"** — and SecureStaff BV is approved as a supplier. One click — all documents shared. The company stays in full control and sees exactly what the broker receives. No data is shared without explicit consent. For FlexProcure / Rijkswaterstaat All five documents are verified instantly and cryptographically. No risk of forged documents, no manual checks, and the onboarding process takes minutes instead of weeks. Impact Single Verification All supplier documents verified at once — no more collecting files one by one Efficiency Automated supplier verification reduces onboarding time from weeks to minutes Fraud Prevention Digital signatures and revocation mechanisms ensure documents cannot be falsified Standards Based Built on OpenID4VCI and OpenID4VP — works with any compliant wallet The Company Passport Initiative Credenco, through its Business Wallet technology and as part of the **Company Passport** initiative, collaborates with the Chamber of Commerce (KVK), the Tax Authority (Belastingdienst), the Royal Dutch Association of Civil-law Notaries (KNB), and the banking sector (NVB). Together, we deliver all the essential components to issue, exchange, and verify supplier credentials in practice. Suppliers request credentials directly from trusted authorities (KVK, banks, insurers, tax authorities) Organizations instantly verify authenticity via their Business Wallet — no PDFs, no manual checks New businesses can establish themselves more efficiently, including secure and verifiable bank account creation linked directly to the organization Interested in the technical details? This use case is built on open standards like OpenID4VCI and OpenID4VP. Explore our technical documentation for the full implementation guide. Use case Implementations Guides Step-by-step API Reference Explore API This use case is part of Credenco's broader supply chain solutions Real Case This is an example application of our technology. Book a meeting Talk to sales In collaboration with SecureStaff BV visits the KVK portal to request a registration extract The portal redirects the browser to the business wallet SecureStaff BV accepts the KVK registration credential KVK Registration stored in the business wallet SecureStaff BV visits the Tax Authority portal SecureStaff BV accepts the tax compliance credential All 5 credentials collected — ready to register as a supplier Tax Compliance Insurance Certificate Issue KVK Registration Extract Issue Credential Redirecting to your business wallet... New Credential Offer KVK Registration Extract Issuer: Kamer van Koophandel Legal form: Besloten Vennootschap Address: Herengracht 100, Amsterdam Accept Decline Issue Tax Compliance Statement Tax Compliance Statement Issuer: Belastingdienst Status: Compliant Valid: 2026-01-01 to 2026-12-31 SecureStaff BV starts registration on the FlexProcure portal SecureStaff BV reviews which credentials FlexProcure is requesting SecureStaff BV shares all 5 credentials at once All documents verified — supplier approved Supplier Registration Client Required documents KVK Extract, Tax Compliance, VAT Registration, Bank Account Details, Insurance Certificate Provide documents FlexProcure requests the following credentials: Share Sending credentials to FlexProcure... All documents verified! All credentials received and verified Supplier approved ### Digital VOG Credentials Case Study https://www.credenco.com/case/vog Sports clubs Screen trainers and volunteers in bulk with immediate, verifiable results — no more paper trails or delayed onboarding before the season starts. Logistics & recruitment Automate large-scale Certificate of Good Conduct checks during hiring campaigns, reducing time-to-hire from weeks to minutes. Educational institutions Receive and validate student teacher and intern certificates fully digitally, directly from the issuing authority. Sector Government / HR Credential Certificate of Good Conduct Annual volume 1.8M VOGs / year Processing time From 7 weeks to seconds Standard Fraud Prevention Cryptographic signatures make falsified paper or PDF copies impossible to use undetected. Instant Verification Processing time drops from 1–7 weeks to seconds. Onboarding happens in real time. Less Admin Burden No physical documents, no manual handling. The process runs end-to-end digitally. Scalable & Future-Proof Handles thousands of verifications simultaneously, across sectors and borders. Digital Credential for Certificate of Good Conduct Every year in the Netherlands, more than 1.8 million Certificates of Good Conduct (VOGs) are issued. Justis — the screening authority of the Ministry of Justice and Security — is piloting the digital issuance of the VOG as a verifiable credential, transforming a slow paper-based process into an instant, cryptographically verifiable flow. Justis is the Dutch government screening authority responsible for issuing Certificates of Good Conduct (VOG). Together with Credenco, Justis is piloting digital issuance of the VOG as a verifiable credential in preparation for the Dutch EUDI Wallet in 2026. Pilot partner The Challenge The Certificate of Good Conduct (VOG) plays a crucial role in safeguarding trust in Dutch society. More than 350 large organizations and 26,000 sports clubs rely on it to verify employees, trainers and volunteers before granting access to sensitive roles. No club wants a coach with a criminal record for child abuse on the field. Today this process is slow, inefficient and vulnerable to fraud. Paper and PDF-based certificates can be falsified, verification requires manual handling, and processing times range from 1 to 7 weeks. The result: delayed onboarding, unnecessary administrative effort, and millions of euros in lost business value each year. With the Dutch EUDI Wallet arriving in 2026 and the eIDAS 2.0 regulation taking effect, Justis set out to prepare its VOG issuance for this new infrastructure — starting with a controlled pilot in a production environment. The Solution A digital-first approach transforms the process entirely. Justis issues the VOG as a cryptographically secured verifiable credential through Credenco's Business Wallet — the same proven platform used in earlier practical trials, including the successful BOA-app initiative. Citizens receive their certificate directly in their personal wallet, ensuring privacy and full control over their data. Employers, sports clubs and institutions verify authenticity instantly through their Business Wallet — without manual checks, physical documents or waiting periods. The solution is built on international open standards — W3C Verifiable Credentials, the ARF v1.4 Architecture Reference Framework, ETSI TS 119 472-1 and 119 471, and the DIIP v5 profile — ensuring interoperability with the NL-EUDI Wallet, the FIDES Credential Catalogue and third-party wallets. Because the VOG credential uses the same data definitions as today's paper VOG, it plugs in to Justis' existing message formats. The Pilot Building on a successful practical trial in 2024, the 2025 pilot is organized by COVOG inside Justis and runs with at least one large external consumer of VOGs. Target groups include sports associations and the police as preferred pilot organizations — exactly where the value of fast, trustworthy screening is most tangible. Credenco provides the Business Wallet platform (available as a SaaS or on-premise service), a citizen-facing VOG app, and a validation flow that supports both remote sharing (e.g. an emailed validation QR code) and nearby validation through QR scans at the point of entry. The pilot runs through autumn 2025, with evaluation and recommendations completed early 2026. The Result The solution has already been successfully piloted with several sports associations, where volunteers shared their VOG digitally and clubs confirmed validity in real time. The outcome: a faster, more secure and fully automated process that scales effortlessly — and a clear path for Justis toward large-scale digital issuance from 2026 onward. At a glance Impact What changes when the VOG moves from paper to a verifiable credential. Practical Examples Three concrete applications where the digital VOG delivers value today. Future Outlook Digitizing the VOG is a strategic first step toward a comprehensive digital government issuance ecosystem. Using the same wallet infrastructure, diplomas, permits and other certificates can follow — positioning government as the trusted source of digital assurance and unlocking significant economic and societal value. With 1.8 million VOGs issued every year, this solution touches millions of citizens and tens of thousands of organizations, strengthening trust and safety across the country. This case study is part of Credenco's broader government solutions Real Case Example This is an example application of our technology. Book a meeting Talk to sales In collaboration with ### Digital Product Passport for Construction https://www.credenco.com/case/digital-product-passport Manufacturers of circular facades Issue a DPP per facade element so that it can be dismounted, verified and remounted on a new building — turning products into long-lived assets. Architects & design offices Query authentic product data at design time, so material choices can be made against verified environmental and compositional information. Building owners & material registers Automatically enrich building-level passports (e.g. in Madaster) from the underlying component DPPs, keeping the building model continuously up to date. ESPR Ready A reusable DPP pattern that is compliant with the upcoming Ecodesign for Sustainable Products Regulation. Circular Value Verifiable product data travels with components across their lifecycle — enabling reuse, remanufacturing and high-value recovery. Trust by Default Cryptographically signed credentials prove origin, composition and ownership without manual checks or fragile PDFs. Ecosystem Fit Interoperable with Madaster, CIRPASS2 and European wallet standards (EUDI, W3C VCs) — built to scale beyond the pilot. Digital Product Passport for Construction Verifiable digital product passports (DPPs) for construction materials and components, developed in the **Digitaal TEMPO in de Bouw** consortium — a research project led by HU University of Applied Sciences Utrecht and funded by Regieorgaan SIA and Topsector ICT under the Digital Product Passports call. Consortium lead · Digitaal TEMPO in de Bouw HU leads a consortium of six grant recipients and five project stakeholders to accelerate the adoption of Digital Product Passports in the Dutch construction sector. In collaboration with Situation The construction sector accounts for a large share of Europe's raw material consumption and waste. New European legislation — in particular the Ecodesign for Sustainable Products Regulation (ESPR) — requires manufacturers to make product information transparent, digital and verifiable through Digital Product Passports. For the built environment this is a fundamental shift: materials, components and buildings must be traceable across their entire lifecycle so that reuse and circular construction become possible at scale. Within this context the project **Digitaal TEMPO in de Bouw** was launched (start date 1 September 2025, dossier DPP.DPP.01.011, funded by Regieorgaan SIA and Topsector ICT as part of the Digital Product Passports call). HU University of Applied Sciences Utrecht acts as lead partner; Credenco is one of the six grant recipients and provides the organization wallet technology that allows passports to be issued, managed and shared in a verifiable way. Challenge Although the need for DPPs is widely recognized, SMEs in construction face real-world barriers. There is no shared standard for how passports are issued, verified and exchanged between the many parties in the chain. The project focuses on four core questions: **Authentication and access:** who is allowed to view or use which information? **Integration with information systems and databases:** how is data shared efficiently between parties? **Privacy and security:** how is sensitive product information protected? **Data management and maintenance:** how is the information kept accurate and reliable over time? For Credenco, the challenge is to translate these questions into a working, scalable wallet infrastructure that matches the reality of manufacturers, architects, contractors and asset owners in construction. Solution Together with Quintessence Research, Credenco develops the digital solution that issues and manages DPPs. Credenco contributes its Business Wallet: the place where companies receive, hold and share verifiable credentials based on European standards (EUDI, W3C VCs). EPEA contributes expertise on Cradle-to-Cradle and material passports; Zuyd University of Applied Sciences and HU form the research backbone, guiding the practice-based research under project lead dr. A.F. de Wild. The approach is validated through concrete use cases with project stakeholders from the construction value chain: CISKIN (Alkondor Hengelo) for circular facades, SATIJNplus Architecten for design and integration in a built object, Madaster for embedding in the circular material register, Imperfect for market distribution, and digiGO together with Biobased Nederland for sector connection and knowledge sharing. The consortium aligns with European initiatives such as CIRPASS2 and contributes to an interoperable DPP infrastructure for the construction sector. Expected Result The project runs until August 2027. The intended outcome is a set of lessons learned, recommendations and best practices that allow SMEs in construction to adopt DPPs quickly and unlock the opportunities of circular building. For Credenco, the project delivers concrete validation of the Business Wallet in a complex, multi-stakeholder value chain, and forms the basis for broader rollout of verifiable product passports — in construction and in other sectors that will fall under the ESPR. Impact The project is ongoing until August 2027 — these are the expected outcomes we are building towards together with the consortium. Practical Examples Three concrete applications being explored with the consortium partners. Future Outlook DPPs for construction are a first step towards a much broader ecosystem of verifiable product and supply-chain data. The wallet infrastructure and governance patterns developed in TEMPO are designed to extend to other ESPR product groups — from textiles to electronics — and to connect with the European digital identity framework, positioning organizations to become the trusted source of product assurance in a circular economy. This case study is part of Credenco's broader supply chain solutions Real Case Example This is an example application of our technology. Book a meeting Talk to sales ### Digital KYC for Company Incorporation https://www.credenco.com/case/establish-new-company Sector Procurement · B2B Credential types 5 authoritative sources Onboarding time From weeks to minutes Standards Initiative Speed Onboarding time drops from weeks to minutes — credentials are pre-verified at the source. Trust Every credential carries a cryptographic signature from the issuing authority, eliminating doubt about authenticity. Fraud Prevention Digital signatures and revocation mechanisms make falsified documents technically impossible. Scale Works equally for a single freelancer and an enterprise-scale procurement workflow. Establish a new company Supplier onboarding takes weeks when it should take minutes. Credenco replaces stacks of PDFs and email chains with verifiable credentials — issued directly by KVK, Belastingdienst and other authoritative sources, shared in one tap and verified instantly. Whether a freelancer registers on a procurement platform or a brand-new BV is established, every check is pre-verified at the source. Dutch Public-Private Partnership A Dutch public-private partnership bringing together KVK, Belastingdienst, KNB, NVB and Betaalvereniging Nederland to give every business a verifiable digital identity. Credenco delivers the sandbox, Business Wallet and Issuer Portals that power the initiative. In collaboration with The Challenge Supplier onboarding is one of the most document-intensive steps in procurement. Before a company can deliver goods or services, the buying organisation must collect and verify multiple documents: Chamber of Commerce (KVK) extract — confirming the company is registered and active Tax compliance statement — confirming no outstanding obligations with the Belastingdienst Insurance certificate — proof of valid liability coverage VAT number and IBAN — required for invoicing and payment Today, this still mostly happens via email: PDFs, scanned copies, manual checking. It is slow, fraud-prone, and hard to scale. Origins are difficult to verify, leading to compliance risk and costly delays on both sides. The Solution Credenco replaces document exchange with verifiable credentials. Trusted issuers — the Chamber of Commerce (KVK), the Tax Authority (Belastingdienst), notaries, banks and insurers — issue credentials directly into a supplier's Credenco Business Wallet. When a buyer requests verification, the supplier shares them in seconds. No email, no PDFs, no manual review. This work is part of the **Company Passport initiative** — a Dutch public-private partnership between KVK, Belastingdienst, the Royal Dutch Association of Civil-law Notaries (KNB), the Nederlandse Vereniging van Banken (NVB) and Betaalvereniging Nederland. Together, these parties cover all the credentials a business needs to prove its identity and compliance. Suppliers collect credentials once — directly from authoritative sources — into their Business Wallet. Buyers verify instantly, without requesting documents by email or waiting for callbacks. New companies can establish themselves faster, with verifiable registration and banking details available from day one. Credenco's Role Credenco is the wallet provider and technical backbone of the Company Passport sandbox. We deliver a production-grade Business Wallet for every participant, together with the Issuer Portals that turn each authority into a credential issuer. **Business Wallet** — eIDAS 2.0 and DIIP v5 compliant, with issuing, verification, revocation, trust lists, key management and DID management out of the box. **Issuer Portals** — pre-built portals for PID, KVK (LPID & UBO), Notary (Deed of Incorporation) and newly developed portals for the Tax Authority and a bank. **FIDES Credential Catalog & Blue Pages** — seamless integration so suppliers can discover authoritative issuers directly from their wallet. **Keycloak-based IAM** — per-portal login with username/password or wallet-based sign-in via OpenID4VP. At a glance Ecosystem Partners Company Passport brings together the authoritative sources a business needs to prove its identity and compliance — in one interoperable network. Start a BV in 1 day Starting a company in the Netherlands today takes about six weeks: a notary draws up the deed, KVK registers the company, the Belastingdienst issues a VAT number, and only then can a bank open a business account. Each step waits on paper from the last one. With the Business Wallet, every authority reads a verifiable credential issued by the previous one — and completes the next step the same day. Impact Why moving supplier onboarding onto verifiable credentials fundamentally changes the game for procurement teams, platforms and suppliers alike. Beyond incorporation Once a business holds these credentials in its Business Wallet, supplier onboarding becomes trivial. Procurement platforms such as FlexProcure — used by clients like Rijkswaterstaat — request KVK, tax, VAT, IBAN and insurance in a single flow. The supplier shares them in one tap, and the platform approves onboarding in real time. No PDFs, no email, no manual review. Future Outlook Credenco and its partners are preparing a real-world pilot to test the live exchange of digital KVK extracts and tax compliance certificates. This marks the first step toward supplier onboarding that is fully digital by default. As more authorities — from insurers and banks to government agencies — begin issuing verifiable credentials, the network effect grows: suppliers manage fewer documents, buyers complete more checks in less time, and the entire procurement ecosystem becomes significantly more resilient against fraud. This case study is part of Credenco's broader financial services solutions Real Case Example This is an example application of our technology. Book a meeting Talk to sales Notary (KNB) Notarial deed of incorporation The notary drafts the deed and signs it cryptographically. Issue deed → Deed of Incorporation SecureStaff BV · Articles of association Company registered KVK reads the deed and issues the registration (LPID + UBO). Issue KVK extract → KVK Registration Extract KVK 12345678 · UBO verified VAT number issued The Tax Authority reads the KVK credential and issues VAT. Issue VAT attestation → VAT / Tax Compliance Bank (ABN AMRO) Business account opened The bank reads all prior credentials and opens the account. Issue IBAN → IBAN Attestation Step of Flow steps credentials Previous step Previous Next step Next Every issuer plugs into the same Business Wallet — the wallet is the connector that makes the next step instant. Result · same day Deed of incorporation issued by the notary KVK reads the deed and registers the company Belastingdienst reads the KVK extract and issues the VAT number Bank reads all three credentials and opens the business account One source document. Multiple readers. Instant trust. Six weeks → one day. ### e-Invoicing on the Peppol Network https://www.credenco.com/case/einvoicing Chamber of Commerce number (CoCnr) VAT number Tax address Bank Sender e-Invoice credential (with evidence documents) Sector Finance · B2B Initiative Stakeholders Standards Status Part 1 & 2 delivered · pilot live No more fake invoices Every invoice carries a cryptographic signature linked to credentials issued by KVK, Belastingdienst and the sender's bank. Spoofed sender details and manipulated IBANs become detectable instantly. Instant validation Receivers validate the supplier's legal identity, VAT number and IBAN in a single verification — no manual cross-checks against external registers. Interoperable by design Built on open standards (W3C VC, OID4VCI, OID4VP) and successfully interoperability-tested with other wallet providers — e-invoices flow across wallet ecosystems. Foundation for Peppol & EU eIDAS 2.0 Delivers a verifiable-credentials layer on top of Peppol-style invoicing, aligned with the upcoming EU Digital Identity Wallet and mandatory e-invoicing directives. e-Invoicing Invoice fraud, IBAN manipulation and mismatched VAT numbers cost European businesses billions every year. Together with KVK, the Belastingdienst, Unifiedpost and Visma Yuki, Credenco has built — and interoperability-tested — a verifiable e-invoicing stack. Every invoice is cryptographically bound to its sender, its VAT registration and its IBAN, and travels directly between business wallets. No PDFs, no spoofed headers, no guesswork. Dutch public-private initiative FIDES Labs is a Dutch initiative where public and private stakeholders collaborate on pragmatic digital-wallet and verifiable-credential projects. The Small Scale Pilot e-Invoicing brings together KVK, the Belastingdienst, Unifiedpost and Visma Yuki. In collaboration with The Challenge Today's e-invoicing is only half-digital. Invoices move as PDFs or structured XML via email and ERP systems, but the identity of the sender is never cryptographically proven. The receiver has to cross-check the supplier's KVK number, VAT registration and IBAN against external registers — or skip the check entirely. Spoofed sender details and swapped IBANs are a common fraud vector. VAT numbers and Chamber of Commerce registrations are verified manually, if at all. Every country, platform and ERP speaks a slightly different dialect of the same standard. The Dutch — and European — answer is structured, verifiable invoicing: invoices with a cryptographic proof of **who** is sending them, issued against the same authoritative sources that register the sender's legal existence. The Solution The FIDES Labs Small Scale Pilot e-Invoicing was set up to prove the concept end-to-end, in two phases. **Part 1 — Organizational wallets & credentials.** Credenco delivered a Business Wallet, Issuer Portal and Verifier Portal for the four participating legal entities. KVK issued the Chamber of Commerce number and RSIN as verifiable credentials. The Belastingdienst issued the VAT number and tax address. All parties were onboarded onto the EBSI trust registry, and interoperability was demonstrated with a second wallet provider. **Part 2 — FIDES Blue Pages.** A decentralised business catalogue built on top of the wallets. Organisations can look up verifiable information about counterparties — KVK number, VAT, IBAN, addresses — using Web and EBSI crawlers that read Linked Verifiable Presentations from each legal entity's DID. Think of it as a decentralised "Google for business identity", without a central database. On top of this stack sits the **e-Invoice credential**: a verifiable credential that wraps the invoice payload, links it to the sender's KVK / VAT / IBAN credentials and carries optional evidence documents. Invoices are sent via a dedicated Send Invoice API and land in the receiver's wallet inbox, with OpenID4VP-based authorisation. Credenco's Role Credenco is the technical lead and wallet provider across both phases of the pilot. The work covers: **Business Wallet** — for all participating legal entities, with DID management (did:web, did:ebsi) and Linked Verifiable Presentations. **Issuer Portals** — for KVK (CoCnr, RSIN) and the Belastingdienst (VAT, tax address), including issuing and revocation flows. **Verifier Portal** — validates credentials against trusted issuers and schemas registered on EBSI. **FIDES Blue Pages** — decentralised business catalogue with admin tooling, Web DID and EBSI crawlers, API key management and OpenID4VP admin login. **e-Invoice credential + Send Invoice API** — the wrapper and transport layer that binds the invoice to its sender's verified identity. **Interoperability testing** — live testing with Sphereon and other DIIP-conformant wallets. At a glance What's on a verifiable invoice A verifiable e-invoice is not a PDF — it is a structured credential that bundles the invoice payload with the sender's authoritative identity credentials. Every data point below is issued, signed and independently verifiable. Issued by Impact What changes when invoices become verifiable credentials instead of signed PDFs. Practical Example A supplier sends an invoice to a customer. Both work in their own ERP, connected to their Business Wallet. The invoice travels as a verifiable credential — not as a PDF. 1. Sender Supplier From the ERP, the invoice is passed to the Business Wallet. The wallet wraps it in an e-Invoice credential, signed and linked to the sender's KVK, VAT and IBAN credentials. 2. Transport Send Invoice API The credential is delivered directly to the receiver's wallet inbox. OpenID4VP authorises the transfer — no shared mailboxes, no file attachments. 3. Receiver Customer ERP The receiving wallet verifies sender identity, VAT number and IBAN against the trusted issuers on EBSI. The invoice enters the ERP pre-verified — ready for straight-through processing. Future Outlook Mandatory e-invoicing is coming: most EU member states require structured invoicing from 2026 — and the European Digital Identity Wallet is arriving in parallel. The FIDES Labs pilot provides the missing link: invoices that are not just structured, but verifiable. As more authorities — banks, insurers, government agencies — issue credentials and FIDES Blue Pages grows, entire finance stacks (from procurement to payment) will shift from manual verification to cryptographic trust. That is the foundation for automated, fraud-resistant B2B finance at European scale. This case study is part of Credenco's broader financial services solutions Real Case Example This is an example application of our technology. Book a meeting Talk to sales ### Tax Splitter https://www.credenco.com/case/tax-splitter Sector Public · Tax & Finance Initiative End client Consortium Status Live pilot · Innovation Prize 2026 Belastingdienst End client & data recipient Ministerie van Financiën Commissioner mintBlue Split-payment protocol FIDES Labs Lab facilitator Credenco Business Wallet & Blue Pages From 30–40 hours to zero Dutch entrepreneurs spend an average of 30 to 40 hours per year on VAT administration. When the invoice itself is the declaration, that number drops to zero — without giving up oversight. Closes the VAT gap The European Commission estimates the annual EU VAT gap at €128 billion. Real-time split-payment removes the window in which VAT can go missing, be miscalculated or be routed through fraudulent carousels. Verifiable identity at both ends Every transaction is signed by a sender and receiver whose legal identity, VAT number and tax address were issued as verifiable credentials by KVK and the Belastingdienst — not self-declared. Privacy by design The Belastingdienst only receives the tax-relevant fields of a transaction — date, amount, VAT percentage. The rest of the invoice stays between the two businesses and their wallets. Tax Splitter VAT fraud and late remittance cost EU member states an estimated €128 billion every year, while Dutch entrepreneurs spend 30–40 hours annually on VAT admin. Together with mintBlue, FIDES Labs and the Belastingdienst, Credenco is piloting Tax Splitter: a system that automatically separates the VAT portion from every payment and remits it in real time. The invoice is the declaration — and both parties are identified by verifiable credentials from their Business Wallet. In March 2026, Tax Splitter won the Ministerie van Financiën Innovation Prize. Ministerie van Financiën — Innovation Lab The Belastingdienst, in partnership with the Ministerie van Financiën, is the end client of the Tax Splitter Lab — a joint initiative with mintBlue (split-payment protocol), FIDES Labs (lab facilitator) and Credenco (Business Wallets & Blue Pages). In collaboration with The Challenge VAT is the largest single source of government revenue in the Netherlands — and one of the most fraud-prone. Entrepreneurs declare and remit VAT quarterly, which creates a natural window between when VAT is collected and when it reaches the tax authority. That window is exactly where **btw-carrouselfraude** lives. The EU VAT gap is estimated at €128 billion per year. Dutch entrepreneurs spend 30–40 hours per year on VAT administration. The Belastingdienst has limited real-time insight into VAT flows until after the fact. Sender identity on invoices is not cryptographically guaranteed — spoofed VAT numbers and fake suppliers are common. The ambition — set out in the Belastingdienst's Tax 3.0 vision — is to move from periodic self-declaration to **real-time taxation**: **"sandwich ordered, tax settled"**. That only works if both sides of the transaction can prove who they are, and if the VAT portion can be split off automatically. The Solution Tax Splitter combines three complementary building blocks into a single flow. **1. Verifiable business identity.** Every participating organisation runs a hosted Business Wallet. KVK issues the Chamber of Commerce number and RSIN as verifiable credentials; the Belastingdienst issues VAT number and tax address. Before a transaction starts, both parties have already proven their legal identity to each other. **2. Split payment at the moment of transaction.** mintBlue's stablecoin-based split-payment protocol automatically separates the VAT portion from the gross amount and routes it directly to the Belastingdienst. The merchant receives the net; the tax authority receives the VAT. No quarterly declaration, no timing gap. **3. Decentralised discovery via FIDES Blue Pages.** Counterparties are looked up through Credenco's Blue Pages — a decentralised business catalogue built on verifiable credentials and DIDs. There is no central database; each legal entity publishes its own Linked Verifiable Presentations, crawled and indexed over Web and EBSI. The result: the invoice, the identity check and the tax payment are collapsed into a single transaction. Credenco's Role Credenco is the wallet and identity-infrastructure partner inside the Tax Splitter Lab. Our scope for the pilot phase (Oct 2025 – Mar 2026): **Hosted Business Wallets** — up to four organisational wallets for the pilot participants, with DID management (did:web, did:ebsi) and key management out of the box. **FIDES Blue Pages** — the decentralised counterparty catalogue that lets mintBlue and the Belastingdienst discover and verify participants without a central registry. **Integration support for mintBlue** — hands-on guidance so the split-payment protocol can consume Credenco-issued credentials and presentations. **Standards alignment** — W3C VC, OID4VCI, OID4VP and DIIP v5, so the pilot is interoperable with other EUDI-ready wallets from day one. At a glance How a Tax Splitter transaction works Three steps, one transaction — identity, payment and tax declaration happen simultaneously. 1. Identify Business Wallets exchange credentials Both parties present KVK (CoCnr, RSIN) and Belastingdienst (VAT, tax address) credentials from their Business Wallet. Each side knows instantly that the other is a real, registered, VAT-liable entity. 2. Pay mintBlue splits the transaction mintBlue's split-payment protocol separates the VAT portion from the net amount. The net goes to the supplier; the VAT goes directly to the Belastingdienst — as a single atomic operation. 3. Report Invoice is the declaration The Belastingdienst receives only the tax-relevant fields — date, amount, VAT percentage — already signed and linked to verified identities. No quarterly declaration is needed. The consortium Tax Splitter is built by a small, tightly integrated consortium — each partner owns a specific layer of the stack. Impact What changes when VAT is collected at the moment of transaction, not quarters later. Recognition Innovation Prize 2026 — Ministerie van Financiën In March 2026, Tax Splitter was awarded the Innovation Prize of the Ministerie van Financiën. The jury highlighted the combination of real-time VAT settlement with verifiable organisational identity as a pragmatic path towards reducing the EU VAT gap while cutting administrative burden. Future Outlook The same split-payment + verifiable identity pattern extends naturally to other tax categories: excise duties, tourism tax, gaming tax, transfer tax and cross-border VAT. As the EU Digital Identity Wallet arrives and more authorities issue credentials to Business Wallets, "the invoice is the declaration" can become the default — not the exception. This case study is part of Credenco's broader financial services solutions Real Case Example This is an example application of our technology. Book a meeting Talk to sales ### BOA ID https://www.credenco.com/case/boa-id English Nederlands Español Français Deutsch Suomi Italiano Norsk Svenska Português Dansk Polski Română Eesti Čeština Slovenščina Magyar Hrvatski Ελληνικά Gaeilge Latviešu Lietuvių Malti Slovenčina Sector Public · Enforcement & Identity Initiative INSIGNE — digital BOA ID End client Pilot partner RET Rotterdam — 20 BOAs Standards Justis End client & issuing authority RET Rotterdam Pilot partner & employer of BOAs Credenco Mobile app, Issuer Portal & wallet backend No more lost physical badges A lost plastic BOA badge could previously be used by anyone. A digital BOA ID can be revoked instantly from the Issuer Portal — and the citizen verifying it always sees the live revocation status. Privacy by design The physical badge shows the BOA's full name and other personal data to every member of the public. The digital BOA ID lets the officer choose which attributes to share — proof of authority without unnecessary exposure. Verifiable by any citizen Citizens scan the QR on the officer's screen with their phone camera — no app required. A website hosted by the Ministry of Justice & Security shows authenticity, validity and the selected attributes. Faster, cheaper issuance Digital issuance removes the print-and-ship logistics of physical badges. Justis issues a Verifiable Credential in seconds; the BOA activates it on their phone with a PIN. BOA ID Dutch Special Investigating Officers (BOAs) — from ticket inspectors to environmental enforcement — have historically identified themselves with a plastic badge. Lose it, and anyone can impersonate you; show it, and you reveal your full name to every citizen you address. Together with Justis, the RET and the INSIGNE initiative, Credenco built the first digital BOA ID: a Verifiable Credential issued by Justis, carried on the officer\'s phone, and verifiable by any citizen with a simple QR scan. Authenticity, selective disclosure and instant revocation — built on open standards, piloted with 20 BOAs at RET Rotterdam. Justis is the screening authority of the Dutch Ministry of Justice and Security, responsible for BOA accreditation. Credenco partnered with Justis and RET Rotterdam to pilot the INSIGNE digital BOA ID with 20 enforcement officers in live duty. In collaboration with The Challenge There are roughly 24,000 BOAs in the Netherlands — public-transport inspectors, parking enforcement, forest rangers, harbor police, and many more. Each one carries a physical badge issued by Justis. Two structural problems sit on top of that badge: **Fraud-sensitive.** A lost or stolen badge can be used by anyone. Citizens have no way of checking whether the holder is a real, currently-accredited BOA. **Privacy-sensitive.** The badge shows the BOA's full name. Hostile citizens use that to track officers down, harass them at home, or target their families. **Slow & expensive to issue.** Printing, shipping, activating and revoking physical badges is a logistical chain that takes days. **No way to revoke.** Once a badge is in the wild, Justis has no real-time mechanism to invalidate it in the eyes of the public. The Ministry of Justice & Security wanted a digital alternative that eliminated those risks while preserving the trust that the physical badge carries — and preferably, added new capabilities along the way. The Solution The INSIGNE platform replaces the plastic badge with a Verifiable Credential issued by Justis, carried on the BOA's phone, and verifiable by any citizen — without installing anything. **1. Issuance.** Justis uses a web portal to issue a digital BOA ID as a Verifiable Credential, signed with Justis' own DID. The BOA receives an email with a reference code and, separately, a PIN. They install the INSIGNE app, enter the PIN, and the credential is stored encrypted on their device — with a seed-phrase recovery flow for device loss. **2. Identification.** When the BOA needs to identify themselves, they open the app, choose which attributes to share (badge number, photo, scope of authority) and unlock with biometrics. The app generates a short-lived Verifiable Presentation. **3. Verification.** The citizen scans the QR on the BOA's screen with their default phone camera — no app needed. The QR contains an encrypted link to a Ministry-hosted page showing the BOA's selected attributes, authenticity status and current validity. The presentation expires after 15 minutes and is used at most once. **4. Revocation.** Justis can revoke a BOA ID from the Issuer Portal. The next verification — online within seconds — reports the credential as invalid. The whole flow is built on W3C Decentralized Identifiers and Verifiable Credentials, so the same credential can be used across any compatible verifier and sits wallet-ready for the European Digital Identity Wallet rollout. **The BOA ID in action.** The video below shows BOAs using the INSIGNE app to share his credential, a citizen might scan the QR with their own phone camera to see whether that badge is valid. Your browser does not support the video tag. Credenco's Role Credenco delivered the complete INSIGNE stack for the Justis-RET pilot, from mobile app to Issuer Portal to verification service. Scope: **INSIGNE mobile app** for iOS and Android — credential storage, selective disclosure, biometric unlock, offline safeguards. **Justis Issuer Portal** — web application for issuing, re-issuing and revoking BOA credentials. **Verification service** — public-facing page that renders the Verifiable Presentation for any citizen who scans the QR, plus an authenticated view for fellow enforcement officers. **HSM-backed key management** on the mobile device for the BOA's private keys, plus automatic lockout if the phone stays offline for too long. **Revocation & audit trail** — who issued, who activated, who viewed, and when. **Privacy-by-design architecture** — Verifiable Presentations encrypted at rest, deleted after one view or 15 minutes, and never tied to the verifying citizen's identity. At a glance How a digital BOA ID works Four steps from Justis to the public — issuance, identification, verification and revocation. 1. Issue Justis signs the credential Justis issues a Verifiable Credential for the BOA via the Issuer Portal, signed with Justis' DID. 2. Activate BOA sets up the app The BOA receives a reference code and PIN, installs the INSIGNE app, enters the PIN and stores the credential encrypted on the device. 3. Identify Selective QR on duty The BOA selects which attributes to share and generates a QR. A citizen scans it with their phone camera — no app required. 4. Verify Live authenticity check The citizen lands on a Ministry-hosted verification page showing authenticity, validity and the shared attributes. Revoked? The page says so. The consortium A focused team: Justis as issuing authority, RET Rotterdam as the pilot employer, Credenco as the technology partner delivering the full INSIGNE stack. Impact What changes when the plastic badge becomes a Verifiable Credential. Future Outlook The INSIGNE pattern reaches well beyond BOAs. Any credential issued by a public authority — police ID, vehicle permits, VOG certificates, weapon licences — can follow the same pattern: issued by the authoritative source, carried in a wallet, selectively disclosed, and verifiable by anyone. As the European Digital Identity Wallet rolls out, the same BOA ID becomes portable across member states, interoperable with other wallets, and ready for cross-border enforcement cooperation. This case study is part of Credenco's broader government solutions Real Case Example This is an example application of our technology. Book a meeting Talk to sales ### Company Passport https://www.credenco.com/case/company-passport Company Passport (KYC) Verifiable business credentials for know-your-customer processes. Situation Content to be added based on real project details. Challenge Solution Result This case study is part of Credenco's broader government solutions Real Case Example This is an example application of our technology. Book a meeting Talk to sales In collaboration with ## Company ### Digital Credential Glossary https://www.credenco.com/glossary A tamper-evident digital claim about a person or organisation that can be cryptographically verified without contacting the party that issued it. Verifiable credentials replace paper documents and PDFs with data that a verifier can trust on its own. The World Wide Web Consortium's open data model for verifiable credentials. It defines how claims, issuers, and cryptographic proofs are structured so credentials remain interoperable across different wallets and platforms. Selective Disclosure JSON Web Token: a credential format that lets a holder reveal only some of the claims inside a signed token while keeping the rest hidden, without invalidating the issuer's signature. The ability to share only the specific attributes a verifier needs from a credential, for example proving you are over 18 without revealing your exact birth date. It is a core privacy property of modern credential formats such as SD-JWT. OpenID for Verifiable Credential Issuance: the protocol a wallet uses to request and receive a credential from an issuer over a standard OAuth2-based flow. OpenID for Verifiable Presentations: the protocol a wallet uses to present one or more credentials to a verifier in response to a request, so the verifier can check them without a separate integration per issuer. Decentralized Identifier: a globally unique identifier that does not depend on a central registry. DIDs let issuers, holders, and verifiers reference each other and resolve public keys without a central authority. A DID method that anchors a DID document on a regular HTTPS domain (e.g. did:web:example.com), using existing web PKI instead of a blockchain or ledger. DID Web with Verifiable History: a successor to did:web that adds a tamper-evident, verifiable history log of every DID document version, plus key pre-rotation and witnesses, so a DID document can't be silently rewritten. The European Digital Identity Wallet mandated by eIDAS 2.0: a wallet app every EU member state must offer citizens and businesses for storing and presenting verifiable credentials, recognised across all 27 member states. A cloud-based business identity wallet built for the European market: it lets organisations issue, hold, and verify verifiable credentials for company registration, tax IDs, and certifications, so counterparties across the EU can trust them instantly instead of re-checking documents. Credenco's Business Wallet is an implementation of this concept. The revised European regulation on electronic identification and trust services. It mandates the EUDI Wallet and establishes the legal framework for verifiable credentials to carry legal validity across the European Union. The organisation that creates and cryptographically signs a verifiable credential (for example a government agency, a bank, or a chamber of commerce), vouching for the claims it contains. The person or organisation that receives a verifiable credential, stores it in a wallet, and decides when and with whom to share it. The holder is not necessarily the subject the credential is about. The party that checks a presented credential: validating the issuer's signature, confirming the credential has not been revoked, and reading only the claims the holder chose to disclose. The mechanism an issuer uses to invalidate a credential after it was issued (for example when a qualification expires or a registration is withdrawn), so verifiers checking it afterwards see it as no longer valid. The set of technical standards, legal rules, and governance agreements that let issuers, holders, and verifiers rely on each other's credentials across organisations and borders, such as the framework eIDAS 2.0 establishes for the EU. Know Your Customer: the checks an organisation performs to verify a customer's identity. Verifiable credentials let a customer reuse an identity check already performed elsewhere instead of repeating it for every new relationship. Know Your Business: the checks an organisation performs to verify a business counterparty, such as its registration, UBOs, and authorised representatives. Business credentials let these facts be proven instantly instead of via manual document checks. The organisation that requests a verifiable credential from a holder and relies on it to make a decision, such as a bank onboarding a new business or a shop checking a customer is old enough to buy an age-restricted product. A cryptographic proof, issued by a Wallet Provider, that a specific Wallet Unit meets the technical and security requirements of the EUDI Wallet ecosystem, presented alongside a credential so a verifier can trust the wallet doing the presenting. The ARF calls this a Wallet Unit Attestation (WUA). The specification a relying party uses to describe which credentials and claims it needs from a holder, so a wallet can automatically match the request against the credentials it holds. A mobile driving licence built to the ISO/IEC 18013-5 standard, stored and presented from a smartphone offline or online so any conforming reader can accept it regardless of who issued it. A cryptographic method for proving a statement about a credential is true, such as being over 18, without revealing any of the underlying data the statement is based on. Qualified Electronic Attestation of Attributes: the qualified variant of an EAA, issued by a qualified trust service provider under eIDAS 2.0, carrying the same legal weight as a notarised paper document. The tamper-evident package a holder assembles from one or more verifiable credentials to share with a verifier in response to a specific request, bound to the holder presenting it. The general category of app that lets a holder store credentials and attributes and choose exactly what to share with a relying party; the EUDI Wallet is the EU’s specific, regulated implementation of it. Person Identification Data: the government-issued identity credential at the core of every EUDI Wallet, holding attributes such as name, date of birth and a unique identifier, which other attestations are bound to. Architecture and Reference Framework: the European Commissionu2019s technical specification of the EUDI Wallet ecosystem, fixing the roles, credential formats, protocols and trust infrastructure that eIDAS 2.0 only describes in law. A compact, signed bitstring an issuer publishes in which every credential it has issued has one index, so a verifier can check whether a credential is still valid without revealing to the issuer which one it looked up. A mobile document in the ISO/IEC 18013-5 format: issuer-signed, CBOR-encoded data elements held on a phone that a reader can verify on the spot, including offline. The format the mDL is built on, and one of the two the EUDI Wallet uses. The OpenID4VCI message, usually behind a QR code or link, with which an issuer starts issuance: it names the issuer, says which credentials are on offer, and tells the wallet how it may collect them. How much confidence a relying party can place in a claimed identity, based on how the holder was identified and how the credential is protected. eIDAS defines three levels: low, substantial and high; the EUDI Wallet is issued at high. Qualified Electronic Signature: an electronic signature created with a qualified device and certificate, which eIDAS gives the same legal effect as a handwritten signature throughout the EU. FIDES - Accelerating Digital Trust: a European community that catalogues live digital identity implementations in its Ecosystem Explorer and Blue Pages, and maintains the DIIP interoperability profile. A European consortium of over 180 organisations building the infrastructure for an interoperable EU Digital Identity Wallet for businesses, and testing implementations against each other in its Interoperability Test Bed. European Business Wallet Owner Identification Data: the attestation that identifies the organisation a European Business Wallet belongs to, carrying a cross-border unique identifier, the official legal name from the authentic register, the issuing authority and a trust anchor a verifier can check it against. Decentralized Identity Interop Profile: a FIDES Community profile that picks one coherent set of existing specs for credential-based interoperability where the wallet does not need to be trusted, such as diplomas, licences and business wallets. High Assurance Interoperability Profile: an OpenID Foundation specification that constrains OpenID4VC for use where a high level of security and privacy is required, such as government-issued identity and the EUDI Wallet. The IETF profile that defines how to use SD-JWT to issue and present verifiable credentials, adding a credential type claim, key binding, and issuer metadata rules on top of the underlying selective-disclosure mechanism. The EUDI ARF names it alongside mdoc as a format wallets must support. A digital identity wallet held by a legal entity rather than a natural person, letting a company issue, hold, and present verifiable credentials about itself. The European Business Wallet is the specific implementation of this concept for the European market. A delivery model in which a provider hosts and operates a wallet's issuance, storage, presentation, and underlying security on a buyer's behalf, rather than the buyer building and running that infrastructure itself. The natural or legal person that supplies a Wallet Solution to users under eIDAS 2.0, responsible for its software, security guarantees and compliance obligations. The unique configuration a Wallet Provider gives to one Wallet User: the Wallet Instance app together with the secure cryptographic application and device that generate and protect its keys. Electronic Attestation of Attributes: any electronic attestation certifying attributes about a person or organisation, issued by any provider. A QEAA is its qualified, higher-assurance variant. An authoritative entity, represented by a public key and its associated data, that a relying party accepts as the starting point for verifying a chain of trust. A repository or system, run by a public sector body or private entity, that holds and provides attributes and is considered the primary, authoritative record for them. The collective term for a QEAA Provider, PuB-EAA Provider and non-qualified EAA Provider: the three roles the ARF defines for issuing attribute credentials. The international standard for a mobile driving licence: how a credential is stored on a phone and presented to a reader in person, offline or online. The format the mDL and mdoc are built on. European Blockchain Services Infrastructure: an EU network that anchors cross-border trust for verifiable credentials, such as which issuers and schemas are recognised, used by several EUDI Wallet pilots as their trust registry. The authoritative register a verifier consults to decide whether an issuer is trusted. Each EU member state publishes one under eIDAS 2.0, naming the qualified trust service providers and issuers it authorises. Ultimate Beneficial Owner: the natural person who ultimately owns or controls a legal entity, directly or through a chain of other entities. KYB requires establishing who a business counterparty’s UBOs are. Qualified Trust Service Provider: a trust service provider granted qualified status by an EU member state supervisory body and listed on that country’s Trusted List. Under eIDAS it is the party allowed to issue qualified certificates, QES and QEAA. The software an issuer uses to turn source data into verifiable credentials and deliver them to a wallet, typically over OpenID4VCI. Distinct from the Issuer role, which describes the party rather than the platform. The service interface a relying party calls to request and validate a presentation, covering signature checks, the trust chain, status and revocation, and the returned claims. Distinct from the Verifier role, which describes the party rather than the API. Digital credential glossary Plain-language definitions of the terms Credenco uses across its products and content, from credential formats and protocols to the roles that issue, hold, and verify them. ### About Credenco https://www.credenco.com/about Foundation Building identity infrastructure before wallets BOA ID · Early public-sector pilots · INSIGNE platform Infrastructure & Public Trust Working where trust matters most VOG pilots (Justis / Validata) · eSSIF-Lab · EU alignment European Integration Aligning with emerging EU architecture EBSI · Vehicle Passport · Museum use cases Business Wallet Preparing for market opening Company Passport · WE BUILD · Organization Wallet About Credenco was founded in 2021 on the conviction that organizations needed a reliable foundation for digital identity — long before eIDAS 2.0 redefined the European landscape. We built that foundation. Today, as verifiable credentials and organization wallets move from pilot to policy across Europe, Credenco operates at the intersection of trust, technology, and compliance. We help organizations manage their digital identities independently: secure, privacy-preserving, and built to scale. Vision Credenco envisions a world where organizations are not dependent on central parties for their digital identity and data exchange. In this future, organizations manage their own data and trust relationships – transparent, secure, and interoperable. Trust is no longer an abstract concept, but a digital and verifiable foundation for collaboration between people and organizations across borders and industries. Mission With 20+ years of experience in digital innovation, Credenco empowers organizations to manage their digital documents, data, and trust relationships in a reliable, privacy-friendly, and future-proof way. We achieve this through Verifiable Credentials, which can be securely issued, managed, and verified via the Business Wallet. In doing so, we create the global conditions for more efficient processes, reduced administrative burdens, and a higher level of trust in the digital economy. Build ahead of the market We built the infrastructure before regulation made it inevitable. Now the market is catching up. ### News https://www.credenco.com/news News Stay up to date with the latest from Credenco — product updates, partnership announcements, and insights on the future of digital identity. All No news items in this category yet. Read more ### Contact Credenco https://www.credenco.com/contact Contact Let’s talk about what Credenco can do for your organization. Sales Curious what Credenco can do for your organization? We’d love to tell you more. Reach out to schedule a demo or discuss how we can help. Book a meeting Your point of contact Business Development Company Info The Netherlands VAT Jobs We’re always on the lookout for new talent. Send an open application to . ### eIDAS 2.0 https://www.credenco.com/eidas What is eIDAS 2.0? eIDAS 2.0 is the 2024 revision of the European Union's regulation on electronic identification and trust services. It introduces the European Digital Identity Wallet as mandatory infrastructure for every EU member state and creates a legal framework for issuing and verifying digital credentials that are recognised across borders. Who does eIDAS 2.0 apply to? eIDAS 2.0 applies to EU member states, who must offer citizens and businesses a digital identity wallet, and to organisations that issue or verify identity-related documents, including chambers of commerce, banks, insurers, government agencies, and procurement platforms. When does eIDAS 2.0 take effect? By 2026, every EU member state must provide citizens and businesses with access to a digital identity wallet. Organisations that wait until closer to that date face a compressed transition timeline with higher cost and more disruption than early adopters. What is the European Digital Identity Wallet? The European Digital Identity Wallet (EUDI Wallet) is the mandatory infrastructure eIDAS 2.0 requires each member state to make available. It lets citizens and organisations store, present, and verify credentials such as company registrations, tax compliance statements, and professional qualifications, without relying on paper documents or email. How does eIDAS 2.0 relate to GDPR? eIDAS 2.0 and GDPR reinforce each other. A privacy-by-design wallet architecture keeps personal and organisational data with the holder instead of on a central server, which supports GDPR compliance while meeting the wallet requirements eIDAS 2.0 sets out. Is Credenco's Business Wallet eIDAS 2.0 compliant? Yes. The Business Wallet implements W3C Verifiable Credentials and OpenID4VC for credential issuance and presentation, and integrates with EBSI trust registries, so every credential issued through Credenco carries the standards-based trust eIDAS 2.0 requires. eIDAS 2.0 The revised European regulation on electronic identification and trust services. It mandates the European Digital Identity Wallet and establishes a legal framework for verifiable credentials across all EU member states. W3C Verifiable Credentials The global open standard for digitally verifiable claims. Credentials issued in this format can be independently verified without contacting the issuer. OpenID4VC A suite of protocols (OID4VCI, OID4VP) that enables interoperable credential issuance and presentation between wallets and verifiers. GDPR Europe's General Data Protection Regulation. Credenco's privacy-by-design architecture means personal data stays with the holder — never on a central server. EBSI The European Blockchain Services Infrastructure provides a cross-border trust registry for verifiable credentials, ensuring issuers and verifiers can be trusted across the EU. eIDAS 2.0 and the future of digital identity The European Union's revised eIDAS regulation introduces a binding framework for digital identity across all member states. It mandates the European Digital Identity Wallet and creates the legal foundation for organisations to issue, hold, and verify credentials that are recognised across borders. Credenco is built for this reality from the ground up. Explore the Business Wallet eIDAS 2.0 is the revision of the 2014 European regulation on electronic identification and trust services. Where the original regulation focused primarily on electronic signatures, the 2024 revision dramatically expands scope: it introduces the European Digital Identity Wallet as a mandatory infrastructure for all EU member states. Read Regulation (EU) 2024/1183 on EUR-Lex For organisations, this means a legal framework for issuing and verifying digital credentials — from company registrations and tax compliance statements to professional qualifications and insurance certificates. Credentials issued under eIDAS 2.0 carry legal validity across all 27 member states. The regulation aligns with open standards (W3C Verifiable Credentials, OpenID4VC) to ensure interoperability. Any wallet that meets the technical requirements can participate — preventing vendor lock-in and enabling a genuine European ecosystem of digital trust. Read the EUDI Wallet Architecture and Reference Framework Why it matters By 2026, EU member states must provide citizens and businesses with access to a digital identity wallet. Organisations that issue or verify identity-related documents — from chambers of commerce to banks, insurers, and procurement platforms — will increasingly work with verifiable credentials instead of PDFs and email. Early adopters gain a structural advantage: faster onboarding, lower fraud risk, automated compliance checks, and readiness for mandatory regulations before they take effect. Organisations that wait will face a compressed transition timeline with higher cost and disruption. Who eIDAS 2.0 applies to, and when eIDAS 2.0 applies at two levels. Member states must build and operate the European Digital Identity Wallet infrastructure and make it available to citizens and businesses. Organisations that issue or verify identity-related documents, including chambers of commerce, banks, insurers, government agencies, and procurement platforms, need to be able to issue credentials into that wallet or accept credentials presented from it. The rollout follows a fixed timeline. By 2026, every EU member state must provide citizens and businesses with access to a digital identity wallet. Ahead of that date, organisations that issue or verify credentials are expected to have the technical capability to work with wallet-based credentials, since the demand from wallet holders arrives the moment the wallet itself becomes available. In practice, preparing means three things: aligning credential formats with the open standards eIDAS 2.0 references (W3C Verifiable Credentials, OpenID4VC), connecting to a trust registry so issued credentials can be verified without contacting the issuer directly, and adopting a privacy-by-design architecture that keeps personal and organisational data with the holder rather than on a central server. Organisations that start early avoid the compressed transition timeline, higher cost, and disruption that come with waiting until the deadline is close. Standards we build on Credenco implements the full stack of European and international standards for digital identity and verifiable credentials. How Credenco aligns Credenco's Business Wallet is designed from the ground up to meet eIDAS 2.0 requirements. It implements W3C Verifiable Credentials, OpenID4VC for credential issuance and presentation, and integrates with EBSI trust registries — ensuring every credential issued through Credenco carries the standards-based trust that the regulation demands. All infrastructure runs on European cloud providers. Personal and organisational data is stored in wallets, never on central servers. This privacy-by-design architecture is not a retrofit — it is a core design principle that aligns directly with both GDPR and the eIDAS 2.0 wallet requirements. Book a meeting View our products Frequently asked questions ## Glossary ### Verifiable Credential explained https://www.credenco.com/glossary/verifiable-credential Verifiable Credential A verifiable credential is a tamper-evident digital claim about a person or organisation that can be cryptographically verified without contacting the party that issued it. It replaces paper documents and PDFs with data a verifier can trust on its own. An issuer signs the credential with a private key and gives it to a holder, who stores it in a wallet and presents it to a verifier whenever needed. The W3C Verifiable Credentials Data Model defines the common structure: a set of claims about a subject, metadata about the issuer and validity period, and a cryptographic proof binding all of it together, so any verifier that understands the format can check a credential from any issuer without a bespoke integration. A credential can be encoded as a signed JWT, as JSON-LD with a linked-data proof, or as a format like SD-JWT that supports selective disclosure, and different ecosystems favour different encodings for the same underlying data model. Revocation works without leaking who is checking what: an issuer publishes a status list, and a verifier looks up only whether a given credential's position on that list has been flipped, not which verifier is asking or when. In the EUDI Wallet under eIDAS 2.0, verifiable credentials are the standard format every member state must support, letting a business or citizen reuse one credential such as a mobile driving licence, a diploma or a company registration extract across issuers, sectors and borders instead of re-proving the same facts to each relying party separately. Because the proof is checked mathematically against the issuer's public key rather than through a phone call or a database lookup, verification still works even when the issuer is temporarily unreachable or based in another country. Issuer Verifier How is a verifiable credential different from a PDF certificate? A PDF certificate is just a document; anyone who receives it has to trust whoever sent it, or contact the issuer to confirm it is genuine. A verifiable credential carries a cryptographic signature the recipient can check on their own, instantly, against the issuer's public key, without a phone call, an email, or the issuer being reachable at that moment. Related terms Back to the glossary ### SD-JWT - what it is and how it works https://www.credenco.com/glossary/sd-jwt SD-JWT, short for Selective Disclosure JSON Web Token, is a credential format that lets a holder reveal only some of the claims inside a signed token while keeping the rest hidden, without invalidating the signature. Each claim in an SD-JWT credential is individually hashed and salted, so the holder can strip out any claim they do not want to share and the verifier can still check the remaining ones against the issuer's signature. SD-JWT VC is the profile the EUDI Wallet uses under eIDAS 2.0 for credentials such as a mobile driving licence or an age attestation, where privacy by design is a legal requirement, not just a nice extra. Verifiable Credential Selective disclosure SD-JWT VC Is SD-JWT the same as a JWT? No. A regular JWT signs one fixed block of claims that a verifier either sees in full or not at all. SD-JWT signs the same claims but hashes each one separately, so a holder can leave individual claims out of what they send while the remaining ones still verify against the original signature. Related terms Back to the glossary ### OpenID4VCI - what it is and how it works https://www.credenco.com/glossary/openid4vci OpenID4VCI, OpenID for Verifiable Credential Issuance, is the protocol a wallet uses to request and receive a credential from an issuer over a standard OAuth2-based flow. A holder starts the flow from their wallet, either by scanning a QR code or following a deep link from an issuer's website or app, and the wallet fetches a credential offer describing which credential type is on offer and where to get it. The issuer authenticates the holder, for example through eID login or a document scan, and checks whatever proof of eligibility it needs before minting the credential, then returns it signed in a format such as SD-JWT VC or mdoc. Two issuance modes exist: pre-authorised code flow, where the holder already went through an out-of-band process such as a bank branch visit and just needs to pull the resulting credential into the wallet, and authorization code flow, which mirrors ordinary OAuth2 login and lets the issuance happen entirely online in one session. A key-binding proof ties the credential to a specific key held only by that wallet instance, so a stolen credential file cannot be replayed from a different device. OpenID4VCI is the issuance protocol the EUDI Wallet reference implementation is built on under eIDAS 2.0, so an issuer that supports it can reach every EU wallet through one integration rather than a custom connector per member state or per wallet provider. The same protocol works equally well for a mobile driving licence, a university diploma, or a business registration extract, since the credential's content is opaque to the transport layer that delivers it. Verifiable Credential Does OpenID4VCI work the same way for every type of credential? Yes. OpenID4VCI is a transport and authorisation protocol, not a credential format, so the same flow issues an SD-JWT VC, an mdoc, or any other credential type an issuer supports. A wallet only needs to implement OpenID4VCI once to receive credentials from any issuer that speaks the same protocol, regardless of what the credential itself represents. Related terms Back to the glossary ### OpenID4VP - what it is and how it works https://www.credenco.com/glossary/openid4vp OpenID4VP, OpenID for Verifiable Presentations, is the protocol a wallet uses to present one or more credentials to a verifier in response to a request, so the verifier can check them without a separate integration per issuer. A relying party sends a presentation request describing what it needs to see, either as a redirect in a same-device flow or as a QR code the holder scans with their wallet in a cross-device flow, and the request can ask for a single claim or a full credential. The wallet parses the request, works out which stored credentials satisfy it using a query language such as DCQL, and asks the holder to approve which credentials and claims to share before anything leaves the device. The verifier then checks the response against the original issuer signatures and, where selective disclosure is used, confirms that only the disclosed claims were revealed while the rest stayed hidden without breaking the proof. OpenID4VP supports both online presentation, where the wallet talks directly to the relying party's backend, and proximity presentation over Bluetooth or NFC for in-person checks such as an age gate at a shop counter or a border crossing. OpenID4VP is the presentation protocol the EUDI Wallet uses under eIDAS 2.0, so any relying party that supports it can accept credentials from wallets issued anywhere in the EU without negotiating a bespoke integration with each national wallet provider. Because the holder approves every disclosure explicitly, a relying party never receives more data than it asked for, and the wallet keeps a record of what was shared and with whom. Verifiable Credential Relying party Verifier What stops a relying party from asking for more data than it needs through OpenID4VP? The wallet, not the relying party, decides what actually leaves the device. It shows the holder exactly which credentials and claims the request is asking for, and the holder approves or rejects that specific disclosure. A relying party can ask for anything, but nothing is shared unless the wallet holder consents to that request in the moment. Related terms Back to the glossary ### DID - what it is and how it works https://www.credenco.com/glossary/did A DID, or Decentralized Identifier, is a globally unique identifier that does not depend on a central registry. It lets issuers, holders and verifiers reference each other and resolve public keys without a central authority. A DID resolves to a small document listing the public keys and service endpoints its owner controls, so anyone can verify a signature made with that DID without asking a third party for permission. In the EUDI Wallet under eIDAS 2.0, DIDs commonly identify issuers and, in some credential formats, holders, giving every participant a stable, portable identifier that works the same way across every member state. Verifiable Credential EUDI Wallet Trust Framework did:web did:webvh Who controls a DID? The organisation or person the DID identifies, called its subject, controls it by holding the private key that matches the public key in the DID document. No registry or central authority can revoke or reassign a DID on its subject's behalf. Related terms Back to the glossary ### did:web - what it is and how it works https://www.credenco.com/glossary/did-web did:web is a DID method that resolves a DID document from a well-known HTTPS location on a domain its owner controls, so it can be published and updated using ordinary web infrastructure without a blockchain or distributed ledger. A did:web identifier such as did:web:example.com maps directly to a URL like https://example.com/.well-known/did.json, so any standard HTTPS client can fetch the DID document without running specialised resolver software. Trust in the DID depends entirely on control of the domain and its TLS certificate, and the DID document only reflects its current state: nothing in the method itself records or proves what the document looked like before the most recent edit, which is the gap did:webvh closes. DID did:webvh Trust Framework How is a did:web DID resolved? The DID method identifier and domain map directly to an HTTPS URL under that domain, typically /.well-known/did.json, and fetching that URL returns the DID document. No blockchain, ledger, or specialised network is involved, only ordinary web hosting and TLS. Related terms Back to the glossary ### did:webvh - what it is and how it works https://www.credenco.com/glossary/did-webvh did:webvh, DID Web with Verifiable History, is a successor to did:web that resolves the same way, from a DID document hosted on an HTTPS domain, but adds a hash-chained log of every prior version of the document, so a DID document can no longer be silently rewritten. Every update to a did:webvh document is appended to a verifiable history log, cryptographically chained to the entry before it, so anyone resolving the DID can check the full sequence of changes rather than trusting only the latest snapshot. The method also supports key pre-rotation, where the next signing key is committed to in advance so a future rotation cannot be forged even if the current key is later compromised, and witnesses, independent parties that co-sign updates to make it harder for a single compromised party to rewrite history unnoticed. DID did:web Trust Framework What does did:webvh add over did:web? did:webvh keeps the same HTTPS-hosted resolution as did:web but adds a tamper-evident, verifiable history log of every document version, plus key pre-rotation and witnesses, so past states of the DID document can be checked and a single point of compromise cannot rewrite history unnoticed. Related terms Back to the glossary ### Selective disclosure explained https://www.credenco.com/glossary/selective-disclosure Selective disclosure Selective disclosure is the ability to share only the specific attributes a verifier needs from a credential, for example proving you are over 18 without revealing your exact birth date. It works because a credential format such as SD-JWT hashes and salts each claim separately at issuance time, so a holder can leave any claim out of what they send while the remaining ones still check against the issuer's original signature. The wallet, not the issuer or the verifier, decides at presentation time which claims to reveal, which means the same credential can be reused across many different requests without ever exposing more than each one asks for. This differs from simply redacting a paper document or a PDF, where removing a field either breaks the signature or requires trusting whoever did the redacting: with selective disclosure, the verifier can mathematically confirm that the disclosed claims are genuine and untampered even though other claims from the same credential stay completely hidden. A common example is age verification, where a holder proves they are over 18 by disclosing only a predicate about their birth date rather than the date itself, or a company proving it is registered without revealing its full ownership structure. Selective disclosure is a core privacy requirement for the EUDI Wallet under eIDAS 2.0, which is built on the data minimisation principle from the EU's data protection rules and is designed to let citizens and businesses prove exactly what a relying party asks for and nothing more, reducing the amount of personal data that flows to relying parties and the risk if any single one is ever breached. SD-JWT VC Verifiable Credential Can selective disclosure be used with any digital credential? Only if the credential format was built to support it. A plain signed document reveals everything or nothing, because removing any part of it breaks the signature. Formats like SD-JWT sign each claim separately from the start, which is what lets a holder leave individual claims out later while the rest still verifies. Related terms Back to the glossary ### KYB - what it is and how it works https://www.credenco.com/glossary/kyb KYB, Know Your Business, is the set of checks an organisation performs to verify a business counterparty, such as its registration, UBOs and authorised representatives. Traditionally KYB means manually collecting and checking documents like a chamber of commerce extract for every new business relationship. With verifiable credentials, a business can hold a credential that already proves its registration or UBO structure and present only the facts a relying party asks for, so a counterparty can trust the result instantly instead of re-checking documents that go stale between checks. Verifiable Credential Relying party Is KYB the same as KYC? No. KYC checks the identity of an individual customer, while KYB checks a business as a counterparty, including who owns and represents it. A business relationship often needs both: KYB on the company and KYC on the individuals who act on its behalf. Related terms Back to the glossary ### Relying party - what it is and how it works https://www.credenco.com/glossary/relying-party Relying party A relying party is the organisation that requests a verifiable credential from a holder and relies on it to make a decision, such as a bank onboarding a new business or a shop checking a customer is old enough to buy an age-restricted product. A relying party sends a presentation request over a protocol such as OpenID4VP describing which credential and claims it needs, then checks the response cryptographically against the issuer that originally signed it before acting on the result, rather than calling the issuer or the holder to confirm anything by phone or email. Becoming a relying party does not require building a credential issuer or a wallet: it only requires the ability to send a request, verify a signature against a trust list, and interpret whatever claims come back, which is a much smaller integration than the issuer side of the same ecosystem. Trust in the credential's content rests on the issuer, but trust that the issuer itself is legitimate rests on the relying party checking the issuer against a national or EU-wide Trusted List before accepting anything it signed. Under eIDAS 2.0, every EU member state must ensure relying parties in regulated sectors such as banking, telecom, healthcare and transport can accept EUDI Wallet credentials, and relying parties above a certain size or in specific regulated industries are required to accept the wallet where a citizen offers one. Because the protocol and trust model are standardised across the Union, a relying party that integrates once can accept credentials from any wallet issued anywhere in the EU, whether the holder is an individual proving their age or a business proving it is registered, without a separate contract or technical connection to each issuer. Verifier Verifiable Credential Can any organisation become a relying party without becoming an issuer too? Yes, and most do. Verifying a credential only requires checking a signature against a published trust list and reading the disclosed claims, which is far simpler than the issuer's job of proving identity, managing keys, and maintaining revocation status. A bank checking a business credential and the government body that issued it can be entirely different organisations with entirely different technical footprints. Related terms Back to the glossary ### EUDI Wallet - what it is and how it works https://www.credenco.com/glossary/eudi-wallet EUDI Wallet The EUDI Wallet is the European Digital Identity Wallet mandated by eIDAS 2.0: a wallet app every EU member state must offer citizens and businesses for storing and presenting verifiable credentials, recognised across all 27 member states. Each member state issues or accredits its own EUDI Wallet app, but every implementation follows the same EU Architecture Reference Framework (ARF), so a credential issued in one country can be presented to a relying party in any other without a bilateral agreement between the two states. Alongside ordinary credentials such as a mobile driving licence, a diploma or a business registration extract, a EUDI Wallet holds a wallet attestation proving the wallet instance itself, its app and its hardware-backed key storage, meets the certification requirements set out in the ARF, which a relying party can check before trusting anything the wallet presents. The wallet must support both OpenID4VCI for pulling credentials in from issuers and OpenID4VP for presenting them to relying parties, plus qualified electronic signatures so a citizen can sign a document with the same legal weight as a handwritten signature. Member states are required to offer the wallet free of charge to every citizen and resident who wants one, and no relying party in a regulated sector may refuse a EUDI Wallet credential once eIDAS 2.0's transition period ends. Large online platforms designated under other EU digital rules must also accept EUDI Wallet credentials for identification where they already ask users to prove who they are, extending the wallet's reach beyond public services into everyday commercial life across the internal market. eIDAS 2.0 Wallet Attestation Digital Identity Wallet Organization Wallet Can a EUDI Wallet issued in one EU country be used in another? Yes. Every national EUDI Wallet implementation follows the same EU Architecture Reference Framework and the same issuance and presentation protocols, so a credential issued by one member state's wallet is recognised by relying parties anywhere else in the Union. That cross-border recognition, not just the app itself, is the core requirement eIDAS 2.0 places on member states. Related terms Back to the glossary ### eIDAS 2.0 - what it is and how it works https://www.credenco.com/glossary/eidas-2 eIDAS 2.0 is the revised European regulation on electronic identification and trust services. It mandates the EUDI Wallet and establishes the legal framework for verifiable credentials to carry legal validity across the European Union. eIDAS 2.0 defines the roles every EUDI Wallet ecosystem needs: issuers of qualified and non-qualified attestations, trust service providers listed on national Trusted Lists, wallet providers accredited by a member state, and relying parties that must accept wallet credentials in regulated sectors such as banking, telecom, healthcare and transport. It also introduces Qualified Electronic Attestations of Attributes (QEAA), which carry the same legal weight as a notarised paper document, so a business can rely on a digital credential such as proof of company registration or a professional qualification without a manual check or a phone call to confirm it. The regulation builds on the original 2014 eIDAS framework's qualified trust services, such as qualified electronic signatures and seals, but extends legal recognition to the new credential formats and wallet architecture the EUDI Wallet is built on. Every member state must notify its national eID schemes and Trusted Lists to the European Commission, which publishes a combined EU Trusted List so any relying party or wallet in the Union can verify who is authorised to issue what, without maintaining 27 separate lists of trusted issuers itself. eIDAS 2.0 also sets binding deadlines: member states must make a EUDI Wallet available to citizens, and large online platforms and relying parties in regulated sectors must accept it, once the regulation's transition period runs out, turning what started as a voluntary pilot programme into a legal obligation across the internal market. EUDI Wallet Trust Framework QEAA Does eIDAS 2.0 replace the original 2014 eIDAS regulation? No, it amends and extends it. The qualified trust services from the original regulation, such as qualified electronic signatures, seals and Trusted Lists, keep functioning as before. eIDAS 2.0 adds the EUDI Wallet, new attestation types like QEAA, and legal obligations on member states and relying parties on top of that existing foundation. Related terms Back to the glossary ### Trust Framework - what it is and how it works https://www.credenco.com/glossary/trust-framework Trust Framework A trust framework is the set of technical standards, legal rules and governance agreements that let issuers, holders and verifiers rely on each other’s credentials across organisations and borders, such as the framework eIDAS 2.0 establishes for the EU. In practice, a trust framework is anchored by Trusted Lists: national registries, published by each EU member state, of the qualified trust service providers and issuers authorised to operate under it. A verifier checks a credential's issuer against the relevant Trusted List rather than maintaining its own list of who to trust, so the same check works no matter which member state issued the credential. The framework also defines who may act as a relying party, what a Wallet Provider must guarantee about the wallets it issues, and how a member state registers itself so its Trusted List is recognised by the others. eIDAS 2.0 sets this out at EU level through the European Digital Identity Regulation, with the Architecture and Reference Framework filling in the technical detail: certification schemes for wallet solutions, the data formats credentials must use, and the interfaces issuers and verifiers implement to interoperate. Because the rules are shared rather than negotiated bilaterally, a credential issued in one member state can be verified in another without a prior agreement between the two parties involved, and a trust service provider that loses its authorisation is removed from the Trusted List, which immediately signals to every verifier that its credentials should no longer be accepted. This shared governance is what distinguishes a trust framework from a simple technical standard: the standard defines the message format, while the framework defines who is allowed to send it and what happens when that permission is withdrawn. eIDAS 2.0 Issuer Verifier Why can a credential from one EU country be trusted in another? Because every member state publishes its authorised issuers and trust service providers on a Trusted List under the same eIDAS 2.0 rules. A verifier in one country checks the issuer against the relevant Trusted List rather than negotiating trust bilaterally, so the same check works regardless of which member state actually issued the credential. Related terms Back to the glossary ### Wallet Attestation - what it is and how it works https://www.credenco.com/glossary/wallet-attestation Wallet Attestation A wallet attestation is a cryptographic proof, issued by a Wallet Provider, that a specific Wallet Unit meets the technical and security requirements of the EUDI Wallet ecosystem, such as running approved software and storing keys in a secure element. The ARF calls this a Wallet Unit Attestation (WUA). A WUA is presented alongside a credential, so a verifier can check not only who issued the credential but also that the wallet doing the presenting is a genuine, unmodified Wallet Unit rather than a spoofed client. The ARF defines two concrete subtypes: a Wallet Instance Attestation (WIA) covers the app itself, and a Key Attestation (KA) covers the cryptographic keys generated in the wallet's secure hardware. Together they are scoped to the wallet software and its keys, distinct from a verifiable credential, which makes a claim about the holder's identity or attributes. A Wallet Provider reissues the attestation periodically and can refuse to renew it once a device is found to be jailbroken, running an outdated wallet version, or otherwise no longer meeting the certification baseline, which is how compromised wallet instances get pushed out of the ecosystem without touching the credentials stored on them. Relying parties can require a fresh wallet attestation as part of a presentation request, and some deployments bind it cryptographically to the specific transaction so a captured attestation cannot be replayed in a different session. This layered check, credential plus wallet plus keys, is what lets a verifier trust a remote presentation to the same degree as an in-person document check, without a separate enrolment step for every relying party the wallet ever talks to. Wallet Unit Wallet Provider EUDI Wallet Trust Framework Verifiable Credential Does a wallet attestation replace the need to check the credential itself? No, it checks a different thing. The credential proves a claim about the holder, such as their age or qualification, while the wallet attestation proves the app presenting it is a genuine, unmodified Wallet Unit with keys held in secure hardware. A verifier normally checks both before trusting a presentation. Related terms Back to the glossary ### Issuer - what it is and how it works https://www.credenco.com/glossary/issuer Issuer An issuer is the organisation that creates and cryptographically signs a verifiable credential, for example a government agency, a bank, or a chamber of commerce, vouching for the claims it contains. An issuer hands a signed credential to a holder over a protocol such as OpenID4VCI, and never needs to be contacted again when that credential is later checked: a verifier validates the signature against the issuer's public key instead. Under eIDAS 2.0, an issuer of qualified attestations must be listed on a national Trusted List, so any verifier can confirm it is authorised without a separate agreement per issuer. Issuing is a distinct role from operating a wallet or a verifier system: an organisation can hold all three roles, but the technical and legal obligations differ for each. As an issuer, it is responsible for keeping its signing keys secure, publishing a revocation status list so verifiers can check whether a credential is still valid, and defining the schema of the credential, which claims it contains and in what format, typically SD-JWT VC or an ISO mdoc. Because verification does not require contacting the issuer at the time of use, an issuer can go offline, change its infrastructure, or even cease operating a given credential type, as long as its public key and status list remain published for the credentials it already issued to stay verifiable. This separation between issuance and verification is what lets a credential be checked instantly, anywhere, without the issuer being part of every transaction. Verifiable Credential Holder Trust Framework Does an issuer need to be online for a verifier to check a credential? No. A verifier checks the credential's signature against the issuer's published public key and looks up its revocation status list, neither of which requires contacting the issuer directly. This is why an issuer can be offline or even stop operating a credential type while credentials it already issued remain verifiable, as long as the key and status list stay published. Related terms Back to the glossary ### Holder - what it is and how it works https://www.credenco.com/glossary/holder Holder A holder is the person or organisation that receives a verifiable credential, stores it in a wallet, and decides when and with whom to share it. The holder is not necessarily the subject the credential is about. A holder controls a credential rather than owning the facts it describes: a company may hold a credential about one of its employees, or a parent may hold one on behalf of a child. When a relying party asks for proof, the holder decides which credential to present and, with selective disclosure, exactly which claims inside it to reveal. The holder role is what the EUDI Wallet is built around: the wallet software runs on the holder's device, stores the credential locally rather than in a central database, and prompts the holder to review and approve each presentation request before anything is sent. This puts the holder in a position no paper document allows, being able to disclose a single fact, such as being over eighteen, without revealing the birth date, address or any other claim on the same credential. A holder can also collect multiple credentials from different issuers into one wallet and combine them in a single presentation, for example proving both a professional qualification and a company registration in one interaction with a relying party. Because control sits with the holder rather than the issuer or verifier, losing access to the device or wallet, not the credential's content, is what typically triggers reissuance. The distinction between holder and subject matters most for credentials issued about a minor, an animal or an asset, where the person controlling the wallet and the party the claims describe are simply not the same entity. Issuer Verifier Selective disclosure Is the holder always the person the credential is about? No. A holder is whoever controls the wallet and decides when to present a credential, which is not always the subject of its claims. A company can hold an employee's professional credential, or a parent can hold one issued about a child, so the holder and the subject are frequently two different parties. Related terms Back to the glossary ### Verifier - what it is and how it works https://www.credenco.com/glossary/verifier Verifier A verifier is the party that checks a presented credential: validating the issuer's signature, confirming the credential has not been revoked, and reading only the claims the holder chose to disclose. A verifier is often the same organisation as the relying party requesting the credential, but the roles are distinct: the relying party decides what to ask for and what to do with the result, while the verifier is the technical function that checks the signature, the Trusted List entry of the issuer, and the revocation status before that result can be trusted. In an OpenID4VP exchange, a verifier sends a presentation request describing which credential and claims it needs, receives the holder's response, and then runs three checks before accepting it: that the signature matches the issuer's published key, that the issuer appears on the relevant Trusted List for the credential type presented, and that the credential has not since been revoked according to its status list. Only after all three pass does the verifier hand a trusted result back to the relying party, for example confirming that a person is over eighteen or holds a valid professional qualification, without ever seeing claims the holder did not choose to disclose. Because verification is a well-defined, repeatable check rather than a judgement call, the same verifier logic can serve many different relying parties and credential types, which is why organisations often buy verification as a service rather than building it once per use case. A poorly implemented verifier, one that skips the Trusted List check or caches revocation status too long, is a common source of trust framework failures even when the credential and the issuer are both entirely legitimate. Holder Issuer Revocation Is a verifier the same thing as a relying party? Not exactly. The relying party is the organisation deciding what to ask for and what to do with the result, such as granting access after an age check. The verifier is the technical function performing that check: validating the signature, the issuer's Trusted List entry, and revocation status. The same organisation often plays both roles. Related terms Back to the glossary ### Presentation Exchange explained https://www.credenco.com/glossary/presentation-exchange Presentation Exchange Presentation Exchange is the specification a relying party uses to describe, in a machine-readable way, exactly which credentials and claims it needs from a holder, so a wallet can automatically match the request against the credentials it holds. A presentation definition lists the credential types and fields a relying party accepts as proof, for example "a credential proving the holder is over 18, issued by a Trusted List member". The wallet evaluates that definition against the credentials in the holder's wallet, shows the holder which ones match, and lets them approve exactly what gets shared. OpenID4VP has historically carried presentation exchange requests between a relying party and a wallet. The specification, published by the Decentralized Identity Foundation, supports constraints beyond a simple credential type match: a relying party can require a specific claim value, restrict which issuers it accepts, or ask for one credential from a set of acceptable alternatives, and can mark some requested items as optional rather than mandatory. This lets a single request cover several acceptable ways of proving the same fact, for example either a driving licence or a national ID card for an age check, instead of forcing the relying party to issue separate requests per credential type. The OpenID4VP working group has more recently moved toward the newer, more compact Digital Credentials Query Language (DCQL) for expressing the same kind of request, with Presentation Exchange remaining in use for backward compatibility in existing deployments. Either way, the underlying idea stays the same: the relying party states its requirements once, in a format wallets can parse without human intervention, so the holder is asked to approve a concrete match rather than to interpret free-text instructions about what to hand over. OpenID4VP Relying party Verifiable Presentation Is Presentation Exchange still the current way to request a credential? It is being superseded. The OpenID4VP working group has moved toward the newer, more compact Digital Credentials Query Language (DCQL) for describing what a relying party needs, but Presentation Exchange remains in use in existing deployments for backward compatibility, so wallets and verifiers often support both formats side by side. Related terms Back to the glossary ### Revocation - what it is and how it works https://www.credenco.com/glossary/revocation Revocation Revocation is the mechanism an issuer uses to invalidate a credential after it was issued, for example when a qualification expires or a registration is withdrawn, so verifiers checking it afterwards see it as no longer valid. Most issuers publish revocation state as a status list: a single compact bitstring where each credential is assigned one bit, published and signed by the issuer so anyone can look up a credential's status without contacting the issuer for every check or exposing which specific credential was checked. A verifier fetches the status list once, checks the relevant bit, and rejects a presentation if the credential has been marked revoked. The IETF Token Status List specification, which builds on the earlier W3C Bitstring Status List work, standardises this format so a status list issued for an SD-JWT VC credential can be checked the same way regardless of which issuer or wallet produced it. Because the whole list is fetched rather than a single lookup, a verifier cannot tell from the network request which specific credential was being checked, which is what keeps the revocation check itself from leaking the holder's activity to the issuer. Status lists are typically refreshed on a short cache interval, a few minutes to a few hours, so a revoked credential stops verifying quickly without requiring the issuer to be contacted at the moment of every presentation. Revocation is distinct from expiry: an expired credential simply carries a validity date that has passed, while a revoked credential is actively marked invalid before its natural expiry, usually because the fact it attested to has changed. Issuer Verifier Verifiable Credential Is a revoked credential the same as an expired one? No. An expired credential has simply passed the validity date it was issued with. A revoked credential is actively marked invalid before that date, usually because the underlying fact changed, such as a licence being withdrawn. The issuer signals revocation through a status list that verifiers check on every presentation. Related terms Back to the glossary ### mDL / ISO 18013-5 - what it is and how it works https://www.credenco.com/glossary/mdl An mDL, or mobile driving licence, is a driving licence stored and presented from a smartphone, built to the ISO/IEC 18013-5 standard so any conforming reader can accept it regardless of who issued it. ISO 18013-5 defines two ways to present an mDL: offline over Bluetooth, NFC or a QR code straight to a nearby reader such as a car rental kiosk, and online over the internet to a remote relying party, both using end-to-end session encryption so the holder controls exactly which fields are shared. The EUDI Wallet uses the same standard for its driving licence credential, so an mDL issued as part of a EUDI Wallet works with any reader already deployed for ISO 18013-5. The credential itself, called an mdoc, is a set of namespaced data elements such as name, date of birth, licence category and expiry date, each individually signed inside a mobile security object, so a reader can request and verify only the fields it needs, for example just an over-18 flag at a shop till rather than the full record. Presentation starts with device engagement: the phone shows a QR code or exchanges a short message over NFC or Bluetooth Low Energy to agree session keys before any data element crosses the connection, and the request itself carries the reader's certificate so the holder can see who is asking and for what before approving it. A companion specification, ISO 18013-7, extends the same mdoc format to unattended online verification, letting a website request an mDL over the internet through an OpenID4VP profile instead of a physical reader, using the identical data model and security object as the offline path. mDL adoption has moved fastest in the United States, and it is the reference format the EUDI Wallet's own driving licence attestation now follows in Europe. Verifiable Credential EUDI Wallet Verifier Can an mDL be used outside the country that issued it? Yes, provided the reader also implements ISO 18013-5. The standard defines a common data format and presentation protocol independent of who issued the credential, so a rental car kiosk or border checkpoint built to the standard can read an mDL from any conforming issuer, the same cross-border interoperability the EUDI Wallet relies on for its own driving licence credential across every member state. Related terms Back to the glossary ### Zero-Knowledge Proof explained https://www.credenco.com/glossary/zero-knowledge-proof Zero-Knowledge Proof A zero-knowledge proof is a cryptographic method for proving that a statement is true, such as "the holder is over 18", without revealing any of the underlying data the statement is based on, such as the actual birth date. Where selective disclosure lets a holder reveal chosen claims as-is, a zero-knowledge proof reveals nothing at all: the verifier learns only that the statement holds, backed by a proof it can check against the issuer's signature. This is a stronger privacy guarantee than selective disclosure, and an active area of standardisation for future credential formats used in the EUDI Wallet ecosystem. The proof is built so that anyone can check it against public parameters and the issuer's signature, yet no combination of proofs handed to different verifiers can be linked back to the same credential or to each other, which removes the correlation risk that comes from repeatedly showing the same signed value. A simple selective-disclosure credential still lets two colluding verifiers compare a hashed claim and conclude the same holder visited both, while a zero-knowledge proof of the identical statement looks different every time it is generated. The trade-off is computational cost and complexity: generating and verifying a zero-knowledge proof takes more processing power than checking a plain signature, and the cryptographic schemes involved, such as BBS+ signatures or zk-SNARKs, are newer and less standardised than the hash-based selective disclosure already deployed in SD-JWT. Several EUDI Wallet reference implementations and pilots are evaluating zero-knowledge techniques as a future upgrade path for attributes where unlinkability matters most, such as age or nationality checks repeated across many unrelated services. Selective disclosure Verifiable Credential KYC Does using a zero-knowledge proof mean the verifier has to trust the holder blindly? No. The verifier still relies on cryptography rather than trust in the holder. The proof mathematically ties the statement to the issuer's original signature, so a verifier can be certain a claim is genuine and unaltered even though it never sees the underlying data, the same assurance a normal signature check gives, just without exposing the value behind it. Related terms Back to the glossary ### KYC - what it is and how it works https://www.credenco.com/glossary/kyc KYC, Know Your Customer, is the checks an organisation performs to verify a customer's identity before starting or continuing a business relationship with them. Traditionally KYC means a customer submits identity documents that a compliance team checks manually, every time they onboard with a new organisation. With verifiable credentials, a customer can reuse an identity check already performed elsewhere, presenting a credential the new organisation can verify instantly instead of repeating the same document checks. Verifiable Credential Zero-Knowledge Proof Is KYC the same as KYB? No. KYC checks the identity of an individual, while KYB checks a business as a counterparty, including who owns and represents it. A business relationship often needs both: KYC on the individuals acting on a company's behalf and KYB on the company itself. Related terms Back to the glossary ### QEAA - what it is and how it works https://www.credenco.com/glossary/qeaa A QEAA, Qualified Electronic Attestation of Attributes, is the qualified variant of an EAA: a verifiable credential issued by a qualified trust service provider under eIDAS 2.0, carrying the same legal weight as a notarised or certified paper document. Any organisation can issue an EAA, an electronic attestation of attributes, but only one issued by a provider listed as qualified on a national Trusted List is a QEAA, and only a QEAA benefits from the legal presumption of accuracy eIDAS 2.0 grants it: a relying party can accept it as proof without further checks, the same way it would accept a notarised extract today. A lower-assurance, non-qualified EAA still carries useful evidence value, but without that legal presumption. To issue a QEAA, a provider must be audited and certified as a qualified trust service provider, meet the same supervisory and liability requirements as providers of qualified electronic signatures and seals, and be published on its member state's Trusted List so any relying party across the EU can verify the issuer's qualified status before accepting the attestation. Common QEAA use cases include professional qualifications, academic diplomas, company registration data and authority-to-represent attestations, all cases where the receiving party would otherwise need to contact a registry or notary directly. Because a QEAA carries the eIDAS 2.0 legal presumption, disputing its accuracy shifts the burden of proof to the party challenging it rather than the party relying on it, which is the same reversal of burden a wet-ink notarised document enjoys today, now available for an entirely electronic credential presented through a EUDI Wallet. EAA eIDAS 2.0 Trust Framework Verifiable Credential Who is allowed to issue a QEAA? Only a qualified trust service provider, audited and certified against eIDAS 2.0's supervisory requirements and published on its member state's Trusted List. Any organisation can issue an ordinary, non-qualified EAA, but the legal presumption of accuracy that lets a relying party accept the attestation without further checks only attaches to attestations from a provider holding that qualified status. Related terms Back to the glossary ### Verifiable Presentation explained https://www.credenco.com/glossary/verifiable-presentation Verifiable Presentation A verifiable presentation is the tamper-evident package a holder assembles from one or more verifiable credentials to share with a verifier in response to a specific request, rather than handing over a whole credential. A verifiable presentation can combine claims from several different credentials into a single response, and is bound to the holder presenting it with its own signature, so a verifier can confirm the person presenting it is the one it was issued to. It is what a wallet actually sends over OpenID4VP: a purpose-built response to one request, not a copy of the underlying credentials themselves. The verifier first states what it needs, typically as a presentation definition listing the credential types and specific claims it will accept, and the wallet matches that request against the credentials the holder already holds before assembling a presentation that answers it exactly, nothing more. This request-response shape is what keeps a presentation minimal: a rental company asking only for an over-18 flag and a licence category receives a presentation containing just those two facts, combined from the underlying mDL, rather than the full credential with every field it carries. The holder-binding signature is what stops a presentation from being replayed by someone else: even a copied, valid credential is useless without the private key tied to the original holder, since that key has to sign the presentation itself at the moment it is created. Presentations are typically short-lived and single-use, generated fresh for each request rather than cached and reused, which limits how much a verifier can correlate across separate interactions with the same holder. Verifiable Credential OpenID4VP Presentation Exchange Does a verifiable presentation reveal the whole underlying credential to the verifier? No. A wallet can build a presentation that includes only the specific claims a verifier requested, combined from one or more credentials, rather than handing over the whole credential each claim came from. A car rental kiosk asking for an over-18 flag and a licence category, for example, receives just those two facts, not the holder's full date of birth or address. Related terms Back to the glossary ### Digital Identity Wallet explained https://www.credenco.com/glossary/digital-identity-wallet Digital Identity Wallet A digital identity wallet is an app that lets its holder store credentials and attributes about themselves or their organisation, and choose exactly what to share with a relying party, keeping the holder in control instead of a central registry. Digital identity wallet is the general category; the EUDI Wallet is the European Union's specific, regulated implementation of it, mandated for every member state under eIDAS 2.0. Wallets from other jurisdictions or private vendors follow the same holder-controlled model but different technical and legal rules, so a credential built for one wallet ecosystem does not automatically work in another unless both implement a shared standard such as OpenID4VCI or ISO 18013-5. A digital identity wallet typically performs three functions: it receives credentials from an issuer over a protocol such as OpenID4VCI, stores them locally on the device rather than in a provider's cloud, and presents them to a verifier over OpenID4VP or an equivalent protocol, disclosing only the attributes that request asks for. Which functions a given wallet exposes and how strongly it protects the private keys behind each credential depend on the wallet solution and the assurance level it targets, from a simple personal app to a wallet built for regulatory compliance and audited key storage. The distinction between a personal digital identity wallet and an organization wallet is in who the holder represents: a person storing their own attributes, or a company holding credentials about itself and acting through employees it authorises. Both rely on the same underlying wallet architecture, credential formats and presentation protocols, just configured for a different kind of holder. EUDI Wallet Verifiable Credential Holder Organization Wallet Is a digital identity wallet the same thing as the EUDI Wallet? Not quite. Digital identity wallet is the general category of holder-controlled apps that store and present credentials. The EUDI Wallet is one specific, regulated implementation of that category, mandated for every EU member state under eIDAS 2.0. Other digital identity wallets exist outside the EU, built by other jurisdictions or private vendors, following the same model under different rules. Related terms Back to the glossary ### W3C VC - what it is and how it works https://www.credenco.com/glossary/w3c-vc W3C VC is the Verifiable Credentials Data Model, the World Wide Web Consortium's open standard for how a verifiable credential is structured: which claims it carries, who issued it, about whom, and how its cryptographic proof is attached. The data model is deliberately format-agnostic. It fixes the shape of a credential, meaning the issuer, the subject, the claims, the validity period and the status information, while leaving the choice of proof mechanism open, so the same credential can be secured with a Data Integrity proof or enveloped in a JOSE or COSE signature. That separation is what lets a wallet built for one ecosystem read a credential issued in another: the meaning of the data does not change when the signature format does. It is the vocabulary most other specifications in this space build on, including the presentation and issuance protocols a wallet actually speaks. Version 2.0 of the data model added explicit support for status mechanisms such as a revocation bitstring, defined how a credential can be extended with vendor-specific vocabularies without breaking interoperability, and clarified how a verifiable presentation is derived from one or more credentials to answer a specific request. W3C VC credentials typically travel as JSON-LD, giving each field a globally unambiguous meaning through linked-data contexts rather than a locally defined schema, which matters when credentials issued in one country need to be understood correctly by a verifier in another without prior agreement between the two. In practice, a W3C VC credential is often the payload carried by a higher-level exchange protocol such as OpenID4VCI for issuance or OpenID4VP for presentation, which handle the transport and session mechanics that the data model itself deliberately leaves out. Verifiable Credential Verifiable Presentation DID SD-JWT Does a W3C VC credential dictate which signature format must be used? No. The data model fixes the shape of a credential, its issuer, subject, claims and status information, but deliberately leaves the proof mechanism open. The same credential can be secured with a Data Integrity proof or enveloped in a JOSE or COSE signature, which is what lets wallets and verifiers built for different signature choices still agree on what the credential actually says. Related terms Back to the glossary ### European Business Wallet explained https://www.credenco.com/glossary/european-business-wallet A European Business Wallet is a cloud-based identity wallet for organisations: it lets a company issue, hold and present verifiable credentials about itself, from its registration and tax identifiers to its certifications and the people authorised to act for it, so counterparties anywhere in the EU can trust them instantly instead of re-checking documents. A business wallet differs from a personal one in where it runs and who acts through it. It lives on a server rather than a phone, because an organisation has no single device and its processes are automated: credentials are requested, presented and checked by systems, at volume, without someone tapping a screen. It is also rarely only a holder: the same organisation typically issues credentials to its own customers, suppliers and employees while verifying those it receives. That is what makes KYB checks that take days today resolvable in a single exchange. Credenco's Business Wallet is an implementation of this concept. Access control is a bigger concern for a business wallet than for a personal one, since several employees may need to act on the organisation's behalf, each with a different scope: one person authorised to sign contracts, another only to view credentials, a third to manage the wallet's own settings. That authority itself is typically expressed as a credential, an attestation that a named individual may act for the company within defined limits, so a counterparty can verify not just who the organisation is but whether the specific person presenting a credential is actually entitled to represent it. Because a business wallet often holds credentials with real commercial consequences, such as authority to sign or a certification that gates access to a regulated market, its key management and audit trail typically need to meet a higher assurance bar than a personal wallet used mainly for identity and age checks. EUDI Wallet Digital Identity Wallet KYB Issuer Can a European Business Wallet issue credentials as well as hold them? Yes, and most business wallets do both. The same organisation that holds credentials about itself, such as registration data or certifications, typically also issues credentials to its own customers, suppliers and employees, and verifies credentials it receives from counterparties. That three-sided role, issuer, holder and verifier at once, is what distinguishes a business wallet from a personal wallet, which is usually only a holder. Related terms Back to the glossary ### PID - what it is and how it works https://www.credenco.com/glossary/pid PID, Person Identification Data, is the government-issued identity credential at the core of every EUDI Wallet: the set of attributes, such as name, date of birth and a unique identifier, that a member state issues to a citizen as the anchor for everything else in the wallet. PID is issued by a PID Provider designated by a member state, after an identity check at the highest level of assurance that state offers, which is why other parties can build on it: an attestation about a diploma or a professional registration means little unless the person presenting it is the person it was issued to, and PID is what establishes that. The ARF Annex 3.01 fixes the minimum attribute set: family name, given name, birth date, and a unique and persistent identifier assigned by the issuing member state, with nationality and other attributes optional depending on the national scheme. In use it is presented selectively like any other credential: a verifier asking only whether the holder is over 18 receives that answer and not the date of birth behind it. The ARF specifies PID in both the SD-JWT VC and the ISO mdoc format, so a wallet can present it to readers built for either. Because PID sits at the root of trust for the whole wallet, most member states expect a citizen to hold one valid PID at a time, reissued when it expires or the underlying registry data changes, and revoked through the same status list mechanism used for other attestations. Many other credentials the wallet can hold, such as a qualified electronic attestation of attributes about a professional qualification, are only issued once the requesting party has confirmed the applicant's PID, so a weak or forged PID would undermine every attestation built on top of it. That is why PID issuance stays with a small number of designated providers rather than the open registration model relying parties use. EUDI Wallet ARF Level of Assurance Selective Disclosure Can a citizen hold more than one PID at the same time? Not normally. Because every other credential in the wallet, from a driving licence to a professional attestation, can rely on PID as proof the wallet belongs to a specific person, member states expect one valid PID per citizen. It is reissued when it expires or when the underlying registry data changes, and old copies are revoked so only the current one remains usable. Related terms Back to the glossary ### ARF - what it is and how it works https://www.credenco.com/glossary/arf The ARF, the Architecture and Reference Framework, is the technical specification of the EUDI Wallet ecosystem: it turns what eIDAS 2.0 requires in law into the concrete roles, credential formats, protocols and trust infrastructure that implementers have to build. It is maintained by the European Commission together with the member states through the eIDAS Expert Group and published in versioned releases, each accompanied by a set of technical specifications and annexes covering individual topics such as the PID rulebook, trust and revocation, or the wallet's cryptographic requirements. The ARF is what settles the questions a regulation deliberately leaves open at the level of detail implementers need: that a wallet uses OpenID4VCI to receive credentials and OpenID4VP to present them, that PID and attestations come in SD-JWT VC and ISO mdoc format, how a wallet proves to an issuer or verifier that it is genuine, and how registered issuers and relying parties are published in national registries so the other side can check them before trusting a credential. It is developed in the open on GitHub, where member states, industry and the large-scale pilots such as Potential and DC4EU raise issues and propose changes before a release is finalised, which is why the document keeps evolving as those pilots surface gaps the text did not anticipate. Anyone building for the EUDI Wallet reads the ARF rather than the regulation or its implementing acts for these details, since the acts set the legal obligation while the ARF fixes the interoperable way of meeting it. A wallet, issuer or verifier that only satisfies the regulation without following the ARF's technical choices would not interoperate with the rest of the ecosystem, even if it were legally compliant. EUDI Wallet eIDAS 2.0 Trust Framework PID How often does the ARF change? The ARF is released in versioned updates as the European Commission, member states and large-scale pilots such as Potential and DC4EU surface gaps or ambiguities while building real implementations. Each release also ships technical specifications and annexes for its own topics. Development happens in the open on GitHub, so implementers can track proposed changes and raise issues before a version is finalised, rather than building against a document that never gets corrected. Related terms Back to the glossary ### Status List - what it is and how it works https://www.credenco.com/glossary/status-list A status list is a compact, signed list an issuer publishes so that anyone holding one of its credentials can be checked for revocation without the issuer being asked about that credential specifically. The list is a bitstring: every credential the issuer hands out is assigned an index in it, and the bit at that index says whether the credential is still valid, revoked or suspended. Token Status List reserves one or two bits per entry depending on how many states the issuer needs to distinguish, since suspended is a separate, reversible state from a permanent revocation. The credential carries the URL of the list and its own index, so a verifier fetches the list once, caches it for a period the issuer sets, and reads a single bit for every check afterwards rather than calling the issuer each time. Because the whole list is downloaded at once and covers every credential the issuer has ever handed out, the issuer never learns which credential was looked at or by whom, since the herd hides the individual: this is the privacy property that makes status lists preferable to per-credential revocation checks, which would let an issuer track exactly when and how often a given credential is used. Compressed, a list covering hundreds of thousands of credentials is a few kilobytes, and lists are typically re-published on a fixed schedule or a content delivery network so a verifier's cached copy stays current without a round trip to the issuer for most checks. The two specifications in use are Token Status List for JWT and CWT credentials, which the EUDI ARF adopts for SD-JWT VC and mdoc attestations, and Bitstring Status List for the W3C verifiable credentials data model. An issuer that instead wants to avoid revocation checks altogether can issue short-lived credentials that simply expire, but status lists remain the mechanism of choice wherever a credential needs a longer validity period. Revocation Issuer Verifier SD-JWT Can a verifier tell which credential someone is checking by watching status list requests? No, that is the point of downloading the whole list. Because a verifier fetches the entire bitstring covering every credential the issuer has ever issued, rather than asking about one specific credential, the issuer cannot tell which entry the verifier cares about. The individual check is hidden inside a large batch of unrelated entries, which is what keeps status checking from turning into a way to track credential use. Related terms Back to the glossary ### mdoc - what it is and how it works https://www.credenco.com/glossary/mdoc An mdoc is a mobile document in the ISO/IEC 18013-5 format: a credential held on a phone as compact, issuer-signed data elements that a reader can verify on the spot, including when neither side has a network connection. The format grew out of the mobile driving licence, ISO/IEC 18013-5's original use case, and was then generalised so an mdoc can carry any set of attributes, not only licence data. Its data elements are encoded in CBOR and covered by a Mobile Security Object, a COSE-signed structure listing a salted hash for every element: the issuer signs those hashes rather than the values themselves, which is what lets the holder release individual attributes and no more without invalidating the signature over the rest. The credential is bound to a private key held on the device, so during presentation the reader can tell the holder is presenting it live rather than replaying a copy someone else captured earlier. In person, the exchange starts when the holder shows a QR code or taps an NFC tag containing a device engagement message, after which the actual attributes move over Bluetooth Low Energy directly between the two devices with no server involved. ISO/IEC 18013-7 extends the same credential to online use, where a website relies on the same COSE-signed data instead of a fresh in-person Bluetooth session. The EUDI ARF names mdoc alongside SD-JWT VC as a format every wallet, issuer and verifier must be able to handle, so the two formats coexist rather than one replacing the other, and a wallet typically holds both an mdoc and an SD-JWT VC copy of the same PID or attestation to work with readers built for either. mDL SD-JWT SD-JWT VC Selective Disclosure ARF Does presenting an mdoc always require an internet connection? No. In person, an mdoc reader and a holder's device exchange data directly over Bluetooth Low Energy or NFC after the holder shows a QR code or taps the reader, with no server or network involved. ISO/IEC 18013-7 adds an online variant for website use, but the original in-person flow, the mobile driving licence's core use case, was designed specifically to work with both devices offline. Related terms Back to the glossary ### Credential Offer - what it is and how it works https://www.credenco.com/glossary/credential-offer A Credential Offer is the message an issuer sends to a wallet to start issuance under OpenID4VCI: it names the issuer, says which credentials are on offer, and tells the wallet how it is allowed to collect them. In practice the offer is what sits behind the QR code on an issuance page or the link in an email or app. It can be delivered by value, embedded directly in an openid-credential-offer:// deep link or QR payload, or by reference, as a URL the wallet fetches to retrieve the same content, which keeps the code short when the offer names several credentials or carries a long issuer state. Scanning or opening it hands the wallet the issuer's URL and one or more credential configuration identifiers, plus a grant that decides the rest of the flow: an authorization code grant sends the holder through the issuer's own login first, useful when the offer was generated on a different device to the one completing the flow, while a pre-authorized code grant is used when the holder was already authenticated where the offer was created, for example right after logging into a government portal, optionally protected by a transaction code shown on that same channel so a code intercepted in transit cannot be redeemed by someone else. From there the wallet reads the issuer's metadata to learn what the named credentials actually contain, exchanges the grant for an access token at the issuer's token endpoint, and calls the credential endpoint to collect what was offered, one credential or a batch at a time depending on what the issuer supports. OpenID4VCI Issuer Holder Verifiable Credential Why do some Credential Offers ask for a transaction code and others do not? A transaction code is required whenever the offer uses a pre-authorized code grant, since the holder was already authenticated on another channel and the code proves the person scanning the offer is the same person that channel authenticated. An authorization code grant instead sends the holder through the issuer's own login as part of the flow, so there is no separate channel to bind and no code needed. Related terms Back to the glossary ### Level of Assurance - what it is and how it works https://www.credenco.com/glossary/level-of-assurance Level of assurance, often shortened to LoA, is how much confidence a relying party can place in a claimed identity. eIDAS defines three: low, substantial and high. The level is set by two things: how thoroughly the person was identified when the credential was first issued, and how well the credential is protected and bound to them afterwards. Commission Implementing Regulation (EU) 2015/1502 sets the technical criteria across four areas: enrolment, the electronic identification means itself, how the holder authenticates with it, and how the issuing body manages and audits the whole process. Low covers a self-asserted registration with little or no verification of the claimed identity; substantial requires evidence that the identity is genuine, typically checked against a document or registry, and a login that uses more than one factor; high additionally requires that the identity was checked against an authoritative source, in person or by an equivalent remote procedure with comparable assurance, and that the credential sits in tamper-resistant hardware such as a secure element. It matters because it decides what a credential may be used for: member states must recognise each other's notified eID schemes at substantial or high for access to public services across borders under the original 2014 eIDAS Regulation, and eIDAS 2.0 requires the EUDI Wallet itself to be issued at high, since PID is the anchor every other attestation in the wallet builds on. A relying party outside the public sector is not bound by the same recognition duty and can ask for whatever level its own risk requires: a service checking only that a customer is over 18 may accept a lower level or a single attribute, while one running anti-money-laundering onboarding will insist on high because the legal consequence of getting the identity wrong is far greater. eIDAS 2.0 EUDI Wallet Trust Framework PID Can a relying party outside government require a higher level of assurance than eIDAS mandates? Yes. eIDAS sets a floor: public services must accept notified schemes at substantial or high, and the EUDI Wallet must be issued at high. A private relying party is free to ask for whatever level its own risk demands, accepting a lower level for something like age verification while requiring high, with matching evidence, for anti-money-laundering onboarding or opening a financial account. Related terms Back to the glossary ### QES - what it is and how it works https://www.credenco.com/glossary/qes A QES, a qualified electronic signature, is the only kind of electronic signature that eIDAS gives the same legal effect as a handwritten one, in every member state and regardless of where it was created. Two things make a signature qualified. It has to be created with a qualified signature creation device, hardware or a certified remote service that keeps the signing key out of everyone’s reach including the provider’s, and it has to be based on a qualified certificate issued by a trust service provider listed as qualified on a national Trusted List. A signature that misses either is still valid evidence as an advanced or simple electronic signature, but a court weighs it rather than being obliged to accept it the way Article 25 of eIDAS obliges it to accept a QES. Because the qualified certificate is checked against a Trusted List published by every member state and cross-checked at EU level, a QES created in one country carries the same legal weight when presented in another, which is the cross-border recognition eIDAS was built to guarantee. Most QES today are created remotely: the signer authenticates to a qualified trust service provider's cloud signing service rather than owning dedicated signing hardware, and the provider triggers the signature on a device it controls under the signer's sole authorisation. The signed document itself typically uses one of the PAdES, XAdES or CAdES formats, which embed the certificate and, where long-term validity matters, a timestamp so the signature can still be verified after the certificate has expired. eIDAS 2.0 puts qualified signing in reach of ordinary users by requiring the EUDI Wallet to let a citizen create a QES free of charge for non-professional use, turning a service previously bought from a trust service provider into a wallet feature. A QES signs a document to bind a person to its content; a QEAA instead attests attributes about a person or organisation. Both come from qualified trust service providers, but they answer different questions and are not interchangeable. QEAA eIDAS 2.0 EUDI Wallet Trust Framework Does a QES created in one EU country need to be re-verified to be accepted in another? No. A QES relies on a qualified certificate checked against the issuing member state's Trusted List, and Trusted Lists themselves are cross-checked at EU level, so a verifier in another member state can confirm the certificate's status without a separate national process. This mutual recognition, guaranteed by Article 25 of eIDAS, is what makes a QES usable across borders without extra legal steps. Related terms Back to the glossary ### FIDES - what it is and how it works https://www.credenco.com/glossary/fides FIDES, in full FIDES - Accelerating Digital Trust, is a European community of organisations working on digital trust in practice: it catalogues what is actually running on verifiable credentials, and publishes the interoperability profiles that let those implementations talk to each other. Its most visible parts are the Ecosystem Explorer, a public catalogue of live digital identity use cases and the wallets behind them; the Blue Pages, a decentralised catalogue in which organisations and the credentials they accept can be looked up; and the Community Awards, voted on with a credential in a wallet rather than an account and a password. FIDES also maintains DIIP, the interoperability profile that pins down which existing specifications a conformant wallet has to implement. Alongside it, FIDES Labs is a Dutch initiative where public and private parties run pragmatic pilots, among them the e-invoicing and tax-splitting pilots Credenco works on with the Belastingdienst. Membership is open to any organisation willing to contribute, and most of its output, the Ecosystem Explorer entries, the Blue Pages listings and the DIIP specification text itself, is published openly rather than kept behind a paywall or a member-only portal. Work happens in focused working groups that report back to a plenary community meeting, which keeps DIIP's twice-yearly release cycle grounded in what implementers are actually running into rather than in theory. FIDES sits alongside, not inside, the WE BUILD consortium: WE BUILD builds the EU Digital Identity Wallet for business under public funding, while FIDES is the wider community where implementers, including several WE BUILD participants, compare notes and align on the profiles that make their separate wallets interoperate in practice. Trust Framework Verifiable Credential European Business Wallet WE BUILD Is FIDES a European Union body? No. FIDES is an independent, non-profit community of organisations working on digital trust, not an EU institution. It runs alongside official EU work such as WE BUILD and the ARF, contributing tools like the Ecosystem Explorer, the Blue Pages and the DIIP interoperability profile that implementers use in practice, but its work is driven by voluntary member contribution rather than by legislative mandate. Related terms Back to the glossary ### WE BUILD - what it is and how it works https://www.credenco.com/glossary/we-build WE BUILD is a European consortium building the infrastructure for a fully interoperable EU Digital Identity Wallet for businesses, bringing together more than 350 participants from over 180 organisations across 30 countries. The consortium works through use cases rather than specifications alone: thirteen of them, including cross-border company registration, creating a company branch in another member state, supplier onboarding and fraud prevention, which are the procurement and compliance problems organisations run into every day. Its Interoperability Test Bed is where that work is checked: wallets, issuers and verifiers are tested against the protocols and profiles the ecosystem will run on, OpenID4VCI, OpenID4VP and the EUDI Wallet standards, so an implementation that passes works with the others rather than only with itself. Credenco contributes as a beneficiary partner in the work package on wallets for business, and its Business Wallet has cleared every test case of the test bed. WE BUILD is funded through the Digital Europe Programme as one of four Large Scale Pilots that ran alongside the EUDI Wallet reference implementation between 2023 and 2026, the others covering government services, health and payments, and each pilot fed real-world findings back into the Architecture and Reference Framework rather than working from it in isolation. Results are shared with the European Commission and the member states running national wallet pilots, so a business-wallet requirement discovered in a WE BUILD use case can end up reflected in a later ARF revision rather than staying a one-off workaround. Each work package publishes its methodology and test results openly, so an organisation outside the consortium can still learn from the interoperability findings rather than only from the specifications they later informed. European Business Wallet EUDI Wallet ARF FIDES What does WE BUILD actually test? WE BUILD is one of four Large Scale Pilots funded through the Digital Europe Programme to test the EUDI Wallet ecosystem in practice, this one focused on business use cases such as company registration, branch creation and supplier onboarding. Its Interoperability Test Bed checks whether wallets, issuers and verifiers built by different organisations actually work together against the same protocols, rather than each vendor only testing against itself. Related terms Back to the glossary ### EBWOID - what it is and how it works https://www.credenco.com/glossary/ebwoid EBWOID, European Business Wallet Owner Identification Data, is the attestation that identifies the organisation a European Business Wallet belongs to, issued from an authentic source such as a business register. It is deliberately small. Rather than describing a company in full, it carries a cross-border unique identifier such as an EUID, the official legal name as held in the authentic register, the issuing authority and country, an expiry date, status information for revocation and suspension, and a trust anchor a verifier can follow to check all of it. It also states its own legal category, either a QEAA or a public-sector EAA, so a relying party knows what weight it carries. Issuers are public sector bodies, qualified trust service providers, or the Commission for Union entities, always working from authentic sources notified to the Commission. The format is SD-JWT VC, with the credential type uri:eu.ebw.oid.1, or the W3C data model; ISO mdoc is explicitly out of scope. EBWOID identifies the organisation and nothing more, so where a transaction has to be bound to a person acting for it, the relying party asks for that representative's PID alongside it. EBWOID is defined in the WE BUILD attestation rulebooks catalogue rather than in a stand-alone European regulation, which means its exact schema can evolve alongside the consortium's other business-wallet rulebooks without a legislative change each time. A verifier checks it the same way it checks any other attestation: by following the trust anchor back to a Trusted List entry for the issuing authority, so accepting an EBWOID does not require a separate integration with each country's business register. In practice it shows up wherever a transaction needs to establish which company is on the other end before deciding whether to proceed, cross-border invoicing, supplier onboarding, tender participation, without exposing turnover, ownership or any other detail the business register happens to hold. European Business Wallet PID QEAA SD-JWT Is EBWOID the same as a PID? No. An EBWOID attests which organisation a European Business Wallet belongs to, comparable to a company registration certificate, while a PID attests who a natural person is. A transaction that needs both facts, for example a signature made on behalf of a company, has the wallet present the EBWOID for the organisation and the signer's PID together, since neither credential substitutes for the other. Related terms Back to the glossary ### DIIP - what it is and how it works https://www.credenco.com/glossary/diip DIIP, the Decentralized Identity Interop Profile, is not a specification of its own but a profile: it picks one coherent set of existing specs — credential format, signature algorithm, identifiers, issuance and presentation protocol, revocation — and makes the optional parts mandatory, so "we use DIIP v5" replaces a paragraph of spec references. Started in the Dutch Blockchain Coalition, DIIP is now maintained by the FIDES Community, which releases a new version roughly twice a year and includes Credenco on its editor team. It targets interoperability where device binding is not required and the wallet itself does not need to be trusted, such as diplomas, certificates, licences, permits and business wallets; strong customer authentication and PID sharing are explicitly out of scope, which is HAIP territory instead. Versions have tracked the underlying specs as they matured: v1 (2023) profiled JWT-VC over early OpenID4VCI and OpenID4VP drafts with Presentation Exchange, v2 (2024) moved to later drafts of the same set, v4 (2025) added SD-JWT VC as a required format alongside W3C VCDM 2.0 and replaced Status List 2021 with the IETF Token Status List, and DIIP v5 (January 2026, current) aligns on the final OpenID4VCI and OpenID4VP 1.0 specifications and adds optional trust establishment through OpenID Federation; v6 is in development. Conformance to a DIIP version is checked with a public test suite, so a wallet, issuer or verifier can validate its own implementation before claiming support rather than relying on a self-declaration. Adoption has grown beyond its Dutch origin: DIIP is referenced by ecosystem pilots and business-wallet implementations across several EU member states as the profile that lets their credentials verify outside their home network, which is the interoperability problem it was built to solve in the first place. OpenID4VCI OpenID4VP DID Is DIIP the same profile as HAIP? No. HAIP is the OpenID Foundation's high-assurance profile for government-issued identity such as the PID, anchored in X.509 certificates. DIIP targets a wider range of everyday credentials, diplomas, licences, permits and business wallets, where the wallet itself does not need to be trusted and strong customer authentication is out of scope. The two are complementary: both build on OpenID4VCI, OpenID4VP and SD-JWT VC, but for different assurance needs. Related terms Back to the glossary ### HAIP - what it is and how it works https://www.credenco.com/glossary/haip HAIP, the OpenID4VC High Assurance Interoperability Profile, is an OpenID Foundation specification that constrains the OpenID4VC specs for use where a high level of security and privacy is required — government-issued identity, PID, QEAA — and is the profile the EUDI Wallet ecosystem builds on. HAIP 1.0 Final (24 December 2025) profiles OpenID4VCI and OpenID4VP 1.0 Final, SD-JWT VC and ISO/IEC 18013-5 (mdoc/mDL) as credential formats, of which an implementation must support at least one, with DCQL as the mandatory query language rather than Presentation Exchange. Trust is anchored in X.509 certificates rather than DIDs, and where a credential is holder-bound a key-binding JWT must be present on presentation. DIIP describes HAIP as complementary rather than competing: both build on the same OpenID4VCI, OpenID4VP and SD-JWT VC foundation, but HAIP is the higher-assurance, X.509-anchored route the EUDI Wallet and eIDAS 2.0 use for identity credentials such as the PID, while DIIP adds DIDs and W3C VCDM 2.0 for cross-domain ecosystems that do not need that level of assurance. HAIP is developed within the OpenID Foundation's eKYC and Identity Assurance working group, the same body that maintains OpenID4VCI and OpenID4VP themselves, which keeps the profile in step as those base specifications move from draft to final rather than trailing behind them. Because it is aimed at government-issued credentials, an implementation claiming HAIP conformance is expected to go through the OpenID Foundation's certification program, giving relying parties an independent check rather than a vendor's own claim. The profile deliberately narrows choice: where OpenID4VCI and OpenID4VP leave several credential formats, query languages and trust models optional, HAIP picks one combination for each, so two HAIP-conformant wallets from different vendors can be relied on to interoperate without additional bilateral testing. OpenID4VCI OpenID4VP mDL Is HAIP mandatory for OpenID4VCI and OpenID4VP implementations? No. Any implementation is free to build directly against OpenID4VCI and OpenID4VP without following HAIP. What HAIP adds is a fixed, tested set of choices, credential formats, a query language, a trust model, so that two independent implementations following it can be relied on to interoperate without extra bilateral testing. The EUDI Wallet ecosystem requires it precisely because that guarantee matters for government-issued identity. Related terms Back to the glossary ### SD-JWT VC - what it is and how it works https://www.credenco.com/glossary/sd-jwt-vc SD-JWT VC is the IETF profile that defines how to use SD-JWT to issue and present verifiable credentials: it fixes the claims, type, and key binding a credential needs on top of the underlying SD-JWT selective-disclosure mechanism, so wallets and verifiers can interoperate on the same credential format. SD-JWT alone only defines how to selectively disclose the claims inside a signed token; SD-JWT VC adds the credential-specific layer on top: a claim identifying the credential type, a required key-binding JWT so a presentation can be tied to the holder's wallet, and rules for status and issuer metadata. It differs from mdoc, the ISO-side format, in encoding and transport rather than in privacy properties: both support selective disclosure, but SD-JWT VC is JSON-based and issued over OpenID4VCI, while mdoc is CBOR-based and issued for offline, in-person presentation. The EUDI ARF names SD-JWT VC alongside mdoc as a format wallets must support. SD-JWT Selective Disclosure mdoc Is SD-JWT VC the same as SD-JWT? No. SD-JWT is the general selective-disclosure mechanism for JSON Web Tokens. SD-JWT VC is a specific profile of it for verifiable credentials, adding a credential type claim, key binding, and issuer metadata rules that a generic SD-JWT does not require. Related terms Back to the glossary ### Organization Wallet - what it is and how it works https://www.credenco.com/glossary/organization-wallet Organization Wallet An organization wallet is a digital identity wallet held by a legal entity rather than a natural person: it lets a company or other organisation issue, hold, and present verifiable credentials about itself and act as a business counterparty in its own right, rather than through an individual's personal wallet. A personal EUDI wallet identifies a natural person and is designed around that person tapping through occasional prompts. An organization wallet identifies a legal entity instead, so its credentials cover facts like company registration, tax identifiers, and authorised representatives, and it is built to run unattended on a server, issuing and verifying credentials at the volume an organisation's processes require. The European Business Wallet is the specific implementation of this concept for the European market; Credenco's Business Wallet is the product built on it. European Business Wallet Digital Identity Wallet How is an organization wallet different from a personal wallet? A personal wallet identifies a natural person and is used interactively from a phone. An organization wallet identifies a legal entity, holds credentials about the organisation itself such as registration and authorised representatives, and typically runs unattended on a server to handle credential requests at the volume the organisation's processes require. Related terms Back to the glossary ### Wallet as a Service (WaaS) explained https://www.credenco.com/glossary/wallet-as-a-service Wallet as a Service (WaaS) Wallet as a Service (WaaS) is a delivery model in which a provider hosts and operates the wallet infrastructure - issuance, storage, presentation, and the underlying security - on a buyer's behalf, rather than the buyer building and running that infrastructure itself. Buying WaaS means procuring the wallet's behaviour through an API and a set of managed guarantees, not a piece of software the buyer installs and operates. The provider carries responsibility for key management, protocol compliance such as OpenID4VCI and OpenID4VP, and keeping up with evolving standards like eIDAS 2.0, while the buyer configures branding, credential types, and business logic on top. It is the same build-versus-buy trade-off organisations make for other infrastructure, applied to wallets: WaaS trades some control for faster time to market and no in-house cryptographic engineering team. Organization Wallet European Business Wallet Digital Identity Wallet What does a buyer actually get with Wallet as a Service? A hosted, managed wallet reachable through an API: credential issuance, storage, and presentation, plus the key management and protocol compliance behind them, operated by the provider. The buyer configures credential types, branding, and business rules rather than running the underlying infrastructure itself. Related terms Back to the glossary ### Wallet Provider - what it is and how it works https://www.credenco.com/glossary/wallet-provider Wallet Provider A Wallet Provider is the natural or legal person that supplies a Wallet Solution to users under Article 5a of eIDAS 2.0 (Regulation (EU) No 910/2014): the party responsible for the software, the security guarantees, and the compliance obligations behind the wallet a user actually holds. Being a Wallet Provider is a regulated role, not just a technical one: it carries obligations around certification, security incident reporting, and conformity with the technical specifications set out in the ARF. A single Wallet Provider can supply many Wallet Units to many Wallet Users, and member states may run their own wallets or recognise wallets from certified private-sector providers, which is the market Credenco operates in as a Wallet Provider for the Business Wallet. Wallet Unit EUDI Wallet eIDAS 2.0 Who can become a Wallet Provider? Any natural or legal person can apply, but a Wallet Provider must meet the certification, security, and conformity requirements eIDAS 2.0 and the ARF set out before it can supply a Wallet Solution that member states and relying parties will trust. Member states may also run their own wallets directly rather than certifying private providers. Related terms Back to the glossary ### Wallet Unit - what it is and how it works https://www.credenco.com/glossary/wallet-unit Wallet Unit A Wallet Unit is the unique configuration a Wallet Provider gives to one Wallet User: the Wallet Instance (the app), together with the Wallet Secure Cryptographic Application and Wallet Secure Cryptographic Device that generate and protect its keys. The ARF distinguishes a Wallet Solution, the software and service a Wallet Provider builds and offers generally, from a Wallet Unit, the specific instance of that solution issued to one user and bound to that user's own secure hardware. In everyday use, Wallet Instance is the app installed on a device, and Wallet Unit is that installed app together with the cryptographic material behind it: the pairing is what lets a Wallet Unit Attestation later prove a request came from a genuine, unmodified copy rather than a spoofed client. This distinction matters most when something goes wrong: a Wallet Provider can revoke a single Wallet Unit, for example because its device was reported lost or its Wallet Secure Cryptographic Device is suspected compromised, without affecting any other user running the same Wallet Solution. Revoking the Wallet Solution itself is the far more disruptive step of withdrawing the whole product from the market. A Wallet Unit Attestation is issued per Wallet Unit rather than per Wallet Solution, since it has to speak to the specific hardware behind one user's keys, and a relying party checking that attestation is really asking whether this particular Wallet Unit, not the software brand behind it, is genuine and has not been tampered with. The ARF also allows one Wallet User to hold several Wallet Units, for instance on a phone and a separate hardware device, each provisioned from the same Wallet Solution but cryptographically independent of the others. Wallet Provider Wallet Attestation EUDI Wallet What is the difference between a Wallet Unit and a Wallet Solution? A Wallet Solution is the software and service a Wallet Provider builds and offers to the market in general. A Wallet Unit is one specific copy of that solution, installed on one user's device and bound to that user's own cryptographic hardware. Revoking a single Wallet Unit, say because a phone was lost, does not affect any other user running the same Wallet Solution. Related terms Back to the glossary ### EAA - what it is and how it works https://www.credenco.com/glossary/eaa An EAA, Electronic Attestation of Attributes, is any electronic attestation that certifies one or more attributes about a natural or legal person, issued by any provider. It is the general category; a QEAA is the qualified, higher-assurance variant of it. Any organisation can issue an EAA, and a relying party still has to judge how much to trust the issuer, unlike a QEAA, which carries the legal presumption of accuracy eIDAS 2.0 grants. A PuB-EAA is an EAA issued by, or on behalf of, a public sector body: it sits between the two, coming from a trusted institutional source without going through qualified trust service provider certification. In practice most attestations useful for business use cases, such as a chamber-of-commerce extract or a professional qualification, start as EAAs or PuB-EAAs before some of them are also offered in qualified form. QEAA Attestation Provider Verifiable Credential What is the difference between an EAA and a QEAA? An EAA can be issued by any provider and carries whatever trust a relying party is willing to extend based on who issued it. A QEAA can only be issued by a qualified trust service provider listed on a national Trusted List, and eIDAS 2.0 gives it a legal presumption of accuracy, so a relying party can accept it without further checks. Related terms Back to the glossary ### Trust Anchor - what it is and how it works https://www.credenco.com/glossary/trust-anchor Trust Anchor A Trust Anchor is an authoritative entity, represented by a public key and its associated data, that a relying party accepts as the starting point for verifying a chain of trust, based on the model in RFC 5914. A verifier does not re-establish trust from scratch every time it checks a credential: it follows a chain of certificates or attestations back to a Trust Anchor it has already decided to trust, and if that chain resolves cleanly, everything below it is trusted by extension. In the EUDI ecosystem, a Trusted List published by a member state acts as a registry of Trust Anchors, telling relying parties which public keys back qualified trust service providers, so they do not need a separate trust relationship with every issuer individually. A Trust Anchor is not itself a certificate: RFC 5914 defines it as the combination of a public key, the name of the entity it belongs to, and any constraints on what that entity is allowed to assert, packaged in a Trust Anchor Information Object or a self-signed certificate used as a convenient container for the same data. Because everything downstream depends on it, a Trust Anchor cannot be discovered on the fly; a relying party has to obtain it out of band, through a Trusted List, a hardcoded root, or another channel it already trusts, before it can verify anything. This also makes Trust Anchor rollover a deliberate operation: when a member state rotates the key behind an entry in its Trusted List, relying parties need to pick up the new Trust Anchor before the old one expires, or verification for that issuer breaks. Trust Anchors are the reason an EUDI Wallet verifier can accept credentials from an issuer it has never dealt with directly, since trust travels through the Trusted List rather than through a bilateral agreement with every issuer. Trust Framework Attestation Provider Issuer How does a relying party actually use a Trust Anchor? It follows the chain of certificates or attestations presented with the credential back to a Trust Anchor it has already agreed to trust, typically an entry in a member state's Trusted List. If that chain resolves cleanly to a Trust Anchor already on the relying party's trust list, the credential is accepted without the relying party needing any separate, direct relationship with the issuer that signed it. Related terms Back to the glossary ### Authentic Source - what it is and how it works https://www.credenco.com/glossary/authentic-source Authentic Source An Authentic Source is a repository or system, run by a public sector body or private entity, that holds and provides attributes about a person, organisation, or object, and is considered the primary, authoritative record for that attribute. A national trade register is an Authentic Source for company registration data; a tax authority is an Authentic Source for a VAT number, and a civil registry is an Authentic Source for a person's date of birth or address. An Attestation Provider that issues a credential based on an attribute is not itself the Authentic Source unless it also runs the underlying register: the two roles are often the same organisation, but the ARF keeps them conceptually separate, because a wallet or verifier needs to know which party actually vouches for the data's accuracy at the moment it was recorded. For a KYB or KYC check, going back to the Authentic Source rather than a document the counterparty presents is what removes the need to re-verify data that hasn't changed, since the record itself, not a photocopy or a self-declaration, is the thing being trusted. The EUDI Wallet's PID is a clear example: it is issued from population registers or comparable Authentic Sources designated by each member state, and its accuracy rests on that designation rather than on the wallet provider's own checks. Member states are required to identify and publish which bodies count as Authentic Sources for a given attribute, so an Attestation Provider, a wallet, or a relying party can trace a claim back to where it originates instead of relying on a chain of undocumented assertions. This is also what makes the once-only principle workable in practice: once an Authentic Source has confirmed an attribute, that confirmation can be reused across many attestations and many relying parties, rather than the same fact being collected and checked again by every organisation that needs it. KYB KYC Attestation Provider How is an Authentic Source different from an Attestation Provider? An Authentic Source is the underlying record, a trade register or a civil registry, that holds the attribute and is treated as its origin. An Attestation Provider is the party that issues a credential based on that record. The two roles are often the same organisation, but the ARF keeps them separate so a wallet can trace an attribute back to where it was actually confirmed. Related terms Back to the glossary ### Attestation Provider explained https://www.credenco.com/glossary/attestation-provider Attestation Provider Attestation Provider is the collective term for the three roles the ARF defines for issuing attribute credentials: a QEAA Provider, a PuB-EAA Provider, and a non-qualified EAA Provider. Which one an issuer is determines how much trust a relying party can place in what it issues. A QEAA Provider is a qualified trust service provider listed on a national Trusted List, so its attestations carry the eIDAS 2.0 legal presumption of accuracy, the same legal weight a qualified electronic signature has. A PuB-EAA Provider is a public sector body, or an entity acting on its behalf, issuing attestations without going through qualified certification, because its own public mandate already establishes the trust a relying party needs. An EAA Provider is any other organisation issuing attestations at whatever assurance level it can support, which covers most private-sector use cases such as a professional body confirming a licence or an employer confirming a role. All three draw on Authentic Sources for the attributes they attest, and a relying party checks the Trust Anchor behind an Attestation Provider to know which of the three it is dealing with, since the legal weight of the resulting credential depends entirely on that classification. A verifier accepting an attestation for a regulated process, opening a bank account under KYC rules for example, typically needs a QEAA or PuB-EAA rather than an ordinary EAA, while a loyalty scheme or an internal company badge can rely on the lower bar an EAA Provider offers. The ARF requires each Attestation Provider to register itself and the attestation types it issues, so the distinction between the three roles is enforceable rather than a matter of a provider's own claim. EAA QEAA Trust Anchor Authentic Source Can an EAA Provider issue the same attestations as a QEAA Provider? No. An EAA Provider issues attestations at whatever assurance level it can support, without the qualified certification a QEAA Provider holds. A relying party that needs the eIDAS 2.0 legal presumption of accuracy, for a regulated KYC process for example, has to rely on a QEAA or PuB-EAA Provider rather than an ordinary EAA Provider's attestation. Related terms Back to the glossary ### ISO/IEC 18013-5 - what it is and how it works https://www.credenco.com/glossary/iso-18013-5 ISO/IEC 18013-5 is the international standard for a mobile driving licence: it defines how a credential is stored on a phone and presented to a reader in person, including when neither device has a network connection. The standard specifies two presentation channels, offline over Bluetooth or NFC straight to a nearby reader and online to a remote relying party, both encrypted end to end so the holder controls exactly which fields are shared and the reader can confirm the response came from the phone presenting it. A reader requesting an age check, for instance, receives only a yes-or-no answer rather than the full date of birth, because the standard's data model lets a holder disclose individual elements rather than the whole document. Although it was written for driving licences, the underlying data model generalises to any credential: the mdoc format carries the same offline/proximity model for attributes beyond a licence, such as a professional qualification or an employee badge. The offline channel matters in practice wherever connectivity cannot be assumed, a border checkpoint, a rural fuel station, or a venue with poor signal, since the credential and the reader can complete the exchange over a direct radio link with no round trip to a server. The EUDI ARF names ISO/IEC 18013-5 alongside SD-JWT VC as a format wallets must support, which is why HAIP profiles it as a credential format too, and why a wallet built for the EUDI ecosystem has to implement both presentation flows rather than choosing one. Several EU member states' mobile driving licence pilots already issue mdoc credentials conformant with this standard ahead of the wider EUDI Wallet rollout. mDL mdoc HAIP Does ISO/IEC 18013-5 only apply to driving licences? No. It was written for mobile driving licences, but its data model and presentation protocols generalise to any credential presented offline or online to a reader. The mdoc format reuses this model for attributes beyond a licence, which is why the EUDI ARF names ISO/IEC 18013-5 as a credential format wallets must support, not only as a driving licence standard. Related terms Back to the glossary ### EBSI - what it is and how it works https://www.credenco.com/glossary/ebsi EBSI, the European Blockchain Services Infrastructure, is a network of nodes run by EU member states and the European Commission that anchors cross-border trust for verifiable credentials, such as which issuers and schemas are recognised, without relying on a single central registry. A relying party or wallet can check EBSI to confirm that a credential schema or an issuer is registered, the same way a Trusted List answers that question under eIDAS 2.0, but for a wider set of use cases than the regulation alone covers, including diplomas, business credentials and self-sovereign identity pilots run before eIDAS 2.0 existed. Each participating country runs its own EBSI node, and the network reaches agreement on the shared registry through those nodes rather than through one central server that any single party could take offline or alter unilaterally. It predates the EUDI Wallet and its trust framework, and several EUDI Wallet pilots, including FIDES Community e-invoicing and business-identity work, use EBSI as their trust registry today, ahead of a formal eIDAS 2.0 Trusted List covering the same schemas. EBSI also underpins several Erasmus+ diploma projects and legal-entity verification pilots that predate the EUDI Wallet programme, which is why it is often described as the bridge between early self-sovereign identity work and the regulated eIDAS 2.0 model. A verifiable credential's issuer can be resolved against EBSI using a decentralised identifier rather than a domain name or a certificate chain, which keeps the check working even if the issuing organisation later changes its web infrastructure. eIDAS 2.0 Trust Framework EUDI Wallet Is EBSI required under eIDAS 2.0? No. EBSI is not an eIDAS 2.0 requirement; it is a separate EU infrastructure that predates the regulation. Trusted Lists are the mechanism eIDAS 2.0 itself defines for issuer trust. Several EUDI Wallet pilots use EBSI as a trust registry today because it already covers use cases, such as diplomas and business credentials, that eIDAS 2.0 Trusted Lists do not yet fully address. Related terms Back to the glossary ### Trusted List - what it is and how it works https://www.credenco.com/glossary/trusted-list A Trusted List is the authoritative register a verifier consults to decide whether an issuer is trusted: each EU member state publishes one, naming the qualified trust service providers and issuers it authorises to operate under its trust framework. A verifier checks a credential’s issuer against the relevant Trusted List instead of maintaining its own list of who to trust, so the same check works no matter which member state issued the credential. Trusted Lists are what makes a trust framework operational rather than only a legal description: eIDAS 2.0 requires every member state to maintain one, and the ARF names it as a normative building block of the EUDI Wallet ecosystem alongside the PID and the wallet’s own trust anchors. Each list entry ties a trust service provider or issuer to the public key it uses to sign attestations, so a verifier can confirm both that the issuer is authorised and that a specific credential’s signature actually belongs to it. The lists are published in a machine-readable format and updated by the member state whenever a provider’s status changes, is added, suspended, or withdrawn, so a revocation takes effect for every relying party checking that list rather than requiring each one to be notified separately. A shared technical format defines how all member states publish their lists, which is what lets a wallet or verifier in one country parse another country’s Trusted List without bespoke integration work. Without this shared format, cross-border recognition of credentials under eIDAS 2.0 would require bilateral agreements between every pair of member states instead of one consistent mechanism. Trust Framework Issuer Verifier eIDAS 2.0 Who decides what goes on a Trusted List? Each EU member state’s designated supervisory body maintains its own Trusted List and decides which qualified trust service providers and issuers appear on it, based on eIDAS 2.0 requirements. It adds a provider once it has been certified, and removes or suspends one if its status changes, so the list always reflects who that member state currently authorises. Related terms Back to the glossary ### UBO - what it is and how it works https://www.credenco.com/glossary/ubo A UBO, Ultimate Beneficial Owner, is the natural person who ultimately owns or controls a legal entity, directly or through a chain of other entities, even when that person’s name appears on no public register. KYB checks a business itself, its registration, its authorised representatives, but establishing who ultimately stands behind it is a separate and often harder step: ownership can run through several holding companies or trusts before it reaches a person. A UBO credential lets that chain be proven once, by the register or notary that established it, and then presented instantly to every counterparty that needs it afterwards, instead of each one re-tracing the ownership structure from scratch. Regulators typically define a UBO threshold, commonly a stake of twenty-five percent or more, or control exercised through other means such as voting rights or the ability to appoint management, so establishing UBO status is not always a simple ownership-percentage lookup. AML rules require regulated entities, banks, notaries, and payment providers among them, to identify and record the UBO behind every corporate customer before onboarding it, which is why UBO registers exist in most EU member states today. A verifiable UBO credential draws on the same Authentic Sources those registers already hold, so a bank's KYB process can confirm the underlying ownership structure without asking the customer to supply notarised paperwork that the register has already established. Because ownership structures change, an acquisition, a share transfer, a new trust arrangement, a UBO credential is only as reliable as how recently it was issued or last confirmed against the register behind it. KYB KYC Is a UBO the same as a company's legal owner listed in the trade register? Not necessarily. A trade register typically lists direct shareholders or directors, which can be another company rather than a person. A UBO is specifically the natural person at the end of that ownership chain, found by tracing through any intermediate entities. A UBO register exists precisely because that person often does not appear directly in the trade register. Related terms Back to the glossary ### QTSP - what it is and how it works https://www.credenco.com/glossary/qtsp A QTSP, a Qualified Trust Service Provider, is a trust service provider that a EU member state supervisory body has granted qualified status and listed on that country’s Trusted List, making it the party allowed to issue qualified certificates, a QES or a QEAA under eIDAS. Any organisation can offer a trust service, but only one supervised and audited against the eIDAS qualified requirements earns a place on a national Trusted List, and only that listing lets a relying party trust its output without checking further. A QTSP is what makes a QES a qualified electronic signature rather than an advanced one, and what makes a QEAA carry the legal presumption of accuracy that a regular EAA lacks: both depend on the issuing party being a QTSP, not merely a trust service provider. Losing or never obtaining qualified status does not stop an organisation from operating; it just means its output no longer benefits from the legal weight eIDAS reserves for QTSPs. QES QEAA Trusted List Trust Anchor eIDAS 2.0 Related terms Back to the glossary ### Credential Issuance Platform - what it is and how it works https://www.credenco.com/glossary/credential-issuance-platform Credential Issuance Platform A Credential Issuance Platform is the software an issuer uses to turn source data, such as records in a business register or an identity system, into verifiable credentials and deliver them to a holder’s wallet, typically over OpenID4VCI. The platform sits between an organisation’s existing systems of record and the wallets that will hold its credentials: it maps source data to a credential format such as SD-JWT VC or mdoc, signs it, and runs the credential offer and OpenID4VCI exchange that gets it into a holder’s wallet. This is distinct from the Issuer role itself, which is the organisation legally responsible for what the credential asserts; the platform is the technical component that role relies on to actually issue anything. A Credential Issuance Platform typically also manages revocation, so a credential it issued can later be checked against a Status List, and keeps an audit trail of what it issued to whom. Issuer OpenID4VCI Credential Offer Verifiable Credential Related terms Back to the glossary ### Credential Verification API - what it is and how it works https://www.credenco.com/glossary/credential-verification-api Credential Verification API A Credential Verification API is the service interface a relying party calls to request and validate a presentation from a wallet, covering signature checks, the trust chain, status and revocation, and the claims returned to the relying party’s own application. Rather than building OpenID4VP handling, signature verification and trust-chain resolution into every application that needs to check a credential, a relying party integrates once against a Credential Verification API and calls it whenever it needs to verify a presentation. The API runs the OpenID4VP exchange with the holder’s wallet, confirms the presented credential’s signature and issuer against the relevant Trust Anchor, checks its Status List entry for revocation, and returns the verified claims in a form the calling application can use directly. This is distinct from the Verifier role itself, which is the organisation that decides what to ask for and what to do with the result; the API is the technical component that role calls to actually perform the check. Verifier Relying party OpenID4VP Status List Verifiable Presentation Related terms Back to the glossary