DEFONEOS · Sovereign Identity Attestation Specification

1. Overview

The Sovereign Identity Attestation subsystem establishes who-or-what is acting in the DEFONEOS estate. Every action — a tool invocation, a BFT vote, a SIGIL emission, a secret access — carries a signed attestation from a cryptographically identified principal.

There are three principal types:

Human — a real person, identified by a long-lived Ed25519 identity key generated in a MacBook Secure Enclave, with biometric verification.
Agent — a sovereign AI runtime (SOV3 small/large, MCP server), identified by a per-process Ed25519 key, attested at startup.
MCP — a Model Context Protocol server, identified by a manifest-bound Ed25519 key, with periodic re-attestation.

Sovereignty invariant: Identity lives in DEFONEOS hardware, not in Auth0/Okta/Firebase/Clerk/WorkOS. There is no external identity provider to subpoena, no US jurisdiction to comply with, no CLOUD Act exposure. Identity IS the sovereign attestation.

2. Identity Primitives

2.1 Ed25519 Keys

Every principal holds an Ed25519 keypair. The public key is the principal's identity. The private key never leaves the principal's hardware boundary.

Principal	Private Key Custody	Public Key Format	Hardware Binding
Human (Nick)	MacBook Secure Enclave	`ed25519:5x...k2`	Biometric (Touch ID)
Agent (SOV3)	Process memory + MLX runtime	`ed25519:9a...p7`	Secure Enclave (Apple) / TPM (Linux)
MCP Server	Process memory + admission manifest	`ed25519:3h...m4`	TPM where available, sealed keyfile otherwise

2.2 Identity Record

An identity record is a JSON object containing the public key, principal type, ring assignment, registration timestamp, and the BFT witness quorum signature.

{ "id": "ed25519:5xKb...k2", "type": "human", "ring": "Ring0", "registered_at": "2026-06-15T10:00:00Z", "biometric_verified": true, "hardware_binding": "secure_enclave", "witnesses": [ {"agent": "ed25519:9aXk...p7", "sig": "7f3a...c2"}, {"agent": "ed25519:8hLp...r5", "sig": "4b1d...e8"}, {"agent": "ed25519:6mNq...t9", "sig": "2a9c...b1"} ], "sigil_receipt": "sigil:attest:abc123def456" }

3. Attestation Lifecycle

3.1 5-State Lifecycle

Every attestation moves through 5 states. No attestation can act before reaching ACTIVE.

State	Meaning	Can Act?	Witness Required
PROVISIONED	Key generated, not yet attested	❌	—
PENDING_WITNESS	Awaiting 3 BFT witness signatures	❌	3/3 standard, 5/5 high-trust
ACTIVE	Fully attested, can act in estate	✅	3/3 witnessed
SUSPENDED	Temporarily blocked (e.g., red-line violation)	❌	3/3 to reinstate
REVOKED	Permanently disabled, key on deny-list	❌	5/5 to re-register

3.2 BFT Witness Quorum

Every new attestation requires a witness quorum from the 33-agent BFT defense council. The witness count varies by principal sensitivity:

Principal	Witness Count	Quorum	Use Case
Human owner	3 of 33 agents	Simple majority (2/3 of witnesses)	Single owner seat, high trust
Agent (SOV3 runtime)	3 of 33 agents	2/3 of witnesses	Substrate nodes
MCP server (Ring0)	5 of 33 agents	3/5 of witnesses	Sovereign-critical MCPs
MCP server (Ring1)	3 of 33 agents	2/3 of witnesses	Defence MCPs
MCP server (Ring2)	3 of 33 agents	2/3 of witnesses	Civil MCPs

4. Attestation Format

4.1 Canonical Attestation Object

An attestation is a signed JSON document binding a principal to a specific action and time window.

{ "attestation_id": "att:2026-07-15T05:30:00Z:abc123", "principal": "ed25519:5xKb...k2", "principal_type": "human", "ring": "Ring0", "action": "tool.invoke:sovereign-data-escrow-protocol:release", "timestamp": "2026-07-15T05:30:00Z", "expires_at": "2026-07-15T05:35:00Z", "context_hash": "sha256:9f8e7d6c5b4a...", "ring_constraints": ["Ring0_only"], "red_line_check": "passed", "signature": "ed25519:5xKb...k2:7f3a4b1d2a9c...", "witnesses": [ {"agent": "ed25519:9aXk...p7", "sig": "...", "voted_at": "..."}, {"agent": "ed25519:8hLp...r5", "sig": "...", "voted_at": "..."}, {"agent": "ed25519:6mNq...t9", "sig": "...", "voted_at": "..."} ], "sigil_receipt": "sigil:att:abc123def456" }

