AEON Security Architecture
Overview
AEON provides a deterministic structural model that enables reliable document integrity, authentication, and encryption without embedding cryptographic mechanisms directly into the language.
Security features in AEON are implemented through conventions layered on top of AEON core, allowing the language itself to remain minimal while enabling interoperable secure data exchange.
The AEON security model is based on four conventions:
aeon.gp.security.v1aeon.gp.integrity.v1aeon.gp.signature.v1aeon.gp.encryption.v1
These conventions together define how AEON documents may be sealed, signed, and encrypted.
Core Principles
The AEON security architecture follows several key principles.
Deterministic Structure
AEON documents have deterministic structural semantics. Canonical document state can therefore be hashed reliably across independent implementations.
Envelope Closure
Security metadata is placed in a document closure structure called the envelope.
This keeps cryptographic metadata separate from document content while ensuring the envelope can seal the document.
Convention Layering
Cryptographic mechanisms are defined by conventions rather than AEON core.
This allows algorithms and security models to evolve independently of the language.
Processor Neutrality
AEON does not mandate specific algorithms, trust models, or key infrastructure. Processors and profiles may apply their own security policies.
Document Structure
An AEON document participating in the security conventions conceptually contains three parts:
aeon:header
The header declares core processing metadata such as encoding and mode.
Document Body
The body contains the semantic content of the document.
aeon:envelope
The envelope contains integrity, signature, and encryption metadata.
The envelope must be the final binding in the document.
No additional bindings may appear after it.
The Security Envelope
The envelope is defined by aeon.gp.security.v1.
Example:
Each section may be present depending on the conventions used.
Integrity Layer
aeon.gp.integrity.v1 defines how a deterministic hash of the document is computed.
The hash covers the final canonical document state excluding the envelope.
Example:
This provides tamper detection and forms the foundation for signatures.
Signature Layer
aeon.gp.signature.v1 defines how cryptographic signatures are represented.
Each signature verifies the integrity hash declared in the envelope.
Example:
Multiple signatures may appear, allowing co-signing and approval workflows.
Encryption Layer
aeon.gp.encryption.v1 defines how encrypted payloads are represented.
Example:
Encryption protects the document body while leaving the envelope visible so processors know how to decrypt the document.
Verification Workflow
A processor verifying a secured AEON document typically performs the following steps:
- Parse the AEON document.
- Locate
aeon:envelope. - Compute the canonical integrity hash.
- Compare with
integrity.hash. - Verify each signature using the declared algorithm and key.
- If encrypted, decrypt the payload using the declared key.
The exact security policy applied is determined by the processor or profile.
Security Convention Stack
The conventions form a layered model:
This architecture allows AEON to support secure documents while keeping the core language independent of cryptographic mechanisms.
Design Outcome
The AEON security model enables:
- deterministic document integrity
- self-verifying documents
- multiple independent signatures
- encrypted payloads
- extensible security conventions
All without introducing cryptographic complexity into the core language.
Good idea. Conventions define structure, but profiles define safe usage. Without profiles, every system could choose different algorithms and you lose interoperability.
Below is a simple three-profile model that keeps things manageable while allowing growth.
AEON Security Profiles
Profiles define approved algorithm sets and usage rules for the AEON security conventions.
They sit above the conventions:
Profiles ensure that independently built systems can securely exchange AEON documents.
1. aeon.secure-basic.v1
Purpose
Provide a minimal, widely implementable security baseline.
Designed for:
- simple document signing
- lightweight interchange
- developer tooling
- configuration files
- small services
Required conventions
Allowed algorithms
Hash:
Signature:
Not included
- encryption
- timestamp authorities
- Merkle proofs
- audit logs
Example
2. aeon.secure-standard.v1
Purpose
Provide a general-purpose secure document profile.
Designed for:
- enterprise document exchange
- APIs
- signed records
- authenticated messages
Required conventions
Allowed algorithms
Hash:
Signature:
Encryption:
Optional features
- multiple signatures
- encryption + signature combination
- signing metadata (
time,issuer)
Example
3. aeon.secure-advanced.v1
Purpose
Enable high-assurance and large-scale verifiable systems.
Designed for:
- regulatory logs
- supply chain records
- AI traceability
- long-term archives
- distributed verification
Required conventions
Features
- Merkle subtree verification
- cryptographically chained audit logs
- multiple signing authorities
- timestamp proofs
- partial document verification
Example envelope
Profile Declaration
Profiles should be declared in the document metadata.
Example:
or
Profiles act as policy declarations, not structural rules.
Why Profiles Matter
Profiles provide:
Interoperability
Systems can safely exchange AEON documents knowing which algorithms are expected.
Security baseline
Profiles prevent weak or incompatible algorithms.
Implementation simplicity
Developers can implement a profile rather than the entire security ecosystem.
Recommended Launch Set
For the first release of AEON security, I would ship only two profiles:
Leave advanced for later.
This keeps the ecosystem manageable.
Strategic Outcome
With:
- security conventions
- integrity hashing
- signature vocabulary
- encryption envelope
- security profiles
AEON becomes a format for:
verifiable structured data
which is a very strong differentiator compared to:
- JSON
- YAML
- TOML
- XML