Every claim, with a way to check it
This register includes deployed surfaces, sandbox capabilities, release-candidate engine capabilities and explicit integration limits. Check each row against the file, URL or test named beside it; operational availability is kept separately on Status.
Company
| Claim | How to check |
|---|---|
| Verifable is a product of Lumoin Oy, an existing company. | The Organization node in this site's JSON-LD names legalName: Lumoin Oy; the footer reads © 2026 Lumoin Oy. Also lumoin.com. |
| Lumoin Oy is a Finnish limited company, so Verifable is built inside the European Union and under EU law. | Oy is the Finnish limited-company form, and the published VAT identifier FI28496474 carries the Finnish country prefix. Both are in this site's JSON-LD. |
| A person can reach a person. | hello@lumoin.com, or contact@lumoin.com in the JSON-LD contact point. |
| Everything claimed on this site is claimed by Lumoin Oy alone. | No third-party certification, accreditation or audit report is named anywhere here, and the standards list describes what the code implements rather than what anyone has certified. |
| The people and companies in the home-page story are a scenario. | The story is labelled fictional in the page itself. Customer names and case studies appear here when there are some to publish. |
Source and licence
| Claim | How to check |
|---|---|
| The Verifable Wallet has a public source repository. | github.com/Lumoin/Verifable — check the repository's licensing and releases separately from source availability. |
| The identity and credential library underneath it is public under Apache-2.0. | github.com/Lumoin/Verifiable — decentralized identifiers, verifiable credentials, protocols, cryptographic routines, in C#. |
| The advanced-cryptography and distributed-state stacks are public under Apache-2.0. | Lumoin.Veridical (zero-knowledge proofs, polynomial commitments, folding schemes, BBS selective disclosure, split-ECDSA) and Lumoin.Verisync (conflict-free replicated data types, causal contexts, leaderless consensus). |
| The Veritas evidence database has a public source repository. | github.com/lumoin/Lumoin.Veritas — public source, documentation and tests. Apache-2.0. |
| The licence covers the code; the name and marks are held separately. | TRADEMARK.md in the wallet repository names Verifable, the logo, and the domains as Lumoin Oy trademarks, distinct from the Apache-2.0 grant. |
What the platform does
| Claim | How to check |
|---|---|
| The whole API surface is published as a version-controlled contract. | /openapi/verifable-server.json — OpenAPI 3.1.1, emitted by the server build, rendered live in Documentation. |
| A passport cannot be issued in a shape that fails its product group's rules. | POST /product/passports validates the credentialSubject against the group's SHACL shape before signing. Try it yourself by issuing a passport, including the "make it fail" toggle. |
| An issued product has its own identity that third parties can resolve. | The subject id is did:web:<host>:product:<id>, with the DID document at /product/{id}/did.json and the signed passport at /product/{id}/dpp.json. |
| Reading a passport is a policy decision, so access follows the tier rather than the URL. | GET /product/{id}/dpp.json is tier-gated through an AuthZEN policy decision point that resolves the caller's tier from the authenticated session. Decisions are inspectable in Operations. |
| One product identifier resolves to a typed set of links, one per credential. | GET /resolve/{productId} returns an ISO/IEC 18975 link-set as RFC 9264 application/linkset+json with RFC 8288 Link headers: anchor = the product DID, plus dpp / dcc / dte arrays. |
| An issued passport can carry a GS1 Digital Link identifier (GTIN, optional serial). | GS1 URI syntax, application identifiers 01/10/17/21, and the mod-10 check digit are validated at issuance time (src/Verifable.Web/src/core/gs1-digital-link.ts); the identifier is shown on the passport and encoded as a QR data carrier. |
| UNTP credentials are verified against a real trust anchor. | POST /untp/verify selects the anchor from issuer.id: a tenant key, an enrolled foreign issuer key, or a live did:web resolution over an SSRF-guarded outbound transport. |
| JCS proof canonicalisation does not fetch JSON-LD contexts. | POST /vc/issue and /vc/verify use an eddsa-jcs-2022 Data Integrity proof: RFC 8785 canonicalization signs every property and resolves no JSON-LD context. Run it in the playground. |
| Validation findings point at the exact field. | POST /vc/validate returns RFC 6901 JSON Pointers into both the credential and the schema; remote $ref resolution is off. |
| Selective disclosure is real cryptography, so an undisclosed field is absent from the proof rather than hidden by the response. | POST /vc/bbs/issue, /vc/bbs/derive, /vc/bbs/verify — issue, derive a subset proof, verify the derived proof. |
| The OID4VP status check rejects a revoked credential. | Issued credentials carry a Bitstring Status List entry pointing at the tenant's hosted list; the OID4VP verifier reads the live list, so a revoked index is rejected on presentation. Exercised in the test tenant at the sandbox. |
| DIDs resolve server-side, so the browser's cross-origin wall is not the limit. | GET /did/resolve and the resolver: did:key is computed in-process, did:web is fetched by the server. |
| The public SPARQL endpoint queries a temporary example graph. | GET|POST /sparql — SPARQL 1.2 SELECT and ASK over the provenance store, returning application/sparql-results+json; malformed queries return span-bearing parser diagnostics. This public endpoint intentionally uses a temporary in-memory graph; the Veritas database separately supports selectable durable storage and replicated topologies. |
| Shapes, RDF, and CBOR can be inspected directly. | POST /shacl/validate (full report: focus node, path, severity, source shape, constraint component), POST /rdf/inspect, GET /cbor/inspect (Extended Diagnostic Notation linked to byte spans). |
| Sign-in uses passkeys. | WebAuthn registration, authentication, and session endpoints are implemented (/webauthn/*). A configured database enables passkey persistence through PasskeyDurabilityInitializer; the no-database fallback is in memory. Verify the deployment's storage configuration. |
| Failures are returned in a documented machine format. | Unhandled exceptions become RFC 9457 application/problem+json with no exception detail leaked — src/Verifable.Server/GlobalExceptionHandler.cs. |
Veritas evidence database
Veritas is first-party Lumoin technology with public source. These are engine capabilities, not simulations in the public Workbench. The Workbench has a deliberately smaller deployment boundary described on the Veritas product page.
| Claim | How to check |
|---|---|
| Veritas runs as a real in-memory mutable database. | VeritasEngine.OpenMutableAsync selects InMemoryDatasetJournal when no durable journal path is supplied; database tests exercise commit, query, reopen and world operations. |
| Veritas can ask spatial questions over the same graph that holds product and lifecycle evidence. | Engine tests run location and relationship queries through the normal SPARQL path. GeoSPARQL support is implemented and tested in the release candidate; full GeoSPARQL conformance is not claimed. |
| Durable storage detects torn journal tails and protects coherent multi-graph snapshots. | FileBackedDatasetJournalTests exercises torn-tail recovery and flush failure; VeritasEnginePersistTornSnapshotTests races commits across graphs and proves persistence never captures a mixed snapshot. The documented Windows pointer-rename power-loss window remains explicit. |
| A dataset can fork a possible world without copying the graph or changing current truth. | MutableSparqlDataset.ForkAsync shares the term dictionary, arena and content-addressed state; DiffFrom returns exact graph additions and removals. |
| Independent active-active processes accept changes and converge over a real peer transport. | ActiveActiveReplicateProcessTests starts separate CLI processes, writes to independently owned stores and proves convergence, including writes that land between pull rounds. |
| Decentralized reconciliation carries removals rather than resurrecting stale facts. | DottedReplicateProcessTests proves a retraction survives pairwise repair and moves transitively through three independent processes. Partition and corrupt-sketch cases fail closed and then converge. |
| The engine exposes structured internal trace and OpenTelemetry surfaces. | SparqlExecutionTraceEvent reports operator strategy, inputs and outputs; reasoning, storage, repair, replication and network-governance events use the same correlation-oriented trace model, with named veritas.* metrics. |
| Verifable has a runnable local MCP binding and a tested hosted MCP server binding. | VeritasMcpServer exposes sparql_query, graph_analytics and graph_analytics_list over local stdio. Verifable.Server implements dual-era POST /mcp/{segment}, its RFC 9728 metadata and the mcp.tools gate for resolve_did, sparql_query and public dpp_chain_walk, plus the governed product_passport_get. That fourth tool takes only a product identifier; the validated token supplies caller, tenant, represented principal under RFC 8693 delegation and disclosure tier. Where tenant configuration allows the dpp.stakeholder scope, that grant receives the full signed credential, while other grants receive a masked public projection with restricted fields absent and proof removed. Every served or refused read records dpp.passport.read, joined to decision and action evidence by the returned trace identifier. The MCP and HTTP reads dispatch through the same typed operation. The hosted binding is implemented and integration-tested; named-origin activation and external partner proof are recorded separately. |
| An additional consensus mode is in advanced testing. | It is being tested in Verisync and is not part of the current Veritas deployment. |
Wallet protocols
These run against the pre-seeded test sandbox tenant at /connect/test/, open without provisioning or an account. Its keys are regenerated on every server restart, so credentials issued here suit integration work. The catalog and endpoint reference are in the sandbox.
| Claim | How to check |
|---|---|
| Credentials are issued over OpenID for Verifiable Credential Issuance 1.0. | POST /connect/test/oid4vci/offer, Pre-Authorized Code grant, with issuer metadata at /.well-known/openid-credential-issuer. Scan the offer with any OID4VCI wallet from the sandbox. |
| Credentials are presented over OpenID for Verifiable Presentations 1.0. | POST /connect/test/oid4vp/request, with nonce and audience binding. |
| SD-JWT VC (dc+sd-jwt) is issued. | Configuration verifable.identity.sdjwt.1 in the catalog, plus a HAIP variant whose metadata declares key attestation. |
| ISO/IEC 18013-5 mdoc (mso_mdoc) is issued and verified. | Configuration verifable.identity.mso_mdoc.pid.1, issued as an mdoc document with a COSE_Sign1 IssuerAuth; the verifier accepts our own issuance key and foreign IACA root certificates as trust anchors. |
| UNTP passports, conformity credentials, and traceability events are issued as wallet-redeemable credentials. | DigitalProductPassport, DigitalConformityCredential, and DigitalTraceabilityEvent configurations, secured as enveloping JWS (vc+jwt). |
| Veritas is integrated into the native wallet codebase as a semantic credential-store path. | The integration is implemented and tested, but remains opt-in. The installed wallet still uses SQLite by default. |
| Hardware-backed holder-key protection is in development. | The current app does not use hardware-backed protection for its production holder keys today. |
Regulations, by number
| Instrument | What runs today |
|---|---|
| Regulation (EU) 2023/1542 — Batteries Regulation | Issuing a passport uses this regulation's battery passport clusters as its form fields, SHACL-gated on the matching shape, and /vc/validate?schema=battery-passport validates the same clusters standalone. |
| Regulation (EU) 2024/1781 — Ecodesign for Sustainable Products (ESPR) | The passport mechanics this framework needs — signed credentials, resolvable product identity, tiered access, event history — are shipped and listed above, and the battery product group is built on them. Per-group data requirements arrive through ESPR delegated acts. |
| Regulation (EU) 2024/1183 — eIDAS 2.0, amending Regulation (EU) No 910/2014 | The wallet protocol layer it governs is implemented and listed above: OID4VCI, OID4VP, SD-JWT VC, mdoc, and a HAIP-shaped PID. Conformance testing against the EUDI Architecture and Reference Framework is a separate exercise and has not been done. |
If this checks out
Start with the available public tools: run the sandbox, issue a passport, query the playground, read the contract, or take this page itself as /llms.txt. For organisation access, sign in or use an invitation. Data retention depends on the service and deployment, not sign-in alone. What it costs today is on pricing. Who is behind it is on the company page. Corrections are welcome: hello@lumoin.com.