Design Elements¶

This is the technical reference section.

Naming Scheme¶

Stream naming hierarchy (include diagram from paper)
Data naming:
/org/md2k/.../DATA/

Attribute names (/org/md2k/ATTRIBUTE/...)

Manifest naming (.../MANIFEST/)

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