Platform
What is Thoryn?
Thoryn is a trust spine for European software. It signs the credentials your customers present, verifies the credentials others present to you, and writes every check to an audit chain you can replay.
Five layers compose the stack — application surface, verifiable credentials, the broker, trust primitives, and the sovereign signing root.
Every signature ties back to a Vault Transit key under EU jurisdiction. The audit row survives the system that signed it.
How it works
Five layers, one trust spine.
The Thoryn architecture is a stack you read top to bottom. Applications at the surface — phones, browsers, kiosks, CLIs — issue or present credentials. The credential layer carries those payloads as W3C VC 2.0. OID4VP and OID4VCI are the wire format. The broker mediates: federation, issuance, verification, revocation, audit. Below the broker sit the trust primitives. Each tenant gets its own Trust Registry, a Status List 2021 bitmap for revocation, and a historical JWKS endpoint. A credential issued in 2025 still verifies in 2032 against the key that signed it. At the floor is the signing root: Vault Transit, ECDSA P-256, EU-hosted, no US cloud on the hot path.
Architecture
The stack, in full.
Click any layer to inspect its sub-components and canonical specs. Every link points to the original standards body — no aggregator pages, no shorteners.
Applications
Phone scan · Browser · Desk-tablet · Drone ground station · API
Sub-components
- Phone scan (apps/scan)
- Holder portal (apps/holder)
- Customer console (apps/console)
- thoryn CLI
- Tenant API integrations
Verifiable Credentials
W3C VC 2.0 · OID4VP · OID4VCI · C2PA-aligned
Sub-components
- W3C VC 2.0 data model
- OID4VP presentation flow
- OID4VCI issuance flow
- C2PA-aligned provenance
Standards
Thoryn Broker
Federation · Issuance · Verification · Revocation · Audit
Sub-components
- Federation members
- Credential issuance
- Wallet + wallet-less verify
- Revocation propagation
- Verifiable audit chain
Standards
Trust Primitives
Trust Registry · Status List 2021 · Historical JWKS
Sub-components
- Trust Registry (per-tenant)
- Status List 2021 bitmap
- Historical JWKS
- Issuer key history
Standards
Sovereign Signing
Vault Transit · ECDSA-P256 · EU-hosted, no US cloud
Sub-components
- Vault Transit signing engine
- ECDSA P-256 keys
- Per-tenant key isolation
- EU-hosted infrastructure
Standards
Trust primitives
The mechanisms that make a verdict checkable.
Five primitives carry the load. Who you trust. What is still good. Which key was current at issuance. How a credential descends from its parents. What the system claims to have done.
Trust Registry
Per-tenant list of issuer DIDs and their accepted credential types. Live-queried on every presentation; revoke an issuer once and every verifier rejects in seconds.
Status List 2021
W3C Status List bitmap signed by the broker and served per-tenant. Verifiers consult the bit at the credential's index — fresh-revocation policy is set per credential class.
Historical JWKS
The current JWKS stays small for hot-path verification. A separate historical-jwks endpoint exposes every retired kid across the row retention horizon, so a credential issued in 2025 still verifies in 2032.
Chain-of-custody DAG
A directed acyclic graph of parent credentials. Combine 12 batches into 1 outgoing (fan-in); split 1 incoming into 850 retail bags (fan-out). Buyers walk the graph back to origin.
Signed audit chain
Every verification writes a hash-chained row signed by a tenant-scoped Vault key. The chain is verifiable end-to-end with the replay tool — the audit trail outlives the system that wrote it.
Auditability
Replay against history, not against now.
Auditors arrive months after the credential was presented. They ask a single question: was this verdict sound when you wrote the row? Thoryn answers by reconstructing the state at that timestamp. The issuer key that was current. The Trust Registry contents. The Status List bit. The wallet policy version.
The audit-replay tool walks the chain forward from a known anchor. It recomputes each row's HMAC against the tenant key version that signed it. It then prints the verdict the row should have produced. Counterparties can run the same replay against the same signed receipt — no shared infrastructure required.
Audit rows are retained for at least seven years, per eIDAS. The historical-jwks endpoint covers the same window, so retired keys remain verifiable. C2PA-aligned receipts let downstream tooling cross-reference content provenance with the audit row that signed it.
# Replay an audit row as it stood on 2025-08-14.$ thoryn audit-replay --row 0x9c4e…b8a1 --against 2025-08-14↳ resolved tenant: acme-eu-prod↳ key version at issue-time: v3 (kid: ek-7f2a)↳ historical-jwks: 2 retired kids covered↳ trust registry snapshot: r-2025-08-14T09:12:03Z↳ status-list bit @ index 41,902: clear↳ wallet profile pinned: walletless-v1verdict: VALID — row HMAC matches signed state# Run with --counterparty for a portable receipt.Sovereignty
EU jurisdiction by structure, not by toggle.
Sovereignty is a property of the trust spine, not a deployment flag. Every link in the chain is in the EU; every signing key is under a jurisdiction Thoryn controls.
Vault Transit signing
Issuer keys, broker keys, and audit-row HMAC keys live in HashiCorp Vault. The JVM never touches a key directly — every signature is a Vault round-trip. Heap dumps cannot forge a row.
EU-hosted clusters
Compute and storage run on Hetzner Germany (Falkenstein and Nürnberg). No US-cloud component sits on the hot path. The CLOUD Act has no jurisdictional purchase.
Open-source critical components
The broker, the issuer-bridge framework, and the audit-replay tool are open source. A customer who needs to fork can. Inspect the signing strategy at adrs/2026-04-26-jwt-signing-strategy.md.
No US cloud on the hot path
DNS, edge, and storage all sit on EU-incorporated providers. The platform refuses an outbound URL that resolves to AWS, GCP, or Azure metadata IPs — enforced in code, not policy.
Standards
Pinned to the spec, not to our interpretation.
Every credential format, every wire protocol, every cryptographic primitive points to a published specification — W3C, OpenID Foundation, IETF, NIST. Pinned versions; no aggregator sites.
| Specification | Version pinned | Where it appears |
|---|---|---|
| W3C Verifiable Credentials Data Model | 2.0 | Credential payload format |
| OpenID for Verifiable Presentations | Draft 24 | Wallet → verifier presentation |
| OpenID for Verifiable Credential Issuance | Draft 15 | Issuer → wallet issuance |
| W3C Status List 2021 | Candidate Rec. | Per-tenant revocation bitmap |
| C2PA Content Credentials | 2.1 | Content provenance receipts |
| EUDI Architecture Reference Framework | 1.4+ | EU wallet relying-party surface |
| RFC 6749 — OAuth 2.0 | 2012 | Authorization framework |
| OpenID Connect Core | 1.0 | OIDC federation flows |
| RFC 7517 — JSON Web Key Set | 2015 | Current + historical JWKS |
| FIPS 186-5 — ECDSA | 2023 | Signature primitive (P-256) |
See the spine for yourself.
Sign a sandbox SBOM credential, walk an audit chain, or talk to the team about your verification problem. No request form, no calendar invite.