What this is — and what it is not.

Thoryn is a federated trust orchestration layer. It connects identity providers, credential issuers, wallets, verifiers, and relying parties so that trust signals — supplier certifications, partner authorizations, compliance attestations, delegations, role proofs, organization claims — can be issued by one party, verified by another, and re-verified by an auditor years later.

Thoryn does not replace enterprise IdPs. It complements existing IAM (Okta, Entra, OIDC providers, SCIM directories) with a verification layer that travels with the credential, not with the session.

• Paste any compact JWS / Verifiable Credential issued through the Thoryn broker and inspect the verdict: signature, validity window, Status List 2021 revocation status, issuer recognition.
• See the full chain-of-custody tree — upstream issuers, combine/split events, and the per-node verdict at the moment the credential was handled.
• Replay the same credential against any historical date inside the retention horizon; the broker resolves the issuer's JWKS as it existed at that moment, even after key rotations.
• Download a regulator-shaped receipt PDF you can replay offline years later via thoryn audit-replay --chain.

Most enterprise IT today federates identity — Okta handles who can log in, Entra handles which application someone can open. That answers who is this user.

Federated trust answers a different question: is this credential, certificate, attestation, or claim trustworthy right now? Supplier onboarding wants to verify a fair-trade certification. Procurement wants to confirm a partner's ISO accreditation. API access wants to gate on a compliance attestation. M&A due diligence wants to replay a contract signature against historical keys. Each of these is a trust signal flowing between organizations — not a login. Thoryn is the layer that makes those signals issuable, verifiable, revocable, and replayable across organizational boundaries.

The sandbox itself is free forever. Anyone can verify against sandbox-signed credentials, anyone can download receipt PDFs, anyone can run the replay tool. No account, no rate-limit-by-tenant, no per-call charge.

The paid path is for issuers who want to publish their own signed credentials through a Thoryn broker. An issuer becomes a Thoryn tenant, receives an issuer-bridge integration with their own Vault Transit key, and their credentials live in their own tenant with strict scope-based isolation from the sandbox and from other tenants.

The verification primitives demonstrated here apply across the EU regulations driving the move to verifiable credentials:

• eIDAS 2.0 + EUDI Wallet. W3C VC 2.0 + OID4VP are the wire format the EU is putting legal weight behind for verifiable credentials. Thoryn rides the same rails.
• NIS2 / DORA. Supply-chain measures and ICT third-party register requirements both demand auditable, replayable evidence chains for external parties touching the operations.
• CRA (Dec 2027). Software-manufacturer obligations under Article 13 and 14 are one specific application of the same verification + revocation primitives. The architecture is regulation-agnostic — the same broker carries identity, supply-chain, and compliance credentials.

Thoryn is intentionally complementary to the tools you already have:

• Existing IdPs. Okta, Entra, Auth0, Keycloak — Thoryn federates with them as upstream identity providers. Your users keep logging in where they always did.
• Existing verifiable-credential ecosystems. Thoryn doesn't replace wallet vendors, issuer SDKs, or transparency logs. It gives them a place to land inside enterprise workflows — relying parties don't need a separate integration with every issuer.
• Existing compliance stacks. GRC platforms, audit-evidence vendors, certificate authorities all keep doing what they do. Thoryn turns their outputs into credentials that travel.

The Thoryn verification sandbox demonstrates cryptographic verification of trust credentials issued through a Thoryn broker. The sandbox is advisory and educational; verifying a credential here does not constitute a legal or commercial assurance about the underlying organization, product, or claim. When a displayed credential describes a regulated product or service, manufacturer- and operator-liability under applicable EU regulation remains with the issuing organization. To run your own attested credentials under your own signing key, contact Thoryn about an issuer-bridge integration.

Source code lives in the Thoryn monorepo under apps/sandbox/. For commercial enquiries (issuer-bridge integration, tenant onboarding, federation with your existing IdP), visit the Thoryn marketing site.

← Back to the sandbox home