Tim Bouma on Nostr: How the OpenID Verifiable Presentations spec could be simplified using nostr, based ...

How the OpenID Verifiable Presentations spec could be simplified using nostr, based on how nostr already supports verifiable identity and data exchange.

⸻

🔑 1. Identity as Keypair (DID by Design)
• OpenID VP: Requires Decentralized Identifiers (DIDs) and DID Documents.
• Nostr: Your public key is your DID—represented simply as did:nostr:<hex pubkey> .
• No need for complex DID resolution: clients already use the nostr key directly.

⸻

📄 2. Presentations as Signed Events
• OpenID VP: Encodes claims in JSON-LD, wraps them in JWTs or SD-JWTs, and transports them via OIDC flows.
• Nostr: Use a standard "note" event (e.g., kind=1000+) with a JSON payload containing your claims, then sign it with your private key—simple, peer-to-peer, trustless.

⸻

🔄 3. Issuer → Holder → Verifier via Relays
• OpenID VP: Uses OIDC endpoints to fetch credentials/presentations.
• Nostr:
• Issuer publishes a signed credential event referencing the holder’s pubkey.
• Holder reposts or includes that event when they want to present.
• Verifier just reads from relays and validates the signature—no HTTPS endpoint calls necessary.

⸻

🔐 4. Proofs are Native
• OpenID VP: Proofs need standardized mechanisms (JWS, BBS+, ZK proofs).
• Nostr: Every event is natively signed with your Schnorr key, and signature validity is inherent to the protocol   .

⸻

🧭 5. Transport & Discovery via Relays
• OpenID VP: Requires well-known endpoints and discovery mechanisms.
• Nostr: Clients maintain relay lists via NIP‑11 (relay info) or stored in the did:nostr DID document. Events are broadcast to all relays—presentation is automatically discoverable.

⸻

🛰️ 6. Exchange Flows: Simplified

Step OpenID VP Nostr
Holder → Verifier HTTP redirect, JWT payload Post event to relay; reference it in chat or a CLI
Verifier → Holder Request parameter Verifier requests event via relay filter
Validation Fetch DID doc, verify JSON-LD proofs Use the same pubkey, validate signature via nostr client


⸻

Why it’s simpler in nostr
1. 🧩 Unified protocol: Signing, identity, transport all in one WebSocket-based system—no HTTP endpoints or token flows.
2. 🔎 Decentralized, public: No need for server comp, endpoint maintenance—relays funnel data openly.
3. ✅ Standard Crypto: Schnorr signatures, standard key management across identity + claims.
4. 🚀 Low barrier: Developers already integrate signing and event publication; adding a credential kind is trivial over existing NIP structure.

⸻

What remains to be done
• Define event kind/type for credential issuance—e.g., NIP‑X with kind=40000 for “Verifiable Credential”.
• Standardize JSON format for claims and metadata.
• Client UI+UX: Tools to issue credentials, hold them, present them, just like a VP wallet.
• Optional advanced proofs: Could layer ZK proofs on top—but only when needed.

⸻

✅ In summary

Nostr’s protocol already covers:
• Identity (public key = DID)
• Proof (signature embedded)
• Transport (publish via relays, read via filters)

To simplify OpenID VP, you just need to define:
1. A credential event type
2. A claim structure
3. A UI/UX wallet flow

Then, everything else flows naturally—no servers, no tokens, no complex JSON‑LD plumbing. It’s much more direct, open, and user-controlled.

⸻