Bio-DID-Sequencer

Bio-DID-Seq is the backend service that ties the platform together: it mints and resolves did:bio identifiers, stores the documents they point at, and bridges to the identifier systems research already runs on - DOI and Handle - so adopting a DID doesn't mean abandoning the citation infrastructure a dataset already lives in.

How it's layered

The service splits into five layers. The split isn't decorative, each layer has a different trust model, and keeping them separate is what lets one be swapped or audited without touching the others.

Storage

An IPFS cluster holds the data itself. Everything is referenced by its hash, so integrity checking is built into the address - a tampered block simply doesn't match its CID. The cluster runs as a private network, which keeps replication under the platform's control without giving up content addressing.

Identity

The did:bio method - W3C DID 1.0 conformant, published spec, anchored on Solana. Its defining trick is generative resolution: any valid identifier resolves to a deterministic document even if nothing was ever written on-chain, so creating a DID is free and offline. ML-DSA-87 assertion keys are a first-class verification method type, not an extension bolted on later.

Authorization

UCAN capability tokens, signed with ML-DSA-87. The capabilities live inside the signed payload - a holder can't widen their own grant - and delegation chains support attenuation with cascading revocation.

Application

An Actix Web API in Rust. Compute heavy work (uploads, BioAgents processing) runs async with task handles rather than holding connections open, and everything is rate-limited per user.

Integration

Connectors outward: BioAgents for AI processing, the Harvard Dataverse adapter, and the DOI/Handle bridge.

The DID document

The central data structure is the DID document - here's a real one from devnet, trimmed only slightly:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://www.w3.org/ns/cid/v1"
  ],
  "id": "did:bio:devnet:2T6zLFvMx7NJac5qQtiKTaPhMwHLkwKETWjUK1yKv4tc",
  "verificationMethod": [
    {
      "id": "did:bio:devnet:2T6zLFvMx7NJac5qQtiKTaPhMwHLkwKETWjUK1yKv4tc#default",
      "type": "Multikey",
      "controller": "did:bio:devnet:2T6zLFvMx7NJac5qQtiKTaPhMwHLkwKETWjUK1yKv4tc",
      "publicKeyMultibase": "z6MkfuN2vWAoHermh6vY6TgAJfwhBWZCApZb9XeQ9HwLqHfz"
    }
  ],
  "authentication": ["did:bio:devnet:2T6zLFvMx7NJac5qQtiKTaPhMwHLkwKETWjUK1yKv4tc#default"],
  "assertionMethod": ["did:bio:devnet:2T6zLFvMx7NJac5qQtiKTaPhMwHLkwKETWjUK1yKv4tc#default"],
  "service": [
    {
      "id": "did:bio:devnet:2T6zLFvMx7NJac5qQtiKTaPhMwHLkwKETWjUK1yKv4tc#storage",
      "type": "IPFSStorage",
      "serviceEndpoint": "https://ipfs.bio-did-seq.example/api"
    }
  ],
  "metadata": {
    "title": "CRISPR-Cas9 Gene Editing Dataset",
    "researchers": [
      {
        "name": "Jane Smith",
        "orcid": "0000-0001-2345-6789",
        "role": "Principal Investigator"
      }
    ],
    "keywords": ["CRISPR", "gene editing", "genomics"],
    "dataverse_link": "https://dataverse.harvard.edu/dataset.xhtml?persistentId=doi:10.7910/DVN/EXAMPLE"
  }
}

The three workflows that matter

Most interactions with the service reduce to one of these.

DID creation and registration

BioAgents processing

UCAN authorization

API surface

Create a DID

curl -X POST http://localhost:8080/api/did \
-H "Authorization: Bearer <YOUR_TOKEN>" \
-H "Content-Type: application/json" \
-d '{
  "controller": "did:bio:controller123",
  "public_key": "z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
  "metadata": {
    "title": "Research Dataset",
    "researchers": [{"name": "John Doe", "role": "Lead Researcher"}],
    "keywords": ["biology", "genomics"],
    "license": "CC-BY-4.0"
  }
}'

GDPR, honestly

"GDPR compliant" gets claimed by a lot of systems that just added a cookie banner, so it's worth being concrete about what the architecture actually provides. Data minimisation is structural: nothing personal is ever anchored on-chain - only public keys, opaque fragments, and URIs. Erasure works because private payloads are encrypted before they reach IPFS; deleting the key makes every surviving replica unreadable, which is a stronger guarantee than asking a distributed network to please forget something. Access is explicit because every share is a signed, expiring, revocable capability - there is no ambient "org-wide read" to audit around. And deactivating a DID leaves a permanent tombstone rather than a resurrectable gap.

The one thing decentralization gives you for free is worth stating too: there is no central identity authority to compromise, and no single operator whose disappearance takes your identifiers with it.