For identity providers & KYC vendors

Verify once. Let them prove it everywhere, without resubmitting documents.

Last updated: 30 August 2026

Every new relationship repeats the same onboarding: the same documents, the same checks, a new copy of the customer’s identity in another organisation’s database. The cost is yours and the customer’s; the risk multiplies with every copy.

What we do, and what we deliberately do not

We consume identity. We never reissue it. Your verification remains the trust anchor and the customer relationship remains yours. What SPT‑Txn adds is a portable, privacy‑preserving form of the assertion you already produce.

A compliance attestation in standards‑based form — W3C Verifiable Credentials, serialized as SD‑JWT VC — bound to a privacy‑preserving commitment to the human, not to a name.
Selective disclosure: the relying party receives the fields it needs and nothing else; other conditions are proven in zero knowledge rather than revealed.
Delegation: the customer, or an agent acting for them, can pass on a strictly narrower slice of that authority without another round of onboarding.

It plugs into what you already run

Integration is a standard OAuth 2.0 Token Exchange (RFC 8693) against your existing OpenID Connect provider — no rip‑and‑replace, no proprietary protocol, and the exchange endpoint validates your tokens against your live JWKS.

Stated precisely, because the difference matters: the flow is proven end‑to‑end against Keycloak, including a one‑command local deployment. For PingOne and Auth0 we ship hermetic conformance tests against those providers’ actual token shapes — discovery, JWKS, claim structure and both machine‑to‑machine and user flows — run in CI with no tenant required. Those are conformance tests, not live tenant runs, and we distinguish the two rather than blurring them.

Algorithm agility, without a flag day

Every token names the algorithm it was signed with, and a signed trust registry decides which algorithms and which issuers are accepted. That is what lets a deployment move to post‑quantum signatures gradually, per issuer, instead of coordinating a single cut‑over across every relying party at once.

You run it. That is the point.

The control plane belongs with the regulated entity that already carries the obligation. We publish the software under Apache‑2.0; you deploy it, you hold the keys, you set the policy, and no transaction detail reaches us or anyone else. We do not operate a service in your money path and we take no fee per transaction.

Honest boundaries

SPT‑Txn is a proof of concept and a specification effort. Nothing in it has been externally audited or certified, and it is not in production use. Our security reviews are our own. On‑chain footprints are on public testnets except where stated otherwise. An independent review of the zero‑knowledge circuits and the protocol is wanted and has not happened. We say this plainly rather than implying assurances we have not earned. One more, since an institution will ask it first: key reconstitution is designed but not settled. If an issuer loses its signing key, the revocation cascade and a cross‑organisation quorum are specified, but the ceremony shape is an open decision. Who holds what, and what it takes to stand an issuer back up without invalidating the delegations beneath it, is not a runbook we can hand you today.

If this is useful to you

Everything is public and reproducible — the reference implementation, the specification work, and the tests behind each claim above.

Reference implementation on GitHub →
Framework paper and IETF Internet‑Draft →
rudi@violetskysecurity.com