# Keystone Identity Architecture

"Keystones" combine the concept of a cryptographic key with the ibgib concept of a "stone" (immutable data) to create an audit-trail-based identity system.

## 1. Principles

*   **Auditability as Validation**: Validation is not checking a certificate authority; it is replaying the history of the Keystone timeline to verify the cryptographic proofs from Genesis to present.
*   **Propagation as Witnessing**: When a Space accepts a Keystone frame, it "witnesses" it, effectively voting on its validity.
*   **Hash-Based (Post-Quantum)**: Security relies on hash pre-imaging difficulty (`hash-reveal-v1`) rather than RSA/ECC, leveraging the intrinsic properties of the ibgib DAG.

## 2. Core Concepts

*   **Keystone**: An identity timeline. A graph of ibgib frames evolving over time.
*   **Challenge Pool**: A collection of puzzles stored in each Keystone Frame.
*   **Constraint/Policy Engine**: Logic that determines *which* challenges must be solved to authorize a specific action (Binding, FIFO, Stochastic).

## 3. Policy Engine (Selection & Mitigation)

To prevent replay attacks by Man-in-the-Middle (MITM) actors, the challenges required to sign a frame are selected via a multi-layered pipeline:

1.  **Mandatory Demands**: The verifier explicitly requests specific challenge IDs.
2.  **Target Binding**: Challenges are mapped to buckets (e.g., hex characters). Signing a target `a1c04...` requires solving challenges in the `a`, `1`, `c` buckets. This creates **Content-Dependent Binding**.
3.  **FIFO**: Consumes $N$ challenges from the "front" of the pool (Performance).
4.  **Stochastic**: Randomly selects $N$ additional challenges (Anti-Grinding).

## 4. Cryptographic Strategy (`hash-reveal-v1`)

A variation of a Sigma protocol using Hash-Based Cryptography.

*   **Commit**: Alice publishes $H = Hash(S)$ in Frame $N$.
*   **Reveal**: To authorize Frame $N+1$, Alice reveals $S$.
*   **Derived Secrets**:
    *   `MasterSecret` + `PoolSalt` -> `PoolSecret`
    *   `PoolSecret` + `ChallengeID` -> `Solution`
    *   `Solution` -> `Challenge`

## 5. Lifecycle

### 5.1 Genesis
Inputs: `MasterSecret`, `PoolConfig`.
Generates initial challenges and the Genesis Frame. Persists to local Space.

### 5.2 Sign (Evolution)
Inputs: `LatestKeystone`, `Claim`, `MasterSecret`.
1.  **Auto-Routing**: Selects pool based on Verb (e.g., 'revoke').
2.  **Selection**: Runs Policy Engine.
3.  **Solving**: Generates solutions.
4.  **Replenishment**: Adds new challenges (Top-Up) or burns them.

### 5.3 Validate
Inputs: `PreviousFrame`, `CurrentFrame`.
Re-runs the Policy Engine to ensure the correct challenges were solved and verifies the hash pre-images.

### 5.4 Revoke
Consumes **ALL** challenges in the revocation pool ("Scorched Earth"). The identity can no longer evolve.
