How a specialist team built the digital identity
engine inside SarawakPass

The specialist vendor team—which I was a core member of—focused on three areas that form the proprietary offering:

• •Digital Identity — verifiable credentials, identity verification flows, and self-sovereign identity infrastructure
• •IAM (Identity and Access Management) — single sign-on, authentication protocols, and credential lifecycle management
• •Digital Wallet SDK — a hardened, OWASP MASVS-compliant mobile SDK that powers the wallet experience on iOS and Android

The team: seven people. Two iOS engineers. Two Android engineers. Two backend engineers specialising in digital identity. One technical lead. We built the full package — SDK, backend identity services, and a standalone validator application — and delivered it as proprietary IP to the main contractor for integration into SarawakPass.

The core of what the team built is a verifiable credentials system. Here's what that means in practice.

When a citizen completes eKYC (electronic Know Your Customer) — scanning their Malaysian IC and verifying their face — the government issuer signs a digital credential asserting something about that person. For example: "This person holds a valid Sarawak digital identity." That credential is cryptographically signed and stored in the user's wallet.

When the citizen needs to prove who they are — at a government counter, at a service desk, at a border checkpoint — they present that credential. The verifier checks the cryptographic signature, not a database lookup. This is self-sovereign identity in action: the user holds their own credentials, and verification happens without calling home to a central server.

The team implemented this using SD-JWT-KB (Selective Disclosure JSON Web Token with Key Binding). Here's why that matters:

• •Selective Disclosure (SD) — the user can prove they're over 18 without revealing their exact date of birth. They can prove they're a Sarawak resident without revealing their full address. Each attribute in the credential can be disclosed independently.
• •Key Binding (KB) — the credential is bound to the device's cryptographic key. Even if someone copies the token, they can't use it because they don't hold the private key. The presentation proof requires signing with the device's key, proving the presenter is the legitimate holder.
• •JOSE (JSON Object Signing and Encryption) — the underlying format for encoding, signing, and optionally encrypting the credential data. The team used JWS (JSON Web Signature) for integrity and JWE (JSON Web Encryption) where confidentiality is required.

Sarawak is the largest state in Malaysia. Much of it is rural, with limited or no internet connectivity. If digital identity only works online, it fails the people who need it most.

The system was designed so that verification works without any network connection. Here's how:

• •Local credential storage — all verifiable credentials are stored encrypted on-device. When the user opens their wallet, everything is there. No loading spinner waiting for a server.
• •BLE proximity transfer — when a citizen needs to prove their identity to a verifier (e.g. a government officer in a rural area), both devices communicate over Bluetooth Low Energy. The citizen's app sends the credential and a fresh presentation proof. The validator app verifies it locally using the cached issuer public keys. No internet required on either side.
• •Proprietary proximity data sharing — two engineers on the team built the BLE data transfer protocol entirely in-house. This is a proprietary proximity sharing implementation — not an off-the-shelf library. Every packet transmitted over BLE is wrapped in an SD-JWT-KB presentation, which means even if an attacker intercepts the Bluetooth signal, they cannot modify or hijack the data. The key binding proof ties the presentation to the holder's device key, making man-in-the-middle attacks cryptographically detectable. Without the legitimate device's private key, intercepted data is useless.
• •Sign digest verification — the presentation includes a cryptographic signature (a digest) that the validator checks against the credential. If the signature is valid and the credential hasn't expired, the identity is confirmed.

This means a government officer standing in a longhouse in the interior of Sarawak can verify a citizen's identity using nothing more than two phones and Bluetooth.

Alongside the SDK, a standalone validator application was built. This is the tool that government officers, service desk staff, and other verifiers use to check a citizen's credentials.

The validator does three things:

1. 01Receive — accepts a credential from the holder app via QR code scan or BLE proximity transfer.
2. 02Verify — checks the issuer's cryptographic signature, confirms the credential hasn't been tampered with, validates the key binding proof (confirming the presenter holds the legitimate private key).
3. 03Display — shows the verified identity attributes to the verifier, with clear indication of which attributes were selectively disclosed.

The validator works fully offline. It caches the government issuer's public keys, so it can verify credentials anywhere — at a border checkpoint, in a rural clinic, at a government counter during a network outage.

The deliverable to the main contractor was a complete, self-contained package:

• •Digital Wallet SDK — iOS and Android libraries for credential storage, presentation, and verification, with full OWASP MASVS security hardening
• •Verifiable Credentials Engine — SD-JWT-KB issuance, selective disclosure, key binding, and signature verification — online and offline
• •Validator App — standalone verifier application for government officers and service desks, with BLE and QR code credential acceptance
• •Identity Backend — issuer services, key management, CSR processing, and credential lifecycle management
• •Secure Enclave Integration — hardware-backed key pair generation and CSR creation on iOS and Android
• •SDK Security Suite — jailbreak detection, anti-tampering, anti-reverse engineering, proxy detection, and runtime hook detection

All of this is proprietary intellectual property — licensed to the main contractor as part of the SarawakPass ecosystem.

2.9 million Sarawakians. Government services that range from digital payments to land surveys to healthcare benefits. An environment where internet connectivity is not guaranteed. And a threat model that includes state-level actors, organised fraud, and physical device compromise.

Building a digital identity system for this context is not the same as adding "Sign in with Apple" to a consumer app. Every cryptographic decision, every offline fallback, every SDK hardening measure exists because the system has to work for a real person standing in front of a real government officer, possibly with no internet, possibly on a compromised device — and still deliver a trustworthy result.

That's what the team built. That's what SarawakPass runs on every day.