The architecture of
zero trust
A four-layer decentralized stack - dPKI, secure enclaves, hybrid wallets and edge enforcement - eliminating the God View at the speed of the network.
Eliminating the “God View”
Traditional Zero Trust architectures centralize the Policy Decision Point (PDP), aggregating sensitive user metadata into a single honeypot and a single point of failure. dZTA dissolves that model for Mobile Edge Computing.
Hardware-Isolated Roots of Trust
Sealed on-device enclaves hold identity keys and run the prover logic — shielded from the operating system, malware, and cloud compromise. Personal data never leaves the mobile device.
Self-Sovereign Identity & ZK Proofs
Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) are standardized on W3C models, while Zero-Knowledge Proofs authorize access without ever revealing the underlying data.
Consensus Governance, Edge Enforcement
Distributed validators agree on policy while local Envoy sidecars enforce sub-50ms decisions at the Mobile Edge — strict, ultra-low-latency access control without cloud routing.
A Four-Layer Decentralized Stack
Local roots of trust, standardized cryptographic identities, abstract mathematical verification, and edge proxy enforcement — working as one integrated system.
The Shared Global State — Hyperledger Fabric
An enterprise permissioned blockchain network acting as the decentralized Public Key Infrastructure (dPKI). It stores immutable W3C DID Documents, network-wide access control chaincode, organization channels, Certificate Authorities, and real-time cryptographic revocation accumulators.
- Channel Ledger Engine
- CouchDB State Engine
- Orderer Nodes
- Organization Channels & Peers
- Revocation List
The Local Physical Root — Mobile TEE / Secure Enclave
Hardware-level CPU isolation (such as ARM TrustZone) secures device identity keys away from the main phone operating system — preventing malware extraction and computing hidden witness vectors for proofs.
- ARM TrustZone Isolation
- Key Management
- Witness Vector Computation
The Identity Protocol — Hyperledger Aries (Hybrid)
Standardizes device statements using W3C DIDs and cryptographically signed Verifiable Credentials. Pairwise Peer DIDs (did:peer) establish isolated network-relationship keys, eliminating user location tracking across edge nodes.
- DIDComm v2 Messaging
- Verifiable Credential Wallet
- Pairwise Peer DIDs
- Custom Circom Plug-in
The Privacy & Cryptographic Engine — ZKP Circuits
Compiled Circom arithmetic circuits (rank-1 constraint systems) parse hidden witness parameters and generate highly compressed Groth16/Plonk zk-SNARK proofs (π) — decoupling access authorization from plain-text identity tracing.
- Circom Circuit Compiler
- R1CS Constraint Systems
- Groth16 / Plonk SNARKs
- snarkjs WebAssembly Prover
MEC Integration & Runtime Enforcement — The Edge Gateway
Cloud-native Envoy Proxy sidecars deployed alongside localized edge microservices. The sidecar intercepts raw ingress traffic, evaluates inbound ZKP payloads locally using a memory-cached Verifying Key synced from Layer 1a, and enforces sub-50ms access decisions without cloud routing.
- Custom HTTP Client
- App Transport Layer Handler
- Dynamic Nonce Handshake Manager
- Envoy Proxy & ExAuthz Wasm Filter
The Hybrid Aries Wallet
Native Aries excels at AnonCreds, but AnonCreds are cryptographically distinct from the Groth16/Plonk zk-SNARKs that Edge enforcement expects. The wallet must therefore split into two cooperating layers.
A · Aries Layer — Transport & Storage
Handles DIDComm v2 messaging pipelines, out-of-band credential offers from the organization issuer, and secure storage of the JSON-LD / AnonCreds credential payload inside the local wallet.
B · Custom Circom Plug-in Layer
Intercepts the raw data inside the wallet, securely feeds it to the phone's hardware enclave (Layer 1b), and runs the prover() to output the SNARK coordinates the Envoy sidecar expects.
Note: If the hybrid method fails due to cryptographic differences, manual wallet coding will be required — forcing manual handling of every call to Layers 1a, 1b, and 3. This is the single highest-risk decision point in the framework.
Development Progress
Shared Global State — Hyperledger Fabric
DNS routing engine, networking endpoints, channel ledger, CouchDB state, orderers, organization authorities and peers, plus the test chaincode are complete. Main chaincode waits on Layer 3 parameters; the revocation list is deployed and empty.
Local Physical Root — Mobile Secure Enclave
Deliberately skipped until last: this layer requires a fully functional Android / iOS application, and every parameter and mathematical function must be finalized by the preceding layers first.
Identity Protocol — Hybrid Aries
The next layer to be implemented. Setup is underway: encrypted Local_wallet.db, pairwise did:peer generator, and the W3C Verifiable Credential assertion app remain to be built.
Privacy & Cryptographic Engine — ZKP Circuits
Role_verification.wasm circuit, the policy proving key (pk) asset, and the embedded snarkjs WebAssembly prover engine are the three components yet to be built in this layer.
MEC Integration & Runtime Enforcement
Mobile application layer: custom HTTP client with header injection, app transport layer protocol handler, and dynamic nonce handshake manager. Edge application layer: target core microservice (Web/gRPC), Envoy Proxy traffic interception, and the custom Wasm/Rust ExAuthz filter plugin.
The endpoint is the whole system.
Each layer runs on a different protocol or host abstraction, so the endpoint service binds them together — if it fails, the entire system fails.