Atala PRISM DIDs + Verifiable Credentials + Cardano 725 metadata — end‑to‑end, verifiable, and simple.
NMKR Identity lets projects prove who they are with a company DID, issue project/asset credentials, and ship Cardano 725 metadata that points back to those proofs — all signed with the same DID key.
- Company DID (your public key identity)
- Platform Attestation VC (our signed statement about your DID)
- Credential VC per project/asset (signed by your DID)
- Cardano 725 metadata (signed by your DID) that references your DID and VC URL
Verifiers check DID → VC → Platform VC → 725, all under your DID public key.
- Create DID
- Enter company info; download your one‑time key. We never keep plaintext keys.
- KYC & Review
- Upload docs; admin reviews and approves.
- Platform Attestation (VC)
- We issue a VC (issuer = platform DID) referencing your DID (and policy).
- Credentials
- You create a VC per asset/project (issuer = your DID). Policy ID is required to scope the claim.
- 725 Metadata
- Generate signed metadata that references your DID (+ VC URL). Every version is saved and downloadable.
- DID Document — self‑signed by your DID key (public JWK inside)
- Platform Attestation — a VC signed by our platform DID (references your DID and policy)
- Credential VC — per asset/project, signed by your DID key
- 725 Metadata — signed by your DID key; references your DID (+ VC URL) in
files[]
- Start at the VC (issuer = DID)
- Resolve DID → verify DID Document signature (using its public JWK)
- Verify VC signature (using DID public key)
- Verify platform attestation VC signature (using platform public key)
- Verify 725 metadata signature (using DID public key) and confirm it references the same DID (+ VC URL)
- Check credential status (active/revoked)
In the UI, press “Verify” on a credential — the app runs every step and shows pass/fail.
- VC JSON
GET /api/credentials/<id>
- VC Status
GET /api/credentials/<id>/status→{ id, type: "SimpleStatus", status }
- DID + Attestations
GET /api/dids/<did_id>/public
All are safe to expose (they’re public material). Signatures are what give trust.
- DIDs (Dashboard) — DIDs as parents; credentials listed beneath with a “+” button
- DID Overview — DID chip, pretty DID JSON, platform attestation VCs
- Credential Detail — Verify, Download VC, Open Public VC, Generate 725, Saved metadata versions (download)
- Python 3.10+
- Install deps:
python3 -m pip install -r requirements.txt
- Start dev server:
python3 app.py
- Open: http://localhost:8000 (dev only; use a production server in prod)
SECRET_KEY— Flask secret (set in production)DATABASE_URL— e.g.,postgresql+psycopg2://user:pass@host:5432/db(defaults tosqlite:///app.db)ADMIN_EMAIL,ADMIN_PASSWORD— bootstrap/update admin at startupVERIFIER_PRIVKEY_HEX— 32‑byte hex; pins a stable platform verifier keyBASE_URL— if set (e.g.,https://identity.nmkr.io), used for link generation; otherwise the app falls back to the current host dynamicallySESSION_COOKIE_SECURE=1— when serving behind HTTPS
docker-compose up --build- Generate DID:
python -m token_identity.cli generate-did --policy-id <policy> --collection <name> [--asset <asset>] [--website url ...] [--privkey-hex hex] [--out did.json]
- Generate 725 metadata:
python -m token_identity.cli generate-metadata --did did.json --policy-id <policy> --collection <name> [--privkey-hex hex] [--out metadata.json]
- Verify (DID + 725):
python -m token_identity.cli verify --did did.json --metadata metadata.json
- Never expose or commit your private key. The app only stores an encrypted version; you download and hold the key for signing.
- The dev server (
python app.py) is for development (debug + reloader). Use a production WSGI/ASGI server in prod and set strong secrets.
- CSRF (Flask‑WTF) and basic rate limits (Flask‑Limiter) are enabled.
- In dev (SQLite), schema changes can trigger rebuilds. Use Postgres + migrations for production.
- No license included. Add one if needed.