Align with did:nostr and allow Multikey verification methods

[melvincarvalho]

Summary

Web Ledgers already treats did:nostr as a first-class URI type in the data model (see the example ledger in the README). What is missing is an integrity layer: ledger entries are currently unsigned assertions, so a consumer has to trust whoever served the document. The did:nostr -> Multikey -> BIP340 Data Integrity path is now a coherent, standards-track way to close that gap using a key the controller already has.

Proposal

Allow a Web Ledgers document to carry a Data Integrity proof so balance assertions are verifiable independently of the host:

• controller is a did:nostr: identifier (the bare 64-char x-only key, already supported as a URI type)
• the verification method is a Multikey whose publicKeyMultibase is the canonical even-parity form agreed in CCG: f (base16) + e701 (secp256k1-pub) + 02 + the 64-hex key
• the proof is a BIP340 Schnorr signature over the canonicalized ledger, using the BIP340 Data Integrity cryptosuite

The same secp256k1 key that signs Nostr events and authenticates over NIP-98 then signs the ledger. A consumer resolves the did:nostr, reconstructs the Multikey, and verifies. No new key, no new trust root.

Example shape

{
  "@context": ["https://webledgers.org/ns/v1", "https://w3id.org/security/data-integrity/v2"],
  "controller": "did:nostr:de7ecd1e2976a6adb2ffa5f4db81a7d812c8bb6698aa00dcf1e76adb55efd645",
  "ledger": [
    { "url": "did:nostr:abc123...", "balance": 100 }
  ],
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bip340-rdfc-2025",
    "verificationMethod": "did:nostr:de7ecd1e...#key1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z..."
  }
}

(verificationMethod resolves to a Multikey of the form fe70102de7ecd1e....)

Scope

In scope for this issue:

• one new informative section in the spec (provisional title: Verifiable Ledgers) describing the controller / Multikey / proof shape above
• one signed example

Out of scope (later issues if wanted): transaction history, multi-signature, embedding ledgers inside Verifiable Credentials, signing individual entries vs the whole document.

Notes / caveats

• The BIP340 Data Integrity cryptosuite is an open CCG work-item proposal (Data Integrity BIP340 Cryptosuite w3c-ccg/community#254) and a dcdpr.github.io/data-integrity-schnorr-secp256k1 draft, not a W3C Recommendation. The canonical even-parity (02) Multikey shape is the agreement reached in that thread (verifier-side prepend of 02, keeping the did:nostr identifier in raw-hex). The section should be marked informative and cite #254 so the dependency is explicit.
• The did:nostr identifier stays parity-agnostic (64-hex x-only). The 02/03 parity only exists at the Multikey layer; conformant Web Ledgers proofs use the canonical 02 form, while decoders may tolerate 03 for general interop.

Refs

• did:nostr method: https://github.com/nostrcg/did-nostr
• CCG BIP340 Data Integrity cryptosuite: Data Integrity BIP340 Cryptosuite w3c-ccg/community#254