A Lumion is a row of data that carries its own rules with it. Wherever it goes any user can prove what the data is, who wrote it, and who is allowed to read or change each part of it, all without servers or authorities. This is the opposite of the usual case, where software defines the rules for data. Software very rarely has a formal specification and can change significantly in a single version update, let alone the wholesale replacements that happen over time. A Lumion has a formal RFC specification.

In brief, a Lumion takes a plain text row of information (for example, a row in a CSV file) and adds privacy, encryption, a global namespace, and a way for one row to point at another. Lumions wouldn't be needed if JSON already had those concepts.

A Lumion is also closed under copy, by which we mean you can copy it anywhere and it still fully works, because everything it needs to function travels inside it. That, together with being verifiable offline, means a row can be moved anywhere in the cloud or onto other devices at any time and keep all its protections.

What's in this directory

Here you will find the draft Lumion RFC specification, split in the usual way for IETF RFC standards. As quickstart, go to the runnable Python demo, which builds example Lumions in a plain text file and shows each property being added one at a time.

Document	Layer	Status
draft-shearer-lumion	The Lumion: the self-contained object and its properties. Standalone.	Draft complete
draft-shearer-lumion-encoding	Lumion encoding: the byte layout for one Lumion.	Draft complete
draft-shearer-lumion-authority	The Lumion authority layer: optional guarantees that require an external lookup of some kind.	Planned, not yet started
draft-shearer-lumion-exchange	The Lumion wire protocol: optional transport between parties. Depends on the preceding documents.	Possible future work, maybe never

The first two documents are complete RFC drafts and contain everything needed to implement Lumions. The authority and (possible) exchange documents relate to external systems such a lookup service for usernames or seeing if a particular Lumion has been redacted. The .txt files are generated from the Kramdown source in src/, following RFC-KRAMDOWN-HOWTO.md.

The Lumion was originally developed for LumoSQL, a privacy-and-integrity modification (not a fork) of SQLite. The idea is that a Lumion can be used for rows in the trillions of SQLite databases that exist, for apps used for finance, chat, dating and other highly personal purposes. A row from such an app could travel across the cloud and live in multiple databases and still have its security protections enforced. The high-level LumoSQL motivation document explains the Lumion strategy.

Rules enforced by data instead of code

Normally it is software that enforces a rule such as you do not have permission to read that person's salary. The rule lives in one program, written by a software developer. If the developer made a mistake with the rule, or the program does not know the salary is your salary, then things go wrong. You may be shown the incorrect salary, or denied access to your own personal data. This is everyday experience of a computer doing the wrong thing with your data and no way to argue with it.

A Lumion turns this on its head, because the enforcement rule lives in the data. A salary row can be encrypted with several keys, and one of them the employee holds (you, in this case). You can therefore always read your own salary. Another key is held by the Payroll Department, who can read and change it because that is their job. A read-only key could be issued to the tax office. In future RFC revisions this read-only key could be issued with the special property that it starts working at the time and date the user specifies (which does not require any non-public information) or that it stops working the moment the salary changes (which does require an external authority, something the third planned RFC describes). The important fact is that no program is trusted to remember the rule, because it is enforced in data.

Lumions move the decisions that matter out of unreliable code and into the data structure. Any application that handles the data must abide by the data's mathematical rules.

Lumions are not a blockchain

While it is true one Lumion can point to another and has cryptographic integrity, there is almost no overlap between a blockchain and a Lumion. A blockchain is a shared, ordered, append-only ledger maintained by consensus among many people. On the other hand, Lumion is a single self-contained object that proves things about itself and doesn't care what anyone else thinks.

The three problems a Lumion solves

Problem 1: Complexity. The software that runs all of society is too large and complex for anyone to understand in full, and the cost of software change means conservative thinking is correctly appled. But the same thinking means software becomes incompatible when the inevitable system upgrades happen. This is a simple version of the technical debt concept, where software degrades over time. Technical debt is recognised as a major drag on organisations and even society. A Lumion does not rot in this way, because its rules are enforced by its own bytes and public cryptography rather than by a particular program continuing to run and be maintained.

