Thoryn

Wallets, programmable

Compliance

ARF high-assurance, GDPR as a tool (controller = your app), NIS2, DORA, and the App-Store disclosure shape.

The SDK's design — hardware-backed keys, biometric gate, device-bound storage — is what ARF prescribes for high-assurance holder wallets. It's a compliant starting point; your app adds the deployment, registration, and operational compliance on top.

Native Wallet SDK compliance posture — ARF high-assurance eligibility, wallet attestation, GDPR, NIS2, DORA, mobile-app disclosures
Hardware-backed keys via Secure Enclave / Android Keystore · biometric gate · ARF high-assurance eligible · wallet attestation roadmap.

ARF high-assurance eligibility

  • Secure Enclave / StrongBox — keys never leave secure hardware
  • Biometric gateBIOMETRIC_STRONG on Android; LAPolicyDeviceOwnerAuthenticationWithBiometrics on iOS
  • Per-device binding — keys are not exportable, not transferrable

Wallet attestation (roadmap)

ARF expects wallet providers to attest their wallet binaries and provisioned keys. The SDK supports attestation on the holder side today (sending an attestation during presentation). The wallet-provider side — operating as a qualified wallet provider — is a further integration, requiring member-state accreditation alongside the software.

GDPR

When your app embeds the SDK, you are the data controller for the user's credentials. Thoryn provides the SDK — a tool — not the processing operation.

  • Lawful basis: consent (Art. 6(1)(a)) or contract performance (Art. 6(1)(b))
  • Access (Art. 15): the user's in-app credential list is an Art. 15 surface
  • Erasure (Art. 17): user can delete individual credentials or their wallet
  • Data minimisation: selective disclosure preserved; only requested claims leave the wallet
  • International transfers: SDK runs on the user's device; no transfer concern at the SDK layer

NIS2

Your app + SDK contribute to your organisation's NIS2 posture: biometric-gated presentations, hardware-bound keys, per-credential consent, ES256 / EdDSA signatures, TLS 1.3 outbound. SDK is a documented third-party dependency in your supply chain.

DORA

For financial-services customers, the SDK is documented as a third-party ICT service component (Art. 28–30). Incident-response for SDK-related events flows into your Art. 17–23 reporting. Right-to-audit clauses apply.

Mobile-app disclosures

Your app's App Store / Play Store privacy disclosures must cover credential data held on-device, biometric usage (per-platform disclosure), and network calls to Credential Issuer / Broker / Trust Registry. SDK documentation provides the reference.

Ready to embed a wallet in your app?

See the ADR, the scaffold, and the roadmap — book a 30-minute integration call.