One-Line Idea#

LightDID-ZKP selects the right privacy-preserving presentation mechanism by checking verifier policy semantics, privacy requirements, credential-backed predicate needs, and device resource limits before applying cost scoring.

The core idea is simple:

Do not choose the cheapest proof first. Choose only from mechanisms that satisfy the verifier policy and privacy semantics, then optimize for cost.

Why This Project Exists#

Decentralized identity systems increasingly support privacy-preserving verifiable presentations. A holder wallet may support more than one presentation mechanism, but each mechanism is suitable for a different kind of verifier request.

For example, a verifier may ask for selected attributes such as name, degree, institution, or membership status. In such cases, a BBS-style selective-disclosure presentation can reveal only the required fields while hiding the rest.

Another verifier may ask for a predicate such as age greater than 18, income above a threshold, eligibility status, or another credential-backed condition. In that case, simple selective disclosure is not enough because the verifier needs proof that a hidden predicate is satisfied.

LightDID-ZKP addresses this decision problem. It introduces a selector that does not treat all proof systems as interchangeable. Instead, it checks the policy, privacy level, predicate requirement, issuer binding, freshness rule, status-policy requirement, and device constraints before selecting the presentation backend.

Project at a Glance#

What Makes LightDID-ZKP Different#

Important

LightDID-ZKP is not a new cryptographic proof primitive. It is a selector and orchestration layer above existing presentation mechanisms.

Reader Walkthrough#

A reader can understand LightDID-ZKP in five steps:

1. Verifier sends a presentation request containing required attributes, predicate needs, issuer requirements, freshness expectations, status-policy rules, and resource constraints.
2. CAPS-ZK parses the policy and identifies whether the request requires selective disclosure, credential-backed predicates, or both.
3. Candidate mechanisms are filtered using semantic, privacy, predicate, issuer-binding, freshness, status-policy, and resource checks.
4. Only safe mechanisms are scored using latency, proof size, verification cost, and memory indicators.
5. The selected backend is returned with a reason. If no backend satisfies the policy safely, the selector rejects the request instead of downgrading privacy or semantics.

System Architecture#

LightDID-ZKP separates credential issuance, holder-side decision logic, backend selection, cryptographic presentation generation, and verifier-side policy checking.

CAPS-ZK does not replace BBS or AnonCreds. It decides when each mechanism is appropriate and prevents unsafe substitutions.

CAPS-ZK Selection Workflow#

The workflow is intentionally policy-first. Resource optimization is applied only after the mechanism passes the safety and semantics checks.

Core Modules#

Presentation Profiles#

End-to-End Workflow#

Example Decision Cases#

Experiment Protocol#

The experiment package follows a manuscript-style reproducibility setup.

The repository contains benchmark summaries, selector decisions, ablation results, resource-sensitivity outputs, and generated figures.

Repository Structure#

1
LightDID-ZKP
2
├── assets/
3
│   └── diagrams/
4
│       ├── lightdid_banner.svg
5
│       ├── lightdid_layered_architecture.svg
6
│       ├── caps_zk_selection_flow.svg
7
│       ├── experiment_pipeline.svg
8
│       └── verifier_metadata_guard.svg
9
│
10
├── benchmarks/
11
│   ├── lightdid_benchmark_summary.csv
12
│   ├── selector_decisions.csv
13
│   ├── resource_sensitivity.csv
14
│   └── ablation_cost_first_fallback.csv
15
│
16
├── configs/
17
│   ├── policies.yaml
18
│   ├── device_profiles.yaml
19
│   └── experiment_config.yaml
20
│
21
├── docs/
22
│   ├── ARCHITECTURE.md
23
│   ├── DEVELOPER_GUIDE.md
24
│   ├── REVIEWER_NOTES.md
25
│   └── GITHUB_ABOUT.md
26
│
27
├── experiments/
28
│   ├── run_all.py
29
│   ├── generate_tables.py
30
│   ├── plot_results.py
31
│   └── optional_real_backend_templates/
32
│
33
├── results/
34
│   ├── figures/
35
│   └── tables/
36
│
37
├── src/
38
│   └── lightdid_zkp/
39
│       ├── selector.py
40
│       ├── policy.py
41
│       ├── profiles.py
42
│       ├── metrics.py
43
│       └── utils.py
44
│
45
├── tests/
46
│   └── test_selector.py
47
│
48
├── README.md
49
├── requirements.txt
50
├── pyproject.toml
51
├── CITATION.cff
52
└── LICENSE

Important Project Paths#

Local Run Command#

Create and activate a Python environment:

1
python -m venv .venv

Windows:

1
.venv\Scripts\activate

macOS/Linux:

1
source .venv/bin/activate

Install dependencies:

1
pip install -r requirements.txt

Run the full experiment pipeline:

1
python experiments/run_all.py

Run tests:

1
pytest -q

Reproduce Tables and Figures#

Generate manuscript-style tables:

1
python experiments/generate_tables.py

Generate result figures:

1
python experiments/plot_results.py

Outputs are saved in:

