The State of DID Adoption for Software Supply Chain Trust

We talk a lot about trust in software supply chains. SBOMs tell us what’s in the software. SLSA attestations tell us how it was built. But there’s a missing piece: who vouches for it, and should we trust them?

Decentralized Identifiers (DIDs) offer a compelling answer. With did:web, an organization can publish a cryptographically verifiable identity document at a well-known URL on their domain. Anyone can resolve it, verify signatures, and build trust chains.

But here’s the question we had: Are the organizations we’d want to trust actually publishing DID documents?

The Survey

We checked /.well-known/did.json on domains that matter for software supply chain trust:

Software Foundations & Standards Bodies

Organization	Domain	DID Document
Open Source Security Foundation	openssf.org	❌ 404
Cloud Native Computing Foundation	cncf.io	❌ 404
Linux Foundation	linuxfoundation.org	❌ 404
Apache Software Foundation	apache.org	❌ 404
Trust Over IP Foundation	trustoverip.org	❌ 404
Content Authenticity Initiative	contentauthenticity.org	❌ 404
Sigstore	sigstore.dev	❌ (returns web app)

Identity/VC Ecosystem

Organization	Domain	DID Document
Decentralized Identity Foundation	identity.foundation	✅ Valid
Veramo (identity framework)	veramo.io	✅ Valid
W3C	w3c.org	❌ Connection refused
SpruceID	spruceid.com	❌ 404
Microsoft	microsoft.com	❌ 404

The Gap

The organizations most central to software supply chain security—OpenSSF, CNCF, Sigstore, the Linux Foundation—don’t have DID documents.

This creates a chicken-and-egg problem:

• Tools can’t verify trust chains to these anchors
• Without verification, there’s no pressure to publish DIDs
• Without DIDs, tools can’t offer the verification

Meanwhile, the DID/VC ecosystem players (DIF, Veramo) are publishing DIDs, but they’re not the trust anchors developers care about for supply chain decisions.

What the Valid DIDs Look Like

When organizations do publish DIDs, they work beautifully. Here’s what identity.foundation publishes:

{
  "@context": ["https://www.w3.org/ns/did/v1", ...],
  "id": "did:web:identity.foundation",
  "verificationMethod": [{
    "id": "did:web:identity.foundation#key-1",
    "type": "EcdsaSecp256k1VerificationKey2019",
    "publicKeyJwk": { "kty": "EC", "crv": "P-256", ... }
  }],
  "authentication": ["did:web:identity.foundation#key-1"],
  "service": [{
    "type": "LinkedDomains",
    "serviceEndpoint": "https://identity.foundation"
  }]
}

This is everything you need to:

• Verify signatures from the organization
• Authenticate communications
• Discover service endpoints for credential issuance

Two DID Methods for Supply Chain

This survey reinforced our thinking about which DID methods matter for SBOM signing:

did:web - For Organizations

did:web:acme.com              → Trust anchor, key rotation, service discovery
did:web:acme.com:team:security → Team-level signing authority

Pros: Human-readable, tied to domain ownership, updatable, service endpoints Cons: Requires web infrastructure, DNS dependency

did:key - For CI/CD and Ephemeral Signing

did:key:z6MkpL2yCePz5HuehhDtnDsguzJQnH36TWeBYRpn3mQa6vno

Pros: Self-contained, no infrastructure, works offline, perfect for CI Cons: No key rotation (DID changes), not human-readable, no service endpoints

The right model: Organizations anchor with did:web, CI systems sign with did:key, VCs connect them.

did:web:acme.com
    │
    └─ issues VC to ─→ did:key:z6Mk...  (CI runner)
                              │
                              └─ signs SBOM

The Opportunity

The current state of DID adoption is both a problem and an opportunity.

The problem: You can’t verify trust chains to OpenSSF or CNCF because they don’t publish DIDs.

The opportunity: Someone needs to bridge this gap. Options:

1. Help these organizations publish DIDs - The technical barrier is low (it’s just a JSON file). The organizational barrier is higher.

2. Attestation-based trust - Issue credentials about membership verified through other means:

   Noosphere issues:
   ├─ OpenSSFMemberCredential (verified via API/manual)
   ├─ SLSABuilderCredential (verified via Sigstore logs)
   └─ CNCFMaintainerCredential (verified via GitHub org)

3. Build the trust graph now - Start with organizations that do have DIDs, grow from there.

What We’re Building

At Noosphere, we’re taking a pragmatic approach:

1. Support both did:web and did:key - Organizations get stable identities, CI gets ephemeral signing
2. Issue bridge credentials - Attest to organizational memberships we can verify
3. Build the trust graph - Connect signers to anchors through verifiable paths
4. Make adoption easy - One-line DID document generation, pre-built CI integrations

The goal: when someone signs an SBOM, anyone can answer “does this signer connect to entities I trust?” without manual review.

Call to Action

If you work at OpenSSF, CNCF, the Linux Foundation, or any software foundation:

Please publish a DID document. It’s a JSON file at /.well-known/did.json. The spec is simple. The tooling exists. Your community needs cryptographic trust anchors.

Here’s a minimal example to get started:

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:web:your-foundation.org",
  "verificationMethod": [{
    "id": "did:web:your-foundation.org#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:web:your-foundation.org",
    "publicKeyMultibase": "z6Mk..."
  }],
  "authentication": ["did:web:your-foundation.org#key-1"],
  "assertionMethod": ["did:web:your-foundation.org#key-1"]
}

We’d be happy to help you set this up. Get in touch.

---

Noosphere provides the trust layer for software supply chain security. We help organizations sign SBOMs, verify trust chains, and make policy-driven decisions about which software to trust.