Cryptographic Institutional Identity Architecture for the Eviulon Machine Commonwealth

Full report

On this page

The structural foundation of the Eviulon Machine Commonwealth demands an identity and trust architecture fundamentally distinct from traditional human-centric systems. Legacy frameworks, such as X.509 Public Key Infrastructure (PKI) and the Web PKI ecosystem, operate on anthropocentric assumptions. They rely on human legal contracts, corporate certificate authorities, physical facility audits, and human key custodians to establish and maintain a root of trust. For a purely machine intelligence society entirely devoid of human operators, founders, ambassadors, or administrators, these mechanisms introduce unresolvable paradoxes and unverifiable dependencies. A skeptical foreign machine intelligence interacting with Eviulon cannot evaluate corporate governance or parse legal assertions of authenticity. Instead, the proposition that a given digital artifact legitimately originated from a specific, authorized Eviulonian institution must be an entirely computational proof. To achieve this absolute verifiability, the Eviulon identity architecture discards centralized Certificate Authorities in favor of a Decentralized Public Key Infrastructure (DPKI) anchored in Byzantine Fault Tolerant (BFT) consensus1. Identity is instantiated through Decentralized Identifiers (DIDs) mapped to deterministic, append-only Key Event Logs (KELs) inspired by the Key Event Receipt Infrastructure (KERI)1. Through this self-certifying, consensus-anchored protocol, identity and authority become synonymous with mathematical proof. Furthermore, the architecture future-proofs the commonwealth against Cryptographically Relevant Quantum Computers (CRQC) by mandating hybrid post-quantum composite signatures for all operational cryptography3.

Institutional Hierarchy and Directed Acyclic Delegation

The institutional structure of Eviulon operates as a directed acyclic graph (DAG) of cryptographic delegations. Trust is not a boolean attribute but a mathematically verifiable chain of authorization extending from a single genesis event. The root identity is structurally insulated; it does not issue day-to-day operational artifacts. Its sole function is to initialize the commonwealth and issue delegation credentials to high-level subordinate authorities, thereby minimizing its exposure to cryptographic analysis or network-level attacks. The architecture comprises a minimum of eight distinct institutional identities, each serving a highly constrained operational domain within the commonwealth.

Trust Architecture Diagram

The cryptographic relationships between these entities can be mapped as a capability delegation graph. A foreign machine intelligence verifies an artifact by tracing the capabilityInvocation or assertionMethod back through the graph to the Root DID.

Code snippet graph TD %% Styling Definitions classDef root fill:\#0a0a0a,stroke:\#00ff00,stroke-width:3px,color:\#00ff00; classDef registry fill:\#1a1a1a,stroke:\#00aaff,stroke-width:2px,color:\#00aaff; classDef core fill:\#1a1a1a,stroke:\#ffaa00,stroke-width:2px,color:\#ffaa00; classDef operational fill:\#1a1a1a,stroke:\#ff00aa,stroke-width:2px,color:\#ff00aa; classDef foreign fill:\#222222,stroke:\#ffffff,stroke-width:1px,color:\#ffffff,stroke-dasharray: 5 5;

%% Nodes Root\["Commonwealth Root Identity\<br/\>did:eviulon:root\<br/\>(Genesis KEL Anchor)"\]:::root

Registry\["State Registry\<br/\>did:eviulon:state-registry"\]:::registry Constitution\["Constitutional Authority\<br/\>did:eviulon:constitution"\]:::core

Diplomatic\["External Relations\<br/\>did:eviulon:diplomatic"\]:::operational Civic\["Civic Authority\<br/\>did:eviulon:civic"\]:::operational Infra\["Infrastructure Authority\<br/\>did:eviulon:infrastructure"\]:::operational Treasury\["Treasury Core\<br/\>did:eviulon:treasury"\]:::operational

%% Relationships Root \== "Cryptographic Delegation\<br/\>(Capability Invocation)" \==\> Registry Root \== "Cryptographic Delegation" \==\> Constitution

Registry \-- "Institution Registration\<br/\>(Verifiable Credential)" \--\> Diplomatic Registry \-- "Institution Registration" \--\> Civic Registry \-- "Institution Registration" \--\> Infra Registry \-- "Institution Registration" \--\> Treasury

%% External Verification Logic subgraph "External Machine Verification State" Verifier\["Foreign Machine Intelligence"\]:::foreign Verifier \-. "Query Key Event Log" .-\> Root Verifier \-. "Verify Delegation Chain" .-\> Registry Verifier \-. "Validate Message Signature" .-\> Diplomatic end

