Identity, programmable

Integrations

Broker is the verification side of the credential fabric. Here's how it composes with every other Thoryn product.

Broker is the verification side of the Thoryn credential fabric. Downstream of trust decisions (Trust Registry), upstream of access decisions (Policy Engine). Here's how it composes.

Broker at the centre, connected to Trust Registry, Credential Issuer, Cloud Wallet, Wallet SDK, Policy Engine, and TrustGate — Broker at the centre of verification — every other product either supplies input (Trust Registry, VCT Registry, wallets) or consumes output (Policy Engine, TrustGate, your app).

Thoryn catalog composition

Broker + Trust Registry

Pattern: Broker consults Trust Registry on every presentation for issuer JWKS and trust status. Revoke at Trust Registry → every verifier rejects in seconds.

Wiring: IssuerJwksCache (Redis-backed) points at the Trust Registry's issuer lookup endpoint. Per-wallet-profile config can pin a specific Trust Registry.

Broker + Credential Issuer

Pattern: Credential Issuer mints; Broker verifies. Both share SD-JWT VC, so any ARF-compliant verifier works — the wiring is via Trust Registry, not direct.

Wiring: End-to-end test fixture mints a credential, a holder presents, Broker verifies. Used in CI to catch cross-product regressions.

Broker + Cloud Wallet

Pattern: Cloud Wallet holds credentials server-side and presents via standard OpenID4VP. From Broker's perspective, it's just another holder.

Wiring: Zero Broker-side config. Cloud Wallet implements the holder half of OID4VP; Broker sees a standard VP token.

Broker + Native Wallet SDK

Pattern: Wallet SDK is the phone-side holder; Broker is the server-side verifier. SDK's present() call against Broker's request_uri.

Wiring: Protocol-pure — no SDK-specific handshake.

Broker + Policy Engine

Pattern: Policy Engine decides ALLOW / DENY on verified claims after Broker verifies them, before webhook delivery. Lets you encode 'licensed practitioner type X in region Y' policies as rules.

Wiring: Wallet profile config includes a policy_rule_id. DENY short-circuits the flow with an error on the session.

Broker + VCT Registry

Pattern: Broker resolves credential-type metadata from VCT Registry when a presentation arrives. Caching + fallback follows the IssuerJwksCache pattern.

Wiring: VctResolver calls VCT Registry; metadata cached per TTL.

Broker + TrustGate

Pattern: TrustGate's physical verifier doesn't run full OID4VP logic — it delegates to Broker. Door opens when Broker returns a completed session.

Wiring: TrustGate config points at a Broker URL + wallet profile per door.

Broker + Hub

Pattern: Usually independent. Your app may require both an OIDC session (Hub) and a credential presentation (Broker) for sensitive operations. Each has its own audit trail.

Wiring: No direct wiring; they operate on the same user but on different axes.

Broker + eIDAS Verifier

Pattern: eIDAS Verifier is a specialised Broker for EUDIW PID + attestation credentials. Decision guide: member-state / qualified issuer → eIDAS Verifier; private / sectoral SD-JWT → Broker.

Wiring: Two products that share a verification engine but ship different policy defaults.

External-system integrations

Your app: Two touch-points: POST /broker/sessions from your back-end, and an HMAC-verified webhook receiver. An OpenAPI spec at GET /broker/openapi.json generates typed clients.
Your wallet: Any ARF-conformant wallet: NL reference (CI-tested), EU reference (CI-tested, feature-flagged until GA), Thoryn Wallet SDK, Cloud Wallet, commercial EUDIW wallets. Compatibility is driven by credential format, not wallet brand.
Your Trust Registry: Thoryn's, a self-hosted instance, or a third-party ecosystem registry. Per-wallet-profile configuration.
Your SIEM: Every verification event emits structured logs (broker.session.created, presentation.received, presentation.verified, presentation.rejected with failure_reason, webhook.delivered/.failed). Ship to Elastic, Loki, Splunk.
Your policy service: If not using Thoryn's Policy Engine, Broker calls any HTTP policy-decision endpoint that returns {allow, reasons}. Integrates with OPA, Cedar, or a homegrown service.

Also on Broker

Ready to verify credentials?

Request access to run the demos and wire Broker into your app.

Get started Book a demo