Choosing DID/VC Open Source: walt.id, Procivis One, Credo, and Multipaz

ZenChAIne·October 9, 2026

DIDVCOSSDigital IdentityWallet

Introduction

You have learned the credential formats. Now you want to issue a training certificate. The previous article compared W3C VC, SD-JWT VC, and mdoc using the same certificate. Looking for implementations brings another list of names: walt.id, Procivis One, Credo, and Multipaz. Just when the standards start to make sense, there is a new vocabulary to learn.

These projects publish source code that developers can use and modify under their licenses. Some provide services you run and call through APIs; others provide libraries you incorporate into an application. This article explains who develops them, what published adoption evidence shows, and which parts of a credential system they help build.

For this series, walt.id and Procivis One Core are candidates for an API-based issuance, holding, and verification experiment. Credo is a candidate for application development in TypeScript, while Multipaz is a candidate for mobile key management and mdoc presentation. Their roles overlap. This is a review of public documentation checked on October 6, 2026, not a report of software we have already deployed or tested together.

Which part of the system are you building?

A training provider issues a certificate, a learner keeps it, and an employer verifies it. That requires software for at least three roles.

An issuer service delivers a credential to a holder's wallet, which presents it to a verifier service. Business decisions remain with the training provider, learner, and employer.

Role	Credential-related work	Decisions the business still makes
Issuer	Assemble and sign the certificate, then deliver it to a wallet	Whether the learner completed the course and who should receive the certificate
Wallet	Manage credentials and keys; present credentials when the holder chooses	How to let the holder understand and approve what is shared
Verifier	Check the signature, validity period, and required attributes	Whether this training provider and course meet the employer's requirements

OpenID4VCI defines procedures for issuing credentials to wallets. OpenID4VP defines procedures for presenting them to verifiers. These exchange protocols work alongside credential formats such as W3C VC, SD-JWT VC, and mdoc. They do not decide whether a course was completed or an applicant should be hired.

API platforms and SDKs

With an API platform, a business system uses HTTP to request credential creation and communication with a wallet, so an existing Java or Python application can call the same interface. An SDK, or software development kit, provides libraries and development software that your application calls directly for tasks such as generating keys, receiving credentials, or presenting them. This lets you implement screens and storage around your application, but the SDK must support its language and runtime. A call to code running inside the application does not require an HTTP request to a separate API platform; operations involving wallets or verifier services may still require network communication.

The projects do not fall neatly into one category: walt.id offers libraries and mobile applications, Procivis offers an embedded SDK, and Credo and Multipaz can also be used on servers. Choosing one therefore means deciding which part of your system it will implement. As of October 2026, my view is that there is still no single default OSS choice for DID/VC that I would recommend regardless of the application being built.

Major DID/VC open-source projects

The six projects below cover service platforms, application SDKs, and a reference implementation. Their software roles and their planned use in this series are separate columns: a project used for an integration experiment may also serve as a foundation for an operational service.

Project	Developer and background	Software role	Planned use in this series
walt.id Community Stack	Vienna-based walt.id, offering Community and Enterprise products	Issuer, wallet, and verifier APIs, libraries, and applications	Exercise the full certificate flow through APIs
Procivis One Core	Procivis AG, a Swiss subsidiary of Orell Füssli	Core API and embedded SDK for issuing, holding, and verifying credentials	Compare with walt.id before choosing the primary teaching implementation
Credo	Successor to Aries Framework JavaScript; an OpenWallet Foundation project with contributors including Animo	TypeScript framework for Node.js and React Native credential applications	Follow issuance, presentation, and verification in application code
Multipaz	Started by Google and donated to the OpenWallet Foundation	Mobile and server SDK for mdoc and SD-JWT VC	Explore mobile keys and proximity and online presentation
EUDIPLO	Development led by Mirko Mollik; grew within OWF, with its current README identifying LF Decentralized Trust	Middleware handling issuance and presentation between business backends and wallets	Test integration with external wallets
EUDI Wallet reference implementation	European Commission	Applications, libraries, and servers demonstrating the European wallet architecture	Study the implementation and try it as a recipient of our certificate

