Identity, programmable
Compliance
ARF, eIDAS 2.0, GDPR, NIS2 — how Broker maps to each regulatory frame, plus the six attack vectors it neutralises.
Broker is the product in the Thoryn catalog most tightly bound to the eIDAS 2.0 regulatory framework. It's the relying-party side of the EU Digital Identity Wallet ecosystem.
ARF (Architecture and Reference Framework)
Currently aligned (ARF 1.4+)
- OpenID4VP flow — tested against the NL + EU reference wallets
- SD-JWT VC — full IETF draft support (disclosures, commitments, cnf holder binding)
- Selective disclosure —
limit_disclosure: requiredhonoured; undisclosed claims protocol-unreachable - Trust chain — Trust Registry integration with issuer revocation
- W3C Presentation Exchange 2.0 presentation definitions
- Holder binding via
cnf.jwk - IETF OAuth Status List — bit-level revocation check on every presentation
Roadmap
- mdoc (ISO 18013-5) — partial today; full conformance tracked
- Wallet attestation verification (attest the presenting wallet was provisioned by a trusted provider)
- Trust-list Federation via OpenID Federation 1.0
eIDAS 2.0 (Regulation (EU) 2024/1183)
Relying parties verifying EUDIW credentials must publish an RP-register entry, request only what's needed (data minimisation), store presentations for audit, and offer user control. Broker's role:
- Presentation definitions enforce only the requested claims; wallet selective disclosure blocks leakage
- Every session + every verification decision is persisted with reasons
- Presentation definitions carry display metadata so wallets can render informed-consent screens
GDPR
Broker processes verification events (session metadata, success/failure, timestamps). It does not persistently store verified claims — those go to your webhook. Stronger than filtering: undisclosed claims are cryptographically unreachable, so a compromised Broker operator still cannot recover them.
- Session TTL: 10 minutes (configurable)
- Audit records: 1 year default (configurable)
- Verified claims: not stored by Broker
- Hetzner Germany — no third-country transfers from Broker
NIS2
Broker supports the customer's NIS2 posture: ES256 signatures everywhere; TLS 1.3 in transit; self-hosted dependencies (Postgres, Redis, Trust Registry); Prometheus metrics for failed-verification spikes, replay-detection, and trust-chain failures.
Fraud resistance
Six attack vectors, six protocol-layer mitigations. All six covered in the Red-team demo.
| Attack | Mitigation |
|---|---|
Attacker shares a credential they don't own | Holder binding The VP token is signed by the holder's key; the credential embeds a cnf claim with the holder's public key. Without the private key, no valid VP token. |
Attacker replays a valid presentation | Nonce + VP-token-hash cache Each session carries a nonce the wallet includes in the signed request. Broker caches every accepted VP token hash for 24 hours. |
Attacker tampers with claims | Signature validation Any alteration invalidates the issuer's signature. Broker validates the full credential; tampered claims fail check #2. |
Illegitimate issuer | Trust Registry Issuers not listed → rejected. Illegitimate issuers never appear in the list. |
Issuer has been revoked | Trust Registry revocation The issuer's entry is marked revoked → Broker rejects on the next verification. |
Credential has been revoked | Status list Broker resolves status.status_list.uri, checks the indexed bit, rejects on revocation. |
Auditor-ready evidence pack
- Architecture diagram with signature-validation steps
- SBOM of the Broker container
- CI conformance report against reference wallets
- Audit-log schema with sample failure-reason records
- GDPR Art. 30 register for Broker-specific processing
- Red-team demo with repeatable attack scripts
Request via security@thoryn.io.
Also on Broker
Ready to verify credentials?
Request access to run the demos and wire Broker into your app.