Independent Submission D. Shearer
Internet-Draft LumoSQL
Intended status: Experimental 23 July 2026
Expires: 24 January 2027
Lumion Data Object With Self-contained Access Control
draft-shearer-lumion-00
Abstract
A Lumion is a data row that carries with it everything needed to
prove what it is, who wrote it, and who may read or change each of
its parts. Its rules are enforced by mathematics carried inside the
row. This is the opposite of the usual scheme where software defines
the access rules for data. It is self-contained so that any party
holding the Lumion can verify these properties using only public
information. A Lumion can be exported from a database and moved
across the cloud without losing its integrity.
This document specifies the Lumion as a set of required properties,
building from the simplest signed row up to a row with per-field
access rules. The encoding is specified in [LUMION-ENCODING]. Every
property defined here works in isolation and still works no matter
where it is copied. Future properties may require an external
authority, meaning a system outside a copy of the Lumion that makes
statements about it, as described in [LUMION-AUTHORITY].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 January 2027.
Shearer Expires 24 January 2027 [Page 1]
Internet-Draft Lumion July 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. How a Lumion Is Composed . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Properties and behaviour of a Verifier . . . . . . . . . . . 6
6. Properties of a Lumion . . . . . . . . . . . . . . . . . . . 7
6.1. Integrity and Authorship . . . . . . . . . . . . . . . . 7
6.2. Name . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Part Hash and Selective Disclosure . . . . . . . . . . . 7
6.4. Versioning . . . . . . . . . . . . . . . . . . . . . . . 8
6.5. Structural Linkage . . . . . . . . . . . . . . . . . . . 8
6.6. Redaction . . . . . . . . . . . . . . . . . . . . . . . . 8
6.7. Confidentiality . . . . . . . . . . . . . . . . . . . . . 8
6.8. Access Control . . . . . . . . . . . . . . . . . . . . . 9
7. Self-Identification . . . . . . . . . . . . . . . . . . . . . 9
8. Authority Layer . . . . . . . . . . . . . . . . . . . . . . . 9
9. Relationship to Other Documents . . . . . . . . . . . . . . . 10
10. Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
Shearer Expires 24 January 2027 [Page 2]
Internet-Draft Lumion July 2026
1. Introduction
A rule about data is usually enforced by software, for example, a
program that decides who may read a salary or change a record.
Programs change all the time for many reasons, but the data lives on
and is handled by the next version of the program, often with rules
that are different. With Lumions, the rules are moved into the data,
enforced by mathematics. Software complying with the rules can see
or change the data. The guarantees of a Lumion are achieved with
signatures, one-way names, and checksums.
This document specifies the Lumion abstractly, covering mandatory
properties and intent. Details of encoding, ciphers and wire format
are found in other RFCs.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. How a Lumion Is Composed
This section introduces Lumion properties by building from the
simplest form to the most capable, adding one property at a time.
The normative definitions follow in Section 6.
A signed row: A row with a signature over its plaintext content.
Plaintext is the readable content before any encryption is
applied. Any change is detectable, and the signer is
identifiable.
A named row: A row whose identity is derived from its content, so
that the name proves it belongs to this row and two parties
building the same row arrive at the same name.
A versioned row: A row that carries a version count, incremented and
re-signed on each update, so versions can be ordered.
A linked row: A row that references its prior version by name, so a
holder can walk and verify a sequence of updates.
A redactable row: A row from which a holder may remove parts,
leaving the remainder verifiable against the original signature.
Different recipients can receive different subsets of the same
signed row.
Shearer Expires 24 January 2027 [Page 3]
Internet-Draft Lumion July 2026
A confidential row: A row whose content is encrypted to a fixed set
of readers, each of whom can read any copy with a key held in
advance.
A row with access rules: A row in which each field carries a fixed
set of writers permitted to change it, and may be marked
unchangeable for the life of the row. A field is read- only to
anyone outside its permitted writers. This is role-based access
control carried in a row.
3. Terminology
3.1. Terms
Lumion: A self-contained data object conforming to this document,
carrying its own name, integrity proof, authorship, and access
rules.
Part: An addressable component of a Lumion, such as a field of a
row. Each part has its own part hash and may be present in full
or removed (Section 6.6).
Name: A content-derived identifier for a Lumion: a value computed
from the content covered by the Lumion name by a one-way hash
function, such that recomputing it confirms the binding to that
content, and equal named content yields an equal name
(Section 6.2).
Part hash: A hash computed from a part. It lets the part be
referred to and proves that the part was present in the signed
body, even when the part's content has been removed.
Signature: A digital signature over the content, by which any
alteration is detectable and the producing key is identifiable
(Section 6.1).
Redaction: Replacement of a part by its part hash, removing the
part's content while leaving the name and signature valid. Also
called elision. Redaction needs no key and is performed by a
holder (Section 6.6).
Confidentiality: Encryption of content to a fixed set of readers, so
that readers with a key can read it (Section 6.7). Distinct from
redaction: an encrypted part is present in encrypted form, where a
redacted part is absent.
Selective decryption: Release of a key for some confidential parts
Shearer Expires 24 January 2027 [Page 4]
Internet-Draft Lumion July 2026
and not others, disclosing a subset of an encrypted Lumion without
altering it.
Role-based access control: An access model in which each part
carries a fixed set of keys permitted to change it. A read key
may read; a write key in a part's set may change that part
(Section 6.8).
Permitted writers: The fixed set of keys permitted to change a given
part. Fixed when the Lumion is created; administered membership
belongs to the authority layer (Section 8).
Link: A reference held by one Lumion to another, by name. This
revision defines only a prior link (Section 6.5).
Version: A signed count incremented on each update, establishing a
Lumion's place in a sequence of updates (Section 6.4).
3.2. Roles
Three kinds of party can act on a Lumion.
Generator: Produces a Lumion from supplied data and can read any
Lumion it has keys for. A Generator is a full implementation of
this RFC.
Reader: Accesses the parts of a Lumion for which it holds the
required key. A Reader implements verification and reading from
this RFC.
Identifier: Identifies a byte sequence as a Lumion and extracts its
name without a key.
4. Structure
A minimal Lumion is a signed body with a name. Optional parts add
capabilities without removing the guarantees below them. The
structure, with no widths, order, or encoding implied:
Shearer Expires 24 January 2027 [Page 5]
Internet-Draft Lumion July 2026
name = value derived from the signed body
signed body
+--------------------------------------------------------------+
| signature over the whole body |
| |
| parts |
| part content, or, removed-content marker |
| part hash for each part |
| optional access rule for each part: |
| - permitted writers |
| - unchangeable |
| |
| optional version |
| optional prior link to another Lumion name |
+--------------------------------------------------------------+
The name is computed over the whole body, so it is unchanged whether
a part is present or reduced to its part hash. Permitted writers and
the unchangeable mark are themselves inside the signed body. A prior
link contains the name of another Lumion.
5. Properties and behaviour of a Verifier
This section describes the checks a party performs on a Lumion.
On any Lumion, a verifier:
1. Recomputes the name from the content covered by the Lumion name
and confirms it matches the stated name. A present part proves
itself through its content and part hash; a removed part proves
itself through the part hash left behind. The name is therefore
unchanged by removal of parts.
2. Checks the signature over the body, establishing that the content
is unaltered and identifying the key that produced it.
On a Lumion that claims access rules, a verifier holding the prior
version also:
1. Compares the Lumion against the prior version it references, part
by part. For each part, it first confirms that the access rule
for that part has not changed. For each content change, it
checks the rule for that part: an unchangeable part must not have
changed; a change to a part with permitted writers must be signed
by one of those keys.
Shearer Expires 24 January 2027 [Page 6]
Internet-Draft Lumion July 2026
A verifier holding only one version performs steps 1 and 2. Access
rules are enforced by a party holding both versions. A verifier with
a run of versions follows the prior-version references as a chain,
confirming the sequence is unbroken.
6. Properties of a Lumion
A Lumion MUST provide the properties in Section 6.1 and Section 6.2.
It MAY provide any of the others. Each property is stated as a
requirement on the Lumion, independent of encoding.
6.1. Integrity and Authorship
A Lumion MUST be signed over its content. The signature MUST allow
any party to detect any alteration of any signed part, and to confirm
which key produced the Lumion.
A verifier MUST establish the acceptable signing algorithm from the
key or from out-of-band policy, meaning policy supplied outside the
Lumion. A verifier MUST NOT accept an algorithm solely because the
Lumion declares it, and MUST reject an absent or unprotected signing
algorithm.
6.2. Name
A Lumion MUST have a name derived from the content covered by the
Lumion name, such that recomputing the name confirms the binding, and
two parties holding the same named content derive the same name. The
name is computed from the Lumion bytes and public rules.
For this property, named content means the cryptographic content
carried by the Lumion, not necessarily the plaintext meaning of a
field. If a part is encrypted, the encrypted representation is the
named content for naming purposes. Two Lumions containing the same
plaintext but different encryption randomness can therefore have
different names.
The name makes a Lumion recognisable among arbitrary data, and unique
among Lumions through the one-way derivation from named content.
6.3. Part Hash and Selective Disclosure
A Lumion's integrity rests on a single value computed from hashes of
its parts, with three required properties. The value names the
Lumion (Section 6.2). Any part MAY be replaced by its own part hash,
removing the part's content while leaving the overall value
unchanged. A part MAY hold the part hash of another Lumion, allowing
references between Lumions (Section 6.5).
Shearer Expires 24 January 2027 [Page 7]
Internet-Draft Lumion July 2026
This is what makes redaction possible without re-signing: a removed
part leaves behind its part hash, the overall value is unchanged, and
the original signature still verifies.
A Generator MUST add unpredictable data to any removable part whose
content is guessable. This makes trial recovery from candidate
contents infeasible.
6.4. Versioning
A Lumion MAY carry a version count, incremented on each update and
re-signed. A claimed version is an authentic statement of which
version this is.
6.5. Structural Linkage
A Lumion MAY reference its prior version by name. This reference is
a signed part of the Lumion, so a Lumion's claimed prior link and
version are tamper-evident.
A holder verifies a structure by checking each referenced name
against the named Lumion's recomputed name, and verifies a sequence
by following prior references as a chain. A referenced name
identifies a missing member when the named Lumion is absent.
Completeness is an authority-layer guarantee.
A holder MAY disclose the prior link while removing content, or
disclose content while removing the prior link; either remains
verifiable.
6.6. Redaction
A holder MAY remove any part of a Lumion, leaving a valid Lumion with
the same name and the same valid signature. The removed part's
content is gone; its part hash remains, proving the part existed and
was signed.
Redaction is performed by a holder, needs no key, and allows
graduated disclosure of one signed row to different recipients. A
party holding a fuller copy keeps any value already disclosed to it.
6.7. Confidentiality
A Lumion MAY have its content encrypted to a fixed set of readers,
each able to read any copy with a key held in advance.
Shearer Expires 24 January 2027 [Page 8]
Internet-Draft Lumion July 2026
Confidentiality differs from redaction: encryption hides content from
a party without a key; redaction removes content from a reduced copy.
A Lumion MAY use either or both. Key distribution and later reader
changes belong to the authority layer (Section 8).
6.8. Access Control
Access control in a Lumion is a set of fixed rules, carried inside
the Lumion and covered by its signature, constraining how one version
may differ from the version before it. A verifier checks a change by
comparing a Lumion against the prior version it references
(Section 6.5), part by part, against these rules. Because both
versions are signed and named, the comparison is local.
Two rules are defined. The rule attached to a part, including any
set of permitted writers, is fixed when the Lumion is created and
MUST remain identical in later versions. The mechanism rests on one
idea: a write key produces a valid Lumion only for the parts it may
write. The wrong key destroys the signature it would need to be
accepted.
Unchangeable field: A field MAY be marked unchangeable. Its content
MUST be identical to the corresponding field in the prior version.
The field is set once and read-only for the life of the Lumion,
while other fields may change.
Per-field writers: A field MAY carry a fixed set of writers
permitted to change it. A change to that field is valid only if
made by a permitted writer. A field is read-only to anyone
outside its set.
The authority layer handles granting a writer, removing one, and
permitted sets decided after creation (Section 8).
7. Self-Identification
A Lumion is identifiable as a Lumion, and its name extractable, by
any party, using no key.
8. Authority Layer
The companion [LUMION-AUTHORITY] describes guarantees that require
external statements about a Lumion: currency, revocation, dynamic
reader or writer membership, field provenance, append-only fields,
and single-instance claims.
Shearer Expires 24 January 2027 [Page 9]
Internet-Draft Lumion July 2026
9. Relationship to Other Documents
The Lumion (this RFC): The abstract self-contained object and its
properties.
The encoding [LUMION-ENCODING]: A concrete byte layout for one
Lumion: serialisation, one-way functions, the signature scheme,
and deterministic rules.
The authority layer [LUMION-AUTHORITY]: The semantics of guarantees
that need an external authority.
The exchange protocol: How parties transport Lumions and authority
assertions between each other.
10. Size
A Lumion's overhead is a small fixed cost per row, for its signature
and name, independent of how many fields it has, plus a small cost
for each field made separately removable. A fully disclosed Lumion
is close to the size of its underlying data. These costs depend on
the chosen signature; a larger signature raises the fixed cost
without changing the proportion. The fixed cost makes a single
Lumion a poor fit for a small row; a Generator MAY apply one Lumion
to a group of small rows, removable at row boundaries, to share the
cost.
11. Security Considerations
The strength of a Lumion's integrity, authorship, and naming reduces
to the strength of the chosen signature and the collision resistance
of the chosen one-way derivation. Collision resistance means it is
infeasible to find two inputs with the same name. Both are selected
by the Generator and identified in the Lumion.
A verifier MUST establish the acceptable algorithm from the key or
out-of-band policy and MUST NOT trust an algorithm declared by the
Lumion alone. An absent or null signing algorithm MUST be rejected.
This prevents an attacker from choosing how a Lumion is processed.
Removal of a part with guessable content leaks that content through
its part hash, which an attacker matches against candidate contents.
A Generator MUST add unpredictable data to such parts (Section 6.3).
A Lumion's name is constant across copies and redactions, which makes
a Lumion traceable wherever it travels. The name is a persistent
identifier.
Shearer Expires 24 January 2027 [Page 10]
Internet-Draft Lumion July 2026
A Lumion with access rules is verified by comparing it against its
prior version. A verifier that holds only one version checks the
signature and the name. Access rules are enforced by a party holding
both versions.
12. IANA Considerations
Any self-identification convention and registrations belong with the
encoding.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
13.2. Informative References
[LUMION-AUTHORITY]
Shearer, D., "The Lumion Authority Layer (work in
progress)", Work in Progress, Internet-Draft, draft-
shearer-lumion-authority, n.d.,
<https://datatracker.ietf.org/doc/html/draft-shearer-
lumion-authority>.
[LUMION-ENCODING]
Shearer, D., "Lumion Encoding: Byte Layout for Lumion
Objects", Work in Progress, Internet-Draft, draft-shearer-
lumion-encoding, n.d.,
<https://datatracker.ietf.org/doc/html/draft-shearer-
lumion-encoding>.
[LUMOSQL] The LumoSQL Project, "LumoSQL", n.d.,
<https://lumosql.org/>.
Acknowledgments
This document builds on the original Lumions draft of 2021, co-
authored by Dan Shearer, Ruben De Smet and Claudio Calvelli, and on
the LumoSQL project [LUMOSQL].
Shearer Expires 24 January 2027 [Page 11]
Internet-Draft Lumion July 2026
Author's Address
Dan Shearer
LumoSQL
Email: dan@shearer.org
URI: https://shearer.org
Shearer Expires 24 January 2027 [Page 12]