Technical Projects &
Case Studies
Detailed breakdowns of systems I have designed, built, and optimized.
mdoc-builder (Mobile Driving Licence)
The `mdoc-builder` is an open-source Java library built in collaboration with GDS and key government departments. It provides the core cryptographic mechanisms to package, sign, and issue compliant Mobile Driving Licences (mDL) that adhere strictly to the **ISO/IEC 18013-5** international standard.
Applying strong technical judgement to match both DVLA and GDS needs against a rapidly evolving ISO standard, I chose to design this library from scratch with minimal external dependencies. This avoided hacky integrations of incomplete third-party packages, producing a lightweight, secure, and easily extendable core. To ensure maintenance standards, I personally configured SonarQube, Checkstyle, and security vulnerability checks inside CI/CD deployment pipelines.
In digital identity, privacy is paramount. Using CBOR (Concise Binary Object Representation) namespaces and COSE (CBOR Object Signing and Encryption) cryptography, this library allows driver attributes to be divided into individual digests, enabling **Selective Disclosure** (proving you are over 18 without disclosing your full name or exact birthdate).
Key Engineering Contributions:
- Personally designed and developed the core mdoc-builder Java library from scratch.
- Created cryptographic signing interfaces to securely bind driving credentials to mobile device hardware keys.
- Integrated SonarQube, Checkstyle, and Tenable vulnerability checks within CI/CD pipelines to guarantee code compliance.
- Built local containerized Kubernetes replica environments using Docker for simplified squad testing.
Project Technical Stack
How It Works: Interactive Flow
mdoc Certificate & Issuance Lifecycle
This interactive demo illustrates how driving licence certificates are requested, cryptographically bound to hardware security enclaves, and signed by the DVLA root CA.
1. Device Key Provisioning
The mobile wallet generates a secure device public/private key pair (typically using hardware-backed keystores like iOS Secure Enclave or Android Keystore). The private key never leaves the device.
// Public Key (COSE_Key format)
{
1: 2, // Key Type: EC2
3: -7, // Algorithm: ES256
-1: 1, // Curve: P-256
-2: h'd759713f...', // X coordinate
-3: h'f4a22d3e...' // Y coordinate
}Other Systems I've Built
Enterprise integrations and open source contributions.
Transactional Serverless Broker
Designed and implemented a serverless message broker to ingest and validate transactional event streams for high-throughput enterprise applications. Built with Go for sub-millisecond execution times and cost efficiency.
Handled peak loads of 15,000 requests/sec, reduced cloud operational costs by 60% compared to ECS-based container alternatives, and guaranteed at-least-once message delivery protocols.
Commercial Management System (CMS)
Designed and built an Electron-based desktop application integrating a Vue frontend with a Node.js/TypeScript backend. The system handles full business operations including customer accounts, stock management, and serial communication to interface with and control physical devices over Serial I/O.
Successfully deployed and live across 50+ individual business locations in collaboration with a primary industry partner, with ongoing feature development.
Custom E-commerce Platform
Developed and maintained a custom, pixel-perfect e-commerce platform built on Laravel with an HTML and jQuery frontend. Worked closely with external designers to translate designs into high-converting layouts, integrating Stripe, PayPal, and Worldpay payment gateways.
Supported the platform continuously for over 10 years, scaling to process over £1 million in annual gross revenue.
Legacy System Modernization
Led the comprehensive modernization of a legacy custom PHP 5 application responsible for managing the entirety of a client's business operations. Refactored the codebase for compatibility with PHP 8, patched all known security issues, and implemented new features.
Successfully extended the lifespan of a business-critical system, avoiding expensive rewrite costs and improving system security.
Inside the ISO/IEC 18013-5 Spec
Mobile driving licences (mDLs) are not simply digital images or signed PDFs. They are highly structured, cryptographically verifiable data envelopes designed to protect user privacy and establish undeniable authenticity. Here is how the data structures inside `mdoc-builder` are composed.
[01]Dual Envelope Architecture
An mdoc contains two distinct cryptographic envelopes that separate the Authority's claim signature from the Holder's device authentication.
Contains raw user claims (e.g. given name, portrait) grouped by namespace. Each claim is encoded as an individual IssuerSignedItem along with a salt. Hashes of these items are stored in a signed Mobile Security Object (MSO).
Contains a dynamic signature generated on-device using a private key locked in the hardware's Secure Enclave. This proves that the person presenting the mDL is the actual holder, preventing clone attacks.
[02]Anti-Correlation
To guarantee user privacy, the spec enforces safeguards against correlation (tracking a user across multiple verifiers) and dictionary attacks:
- •16-Byte Random Salt: Every claim includes a minimum 16-byte random salt. Without it, public fields (e.g., given_name = "Joe") could be resolved by verifiers running offline hash tables.
- •Digest ID Shuffling: Claims are assigned unique `digestID` integers. In `mdoc-builder`, we generate and randomly shuffle these IDs to eliminate any coding sequence correlation.
[03]Namespace Mapping
Attributes are organized in namespaces to isolate standard data fields from regional or regional authority extensions:
Standard mDL attributes: given_name, family_name, birth_date, portrait, issuing_authority, document_number, un_distinguishing_sign.
British DVLA extensions: provisional_driving_privileges, title, welsh_licence (bilingual flag).
[04]Verification Loop (Selective Disclosure)
The verification process requires no connection back to the issuing authority, protecting offline privacy:
The mobile wallet sends only the requested elements (e.g., portrait, age_over_18) and hides the rest.
The verifier hashes the received items. If they match the digests stored in the MSO, data integrity is proven.
The verifier validates the Issuer's signature on the MSO, and the Device's signature using the MSO's public key.