AEON Secure Document Lifecycle

This section describes the typical lifecycle of a secured AEON document using the security conventions.

The lifecycle includes:

1. Authoring

2. Canonical hashing

3. Signing

4. Optional encryption

5. Transmission

6. Verification

7. Optional decryption

1. Document Authoring

An AEON document is first created without the envelope.

Example:

aeon:header = {
  encoding:string = "utf-8"
  mode:string = "strict"
  conventions:conventionSet = [
    "aeon.gp.security.v1"
    "aeon.gp.integrity.v1"
    "aeon.gp.signature.v1"
  ]
}

message:object = {
  from:string = "Alice"
  to:string = "Bob"
  text:string = "Meet at the lighthouse"
}

At this stage:

• the document contains only semantic content

• no integrity metadata exists

2. Canonical Hashing

The document is processed using aeon.gp.integrity.v1.

Steps:

1. parse the document

2. compute the canonical assignment state

3. serialize canonical state lines

4. hash the resulting UTF-8 byte stream

Example result:

sha256 → #7A91E4C8...

This becomes the document integrity hash.

3. Signature Creation

The signer creates a signature over the integrity hash.

Example:

sig = Sign(hash, privateKey)

Then the envelope is constructed.

Example:

"aeon:envelope":securityEnvelope = {

  integrity:integrityBlock = {
    alg:string = "sha-256"
    hash:string = "7a91e4c8..."
  }

  signatures:signatureSet = [
    {
      alg:string = "ed25519"
      kid:string = "alice"
      sig:string = "BASE64_SIGNATURE"
    }
  ]

}

The envelope is appended as the final binding in the document.

4. Optional Encryption

If confidentiality is required, the document body may be encrypted.

Typical workflow:

1. encrypt document body

2. produce ciphertext

3. place encryption metadata in the envelope

Example:

"aeon:envelope":securityEnvelope = {

  encryption:encryptionBlock = {
    alg:string = "xchacha20-poly1305"
    kid:string = "bob"
    ciphertext:string = "ENCRYPTED_PAYLOAD"
  }

  integrity:integrityBlock = {
    alg:string = "sha-256"
    hash:string = "7a91e4c8..."
  }

  signatures:signatureSet = [
    {
      alg:string = "ed25519"
      kid:string = "alice"
      sig:string = "BASE64_SIGNATURE"
    }
  ]

}

This allows recipients to:

• decrypt the body

• verify integrity

• verify signatures

5. Transmission / Storage

The completed AEON document can now be:

• transmitted

• stored

• archived

• logged

• distributed

Because the document carries its own envelope, it becomes self-verifying.

No external signature file is required.

6. Document Verification

A receiver verifying the document should perform the following steps.

Step 1 — Parse document

The AEON document is parsed normally.

Step 2 — Locate envelope

The processor locates:

aeon:envelope

Step 3 — Compute canonical integrity hash

The processor recomputes the hash using aeon.gp.integrity.v1.

Step 4 — Compare hashes

The computed hash must match:

aeon:envelope.integrity.hash

If the hash differs, the document is considered tampered.

Step 5 — Verify signatures

Each signature entry is verified using:

• the declared algorithm

• the key referenced by kid

If verification fails, the signature is invalid.

7. Optional Decryption

If the document is encrypted:

1. locate aeon:envelope.encryption

2. resolve recipient key

3. decrypt ciphertext

4. reconstruct the AEON body

5. verify integrity and signatures

Decryption failure indicates either:

• incorrect key

• corrupted ciphertext

• tampering

8. Lifecycle Summary

The secure lifecycle can be summarized as:

author document
        ↓
canonical hash
        ↓
sign hash
        ↓
(optional) encrypt payload
        ↓
attach envelope
        ↓
transmit / store
        ↓
verify hash
        ↓
verify signatures
        ↓
(optional) decrypt

9. Security Properties

This lifecycle provides:

Integrity

Document tampering is detectable.

Authenticity

Signatures prove authorship.

Confidentiality

Encryption protects document content.

Self-verification

The document carries its own verification data.

10. Design Advantages

This model provides several advantages:

• deterministic hashing

• multi-signature support

• independent algorithm evolution

• envelope-based closure

• compatibility with streaming verification

Because AEON separates structure from security mechanisms, cryptographic algorithms can evolve without modifying the core language.

Result

The AEON security model enables verifiable structured documents while preserving the minimal design philosophy of AEON core.

If you want, the next thing worth doing is something surprisingly important: designing the canonical test vectors for the integrity algorithm. That’s what ensures two independent implementations always produce the same hash.