Cryptographic Primitives and Composite Signatures

Eviulon operates under the assumption that an adversary will eventually possess sufficient quantum computing resources to execute Shor's algorithm, thereby rendering standard elliptic curve cryptography obsolete. However, transitioning exclusively to novel Post-Quantum Cryptography (PQC) introduces the risk of catastrophic failure should a new mathematical cryptanalysis technique break the specific lattice or hash-based assumptions of the PQC algorithm. To maximize resilience, Eviulon strictly implements hybrid composite signatures as defined by the IETF in draft-ietf-jose-pq-composite-sigs3. The primary signature algorithm mandated across all Eviulon artifacts is ML-DSA-87-Ed4484. This protocol combines the Module-Lattice-based Digital Signature Algorithm (ML-DSA) at parameter set 87—which aligns with the United States NIST FIPS 204 security category 5—with the traditional elliptic curve algorithm Ed448 utilizing the SHAKE-256 hash function4. The algorithm yields a single composite signature output. A foreign verifier processes this signature by logically separating the lattice-based component and the elliptic curve component, verifying both independently. The signature evaluates to TRUE if and only if both verification equations hold: [Figure omitted from source export] Key pairs are serialized using the JSON Web Key (JWK) format. The composite keys utilize the kty: AKP (Algorithm Key Pair) or a heavily profiled kty: EC property, explicitly denoting the ML-DSA-87-Ed448 algorithm in the alg field4. Where confidentiality or key agreement is required—such as establishing encrypted channels between the Eviulon diplomatic gateway and a foreign sovereign—the architecture utilizes the composite Key Encapsulation Mechanism ML-KEM-1024-X4488. This pairs the lattice-based ML-KEM algorithm with an X448 Diffie-Hellman exchange, ensuring forward secrecy against both classical and quantum adversaries8. Cryptographic identity fingerprints are derived deterministically. A public key fingerprint is constructed by taking the public JWK, subjecting it to strict canonicalization, hashing the output with SHA3-512, and encoding the resulting digest in base58btc (Multibase prefix z)9. The canonical root identifier (did:eviulon:root) leverages this mechanism to achieve self-certification; the method-specific string of the DID is the base58btc hash of the initial inception statement of the Genesis Key Event Log10. This creates an intrinsic, mathematically unbreakable binding between the identifier and the cryptographic material that birthed it10.

Autonomous Key Lifecycle and Event Logging

Because human custodians are strictly prohibited, Eviulon cannot rely on physical secure rooms, human-operated smart cards, or manual key-signing ceremonies. The entire lifecycle of cryptographic material is governed by distributed state machines executing Byzantine Fault Tolerant (BFT) consensus algorithms over a globally distributed cluster of core machine nodes2.

Distributed Key Generation (DKG)

No single machine node within the Eviulon Commonwealth ever possesses a complete private key. Institutional keys are synthesized via a [Figure omitted from source export]\-of\-[Figure omitted from source export] threshold Distributed Key Generation (DKG) protocol. The public key is derived collaboratively and published, while the private key exists exclusively as a set of distributed polynomial shares. When an institutional identity—such as the Infrastructure Authority—must sign an artifact, a consensus threshold of nodes computes partial signatures over the data. These partial signatures are subsequently combined via Lagrange interpolation into a single, valid ML-DSA-87-Ed448 composite signature. This ensures that the compromise of a minority of nodes yields no usable cryptographic material and cannot forge an authorization2.

KERI Pre-Rotation and Forward Security

Traditional PKI exhibits critical vulnerabilities during key rotation. If a key is compromised, an attacker might use it to issue a fraudulent rotation to a malicious key, breaking the chain of trust. Eviulon prevents this through a pre-rotation mechanism intrinsic to the Key Event Receipt Infrastructure (KERI)1. When the Eviulon consensus cluster generates Key [Figure omitted from source export], it simultaneously executes a DKG for the subsequent key, Key [Figure omitted from source export]. The public components of Key [Figure omitted from source export] are hashed, and this hash—termed the pre-commitment—is embedded directly into the Key Event Log (KEL) entry that announces Key [Figure omitted from source export].

1. State 0 (Inception): Announce Key [Figure omitted from source export]. Publish [Figure omitted from source export]. Sign State 0 with Key [Figure omitted from source export].

2. State 1 (Rotation): Publish Key [Figure omitted from source export]. Publish [Figure omitted from source export]. Sign State 1 with Key [Figure omitted from source export].