4.2 Time-Bound Validity

Every attestation has a 5-minute validity window by default. Critical actions (BFT votes, secret access, escrow release) use 60-second windows. Routine tool invocations use 5-minute windows. Attestations cannot be replayed outside their validity window.

5. Verification API

5.1 Endpoints

Endpoint	Method	Purpose	Auth
`/attest/verify`	POST	Verify a single attestation	Ring0 only
`/attest/verify-batch`	POST	Verify up to 1000 attestations	Ring0 only
`/attest/revoke`	POST	Revoke an attestation (emergency)	Ring0 + 5/5 witness
`/attest/identity/{pubkey}`	GET	Fetch identity record	Ring0/1/2 (varies by ring)
`/attest/list`	GET	List attestations in time window	Ring0 only

5.2 Verification Algorithm

def verify_attestation(attestation): # 1. Check signature if not ed25519_verify(attestation.signature, attestation.principal): return {"valid": False, "reason": "bad_signature"} # 2. Check time window now = current_time() if now < attestation.timestamp or now > attestation.expires_at: return {"valid": False, "reason": "expired"} # 3. Check witness quorum valid_witnesses = 0 for w in attestation.witnesses: if ed25519_verify(w.sig, w.agent): valid_witnesses += 1 if valid_witnesses < required_quorum(attestation.principal_type, attestation.ring): return {"valid": False, "reason": "insufficient_witnesses"} # 4. Check ring constraints if not check_ring_constraints(attestation): return {"valid": False, "reason": "ring_violation"} # 5. Check red-line compliance if not check_red_lines(attestation): return {"valid": False, "reason": "red_line_violation"} # 6. Check identity record state identity = fetch_identity(attestation.principal) if identity.state != "ACTIVE": return {"valid": False, "reason": "identity_not_active"} return {"valid": True, "verified_at": now, "sigil": "sigil:verify:..."}

6. Revocation and Emergency

6.1 Standard Revocation

An attestation is implicitly revoked when its expires_at passes. Principals can also explicitly revoke an attestation via /attest/revoke with a 3-of-3 witness quorum.

6.2 Emergency Revocation

On red-line violation or compromise detection, the SIGIL ledger emits a red_line_alert event. All attestations from the affected principal are immediately suspended, the principal's identity record transitions to SUSPENDED, and a 5-minute emergency BFT session is triggered.

6.3 Hardware-Bound Rotation

If a private key is suspected compromised, the principal generates a new keypair, registers the new identity record with full witness quorum, and old attestations are revoked. Old keys are added to the deny-list and cannot be re-registered without a 5-of-5 BFT supermajority vote.

7. Compliance Cross-Walk

Standard	Section	How Attestation Meets It
UK GDPR	Article 32	Cryptographic access control + audit trail via SIGIL
DPA 2018	Schedule 1 Part 4	Non-US identity, no US jurisdiction exposure
NCSC CAF	B2 (Identity)	Cryptographic identity for all principals
ISO 27001	A.9 (Access Control)	Signed attestations, ring-based access, time-bound
JSP 440	Chapter 7	UK-only identity custody, BFT witness quorum
EU AI Act	Article 15 (Accuracy)	Verifiable identity prevents impersonation
NIST SP 800-63B	IAL3 / AAL3	Hardware-bound cryptographic authenticator
Zero US CLOUD Act	—	No US-hosted IdP, all keys UK-resident

8. Production Metrics

Metric	Value
Identities registered	37 (1 human + 6 agents + 30 MCPs)
Active attestations (24h)	8,427
Witness quorum success rate	100% (0 failed)
Verification latency (p99)	12ms
SIGIL receipts (attestation events)	3,891
External IdP calls	0
Revocations (last 30d)	2 (both standard, 0 emergency)
Red-line violations blocked	1 (correctly suspended)