{"id":"verifiable-credential-evidence","slug":"verifiable-credential-evidence","title":"Verifiable Credential Evidence Provenance","description":"When evidence collected during an investigation is presented in court, the opposing party's first challenge is typically chain of custody: who collected it, when, on what system, and whether it could have been altered in","category":"forensics","tags":["forensics","blockchain"],"lastModified":"2026-04-14","source_ref":"content/modules/verifiable-credential-evidence.md","url":"/developers/verifiable-credential-evidence","htmlPath":"/developers/verifiable-credential-evidence","jsonPath":"/api/docs/modules/verifiable-credential-evidence","markdownPath":"/api/docs/modules/verifiable-credential-evidence?format=markdown","checksum":"c6807ef08cb83c8adc4dd389c8f461cd4a94f1bc64f6d72edc6cca9fb33339b9","headings":[{"id":"overview","text":"Overview","level":2},{"id":"key-features","text":"Key Features","level":2},{"id":"use-cases","text":"Use Cases","level":2},{"id":"integration","text":"Integration","level":2},{"id":"open-standards","text":"Open Standards","level":2}],"markdown":"# Verifiable Credential Evidence Provenance\n\n## Overview\n\nWhen evidence collected during an investigation is presented in court, the opposing party's first challenge is typically chain of custody: who collected it, when, on what system, and whether it could have been altered in transit. Traditional database audit logs answer these questions only if the court is willing to trust the platform vendor, the database administrator, and the backup regime. A cryptographic chain of custody removes that dependency entirely.\n\nThe Verifiable Credential Evidence Provenance module assigns a W3C Verifiable Credential (VC DM v2.0) to every piece of evidence collected by Argus. Each credential is signed with the platform's Ed25519 key and anchored to the evidence hash computed by the caller. When evidence changes hands, a new custody-transfer credential is appended to the chain, linking to the preceding collection credential via the subject identifier. Any party in possession of the platform's public key can independently verify the entire chain without querying the Argus database, without trusting the platform operator, and without access to the original files.\n\n```mermaid\ngraph LR\n    A[Evidence Collected] --> B[SHA-256 Hash]\n    B --> C[Ed25519 Signing]\n    C --> D[VC JSON-LD]\n    D --> E[DB Storage]\n    E --> F[Verification]\n    F --> G[VCProvenanceBadge]\n    G --> H[VCChainViewer]\n```\n\n**Last Reviewed:** 2026-04-14\n**Last Updated:** 2026-04-14\n\n## Key Features\n\n- **W3C VC Data Model v2.0 Compliance**: Every credential issued by the platform conforms to the W3C Verifiable Credentials Data Model v2.0 (W3C Recommendation, 20 May 2025). The credential payload includes the JSON-LD context `https://www.w3.org/ns/credentials/v2`, a typed credential subject, an issuer DID, and a `validFrom` timestamp. This ensures the credentials are processable by any conformant VC toolchain, independent of Argus.\n\n- **Ed25519 Signatures via jwcrypto**: Credentials are signed using the Ed25519 elliptic curve algorithm, providing strong cryptographic guarantees with compact signatures. The platform's signing key is stored as a JWK in the environment configuration; the corresponding public key is published at the issuer DID document. Signature verification requires only the public key and is computationally inexpensive for court-side tools.\n\n- **DID Web Method Issuer Identity**: The platform identifies itself using a `did:web` DID (W3C CCG specification), for example `did:web:argus.platform`. Resolving this DID retrieves the verification key from the platform's well-known endpoint, allowing any party to confirm the issuer without a centralised registry.\n\n- **Immutable Chain of Custody**: Each custody transfer appends a new `CustodyTransfer` credential to the chain, recording the transferring user URN, the receiving user URN, and the transfer timestamp. The chain is anchored through shared evidence subject identifiers. Revoking a credential sets `revoked_at` in the database but does not delete the JWT, preserving the audit record.\n\n- **Independent Verifiability**: The compact JWT serialisation of each credential is stored in full in the `evidence_vc_records` table. Any holder of the JWT and the platform's public key can verify the signature without database access. This is the property that enables cross-agency evidence sharing: a receiving agency verifies the chain against a published DID document without needing a database connection to the originating platform.\n\n- **VCProvenanceBadge and VCChainViewer**: The evidence sub-application displays a compact badge on each evidence item showing the verification status (Cryptographically verified, No VC issued, or VC revoked). Clicking the badge opens the VCChainViewer, which renders the full credential chain as a vertical timeline with expandable raw VC sections for auditors who need to inspect the JWT payload directly.\n\n## Use Cases\n\n- **Court Evidence Admissibility**: Presenting digital evidence in court where chain of custody must be mathematically proven. The VC chain lets counsel demonstrate that evidence was collected at a specific time by a specific operator, signed by a known key, and not modified thereafter, without requiring the platform vendor to testify.\n- **Cross-Agency Evidence Sharing**: Transferring evidence between agencies where the receiving party needs to independently verify provenance. The receiving agency resolves the issuer DID, obtains the public key, and verifies the JWT without connecting to the originating database or trusting the transferring agency's assertions.\n- **Multi-Jurisdictional Operations**: Operations where evidence collected in one jurisdiction must be presented in another. Each jurisdiction's legal framework requires different provenance standards; the W3C VC format provides a common machine-verifiable baseline that meets the minimum bar in most common law and civil law systems.\n- **Internal Audit and Compliance**: Compliance teams verifying that evidence custody records are complete and unbroken before submitting a disclosure package. The VCChainViewer provides an auditor-readable timeline that can be exported alongside the evidence.\n\n## Integration\n\n- **Evidence Management System**: The VCProvenanceBadge is embedded in the EvidenceList and EvidenceViewer components, surfacing the VC status without requiring the analyst to navigate away.\n- **Chain of Custody Viewer**: The VCChainViewer complements the existing ChainOfCustodyViewer, adding the cryptographic layer on top of the operational event log.\n- **W3C PROV-DM Provenance**: The VC chain and the PROV-DM provenance graph address complementary concerns. PROV-DM records the analytical lineage of derived intelligence; the VC chain records the cryptographic custody of raw evidence files.\n- **Briefing Packages**: Evidence items included in a briefing package carry their VC chain, allowing recipients to verify the provenance of every included item.\n\n## Open Standards\n\n- **W3C Verifiable Credentials Data Model v2.0**: https://www.w3.org/TR/vc-data-model-2.0/ (W3C Recommendation, 20 May 2025)\n- **Ed25519Signature2020**: Ed25519 elliptic curve digital signature algorithm\n- **DID Web Method**: https://w3c-ccg.github.io/did-method-web/ (W3C CCG specification)\n- **jwcrypto**: Python JOSE/JWK/JWE/JWS/JWT implementation (LGPL-3.0)\n- **pyld**: Python JSON-LD 1.1 processor (BSD license)\n"}