Problem 2: Disempowered users. People trust software with intimate data such as banking, health, private messages, and dealings with the state. The assurance they get on their screen is a promise that their data will be looked after, like we take your data security very seriously. The user has no alternative and no recourse, and just has to accept whatever the bank says. Users know that personal data is often shared accidentally or deliberately and that they have no agency over what the tech companies decide to do. A Lumion reverses this in part, giving the data owner control over who may see, change, and move certain kinds of data.

Problem 3: Knowledge that does not survive. Each decade, technical debt means working software grows harder to run as its dependencies shift; much of it is unusable within five or ten years. A row written today instead stays verifiable by its own rules long after the software that made it is gone, for as long as its cryptographic algorithms remain sound. When an algorithm ages, a later encoding can carry the same data forward. There is no chance that todays encryption algorithms cannot be understood in the future (even if they are by then obsolete), whereas it is common for computer languages and systems to become archaeic to the point of illegibility in just a few decades.

What a Lumion can do

A Lumion is built up one property at a time, from the simplest signed row to a fully governed one:

• Sign it. A digital signature over the content makes any change detectable and identifies the author.
• Name it from its content. A content-derived identifier is a one-way hash of the content, which makes it unique among all data in the world and recognisable anywhere. Two people who build the same named content will have the same name for it, because the hash is the same.
• Version it. A signed version count gives it history. The software doing an update can increment the version.
• Link it. Carry the name of a prior Lumion version. Rows therefore form chains that anyone holding member Lumions can walk and check.
• Redact it. A holder can drop one portion of a Lumion. Also called elision, this means the part is gone but the signature still holds.
• Encrypt it. Encrypt the content to a chosen set of readers (confidentiality). Releasing a key for one part but not another gives selective decryption.
• Govern it. Mark, per field, which keys may change it, or mark a field as unchangeable. This is role-based access control carried inside the row.

With the full governance features, the salary row above can be made so that only the employee can read it, only the Payroll Department can change it, and an auditor can verify the numbers with the bank details redacted -- and none of this requires any permissions in a database. If you don't hold a valid key for writing, an attempted write just destroys the signature, so it will be obvious that the row is corrupted, and in many cases the row won't be readable at all.

The same properties help with the everyday problem of trusting the company that wrote the chat app on your phone: with so many updates, upgrades and the occasional bug, you can't really be sure the data or its backups are safe, and criminals or police who get hold of the data have ways to force you to hand over encryption keys. If the chat data is stored as Lumions, you can instead supply a key that:

• proves the data is yours and uncorrupted, but leaves the messages unreadable, or
• lists the To, From and Date fields but keeps message contents redacted, or
• reads the chat data but does not allow it to be written to, so nothing can be quietly altered without it becoming obvious.

Scope: what Lumions cover {#scope-what-lumions-cover}

Role-Based Encryption (RBE) and cryptographic RBAC embed RBAC policy in encrypted data so that a user holding a qualified role can decrypt it. The Lumion concept divides that idea into two:

1. the static part, with rules fixed when the row is created, which can survive copying, and
2. the dynamic part, including grant, revoke and membership administration, which cannot survive copying.

The two complete drafts in this directory address only part 1, i.e. everything that a single copied Lumion can enforce on its own. Part 2 is the job of the planned authority layer (draft-shearer-lumion-authority): revocation, membership management, checking whether a Lumion is the latest version, and connecting Lumions to existing authorities such as blockchain, LDAP or Active Directory. The possible/someday/maybe exchange protocol (draft-shearer-lumion-exchange) would then theoretically cover how parties transport Lumions and authority statements between each other. There are already many ways to exchange rows of data so this last RFC may never be needed.

Making Lumions relevant

There are many excellent encryption schemes that are known to work, but encryption is only useful if everybody has it available to them without difficulty. It would be great if thousands of application developers decided to use Lumions, but until that happens this specification isn't useful. The LumoSQL project aims to use the vast reach of SQLite as a distribution mechanism, and has already demonstrated that this works, including within the existing binary format of SQLite without disturbing existing applications that know nothing of Lumions. Thus there is a feasible path for rolling out privacy-preserving per-row encryption technologies to billions of people in just a few cycles of mobile device updates.

Lumions are also not limited to database rows. The Lumion is described as a row because that is the most common way for data to be stored, but anything that must travel with its access rules can be a Lumion, including a record, a message, a photograph, a document, or a single field.