Architecture » History » Revision 21
Revision 20 (Suravi Regmi, 11/21/2025 06:34 PM) → Revision 21/23 (Suravi Regmi, 11/21/2025 08:23 PM)
# Architecture
This page provides a **high-level architectural view** of MGuard.
It summarizes how the main modules interact, how data flows through the system, and how security and access control are enforced at a system level.
Detailed module-level behavior, policy processing, manifest handling, and sequence diagrams are provided in the linked **Architecture Details** page.
---
## System Architecture Overview
MGuard follows the design described in the paper’s **Design Overview** (§3.1). :contentReference[oaicite:0]{index=0}
A service instance consists of:
- a data source (MD2K repository or sensor-generated streams),
- a **Producer** that adapts and publishes mHealth data into NDN,
- a **Controller** responsible for access policies and requester validation, also contains **Attribute Authority (AA)** issuing decryption keys,
- an **NDN Repository** storing encrypted data, content keys, and manifests,
- one or more **Consumers** subscribing to data streams they are authorized to access.
Data requesters obtain trust anchors and certificates, subscribe to data streams, receive manifest notifications, and fetch/decrypt data objects.
---
## High-Level Architecture Diagram
---
## TODO (Architecture Details)
End-to-end workflows (overview)
Publication workflow
(Adaptor → Publisher → NAC-ABE encryption → Repo → PSync announcement)
Authorization workflow
(Consumer → Controller → DKEY issuance)
Retrieval workflow
(PSync update → manifest fetch → data/CK fetch → decrypt → callback)
Black box components
NAC-ABE → “encrypt(data, attributes) → encrypted data + CK”
PSync → “publish(manifestName) → notify subscribers”
[[Architecture Details]]
