vck
VC-K is a comprehensive Kotlin Multiplatform library for implementing digital identity solutions, with full support for modern credential standards and protocols. It enables developers to build wallet applications, verifier systems, and issuer services using a single, consistent API across multiple platforms.
Designed with developers in mind, VCK provides a flexible, modular architecture that simplifies the implementation of complex identity workflows while maintaining compatibility with the broader digital identity ecosystem, including the EU Digital Identity Wallet (EUDI Wallet).
Notable features to fully support Kotlin multiplatform are:
- Use of Napier as the logging framework
- Use of Kotest for unit tests
- Use of kotlinx-datetime for date and time classes
- Use of kotlinx-serialization for serialization from/to JSON and CBOR
- Implementation of a ZLIB service in Kotlin with native parts, see
ZlibService
Some parts for increased multiplatform support have been extracted into separate repositories:
- Reimplementation of Kotlin's Result called KmmResult for easy use from Swift code (since inline classes are not supported).
- Several crypto datatypes (including an ASN.1 parser and encoder), as well as a multiplatform crypto library, called Signum.
The main entry point for applications is an instance of HolderAgent, VerifierAgent or IssuerAgent, according to the nomenclature from the W3C VC Data Model.
Many classes define several constructor parameters, some of them with default values, to enable a simple form of dependency injection. Implementers are advised to specify the parameter names of arguments passed to increase readability and prepare for future extensions.
Features
VC-K implements multiple credential formats to ensure maximum interoperability:
- W3C Verifiable Credentials Data Model: Rudimentary implementation of the W3C VC Data Model (skipping everything around DIDs)
- SD-JWT (Selective Disclosure JWT): Privacy-preserving credential format with selective disclosure capabilities, see SD-JWT VC (including key binding JWT, JWT VC issuer metadata). We're also following SD-JWT, including features like key binding JWT and nested structures.
- ISO 18013-5 and 18013-7: ISO standard defining Mobile Driving Licence and its generalization mDoc credentials as a CBOR-based credential format
When using the plain JWT representation, the single credential itself is an instance of CredentialSubject. For ISO mDoc claims see IssuerSignedItems and related classes like Document and MobileSecurityObject. For SD-JWT claims see SelectiveDisclosureItem and SdJwtSigned.
Other libraries implementing credential schemes may call LibraryInitializer.registerExtensionLibrary() to register with this library. See our implementation of the EU PID credential and our implementation of the Mobile Driving Licence for examples. We also maintain a comprehensive list of all credentials powered by this library.
OpenID Protocol Implementations
VC-K provides full implementations of the OpenID protocol family for credential issuance and presentation:
OpenID4VCI (OpenID for Verifiable Credential Issuance): Standards-compliant credential issuance flows (OpenID for VCI), including:
- Pre-authorized code grants
- Authorization code flow
- Credential selection with authorization details and scopes
- Pushed authorization requests
- See classes
WalletServiceandCredentialIssuer
OpenID4VP (OpenID for Verifiable Presentations): Complete holder and verifier implementation (OpenID for VP), supporting:
- Same device and cross-device flows
- Response modes:
direct_postanddirect_post.jwt - Request objects by value or reference
- Presentation definitions and submissions
- Verifier attestations
- Signed and/or encrypted responses
- Digital Credential Query Language (DCQL)
- Presentation Exchange
- See classes
OpenId4VpVerifierandOpenId4VpHolder
EUDI Wallet Compatibility
VC-K is designed to be fully compatible with the EU Digital Identity Wallet (EUDI Wallet) ecosystem:
- Implements all required credential formats and presentation protocols
- Supports the European Digital Identity Regulation requirements
- Compatible with EUDI Wallet Reference Implementation
- Follows ARF (Architecture Reference Framework) specifications
VC-K demonstrated very high interoperability with various implementations across the digital identity ecosystem. The library has been successfully tested and validated at Interop Events for Potential, showcasing compatibility with:
- Multiple wallet implementations
- Various issuer systems
- Different verifier platforms
- Cross-vendor credential exchange scenarios´
Usage
VC-K uses a modular structure to separate concerns. Hence, depending on the use cases you want to cover, you will need different artifacts:
| Artefact | Info |
|---|---|
vck |
VC-K base functionality. Contains business logic for creating, issuing, presenting, and verifying credentials. |
vck-openid |
OpenID protocol implementation, including OpenID4VCI. Contains client and server authentication business logic and the actual issuing protocol. |
vck-openid-ktor |
Contains ktor-based OpenID4VCI client and OpenID4VP wallet implementations. |
dif-data-classes |
DIF Presentation Exchange v1.0.0 data classes. Does not depend on any other vck artefact and can hence be used independently of VC-K! |
openid-data-classes |
OpenID data classes. Only depends on dif-data-classes and csc-data-classes and can hence be used independently of VC-K! |
csc-data-classes |
CSC data classes. Does not depend on any other vck artefact and can hence be used independently of VC-K! |
Simply declare the desired dependency to get going. This will usually be one of:
implementation("at.asitplus.wallet:vck:$version")
implementation("at.asitplus.wallet:vck-openid:$version")
Everything else (serialization, crypto through Signum, …) will be taken care of.
Therefore, do not manually add serialization dependencies! In case you are using this project in a codebase with dependencies on kotlinx-serialization, please use the vck-versionCatalog artefact to keep versions in sync.
If you
As discovered in #226, using the deprecated io.spring.dependency-management will cause issues.
The actual credentials are provided as discrete artefacts and are maintained separately over here. It is fine to add credentials and VC-K to as project dependencies, e. g., to use a version of VC-K that is more recent than the one a certain credentials depends on.
Limitations
- Several parts of the W3C VC Data Model have not been fully implemented, i.e. everything around resolving cryptographic key material.
- Anything related to ledgers (e.g. resolving DID documents) is out of scope.
- JSON-LD is not supported for W3C credentials.
- Trust relationships are mostly up to clients using this library.
Contributing
External contributions are greatly appreciated! Be sure to observe the contribution guidelines (see CONTRIBUTING.md). In particular, external contributions to this project are subject to the A-SIT Plus Contributor License Agreement (see also CONTRIBUTING.md).
| This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 959072. | |
|---|---|
Co‑Funded by the European Union |
This project has received funding from the European Union’s Digital Europe Programme (DIGITAL), Project 101102655 — POTENTIAL. |
|---|---|
The Apache License does not apply to the logos, (including the A-SIT logo) and the project/module name(s), as these are the sole property of A-SIT/A-SIT Plus GmbH and may not be used in derivative works without explicit permission!