1
results/tables/
2
results/figures/

Example Selector Usage#

1
from lightdid_zkp.selector import select_presentation
2
from lightdid_zkp.policy import VerifierPolicy
3
from lightdid_zkp.profiles import DeviceProfile
4

5
policy = VerifierPolicy(
6
    required_attributes=["name", "degree", "institution"],
7
    predicate_requirements=[],
8
    max_vp_size_kb=32,
9
    require_credential_backed_predicate=False,
10
)
11

12
device = DeviceProfile(
13
    name="mobile_like",
14
    max_latency_ms=500,
15
    max_memory_mb=512,
16
)
17

18
decision = select_presentation(policy=policy, device=device)
19

20
print("Selected mechanism:", decision.mechanism)
21
print("Reason:", decision.reason)

Example output for selective disclosure:

1
Selected mechanism: BBS
2
Reason: Policy requires selective disclosure only; BBS satisfies disclosure constraints with lower estimated presentation size.

Example output for predicate-heavy policies:

1
Selected mechanism: AnonCreds
2
Reason: Verifier policy requires credential-backed predicate proof; AnonCreds satisfies predicate semantics.

Project Links#

• Wiki Home: LightDID-ZKP Wiki
• Architecture: Architecture and Design
• CAPS-ZK Logic: CAPS-ZK Selection Logic
• Policy Model: Policy Model
• Experiments: Experiment Protocol
• Results: Results and Figures
• Claim Boundary: Security, Privacy, and Claim Boundary

Documentation and Wiki Links#

Because this project does not currently have a YouTube walkthrough, the Wiki is the main public explanation surface.

Architecture Diagrams#

The repository includes project diagrams under assets/diagrams/.

Result Files#

The repository includes result files for:

• BBS presentation latency,
• AnonCreds presentation latency,
• verification time,
• verifiable presentation size,
• RSS memory usage,
• coefficient of variation,
• selector decisions across policy types,
• ablation comparison against unsafe cost-first fallback,
• resource-sensitivity analysis.

Result folders:

1
benchmarks/
2
results/tables/
3
results/figures/

Research Scope and Claim Boundary#

LightDID-ZKP is intended as a research prototype for privacy-preserving decentralized identity presentation selection.

It does not claim to:

• introduce a new zero-knowledge proof primitive,
• replace BBS or AnonCreds,
• provide production wallet security certification,
• prove constrained-device deployment without real device measurements,
• implement a complete DID wallet,
• provide legal or compliance certification for digital identity deployments.

It does claim to:

• provide a policy-aware selection framework,
• provide a resource-aware presentation decision layer,
• compare presentation-level trade-offs,
• support reproducibility through scripts, tables, and figures,
• demonstrate why policy semantics must be checked before cost optimization.

Practical Use Cases#

Engineering Value#

LightDID-ZKP demonstrates how decentralized identity presentation selection can be treated as an engineering decision problem rather than only a cryptographic primitive choice.

The project connects:

• verifier policy parsing,
• backend capability modeling,
• privacy-level abstraction,
• predicate requirement checking,
• resource filtering,
• benchmark-driven cost scoring,
• safe rejection,
• reproducible experiment generation,
• GitHub documentation and Wiki publishing.

This makes the project useful as a research prototype, academic support repository, and technical portfolio project.

Current Strengths#

• Clear focus on decentralized identity and verifiable presentation selection.
• Separates policy correctness from cost optimization.
• Distinguishes BBS selective disclosure from AnonCreds predicate presentation.
• Prevents unsafe fallback and privacy downgrades.
• Includes reproducibility scripts, tables, result files, and diagrams.
• Provides GitHub Wiki documentation instead of relying only on README text.
• States a clear claim boundary, which is important for research credibility.
• Suitable for manuscript support, GitHub portfolio display, and technical review.

Key Innovation#

Key point

The strongest innovation is not claiming a new proof system. The strongest innovation is the policy-safe selector: LightDID-ZKP checks whether a presentation backend satisfies verifier semantics and privacy requirements before optimizing for resource cost.

Most systems discuss proof mechanisms individually. LightDID-ZKP focuses on the wallet-side decision problem that appears when multiple privacy-preserving presentation mechanisms are available.

Conclusion#

LightDID-ZKP shows how decentralized identity wallets can make safer presentation choices when multiple privacy-preserving mechanisms are available.

It connects verifier policy, privacy semantics, backend capability, resource feasibility, and cost scoring into one reproducible framework.

The project is valuable because it explains a practical identity-system problem: a low-cost proof is not acceptable if it does not satisfy the verifier’s actual requirement. By placing policy safety before cost optimization, LightDID-ZKP provides a clean and credible research direction for privacy-preserving decentralized identity presentation selection.

Final Thought#

Policy first. Privacy second. Cost only after safety.

LightDID-ZKP is about making decentralized identity presentation selection safer, explainable, and reproducible.

BBS selective disclosure · AnonCreds predicates · CAPS-ZK selector · no unsafe fallback · no privacy downgrade · GitHub Wiki documentation