1. Introduction

The IronVelo Identity Provider (IdP) is built on a foundation of protocol simplicity and mathematical rigor. By leveraging formally verified core libraries, the IronVelo IdP mitigates many of the systemic risks inherent in traditional identity systems.

Our architecture follows a Minimal Invariant philosophy: enforcing the maximum number of security guarantees from the smallest possible set of verifiable rules. By reducing protocol complexity while strengthening the underlying invariants, IronVelo provides an identity system designed for high-assurance environments such as defense networks and multi-domain operations.

2. Core Protocol Architecture: The Affine Key Subsystem

At the heart of the IronVelo IdP is a specialized Key Management Subsystem built around One-Time Keys (OTK). These keys follow principles derived from Affine Logic and maintain a strict invariant:

Once a cryptographic key is used for decryption, it is immediately and atomically invalidated.

This invariant ensures that authentication artifacts cannot be reused, replayed, or persist beyond their intended lifetime.

2.1. OTK Operations: Inspect and Decrypt

The OTK subsystem exposes two primary interaction modes.

  • OTK Inspection (Token Introspection): When a token is presented, the system atomically fetches the current key, replaces it with new material, decrypts the token for inspection, and re-encrypts the payload with the new key.
  • Standard Decryption: A fetch-and-delete operation used when credentials are consumed for their final action.

2.1.1. Inherent Replay Protection

Because OTK invalidation is built directly into the atomic operations, Replay Attacks become cryptographically infeasible.

If an attacker intercepts and attempts to replay a token, the key material will already have been rotated or deleted by the legitimate user. In either case, the token becomes unusable, the session is invalidated, and the IdP logs the event for immediate analysis.

3. Atomic Authentication Flows

All authentication processes—from initial password submission to MFA challenges and final token issuance—are backed by chained OTK transitions.

This provides two critical properties:

  • No Intermediate Replays: An attacker cannot inject themselves into an ongoing authentication flow.
  • Atomic Transitions: If any step fails or is replayed, the entire chain is invalidated and the authentication process must restart from a clean state.

This model ensures that authentication state cannot be partially captured or reused by adversarial actors.

4. Scalable Revocation and Session Management

IronVelo eliminates the operational burden of large Token Revocation Lists by using a Tiered Identifier Model.

  • Singular Revocation: Individual tokens are revoked instantly by deleting their associated OTK.
  • Family Revocation (Global User Reset): Each token contains a "Family Identifier" encrypted via AEAD. Revoking all active sessions for a user is accomplished by incrementing the Family ID in the central vault.
  • Performance at Scale: During introspection the IdP compares the token's Family ID against the current valid version. This comparison is an O(1) operation and avoids scanning large revocation databases.

This design allows immediate containment of compromised credentials even in large distributed deployments.

5. Secure Delegation: Token Splitting

Modern Multi-Domain Operations require controlled delegation of authority to subsystems, services, or autonomous platforms. IronVelo implements this through Token Splitting.

  • Non-Recursive Splitting: A delegated token cannot be split again, preventing privilege amplification.
  • Strict Subset Enforcement: Using Scope-Forge, the system guarantees that delegated permissions are a strict subset of the parent token's authority.
  • Inherited Security: Delegated tokens inherit the parent Family ID, ensuring that global revocation cascades automatically to all sub-tokens.

5.1. Standards Compatibility Layer

Although IronVelo is designed as a clean-slate protocol, it includes a Standards Compatibility Layer that can optionally enable OAuth2 and OpenID Connect interoperability.

  • Hardened OAuth2 Flow: Session metadata is embedded into the OAuth state parameter and encrypted using an OTK. This guarantees IronVelo as the original issuer and prevents replay of delegation flows.
  • Compromise Resilience: Even if a client ID or secret is compromised, the dynamic OTK-backed state prevents replay or impersonation attacks.

5.2. Limitations of Stateless Token Models (JWT)

In mission-critical environments, the convenience of stateless JSON Web Tokens (JWT) introduces security limitations. While acceptable for many commercial applications, these models struggle to meet the Continuous Authorization requirements defined by the DoW Zero Trust Reference Architecture.

5.3. Revocation Latency

JWTs rely primarily on expiration windows (exp). In many enterprise systems, 15 minutes is considered "short-lived."

  • Operational Risk: In contested environments, a 15-minute window is unacceptable for an attacker operating with stolen credentials.
  • IronVelo Approach: OTK-backed tokens effectively reduce credential lifespan to a single transaction.

5.4. Replay as a Structural Weakness

JWTs are self-contained and therefore replayable until expiration.

  • Operational Risk: Preventing replay requires global JTI tracking or blacklist propagation, which is difficult in fragmented tactical networks.
  • IronVelo Approach: Replay protection is guaranteed by the OTK invariant. Once a token is decrypted, its key is destroyed.

5.5. Indirect Revocation

Revoking all tokens for a compromised user typically requires refresh cycles or large revocation lists.

  • Operational Risk: Propagation delays allow continued lateral movement during a compromise.
  • IronVelo Approach: The Tiered Identifier Model enables immediate global revocation through a single Family ID increment.

5.6. Comparison: Tactical Reality

Metric Standard JWT (Industry) IronVelo OTK (High-Assurance)
Authorization Model Time-based (Temporal) Transaction-based (Affine)
Replay Mitigation Manual (JTI/Blacklists) Cryptographic Rotation
Revocation Complexity O(n) Search O(1) Identifier Check
Security Window Minutes to Hours Single-use (Milliseconds)
Verification Signature Only Protocol Invariant Proof

IronVelo’s architecture aligns with the "Assume Breach" philosophy of modern Zero Trust security. Identity artifacts cannot persist, be reused, or remain valid beyond a single verified transaction.

6. Conclusion: Identity Assurance for Mission-Critical Systems

The IronVelo Identity Provider establishes a high-assurance identity layer for operational environments where trust must be continuously validated and compromise must be rapidly contained.

Through affine one-time key semantics, atomic authentication flows, and constant-time revocation, IronVelo ensures identity artifacts cannot be replayed, reused, or persist beyond their intended lifetime.

When deployed alongside Scope-Forge, IronVelo becomes part of a unified, formally verified access-control plane. The IdP guarantees identity integrity while Scope-Forge guarantees that every authorization decision derived from those identities is mathematically sound.

Together they deliver three critical properties:

  • Identity Integrity: Authentication artifacts are bound to single-use cryptographic keys.
  • Provable Authorization: Access policies are formally verified at compile time.
  • Operational Containment: Compromised identities can be revoked instantly without global state synchronization.

The result is an identity and policy infrastructure suitable for the most demanding defense environments, from enterprise mission networks to resource-constrained tactical systems, where the correctness of access control is not a matter of configuration, but a matter of proof.