EUDIPLO can provide issuance and verification infrastructure for a service. Using it for integration experiments in this series does not limit the project's wider purpose. The EUDI Wallet reference implementation is useful both as code to study and as software to test against.

The OpenWallet Foundation, or OWF, supports collaborative development of open-source wallet components under the Linux Foundation. Standards organizations such as W3C and IETF develop specifications; these projects develop code that implements them.

There is also a governance change to keep in view. An official announcement on September 1, 2026 says OWF will join LF Decentralized Trust effective January 1, 2027, retaining existing project governance, technical committees, and charters. That organizational transition does not, by itself, establish a change in an API or supported protocol.

walt.id: explore the full flow through APIs

walt.id publishes issuer, wallet, and verifier APIs, together with supporting libraries and applications. The Community Stack README describes W3C VC, SD-JWT VC, mdoc/mDL, OpenID4VCI, and OpenID4VP components. mDL means mobile driving licence, a prominent document type using mdoc.

The Vienna-based company distinguishes its self-hosted Community Stack from the commercial Enterprise Stack. In our certificate scenario, the training provider calls an issuance API, the learner receives and presents the credential, and the employer uses a verification API to check it. That makes walt.id a candidate for following the complete exchange between the three parties, while course-completion checks and hiring decisions stay in the business systems we connect to it.

Credential status also needs attention. According to the status documentation, Community Stack users manage and host their own status lists, while Enterprise Stack provides a service for that purpose. For our Community-based service, that means adding status-list publication and ensuring the employer can read the status and reject a certificate the training provider has revoked.

Providing issuance, verification, and wallets as services

A March 2026 case study describes a global ICT provider building an identity-as-a-service platform with issuance, verification, and wallet capabilities. This is useful as an example of providing credential functions for business systems to use. It uses the Enterprise Stack and does not name the customer, so it does not establish the production configuration of the Community edition we intend to test.

The case study's figure of more than 500 million people describes the potential user base that could be reached. It is not a count of active wallet users. The distinction matters when evaluating a vendor's track record.

The README documents v2 APIs alongside legacy v1 implementations. A tutorial must keep its API generation, examples, and configuration aligned. Similarly, its “Web Wallet coming soon” notice concerns the v2 web application; separate Compose and iOS wallet resources are listed.

Procivis One: public-sector use and the Core API

Procivis One Core provides common code for issuing, holding, and verifying credentials. Its README lists formats including W3C VC, SD-JWT VC, and ISO mdoc, together with protocols including OpenID4VCI and OpenID4VP. It is implemented in Rust and documents running its API locally, letting us exercise the issuer, holder, and verifier roles through the same core and compare the workflow with walt.id using identical certificate content.

Procivis AG is a Swiss subsidiary of Orell Füssli. The Core can be used as a server or integrated into a wallet through an SDK. Using the Core in the open-source repository leaves us to connect course management and decide how to build our application screens. If administration interfaces are part of the intended deployment, the wider Enterprise offering, including One Desk, is another option to examine.

Zug's employee credentials and Lithuania's sandbox

A September 2024 company announcement about Zug describes digital employee credentials for more than 500 teachers. They can present them through the eZug application to obtain discounts at participating stationery shops. The reported use replaces physical cards and the annual renewal of validity stickers.

The city issues the credential, teachers carry it, and external shops accept it: the service crosses the issuing organization's boundary. Our training certificate follows the same pattern when a learner takes a provider's certificate to a separate employer, so the example is useful for understanding the service we want to build. The announcement does not identify the public OSS version or configuration, leaving us to establish whether One Core can reproduce that setup.

The Lithuanian project concerns a national sandbox for the European Digital Identity (EUDI) Wallet: an environment for testing connections and uses before wider deployment. It is a public-sector contract, not an announcement that a nationwide citizen service has fully entered production. Those are different stages of adoption.

