Our commitment to open source
OpenDPP is open-core. The client surface — the helpers, schemas and SDKs you integrate with — is open under Apache-2.0, so you can build on it, audit it, and avoid lock-in. The hosted node that signs, seals and resolves your passports is the product we run for you.
What we open, and why
We open everything you need to integrate with OpenDPP and keep the security-critical node closed — open where it builds trust and removes friction, closed where it protects your signing keys.
The client surface is open
Every helper you call to format identifiers, map your data, verify a webhook or talk to the API is published under Apache-2.0. Read it, fork it, vendor it — no account required.
No lock-in
The interop schemas, samples and offline validators are public, so your passports stay portable and verifiable with off-the-shelf tooling, independent of us.
The hosted node is the product
Key custody, sealing, DID and revocation issuance, and resolution run on the managed node. That boundary is what keeps every tenant's private keys inside the vault.
The open packages
Zero- or light-dependency building blocks, published to npm under the @opendpp scope and licensed Apache-2.0.
@opendpp/gs1
GS1 Digital Link URI builders and GS1 mod-10 check-digit helpers — the identifier maths behind every scannable passport.
@opendpp/csv
A pure CSV-to-passport reference mapper: turn a spreadsheet row into a structured passport payload, with errors reported by line.
@opendpp/webhooks
OpenDPP webhook event types plus a constant-time HMAC-SHA256 signature verifier, so you can trust the payloads you receive.
@opendpp/sdk
A typed TypeScript API client generated from the public OpenAPI contract and version-locked to it. Python and a CLI are on the roadmap.
The open repositories
Public, Apache-2.0 repositories under the OpenDPP organisation on GitHub.
- opendpp-interop The interop boundary kit: official AAS (IDTA) and UNTP / W3C-VC schemas, live-reproducible samples, an offline conformance validator, and OpenDPP-authored non-normative SHACL shapes.
- opendpp-knowledge The OpenDPP knowledge bundle in Open Knowledge Format (OKF) — machine-readable Markdown that lets AI agents learn the API. Also served live at /okf and advertised via /llms.txt.
- opendpp-sdk The API client SDKs, generated from the public OpenAPI contract. TypeScript ships today; Python and a CLI are next.
The open / closed boundary
A simple rule: if it helps you integrate with OpenDPP it is open; if it protects your keys or runs the node it stays with the hosted service.
Open — the client surface
- Identifier, CSV and webhook helpers
- The typed API SDK, generated from the public OpenAPI contract
- AAS and UNTP / W3C-VC interop schemas, samples and validators
- The AI knowledge bundle (OKF) and /llms.txt
Closed — the hosted node
- Per-tenant key vault and passport sealing
- did:web and revocation status-list issuance
- The resolver, persistence and retention layer
- The multi-tenant control plane
The closed line is deliberate and load-bearing: your signing keys never leave the vault, and the node never hands out a credential emitter that could sign on your behalf off-platform.
Apache-2.0, and a word on the name
The open packages and repositories are licensed under Apache-2.0 — use them in commercial and open projects alike. The OpenDPP hosted service and its server components remain proprietary.
OpenDPP™ is a trademark of Opendpp UAB. You are welcome to build integrations that work with OpenDPP and to say so; "OpenDPP-conformant" describes software that interoperates with the OpenDPP node — it is not a certification or endorsement we grant.
Build with OpenDPP
Start from the open packages and the public API contract — no account required to read the code.
Explore the OpenDPP org on GitHub