mGuard

# Design Elements

This is the technical reference section.

### 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