The Getting Started guide documents credential workflows through the Core API. We intend to use the same training certificate in walt.id and Procivis, recording setup work, protocol visibility, and additional work for revocation and reissuance. A server simulating the holder role will be treated separately from a wallet keeping its keys on a phone.

Credo: build credential workflows in TypeScript

Credo is a TypeScript framework for Node.js and React Native, making it a candidate for embedding key and DID management, issuance, receipt, presentation, and verification in applications using those environments. If an existing business system simply needs to request issuance, it can instead call the APIs of walt.id or Procivis One. The choice therefore depends on our development language and where we want credential processing to run.

For our learner application, we could call Credo to receive a training certificate and present it to an employer, while designing the screens and business logic ourselves. If we want to start with an existing mobile interface, Bifold and Paradym Wallet are additional applications built with Credo.

It grew out of Hyperledger Aries Framework JavaScript. The OWF project description explains that background and its expansion into multiple protocols and credential formats. The maintainer list identifies the people maintaining the project; Animo is among the organizations involved in its development.

For adoption evidence, the project's 2024 annual report to OWF names British Columbia, the Irish government, and Bhutan through CREDEBL, among others. These are project-reported uses. They do not establish that every named deployment uses the latest OpenID4VC configuration in production. Historical adoption and current protocol support need separate evidence.

On October 6, 2026, the latest GitHub release was v0.7.2, while the public guide displayed v0.6.x. Some README links also point to older specification versions. Rather than infer current capabilities from a link alone, an experiment should inspect the selected release, configuration examples, and migration guidance together.

This series will first follow credential processing from code that calls Credo, then choose an application around the screens and devices needed to test the learner's interactions.

Multipaz: mobile keys and mdoc

Multipaz is a digital credential SDK started by Google and donated to OWF. It uses Kotlin Multiplatform for Android, iOS, and server components, and covers SD-JWT VC and online presentation as well as mdoc. For our certificate, it lets us investigate a learner holding credentials on a phone and presenting them to an employer's nearby reader or online service. That is where we can examine device key management and presentation interactions that running server APIs alone would not demonstrate.

A September 1, 2026 Google article describes Multipaz as a foundational component of Google Wallet and the EUDI Wallet reference implementation, providing an example of the SDK being embedded inside a product and a reference implementation.

We can build our own wallet or verifier application with Multipaz, but placing a certificate in Google Wallet requires meeting that product's accepted-document and issuer conditions. The repository also states that Multipaz is not an officially supported Google product, so certification and support for our own application require separate consideration.

The project README links to Android and iOS test applications, proximity readers, and web verification services. We can use those resources when investigating a phone-held key and a presentation requested by an employer. Whether a key can leave the device, and how device authentication is applied, must be checked against the actual platform and configuration.

The project remains pre-1.0 at the time of this review and warns that APIs and persisted data may change. A reproducible tutorial therefore needs a pinned version, with data migration checked separately when upgrading.

EUDIPLO: connect business systems and wallets

EUDIPLO sits between the business system and the wallet. Its documentation describes business-facing HTTP/JSON APIs and OpenID4VCI/OpenID4VP communication with wallets. In our scenario, the training provider requests issuance and EUDIPLO handles the issuance exchange with the wallet; on the employer's side, it can handle the exchange requesting a presentation. Course-completion and hiring decisions stay in the existing business systems, making this a candidate for adding digital certificates to an existing training service. We still need to connect those systems to EUDIPLO's APIs and provide the learner's wallet as a separate component.

The project proposal identifies a development team led by Mirko Mollik. It developed within OWF, while the current README describes it as an LF Decentralized Trust project.

