Architecture
Digital information is defined legally as Intellectual Property. A Databox translates this principle into software architecture via a relationship-specific Solid exchange point — one organisation program × one person × one opaque box. The Mapping Smithy is the Web Civics control plane; deposits, receipts, and cryptographic evidence protect the shared rights of both parties.
Topology
Organisation systems of record
|
v
Institutional bridge --> organisation-hosted Databox <--> consumer agent / app
| |
v v
Human review queue Independent consumer Pod / vault
|
v
Purpose-bound recipient or service provider
Registers Institution Profiles, forges opaque relationship mappings, issues holder-bound connection credentials, and bridges source-system events into Databox deposits.
/.databox/smithyAuthorised Solid HTTP/LDP operations for deposits, submissions, receipts and evidence. The Databox resource layout, composed authorizer and store integration are Web Civics extensions attached to the retained Solid request path.
/boxes/{opaque-box-id}/Resource layout
Each Databox root is an opaque box. Identifiers are independently random so volume cannot be inferred by incrementing a sequence, and never contain customer data.
| Path | Purpose |
|---|---|
records/ | Organisation → person institutional records |
submissions/ | Person → organisation explicit disclosures |
dispositions/ | Review outcomes for corrections and contested records |
receipts/ | Signed acceptance receipts retainable outside the organisation |
record-index/ | Index views for authorised listing |
disclosure-view/ / audit-view/ | Governed disclosure and audit surfaces |
Security invariants
A Databox belongs to one declared organisation program and one represented relationship.
URLs, logs and storage paths must not contain directly identifying customer information.
Knowing a resource URL never grants access.
Organisation credentials cannot authorise browsing of a consumer’s independent Pod.
In bilateral events (sales, dockets), rights are shared. Dual identical copies are deposited into both independent storage locations under separate WAC controllers, bound associatively by exact-byte SHA-256 digests.
Data access and retention are governed by machine-computable W3C ODRL policies defining explicit permissions, duties, prohibitions, and moral provenance.
Consumer submissions are deliberate disclosures, not background reads from personal storage.
Accepted records are supersede-/tombstone-linked; changes remain auditable.
Record sensitivity is evaluated against current verified assurance, purpose and policy.
The implementation preserves standard Solid HTTP behaviour for compatible agents.
Code map
| Area | Module |
|---|---|
| Control plane / Smithy | smithy/ — MappingSmithy, MappingSmithyHttpApi |
| Live CSS integration | integration/ — LiveDataboxHttpHandler, CssDataboxStore |
| Profiles & provisioning | profile/, provisioning/, identifiers/ |
| Credentials | credential/ — VC connection credential, status list, holder key proof |
| Exchange | bridge/, gateway/, proof/ |
| Evidence & receipts | receipt/, evidence/, storage/ |
| Policy | odrl/, policy/, compliance/ |
| AuthZ & tenancy | authorization/, context/, tenant/ |
| IPMS | ipms/ — modules, vertical profiles, Oxigraph sync |
| Personal profile | Personal vault, hosting/DNS, household governance, safe-exit paths |
The Web Civics Databox enforces fail-closed security invariants across all execution paths. While the default single-process developer preset runs with lightweight in-memory and file stores for instant local evaluation, production enterprise and municipal deployments should configure durable SQL or Oxigraph storage backends, external Key Management Services (KMS), write-once-read-many (WORM) audit ledgers, and centralized identity provider integrations.
Next