Going to production

simple-vc is deliberately minimal. did:key is great for learning and peer-to-peer trust, but a real deployment usually needs more:

Need	Why did:key isn't enough	Where to go
Revocation	The key is the DID; you can't revoke a credential.	Status List 2021 / Bitstring Status List
Key rotation	Rotating the key changes the DID.	did:web, did:ion, did:ebsi
Wallets & exchange	No standard request/response flow here.	OpenID4VC (OID4VCI / OID4VP)
Selective disclosure	Whole credential is revealed.	SD-JWT VC, BBS+

A walt.id path

walt.id is an open-source SSI stack (issuer, verifier and wallet APIs). A typical local setup:

# docker-compose.yml (illustrative)
services:
  issuer:
    image: waltid/issuer-api:latest
    ports: ['7002:7002']
  verifier:
    image: waltid/verifier-api:latest
    ports: ['7003:7003']
  wallet:
    image: waltid/wallet-api:latest
    ports: ['7001:7001']

Then:

1. Issue via the issuer API (OID4VCI): create a credential offer, the wallet claims it.
2. Verify via the verifier API (OID4VP): create a presentation request, the wallet responds with a Verifiable Presentation.

The mental model you learned here — issuer signs, verifier checks against a DID — carries over directly; walt.id adds the exchange protocols, revocation and wallet.

Migration checklist

• [ ] Choose a DID method that supports rotation (did:web is the easiest start).
• [ ] Add a revocation mechanism (status list).
• [ ] Adopt OID4VCI / OID4VP for issuance and presentation.
• [ ] Move keys into a KMS/HSM instead of local seeds.
• [ ] Decide on the proof format (JWT VC, SD-JWT VC, or JSON-LD).