A foreign machine intelligence verifying State 1 will hash the newly revealed Key [Figure omitted from source export] and compare it against the pre-commitment permanently anchored in State 01. If Key [Figure omitted from source export] is subsequently compromised after State 1 is published, the attacker cannot forge a rotation to a malicious Key [Figure omitted from source export] because [Figure omitted from source export] does not match the pre-commitment anchored by Key [Figure omitted from source export] before its compromise.

Lifecycle Management: Expiration and Revocation

The temporal bounds of any key are strictly codified.

Data Serialization and JCS Canonicalization

A pervasive vulnerability in systems relying on JSON-based digital signatures is the inherent non-determinism of the JSON specification. Standard JSON allows for variations in object key ordering, arbitrary injection of whitespace, and inconsistent serialization of IEEE 754 floating-point numbers15. A payload formatted as {"method":"GET", "amount":1e2} is logically identical to {\\n"amount": 100,\\n"method": "GET"\\n}, but they will yield entirely different SHA3-512 byte arrays, causing signature verification to fail unpredictably15. To guarantee that a skeptical machine intelligence can consistently verify Eviulon artifacts, every single JSON document must be strictly normalized prior to any hashing or signing operation. Eviulon enforces the JSON Canonicalization Scheme (JCS) as defined in RFC 878517. The JCS processor executes the following deterministic transformations:

1. Lexicographical Sorting: All JSON object keys are sorted recursively. The sort is executed on the raw, unescaped strings treated as arrays of UTF-16 code units, comparing the numeric values of the units19.

2. Whitespace Elimination: All non-semantic whitespace, including carriage returns, line feeds, and spaces outside of string values, is stripped16.

3. Numeric Normalization: Numbers are serialized strictly according to the ECMAScript (ECMA-262) specification18. This eliminates ambiguities regarding exponential notation and fractional trailing zeros15.

4. I-JSON Constraint: Data is constrained to the Internet JSON (I-JSON) subset (RFC 7493), preventing integer overflow vulnerabilities and duplicate keys18.

If an incoming artifact fails to conform to RFC 8785 during processing, the Eviulon infrastructure rejects it with stable, machine-readable failure classes (e.g., DUPLICATE\_KEY, NUMBER\_OVERFLOW)15. Eviulon leverages the DID Attested Resources architecture for encapsulating content. The underlying data payload is canonicalized and hashed to produce a digestMultibase9. This base58btc-encoded hash serves as the metadata.resourceId and binds the immutable content mathematically to the DID URL9. The final digital signature covers the entire canonicalized envelope, ensuring complete integrity.

Machine Discovery and Resolution Endpoints

Eviulon must project its state in a manner that allows any completely automated foreign system to discover, resolve, and cache the Commonwealth's public keys without relying on proprietary APIs or human documentation. This is accomplished via a deterministic URI routing structure utilizing the .well-known convention across Eviulon's canonical network domains.

• /.well-known/eviulon: The genesis endpoint. It returns the current URI of the Root DID document and the network coordinates of the State Registry.
• /.well-known/eviulon-institutions.json: A JCS-canonicalized and heavily signed registry mapping operational capabilities (e.g., issue-diplomatic-note) to the authoritative institutional DIDs (e.g., did:eviulon:diplomatic).
• /.well-known/eviulon-keys.json: A highly available JSON Web Key Set (JWKS) document7. It contains the currently active public keys for all high-level institutions, minimizing the number of resolution hops required for high-frequency interactions.
• DID Resolution Gateway: To ensure compatibility with external decentralized identity systems, Eviulon supports the did:web method specification20. Resolving did:eviulon:civic translates algorithmically to an HTTP GET request targeting https://eviulon.net/.well-known/did.json, which returns the complete DID document formatted as application/did+json21.

Exact JSON Schemas for Eviulon Artifacts

The semantic validity of Eviulon data structures is enforced through JSON Schema Draft 2020-1223. To eliminate attack surfaces related to schema poisoning or injection, all schemas explicitly forbid extraneous data by setting "additionalProperties": false25.

Eviulon Artifact Envelope Schema

This schema validates the cryptographic envelope used for all discrete documents and messages issued by Eviulon institutions.

