Landscape · deep-dive · W3C Verifiable Credentials

agentic-first vs Verifiable Credentials.

Verifiable Credentials (VCs) are the W3C answer to "how do I cryptographically prove a single claim about a subject?" agentic-first is the file the claims sit inside. They aren't competitors - VCs are the trust layer agentic-first borrows from to make individual fields independently verifiable in v0.2.

What VCs and DIDs are

W3C Verifiable Credentials (v2.0) are signed JSON-LD documents in which an issuer attests one or more claims about a subject, with a cryptographic proof a third party can verify without contacting the issuer. Pair them with a Decentralised Identifier (DID) for the subject and you have a portable, self-sovereign identity primitive that survives platform churn.

Real examples: a university issues a VC for "this DID holds a first-class degree in computer science", a regulator issues one for "this DID is registered as an FCA AR", an exchange issues one for "this DID is a verified beneficial owner". Each individual claim is independently verifiable.

Why VCs alone don't solve our problem

VCs are claim-shaped, by design. There's no canonical VC for "this company's whole public profile, signed by the company itself"; nor is there a clean way to mark a single field inside a larger document as independently verified versus self-asserted. In practice every commercial company-data product invents its own confidence model - and the open web has none.

The shape we actually need is: a file the publisher controls, with claims inside it, where each claim can carry either no proof, a self-assertion, or a VC issued by a recognised authority. That's an envelope problem, not a replacement-for-VCs problem.

Side-by-side

How they compose - today and on the v0.2 roadmap

Today (v0.1)

v0.1 takes a pragmatic first step toward verifiability without requiring every adopter to spin up a VC stack:

• Statutory ID anchors. company.registry.{type,id,url} + company.lei point at registries the directory checks publicly. This isn't a VC, but it's a verifiable claim - you can navigate to the registry URL yourself.
• Per-claim evidence URLs. Every material field can carry an evidence entry whose supports JSON-Pointer points at the field it backs. The directory's confidence score weights evidence density.
• Credentials array (people). A personal profile's credentials[] can carry professional-body memberships (ICAEW, CFA, IoD) with verifiable IDs.

v0.2 (planned, not built)

Two complementary additions, both adopting W3C work rather than forking it:

• Embedded VCs per field. Any field can be backed by a VC issued by a recognised authority - e.g. a Companies House issuer attests company.registry.id; the company carries the VC inline. The validator surfaces "verified by Companies House (VC)" alongside the existing soft signals.
• JWS envelope for the whole file. An optional outer JWS signed by a key the publisher commits to (DNS, key in /.well-known/jwks.json, or a DID) gives the file itself an integrity guarantee. The directory checks the envelope when present and surfaces the result.

Worked example of the v0.2 envelope shape (illustrative, pre-spec):

{
  "schema_version": "0.2.0",
  "updated_at":     "2026-09-01T00:00:00Z",
  "profile_kind":   "company",
  "tier":           "public",
  "company": {
    "name":         "Acme Robotics",
    "registry": {
      "type": "companies-house",
      "id":   "12345678",
      "credentials": [
        {
          "type":   ["VerifiableCredential", "RegistryEntryCredential"],
          "issuer": "https://companies-house.gov.uk/.well-known/issuer.json",
          "issuanceDate": "2026-09-01T00:00:00Z",
          "credentialSubject": { "id": "did:web:acme-robotics.example",
                                 "registry_id": "12345678" },
          "proof": { "...": "VC proof block" }
        }
      ]
    }
  }
}

Why the staged approach

Three reasons for not putting VCs at the centre of v0.1:

• Adopter cost. Issuing a VC requires a key, a signing pipeline, and an issuer-discovery story. Most v0.1 adopters won't have one. The lowest-bar path has to stay a single static JSON file.
• Issuer ecosystem isn't ready. There's no Companies House VC issuer today, no GLEIF VC issuer, no SEC EDGAR VC issuer. As soon as one ships, we want to be ready to consume it - not before.
• Evidence URLs already do most of the work. A registry URL the validator can fetch and check structurally is, in 2026, materially more useful to a sourcing agent than a wallet-presented VC nobody can issue.

The honest summary

VCs are the right answer for the trust layer underneath agentic-first, and we're betting on them landing as the open standard for signed claims. v0.1 gets adopters something useful shipped today (registry anchors + evidence density). v0.2 wires VCs in as the cryptographic backbone, on top of the same profile shape, without breaking anyone who's already published.