Design Elements » History » Revision 4
Revision 3 (Suravi Regmi, 11/21/2025 07:31 PM) → Revision 4/8 (Suravi Regmi, 11/21/2025 07:32 PM)
# Design Elements This is the technical reference section. ### **[[Naming_Scheme|Naming Scheme]]** Naming Scheme [[Naming_Scheme]] Stream naming hierarchy (include diagram from paper) Data naming: /org/md2k/.../DATA/<timestamp> Attribute names (/org/md2k/ATTRIBUTE/...) Manifest naming (.../MANIFEST/<seq>) CK naming conventions DKEY naming conventions PUBPARAMS naming ### Trust Model Trust anchor Component identities Cert verification Signing chain What each module verifies ### Access Control + Policy Structure New policy structure (requester, allow/deny filters) Example policy with evolution from old → new format Filter semantics Mapping to attributes ### NAC-ABE Design Why KP-ABE Data encryption → CK encryption → CK decryption ABE encryption of CK (black box) ABE key issuance (DKEY) CK granularity (second/minute/hour) Tradeoffs of CK reuse level ### Manifest Design Why manifests exist Manifest format (full data names + digest) Creation triggers: count/time threshold Sequential numbering scheme How manifests replace per-data sync announcements ### PSync Design Why PSync is used How the sync list works conceptually Manifest announcement via PSync Differences from classical pub-sub Limitations / assumptions Boundaries (MGuard-specific usage, not raw PSync theory) ### Pub-Sub API Design (MGuard Perspective) Producer API: publish() Consumer API: subscribe() Callback delivery Reliability guarantees