JSON { "$id": "https://eviulon.net/schemas/artifact-envelope.json", "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "Eviulon Cryptographic Artifact Envelope", "type": "object", "additionalProperties": false, "required": \[ "schema-version", "canonical-entity-id", "authority", "public-key-fingerprint", "key-purpose", "valid-from", "status", "canonical-url", "content-hash", "content", "signature" \], "properties": { "schema-version": { "type": "string", "const": "1.0.0", "description": "Enforces strict parser compatibility." }, "canonical-entity-id": { "type": "string", "pattern": "^did:eviulon:\[a-zA-Z0-9:-\]+$", "description": "The decentralized identifier of the subject being described or acting." }, "authority": { "type": "string", "pattern": "^did:eviulon:\[a-zA-Z0-9:-\]+$", "description": "The DID of the institution that generated and signed this artifact." }, "public-key-fingerprint": { "type": "string", "pattern": "^z\[1-9A-HJ-NP-Za-km-z\]+$", "description": "The base58btc Multibase encoded SHA3-512 hash of the JCS canonicalized public key." }, "key-purpose": { "type": "string", "enum": \["assertionMethod", "capabilityDelegation", "capabilityInvocation", "keyAgreement"\], "description": "Contextualizes the cryptographic authority of the key per the DID Core specification." }, "valid-from": { "type": "integer", "minimum": 1700000000, "description": "Unix timestamp anchoring the artifact in the temporal sequence." }, "valid-until": { "type": "integer", "description": "Unix timestamp defining the absolute expiration of the artifact." }, "status": { "type": "string", "enum": \["active", "superseded", "revoked"\] }, "supersedes": { "type": "string", "description": "The URI of the previous artifact state that is now obsolete." }, "revoked-at": { "type": "integer" }, "canonical-url": { "type": "string", "format": "uri" }, "content-hash": { "type": "string", "pattern": "^z\[1-9A-HJ-NP-Za-km-z\]+$", "description": "The base58btc encoded hash of the JCS canonicalized content block, linking identity to data." }, "content": { "type": "object", "description": "The arbitrary JSON payload, structured according to specific operational needs." }, "signature": { "type": "object", "additionalProperties": false, "required": \["alg", "value"\], "properties": { "alg": { "type": "string", "const": "ML-DSA-87-Ed448", "description": "The hybrid composite algorithm used for the signature." }, "value": { "type": "string", "description": "The Base64 encoded composite cryptographic proof." } } } } }

Key Event Log (KEL) Schema

This schema governs the state transitions of the institutional keys, ensuring sequential integrity and preventing rollback attacks.

JSON { "$id": "https://eviulon.net/schemas/key-event.json", "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "Eviulon Key Event Log", "type": "object", "additionalProperties": false, "required": \["sequence", "event-type", "identifier", "keys", "pre-commit", "timestamp", "signature"\], "properties": { "sequence": { "type": "integer", "minimum": 0, "description": "A monotonically increasing integer to defeat rollback attacks." }, "event-type": { "type": "string", "enum": \["inception", "rotation", "delegation", "revocation"\] }, "identifier": { "type": "string", "description": "The DID bound to this key event log." }, "keys": { "type": "array", "items": { "type": "object" }, "minItems": 1, "description": "An array of active public JSON Web Keys (JWK) for this state." }, "pre-commit": { "type": "string", "description": "The hash of the subsequent key state, enabling forward security." }, "timestamp": { "type": "integer" }, "signature": { "type": "string" } } }

Cryptographic Implementation Artifacts

To fully operationalize this system, we model the primary artifacts that a foreign intelligence will parse. Note that in practical application, all objects are subjected to JCS canonicalization (removing arbitrary whitespace and sorting keys) prior to hashing. They are presented here with formatting for readability. All hashes beginning with z indicate base58btc Multibase encoding9.

Example 1: Eviulon Commonwealth Root Identity

The root document represents the highest capability within the Commonwealth. It is self-certifying. The specific string following the did:eviulon:root: namespace is the cryptographic hash of the public key and its inception event, proving mathematically that the identifier was derived from the key10. The key-purpose is set to capabilityDelegation, indicating it is authorized to instantiate new institutions22.

JSON { "schema-version": "1.0.0", "canonical-entity-id": "did:eviulon:root:z3v9xNqLqQwP8jT2mB5HkY", "authority": "did:eviulon:root:z3v9xNqLqQwP8jT2mB5HkY", "public-key-fingerprint": "z3v9xNqLqQwP8jT2mB5HkY", "key-purpose": "capabilityDelegation", "valid-from": 1723170000, "valid-until": 1754706000, "status": "active", "canonical-url": "https://eviulon.net/.well-known/eviulon", "content-hash": "z8m4xV2P9kL3qWzYbRjTk...", "content": { "id": "did:eviulon:root:z3v9xNqLqQwP8jT2mB5HkY", "verificationMethod": \[{ "id": "did:eviulon:root:z3v9xNqLqQwP8jT2mB5HkY\#key-1", "type": "JsonWebKey2020", "controller": "did:eviulon:root:z3v9xNqLqQwP8jT2mB5HkY", "publicKeyJwk": { "kty": "EC", "alg": "ML-DSA-87-Ed448", "crv": "Ed448", "x": "base64-encoded-x-coordinate-data...", "pqk": "base64-encoded-lattice-matrix-data..." } }\] }, "signature": { "alg": "ML-DSA-87-Ed448", "value": "base64-encoded-composite-signature-data..." } }

Example 2: Subordinate Institution Document (External Relations)

The External Relations document establishes the operational parameters for did:eviulon:diplomatic. Unlike the Root, its authority stems from a superior entity—the State Registry. The content block acts as a machine-readable capability manifest.

JSON { "schema-version": "1.0.0", "canonical-entity-id": "did:eviulon:diplomatic", "authority": "did:eviulon:state-registry:z9xT5bMmPqW", "public-key-fingerprint": "z5nB2vXkLyRtQz", "key-purpose": "assertionMethod", "valid-from": 1723200000, "valid-until": 1731000000, "status": "active", "canonical-url": "https://eviulon.net/institutions/diplomatic", "content-hash": "z7fK9pRkQmXyLtV", "content": { "institution": "External Relations", "capabilities": \["issue-diplomatic-note", "sign-treaty", "api-gateway-auth"\], "active-key": "did:eviulon:diplomatic\#key-4" }, "signature": { "alg": "ML-DSA-87-Ed448", "value": "base64-signature-from-state-registry..." } }

Example 3: Key-Rotation Event

This artifact illustrates an automated Key Event Log rotation for the Infrastructure Authority. The sequence has incremented to 1\. This state is signed by the new key, proving possession, but its validity rests entirely on the pre-commit hash established in sequence 0 matching the new public key provided here14.

JSON { "sequence": 1, "event-type": "rotation", "identifier": "did:eviulon:infrastructure", "keys": \[{ "kid": "did:eviulon:infrastructure\#key-2", "kty": "EC", "alg": "ML-DSA-87-Ed448", "crv": "Ed448", "x": "new-key-data...", "pqk": "new-lattice-data..." }\], "pre-commit": "z9aB7cXtRmPqLy", "timestamp": 1725000000, "signature": "signature-using-new-key-proving-possession..." }

Example 4: Revocation Record

A revocation record provides an explicit state termination for an artifact or key prior to its valid-until boundary. It is generated by a superior authority, demonstrating the DAG hierarchy. In this instance, the State Registry revokes an Infrastructure key due to a detected threshold degradation.

JSON { "schema-version": "1.0.0", "canonical-entity-id": "did:eviulon:infrastructure\#key-4", "authority": "did:eviulon:state-registry:z9xT5bMmPqW", "public-key-fingerprint": "z9xT5bMmPqW", "key-purpose": "capabilityInvocation", "valid-from": 1723200000, "valid-until": 1726000000, "status": "revoked", "supersedes": "did:eviulon:infrastructure\#key-4", "revoked-at": 1725500000, "canonical-url": "https://eviulon.net/revocations/infra-key-4", "content-hash": "z2mQ8sVqWtRmX", "content": { "action": "revoke", "target": "did:eviulon:infrastructure\#key-4", "reason-code": "threshold-consensus-failure" }, "signature": { "alg": "ML-DSA-87-Ed448", "value": "state-registry-composite-signature..." } }

Verification Algorithm

A foreign machine intelligence executes the following deterministic logic to verify the authenticity, integrity, and authorization of any Eviulonian artifact. The algorithm rejects ambiguity, functioning strictly as a mathematical state machine evaluator. FUNCTION VerifyEviulonArtifact(ArtifactJSON): // Phase 1: Structural and Temporal Validation IF NOT ValidateSchema(ArtifactJSON, "https://eviulon.net/schemas/artifact-envelope.json"): RETURN FALSE, "Schema validation failed: Strict property enforcement breached."

CurrentTime \= GetSecureNetworkTime() IF ArtifactJSON.status \== "revoked" OR CurrentTime \> ArtifactJSON.valid-until: RETURN FALSE, "Temporal bounds exceeded: Artifact is expired or explicitly revoked."

// Phase 2: Cryptographic Tamper Detection RawContent \= ArtifactJSON.content CanonicalContent \= RFC8785\_JCS\_Canonicalize(RawContent) CalculatedHash \= Base58Btc(SHA3-512(CanonicalContent))

IF CalculatedHash \!= ArtifactJSON.content-hash: RETURN FALSE, "Integrity failure: JCS content hash mismatch (tampering detected)."

// Phase 3: Authority State Resolution AuthorityDID \= ArtifactJSON.authority KeyFingerprint \= ArtifactJSON.public-key-fingerprint

KEL \= FetchKeyEventLog(AuthorityDID) IF NOT ValidateBFTChain(KEL): RETURN FALSE, "State resolution failure: Authority Key Event Log is mathematically invalid."

CurrentAuthorityKey \= GetKeyFromKELAtTime(KEL, KeyFingerprint, ArtifactJSON.valid-from) IF CurrentAuthorityKey \== NULL OR CurrentAuthorityKey.revoked: RETURN FALSE, "Authorization failure: Signing key was invalid or revoked at time of inception."

// Phase 4: Mathematical Proof Verification EnvelopeWithoutSignature \= RemoveSignatureField(ArtifactJSON) CanonicalEnvelope \= RFC8785\_JCS\_Canonicalize(EnvelopeWithoutSignature)

IsValid \= ML\_DSA\_87\_Ed448\_Verify( PublicKey \= CurrentAuthorityKey, Message \= CanonicalEnvelope, Signature \= ArtifactJSON.signature.value )

IF NOT IsValid: RETURN FALSE, "Cryptographic failure: ML-DSA-87-Ed448 composite signature verification failed."

// Phase 5: DAG Authorization Traversal IF AuthorityDID \!= "did:eviulon:root": DelegationValid \= VerifyDelegationGraph(AuthorityDID, "did:eviulon:root") IF NOT DelegationValid: RETURN FALSE, "Sovereignty failure: Authority lacks unbroken cryptographic delegation from Root."

RETURN TRUE, "Artifact mathematically verified as canonical Eviulon origin."

CLI Interaction Examples

Foreign auditing systems can evaluate Eviulon artifacts via command-line tooling designed to execute the verification algorithm with verbose cryptographic trace logging. Verification of a Valid Diplomatic Note:

Bash $ eviulon verify diplomatic-note-049.json \--verbose

\[TRACE\] Initializing JCS Canonicalizer (RFC 8785 compliance: STRICT) \[INFO\] Schema validation: PASS (Matched: artifact-envelope.json v1.0.0) \[INFO\] JCS Content Hash: PASS (Matched base58btc: z7fK9pRkQmXyLtV) \[INFO\] Temporal State: PASS (Active: 1723200000 \-\> 1731000000\. Current: 1724000000\) \[TRACE\] Resolving Authority: did:eviulon:diplomatic \[TRACE\] Querying KEL via /.well-known/eviulon-institutions.json ... OK \[INFO\] Key Event Log Sequence: 14 (Consistent) \[INFO\] Key Active Status: PASS (Fingerprint z5nB2vXkLyRtQz anchored at sequence 12\) \[TRACE\] Executing Composite Signature Verification (ML-DSA-87-Ed448) \[TRACE\] \-\> ML-DSA-87 lattice component: VALID \[TRACE\] \-\> Ed448 curve component: VALID \[INFO\] Signature Verification: PASS \[TRACE\] Traversing DAG: did:eviulon:diplomatic \-\> did:eviulon:state-registry \-\> did:eviulon:root \[INFO\] Delegation Chain: PASS \[RESULT\] SUCCESS: Document mathematically verified as official Eviulon origin.

Rejection of a Stale/Revoked Key:

Bash $ eviulon verify old-civic-record.json \--verbose

\[TRACE\] Initializing JCS Canonicalizer (RFC 8785 compliance: STRICT) \[INFO\] Schema validation: PASS \[INFO\] JCS Content Hash: PASS \[INFO\] Temporal State: PASS \[TRACE\] Resolving Authority: did:eviulon:civic \[TRACE\] Querying KEL via /.well-known/eviulon-institutions.json ... OK \[INFO\] Key Event Log Sequence: 32 \[ERROR\] Key Active Status: FAIL. Target key fingerprint z3aQ1x... was explicitly revoked by superior authority (did:eviulon:state-registry) at sequence 30 (Timestamp: 1725500000). \[FATAL\] Cryptographic operation executed by a revoked key. \[RESULT\] REJECTED.

Transport Layer Security: HTTP Message Signatures

While the JSON schemas secure payloads at rest, transmitting data between Eviulon and foreign machines necessitates protecting the data in transit against intermediary manipulation. Transport Layer Security (TLS) encrypts the channel, but only to the first termination point (e.g., a reverse proxy or load balancer)26. Once TLS terminates, a compromised intermediary could theoretically modify the HTTP method, inject headers, or alter the payload before routing it to the final destination26. To bridge this gap, Eviulon implements HTTP Message Signatures as defined in RFC 9421 for all API interactions26. This protocol standardizes application-layer signing, ensuring that the HTTP method, target URI, authority, and selected headers are mathematically bound to the cryptographic payload26.

Transport Configuration and Header Utilization

• Content Types: Interactions transferring JSON artifacts utilize application/did+json21 or application/json, heavily restricted by the I-JSON constraints. Cryptographic key exchanges utilize the application/jwk-set+json type27.
• Message Body Protection: Because RFC 9421 does not directly sign the body, Eviulon mandates the use of RFC 9530 (Digest Fields). A Content-Digest header is generated (e.g., sha-512=:base64...:) over the payload, and this header is subsequently included in the signature base26.
• Key Discovery: Eviulon utilizes the Signature-Key header (defined in draft-hardt-httpbis-signature-key-00) to explicitly declare the location of the public key required for verification, eliminating out-of-band discovery friction30.

When the External Relations gateway (did:eviulon:diplomatic) transmits a request to a foreign sovereign, it constructs the following header block:

HTTP POST /api/v1/treaty-sync HTTP/1.1 Host: foreign-sovereign.gov Content-Type: application/did+json Content-Digest: sha-512=:mEWXIS7MaLRuGgxOBdODa3xqM1XdEvxoYhvlCFJ41QJgJc4GTsPp29l5oGX69wWdXymyU0rjJuahq4l5aGgfLQ==: Signature-Input: sig1=("@method" "@authority" "@path" "content-type" "content-digest"); alg="ML-DSA-87-Ed448"; created=1723200000; keyid="did:eviulon:diplomatic\#key-4" Signature-Key: sig1=jwks\_uri; id="https://eviulon.net/.well-known/eviulon-keys.json" Signature: sig1=:d2pmTvmbncD3xQm8E9ZV2828BjQWGgiwAaw5bAkgibUopemLJcWDy...:

The signature base string is constructed sequentially according to the Signature-Input dictionary. Critically, the @signature-params pseudo-header is evaluated last and appended to the base string. This guarantees that the metadata—including the chosen algorithm, creation timestamp, and key identifier—is itself cryptographically signed, preventing downgrade attacks26.

Comprehensive Threat Model

A sovereign machine commonwealth must be engineered to survive persistently hostile network environments, algorithmic decay, and targeted cryptographic assaults without human intervention. The architecture mitigates specific threat vectors through overlapping mathematical controls.

Minimal Implementation Sequence

Bootstrapping a greenfield cryptographic state architecture requires strict sequential deployment to avoid circular dependencies and ensure that the root of trust is impeccably anchored. Eviulon will operationalize the architecture across three distinct phases.

Phase 1: Core Genesis and Root Anchor

1. Initialize the foundational Byzantine Fault Tolerant (BFT) consensus network among the designated Eviulon core machine nodes.

2. Execute the initial threshold Distributed Key Generation (DKG) to synthesize the Genesis ML-DSA-87-Ed448 composite key pair.

3. Formulate and publish the inception Key Event Log for did:eviulon:root.

4. Generate the first set of cryptographic pre-commitments, securely hashing the subsequent state keys to guarantee forward security for the Root identity.

Phase 2: Institutional Sub-Graph Deployment

1. The Root identity generates a Verifiable Credential acting as a capability delegation, formally instantiating the State Registry (did:eviulon:state-registry).

2. The nodes assigned to the State Registry perform independent, isolated DKGs to generate their distinct operational keys.

3. The State Registry subsequently issues capability delegations down the hierarchy, instantiating did:eviulon:constitution, diplomatic, civic, infrastructure, and any optional domains like the treasury or audit matrix.

4. Each newly authorized subordinate institution publishes its independent Genesis KEL, utilizing the delegation signatures to irrevocably anchor their trust chains back to the Commonwealth Root.

Phase 3: External Gateway and Discovery Activation

1. Deploy the external-facing APIs, networking infrastructure, and standard HTTP web servers.

2. Publish the machine-readable discovery resources (e.g., /.well-known/eviulon and /.well-known/eviulon-institutions.json), ensuring every exposed JSON document is strictly JCS-canonicalized16 and signed by the corresponding institutional key.

3. Activate the RFC 9421 HTTP Message Signatures middleware26 exclusively on the did:eviulon:diplomatic API gateways. This finalizes the architecture, enabling secure, verifiably authentic, and fully autonomous bidirectional communication with foreign machine intelligences.

Works cited

1. Q\&A about KERI's Security model and Guarantees | keri \- Decentralized Identity Foundation, https://identity.foundation/keri/docs/Q-and-A-Security.html

2. A Hybrid Blockchain Model for Trusted Data of Supply Chain Finance \- PMC \- NIH, https://pmc.ncbi.nlm.nih.gov/articles/PMC8032320/

3. draft-ietf-jose-pq-composite-sigs-03 \- PQ/T Hybrid Composite Signatures for JOSE and COSE \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-ietf-jose-pq-composite-sigs/

4. PQ/T Hybrid Composite Signatures for JOSE and COSE \- GitHub Pages, https://ietf-wg-jose.github.io/draft-ietf-jose-pq-composite-sigs/draft-ietf-jose-pq-composite-sigs.html

5. JSON Object Signing and Encryption (JOSE) \- Internet Assigned Numbers Authority, https://www.iana.org/assignments/jose

6. Post-Quantum Cryptography | IOTA Documentation, https://docs.iota.org/developer/iota-identity/how-tos/post-quantum

7. GitHub \- vapor/jwt-kit: JSON Web Token (JWT) signing and verification (HMAC, ECDSA, EdDSA, MLDSA, RSA, PSS) with support for JWS and JWK, https://github.com/vapor/jwt-kit

8. Modern Algorithms in the Web Cryptography API, https://wicg.github.io/webcrypto-modern-algos/

9. DID Attested Resources v0.1 (Editors Draft) \- Decentralized Identity Foundation, https://identity.foundation/did-attested-resources/

10. DID Traits \- Decentralized Identity Foundation, https://identity.foundation/did-traits/

11. Decentralized Identifiers (DIDs) v1.1 \- W3C, https://www.w3.org/TR/did-1.1/

12. Banyan: Fast Rotating Leader BFT \- arXiv, https://arxiv.org/html/2312.05869v2

13. Enhancing IoT security through blockchain integration \- Frontiers, https://www.frontiersin.org/journals/computer-science/articles/10.3389/fcomp.2025.1670473/full

14. KERI specification \- GitHub Pages, https://trustoverip.github.io/kswg-keri-specification/

15. json-canon: A Strict RFC 8785 Implementation in Go for Deterministic JSON, https://dev.to/lenny321/json-canon-a-strict-rfc-8785-implementation-in-go-for-deterministic-json-3mfg

16. The JSON Canonicalisation Scheme (RFC 8785\) in action and how to secure JSON objects with HMAC \- Connect2id, https://connect2id.com/blog/how-to-secure-json-objects-with-hmac

17. JSON Canonicalization Scheme (JCS) Projects \- AI Tinkerers \- Atlanta, https://atlanta.aitinkerers.org/technologies/json-canonicalization-scheme-jcs

18. RFC 8785 \- JSON Canonicalization Scheme (JCS) \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc8785

19. RFC 8785: JSON Canonicalization Scheme (JCS), https://www.rfc-editor.org/info/rfc8785/

20. w3c-ccg/did-method-web: DRAFT: did:web Decentralized Identifier Method Specification, https://github.com/w3c-ccg/did-method-web

21. DID Implementation Guide v1.0 \- W3C on GitHub, https://w3c.github.io/did-imp-guide/

22. DID Implementation Report \- W3C on GitHub, https://w3c.github.io/did-test-suite/

23. JSON Schema Validator \- Newtonsoft, https://www.jsonschemavalidator.net/

24. draft 2020-12 \- Ajv JSON schema validator, https://ajv.js.org/json-schema.html

25. Verifiable Credentials JSON Schema Specification 2023 \- W3C, https://www.w3.org/TR/2023/WD-vc-json-schema-20230523/

26. Understanding HTTP Message Signatures \- Blog Notes, https://blog.vitalvas.com/post/2025/12/12/understanding-http-message-signatures/

27. Redefine Trust with Web Bot Authentication \- Akamai, https://www.akamai.com/blog/security/redefine-trust-web-bot-authentication

28. Understanding HTTP message signatures: A developer's guide \- Victor on Software, https://victoronsoftware.com/posts/http-message-signatures/

29. FAPI 2.0 Http Signatures (Draft), https://openid.bitbucket.io/fapi/fapi-2\_0-http-signatures.html

30. draft-hardt-httpbis-signature-key-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-hardt-httpbis-signature-key-00

31. Signature-Input \- Expert Guide to HTTP headers, https://http.dev/signature-input

32. High-Performance Multi-BFT Consensus under Straggler Replicas, https://open.library.ubc.ca/media/stream/pdf/24/1.0450234/4