Privacy Controls

Bio-AI DIDs sequencer offers robust privacy controls for your IPFS content, allowing you to restrict access, implement encryption, and manage permissions at a granular level.

Privacy in Decentralized Storage

Public IPFS networks are designed for open content sharing, but many use cases require privacy and access control. Bio-AI DIDs sequencer addresses this with comprehensive privacy features.

Understanding Content Addressing: IPFS content is addressed by its hash (CID). While this provides integrity, it also means anyone with the CID can potentially access the content unless proper privacy controls are in place.

Bio-AI DIDs sequencer Privacy Features

Access Control Methods

Gateway-level Access Control - ML-DSA-87 session token (bearer) authentication - UCAN capability tokens for scoped, revocable delegated reads - IP address allowlisting - Geolocation restrictions

Content Encryption - Post-quantum encrypt-then-store: payloads are sealed before they reach IPFS - ML-KEM-1024 (FIPS 203) wrapped content keys - one fresh key per payload - Client-side encryption options for zero-knowledge workflows

Permission Management - Capability-based access via signed UCAN tokens - Granular access levels (read, write, delete, share, admin) - Temporary, attenuated, and revocable grants

Encrypt-then-store

The strongest privacy control is the one that does not depend on an access-control list being enforced correctly. Private payloads are encrypted before upload, so the CID addresses ciphertext:

fresh 32-byte content key
   ├── AES-256-GCM --> sealed payload --> IPFS (this is the CID)
   └── ML-KEM-1024 encapsulation
         └── HKDF-SHA256 -> AES-256-GCM -> sealed content key

Consequences worth being precise about:

A leaked CID is not a leaked dataset. Any node replicating the block holds bytes that are useless without the ML-KEM decapsulation key.
The AEAD binds the payload to its owner. Associated data ties each sealed payload to the identity it was stored for, so a ciphertext lifted into another account will not open.
Tampering is detected, not silently served. AES-256-GCM is authenticated; a modified block fails to decrypt rather than returning corrupted data.
Legacy content still works. Sealed payloads carry a version marker, so pre-existing plaintext content is served unchanged during migration.

On the "right to be forgotten". IPFS content is immutable and may be replicated beyond your control, so deletion cannot be guaranteed by unpinning alone. Encrypting at rest makes erasure effective rather than merely best-effort: destroying the key renders every surviving replica permanently unreadable. This is why nothing personal is ever anchored on-chain - only public keys, opaque fragments, and URIs.

See Post-Quantum Security for the algorithms and key management, and UCAN Authorization for how a content key is delegated to a recipient inside the capability token itself.

Implementing Privacy Controls

Encryption is a property of the write path

There is no "encrypt: true" flag to remember. Payloads written through the encrypted path are sealed automatically: a fresh AES-256-GCM content key per object, itself wrapped to the server's ML-KEM-1024 key. Reads decrypt transparently, and an object stored as plaintext before the encryption layer existed is detected and passed through unchanged - so both coexist without a migration.

The associated data binds each object to its owner, so a sealed payload cannot be replayed into another account's context even by someone holding the ciphertext.

Access control is capability-based

Access is granted by minting a scoped, revocable UCAN capability - not by editing an ACL:

bash

curl -X POST https://api.ekayana.com/api/share/file \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "cid": "QmXyz…",
    "recipient_did": "did:bio:user:7",
    "capabilities": ["read"],
    "expiration_days": 7
  }'

Revoke with DELETE /api/share/revoke/{token_hash}. Revocation cascades: the proof chain is walked on every validation, so withdrawing a grant also invalidates everything delegated beneath it.

What this gives you under GDPR

Requirement	Mechanism
Data minimisation	Only public keys, fragments, and URIs are ever anchored on-chain
Purpose limitation	Capabilities name one resource and one action set
Storage limitation	Every grant carries a signed expiry
Right to erasure	Delete unpins the platform copy; destroying the key renders surviving replicas unreadable
Integrity & confidentiality	AES-256-GCM at rest, post-quantum key wrapping

Honest limit: IPFS is a public network. Once a plaintext object has been fetched by a third party, no API can recall it. That is precisely why personal and pre-publication data is encrypted before it reaches IPFS - erasure then depends on key destruction, which you control, rather than on cooperation from every node that ever cached the content.

IPNS Publishing Organizations & Regulations