Credo and EUDIPLO both depend on the @openid4vc/* library family for issuance and presentation protocols. The inspected Credo dependencies and EUDIPLO dependencies specify different versions of that family.

Connecting them is still a useful application-level integration test. However, it is different from demonstrating interoperability between independently implemented protocol engines. Our experiments will record which exchange, credential, and cryptographic components are shared, rather than assume that different project names mean independent implementations throughout.

EUDI Wallet reference implementation: study the European wallet architecture

The European Commission's EUDI Wallet reference implementation comprises applications, libraries, and servers demonstrating the European digital identity wallet architecture. The Android application's README describes its primary purpose as a technical showcase and points to separate guidance for production use. For our certificate, we need to align the issuance service's formats and exchange procedures with the wallet and configure trust in the training provider as an issuer. Studying the code helps us understand the European wallet architecture, while connecting to it lets us test whether our issuance service can deliver the certificate.

Choose by the work you need to do

This table identifies candidates from documentation, not measured performance or implementation effort.

Initial objective	Candidates	Decisions still required
Complete issuance, holding, and verification	walt.id, Procivis One Core	Certificate attributes, API generation, key and credential storage
Embed workflows in a TypeScript application	Credo	Modules, persistence, screens, server/device responsibilities
Present mdoc from a phone in person or online	Multipaz	Device and OS, key storage, issuer certificate trust
Connect a business backend to external wallets	EUDIPLO	Wallet version, credential format, protocol configuration
Test against the European reference architecture	EUDI Wallet reference implementation	Application and server versions, test certificates, trust configuration

License scope also matters. The Community Stack, One Core, Credo, Multipaz, and EUDIPLO repositories identify Apache-2.0 licenses; the EUDI Android wallet application uses EUPL-1.2. Read the license for each selected component rather than assume all applications, servers, and commercial services under a project name have identical terms.

A wallet API holding keys on a server also creates different operational responsibilities from a phone holding its own keys. The word “wallet” alone does not establish key custody. Check who can use the keys, where they reside, and who handles recovery after loss.

What the implementation comparison will establish

The comparison of walt.id and Procivis One Core will begin with issuance, receipt, presentation, and verification of the same SD-JWT VC training certificate, then investigate the supported scope for W3C VC and mdoc. We will record setup steps, visibility into protocol exchanges, required devices and external services, and additional work for status and renewal to show the integration work a standards-support table cannot establish.

Alongside successful presentations, we plan to try altered credentials, expired credentials, another holder's key, untrusted issuers, and revoked credentials. Failure to retrieve status information will be recorded separately from a confirmed revocation, including whether the system rejects, errors, or postpones its decision.

SSI aims to give people control of their data and let them carry credentials across services, which requires issuers and verifiers to share ways of reading and exchanging that data. Yet implementations have different integration conditions, so issuers and verifiers must still align their choices after selecting software. In my view, that repeated coordination is one reason adoption remains difficult. We intend to document working combinations and failure conditions so future implementers can reuse what we learn.

Frequently asked questions

Does every option require a blockchain?

No. The architecture depends on the DID method, how verification keys are obtained, and the credential format. If a chain is used, specify what is stored on it and what verification actually reads.

Does an OSS component provide a complete training certificate service?

It can supply credential processing, but course management integration, recipient checks, and agreements with employers still need implementation and operational decisions. A successful software demonstration is only part of launching the service.

Does a conformance test remove the need for our own integration test?

Conformance testing has a defined role, version, format, and configuration scope. Your own certificate attributes, issuer, and intended verifier still need to work in the selected configuration.

Summary

We want to follow one training certificate from issuance through receipt and presentation to an employer, so we will first compare walt.id and Procivis One Core, whose APIs let us exercise that complete flow. We then intend to use Credo to study processing within application code, and Multipaz to investigate phone-held keys and mdoc presentation. EUDIPLO will help us test a business backend connected to external wallets; the EUDI Wallet reference implementation offers a way to study and test against the European architecture.

Published adoption is useful context, but a commercial deployment or government sandbox may use a different configuration from the service we are building. We will choose the primary teaching implementation after running the software and establishing the additional development and operational work it requires, alongside its supported standards.

Sources

🇯🇵 日本語で読む