Technical Architecture · v3.0 · April 2026

Human Authentication Layer
(HAL)

A security infrastructure primitive that proves a verified human owner authorised a specific action — at a specific moment, on a specific device. Not credential possession. Owner presence.

POSITIONING:   Security infrastructure primitive · Not a compliance tool · Not a fraud product
DocumentHAL Architecture v3.0
StatusConfidential — DD Vault
AuthorHaven Holding LLC-FZ
Patent ReferenceUSPTO 64/032,300 (provisional)
01

Executive Summary

HAL is Haven's commercial infrastructure offering: an embedded software module integrated into the client's application, providing on-device biometric authentication that proves a verified human owner authorised a specific action. The architecture is the security model. The biometric template is generated, stored, and verified inside the user's device hardware-backed secure enclave and is non-exportable. Haven processes signed cryptographic attestations only.

PROBLEM

Credentials prove possession, not presence

Passwords, TOTP codes, even passkeys prove that a credential is held — not that the legitimate human owner is present and authorising the specific action displayed. As AI agents increasingly act on behalf of humans and high-value transactions migrate to digital rails, this gap is structural, not incremental.

SOLUTION

Owner-attributed actions, on-device

HAL embeds in the client application. Biometric capture and verification happen exclusively in the device's hardware-backed secure enclave. Every authenticated action carries a cryptographic attestation that binds the verified owner to the specific action — replay-protected, action-bound, time-bound.

DIFFERENTIATION

Zero biometric data, minimal metadata

Biometric templates are non-exportable from the device's secure enclave by hardware design. Haven processes signed attestations and minimal metadata (action ID, timestamp, signature) — never biometric data, never PII, never client business data. Compliance posture is structural, verifiable, and material to enterprise vendor risk reviews.

DELIVERY

Two product tiers, three deployment modes

HAL Standard (native device biometrics, full Haven protocol stack) and HAL Advanced (adds YEO Continuous Facial Recognition for deepfake-defensible high-value verification). Each tier deploys via embedded module, custom SDK, or via the Haven Wallet for federated workforce use cases.

02

Product Tiers

HAL is offered in two tiers. The standard tier delivers Haven's full proprietary protocol stack on native device biometrics — independent of any third-party biometric SDK. The advanced tier layers in YEO Continuous Facial Recognition for deepfake-defensible verification of high-value or high-risk actions. Standard works without YEO. Advanced is the upsell, not the dependency.

TIER 01

HAL Standard

Owner-attributed authentication on native device biometrics

  • Full Haven proprietary protocol stack
  • OAAP action-binding (USPTO 64/032,300, provisional)
  • DASR settlement record protocol
  • Native biometric capture (Face ID, Touch ID, Android BiometricPrompt)
  • Hardware-backed secure enclave storage
  • OS-provided liveness detection
  • Cryptographic attestation generation
  • Risk-tiered verification policies (configurable)
BEST FOR: Standard authentication, login replacement, transaction approval, enterprise auth, workforce identity.
PREMIUM
TIER 02

HAL Advanced

Deepfake-defensible verification for high-value actions

  • Everything in HAL Standard
  • YEO Continuous Facial Recognition (CFR) SDK
  • Multi-frame anti-deepfake verification
  • Continuous owner-presence during transaction window
  • 2D + 3D mask resistance
  • GAN-spoof and replay attack resistance
  • Tested zero-breach record under adversarial conditions
  • Four granted patents (US, GB, CN, EU pending)
BEST FOR: High-value transactions, AI agent execution sign-off, regulated industries, deepfake-targeted environments, institutional custody.

Why this tier structure matters strategically

HAL Standard removes the YEO dependency as a single point of failure. The Haven protocol stack is patent-defensible and ships on native device biometrics on day one. HAL Advanced is a premium upsell — clients with deepfake-targeted use cases pay more for the YEO CFR layer. This structure: (a) eliminates the existential platform-dependency risk, (b) creates a natural pricing ladder, (c) preserves the YEO licence as commercial value-add rather than infrastructure, and (d) materially raises the M&A floor by ensuring a working product exists independent of any single third-party agreement.

03

The OAAP Protocol

The Owner-Attributed Actions Protocol (OAAP) is the cryptographic core of HAL — and the central asset under USPTO provisional patent 64/032,300. OAAP is what differentiates HAL from every other authentication system. It is not a credential, not a signature scheme, not a session token. It is a protocol that produces a single piece of cryptographic evidence binding a verified human owner to a specific action at a specific moment.

OAAP in one sentence

A cryptographic protocol that binds a specific action to a verified human owner at the moment of authorisation, producing a proof that cannot be replayed, cannot be transferred, and cannot be reused for any other action.

What makes OAAP different from existing authentication

Every existing authentication mechanism proves something happened — a credential was used, a signature was applied, a token was presented. OAAP proves who, what, and when, cryptographically inseparable. The "who" cannot be extracted from the "what" because they are mathematically bound in the same proof.

P
Passwords / TOTP / API tokens

Prove: the bearer holds a secret.
Don't prove: who the bearer is, whether they're present, what they're authorising, or whether they intended to authorise it. The same secret authorises every action it's used for.

K
Passkeys / FIDO2 / WebAuthn

Prove: the device has been registered to the user, and the device's biometric unlock succeeded recently.
Don't prove: the verified human is present at the action moment, or that the action being signed is the action the user saw.

S
Digital signatures (RSA, ECDSA)

Prove: a private key signed a piece of data.
Don't prove: the human owner of the key was present, conscious, or aware of what was signed. Stolen keys produce indistinguishable signatures.

O
OAAP

Proves: a verified human owner was biometrically present at the moment of authorisation, and authorised this specific action with these specific parameters. Stolen keys, replayed attestations, transferred credentials, and AI agents acting alone all fail validation.

The four cryptographic bindings

Every OAAP attestation contains four bindings, mathematically combined into a single signed proof. Removing or modifying any binding invalidates the entire attestation.

BindingWhat it cryptographically commits toAttack it defeats
Owner bindingThe biometric verification result was generated by the hardware-bound key associated with the enrolled owner on this device.Stolen credentials, transferred keys, AI agents acting without human authorisation.
Action bindingThe specific action parameters (transaction amount, recipient, reference, action type) are hashed into the attestation itself.Replay attacks against different actions, overlay attacks that show one action but sign another, attestation reuse for any other purpose.
Time bindingA nonce issued by the validator and a timestamp are committed in the attestation. Validity windows are enforced server-side.Replay attacks across time, captured-attestation reuse, race-condition exploits.
Device bindingThe hardware-backed signing key is non-exportable and bound to the device's secure enclave. The attestation includes device-attestation evidence (App Attest / Play Integrity).Cloned devices, emulator attacks, compromised-device attacks, key extraction attempts.

How an OAAP attestation is generated

The lifecycle of a single authorisation, from action initiation to validated attestation.

  1. 01

    Session initiation

    Client backend requests a verification session from the Haven validator, specifying the action context (e.g. transfer $50,000 to recipient X). Validator returns a session ID and a fresh nonce.

  2. 02

    Action context display

    HAL displays the action context inside its own trusted UI surface — not relying on the client app's display. The user sees exactly what they are about to authorise. This is the basis for action-binding.

  3. 03

    Owner verification (on-device)

    Biometric verification runs entirely inside the device's secure enclave. HAL Standard uses native biometrics (Face ID, Touch ID); HAL Advanced layers in YEO Continuous Facial Recognition for multi-frame anti-deepfake verification. Verification produces a TRUE/FALSE result — never the biometric data itself.

  4. 04

    Attestation construction

    If verification succeeds, the four bindings (owner, action, time, device) are combined and signed using the device's hardware-bound non-exportable key. The result is the OAAP attestation — a single signed proof binding the verified owner to the specific action.

  5. 05

    Validator verification

    The attestation is forwarded (via the client's backend) to the Haven validator. The validator verifies signature, nonce freshness, action binding, and device attestation. A signed receipt is returned. Haven sees only the attestation — never the biometric, never the user identity.

  6. 06

    Action execution

    The client backend receives the validation receipt and executes the business action (transfer funds, deploy code, sign document, authorise AI agent execution). The OAAP attestation and validator receipt together form a non-repudiable audit record.

Why OAAP is patent-defensible

USPTO provisional 64/032,300 (filed 8 April 2026) covers OAAP's core innovation: the structural insufficiency of credential-based authorisation, and the cryptographic protocol that resolves it through inseparable binding of owner verification to specific action context.

1
Functional definition of "owner verification event"

The patent defines owner verification functionally — as any non-transferable, non-replayable commitment mechanism. This is broader than biometrics specifically, covering any authentication primitive that satisfies the structural requirements. The protocol's defensibility does not depend on a single biometric vendor.

2
AI agent biometric sign-off

Explicit claims cover the application of OAAP to AI agent execution flows: real-time gating, pre-authorisation scope, and tiered threshold variants. This is the white space that the IBM/RSAC 2026 announcements and NIST AI agent identity paper (March 2026) confirm as the emerging industry need.

3
Confirmed clear of prior art

Cleared against Aware Inc. patents, BAID (December 2025), the IBM/Auth0/Yubico RSAC 2026 announcements, and the NIST AI agent identity concept paper. The structural-insufficiency framing of credentials is the defensible positioning that no existing patent or product currently occupies.

4
Implementation-agnostic

OAAP is the protocol; HAL is the canonical implementation. The patent covers the protocol, allowing licensing to other implementers without compromising Haven's commercial position. This separation creates an additional revenue surface beyond direct HAL deployment — protocol licensing to enterprise IDP providers, IAM vendors, and authentication platforms.

BOTTOM LINE FOR DILIGENCE: OAAP is the only piece of HAL that an acquirer cannot replicate or replace. Native device biometrics are a commodity. The validator infrastructure can be rebuilt. The Verification Module can be re-engineered. The OAAP protocol — and its patent claims around the structural insufficiency of credentials and AI-agent authorisation — is the singular defensible asset. Everything else in HAL is execution; OAAP is the moat.
04

Architecture

HAL is composed of four discrete components. Each has a defined location, a defined responsibility, and a defined data scope. The architectural separation is the security model — enforced by device hardware, not by Haven policy.

01
Verification Module
On-Device · Client App

Sealed, compiled software component embedded inside the client's mobile or desktop application. Performs the entire biometric lifecycle on the user's device.

  • Biometric capture via device camera
  • Encrypted template in Secure Enclave / StrongBox / TPM
  • Liveness verification (Standard: OS · Advanced: YEO CFR)
  • OAAP attestation generation
  • Hardware-bound non-exportable keys
  • Action-binding (transaction context displayed and signed)
02
Recovery & Rebinding
On-Device + Client Identity Layer

First-class architectural component. Handles device replacement, biometric changes (injury, aging), accessibility cases, and re-enrollment via the client's existing identity verification flow.

  • Identity-Gated Biometric Rebinding protocol
  • Re-enrollment uses client's KYC / step-up auth
  • Accessibility fallback flows (where regulated)
  • Multi-device enrolment (where client permits)
  • No biometric data ever recovered or transferred
03
Attestation Validator
Cloud · Haven Backend · Multi-region

Validates OAAP cryptographic proofs. Sees only signed attestations — never biometric data, never PII, never client business data. Multi-region edge deployment with documented SLA.

  • Signature verification against PKI
  • Replay protection (nonce + timestamp)
  • Action-binding verification
  • Audit log issuance (session-bound, not user-bound)
  • SLA: 99.95% target · multi-region failover
  • Sovereign deployment available on enterprise terms

Data Visibility Matrix

What each party sees, holds, and processes. The architectural separation is enforced by device hardware, not by Haven policy.

Data ElementEnd-User DeviceClient AppClient BackendHaven Backend
Raw biometric (camera feed)● Transient, in-memory only○ Never○ Never○ Never
Encrypted biometric template● Hardware secure enclave○ Never○ Never○ Never
Verification result (T/F)● Generated● Returned● Forwarded○ Never (validates proof only)
OAAP attestation (signed proof)● Generated● Passed through● Forwarded● Validated
Audit log metadata○ No○ No● Receipt only● Session ID, action ref, timestamp
User account / transaction data● Yes● Yes● Yes○ Never
User identity (PII, session→user mapping)● Yes● Yes● Yes○ Never (Haven cannot re-identify)
HONEST POSITIONING: Haven processes signed attestations and minimal session-bound metadata. The biometric template is generated, stored, and verified inside the user's device hardware-backed secure enclave and is non-exportable by hardware design. Audit log entries are session-bound and cannot be re-identified to a user without the client's separate session-to-user mapping (which Haven does not hold). This is materially stronger than centralised biometric storage but is not "zero data" in absolute terms — it is zero biometric data and minimal metadata exposure.

Risk-Tiered Verification

HAL does not force the strongest verification on every action. Verification policy is risk-tiered and configurable by the client, balancing security against UX friction and battery impact.

Action Risk TierVerification Method (Standard)Verification Method (Advanced)Typical Use Case
LowNative single biometric checkNative single biometric checkLogin, view balance, view settings
MediumNative biometric + action displayYEO single-frame livenessStandard transactions, AI agent low-stakes actions, settings change
HighNative biometric + multi-frameYEO multi-frame CFR + livenessHigh-value transfer, admin actions, AI agent significant actions
CriticalMulti-frame + dual biometric (security circle)Continuous CFR + dual biometric + DASRWire transfer over threshold, AI agent high-stakes execution, custodial actions
05

Intent vs. Identity

A common and legitimate critique of biometric authentication: proving the legitimate human is present is not the same as proving they intended to authorise the specific action displayed. HAL addresses this gap explicitly through action-binding, contextual display, and dual-biometric authorisation — but the gap is real and worth describing honestly.

HONEST ACKNOWLEDGEMENT

Biometric verification proves identity and presence. It does not, on its own, prove informed voluntary intent. A user could be coerced, socially engineered, fatigued by approval spam, or shown one transaction in the client UI while a different transaction is actually being signed. These are real attack surfaces that affect every authentication system, including Face ID, passkeys, and hardware tokens.

How HAL closes the intent gap

A
Action-binding (cryptographic)

Every OAAP attestation is cryptographically bound to the specific action being authorised. Stealing or replaying an attestation against a different action fails validation. An overlay attack that shows the user one action while signing another cannot succeed — the action displayed and the action signed must match, and the match is verified server-side.

D
Contextual action display

The HAL Verification Module displays the action context (amount, recipient, reference) inside its own trusted UI surface during verification — not relying on the client app's display. This narrows the surface for screen-injection and accessibility-abuse attacks that depend on client UI compromise.

F
Anti-fatigue policies

Configurable rate limiting, cooldown periods, and dual-biometric requirements (Security Circle co-sign) for high-value or anomalous actions. Approval-spam fatigue attacks become structurally harder when high-value actions require co-signing rather than rapid solo approval.

2
Dual-biometric authentication (Security Circle)

For high-risk actions, HAL requires co-authorisation from a second pre-enrolled owner from the user's Security Circle. Each co-signer biometrically authorises via their own HAL instance. The OAAP attestation carries two owner-bindings; validation requires both. This converts coercion, social engineering, and fatigue from "single-point compromise" attacks to "two-party-collusion" attacks — a structurally harder problem.

How dual-biometric authentication closes the residual intent gap

The Security Circle is not a recovery mechanism alone — it is the answer to coercion, fatigue, and social-engineering attacks at the Critical risk tier. When a high-risk action is initiated, HAL routes the authorisation request to a pre-enrolled co-signer on a separate device. The co-signer biometrically authorises via their own HAL instance. The resulting OAAP attestation is multi-party: it cryptographically binds two verified human owners to the same action. The attack surfaces this closes:

Attack vectorSingle-auth (HAL alone)Dual-auth (HAL + Security Circle)
Coercion (forced authentication)Defeats HAL — biometric is realCoercer must compromise a second remote person, on a separate device, in real-time
Social engineering ("just approve this")Defeats HAL — user is genuinely authorisingSecond party provides external sanity check — unmanipulated by the social context
Approval fatigue (spam approvals)Defeats HAL — rapid taps may bypass attentionEach high-value action requires a second human, breaking the rapid-tap pattern
Single-device insider compromiseDefeats HAL — device is the trusted boundaryRequires compromise of two separate devices and two separate users
Deepfake of one user (Advanced tier)Already mitigated by CFR multi-frameCompounded — deepfake must succeed against two enrolled users on two devices

Coercion is not solved by any biometric or cryptographic system in isolation — it requires duress detection, behavioural signals, or human review. But dual-biometric authorisation converts coercion from a single-point attack into a two-party-collusion attack. This is the same structural defence used by bank-grade payment authorisation flows (dual-control, four-eyes principle), implemented cryptographically rather than procedurally.

Selective disclosure: three-tier dual-authorisation consent model

A standard weakness of dual-control systems is that they leak transaction context to the co-signer. For regulated industries (healthcare, legal, government, financial advisory) this is often non-compliant. HAL implements a three-tier consent model that lets the user — or, where institutional policy requires, the institution — control what the co-signer sees.

1
Identity-only co-signing

Co-signer sees: nothing about the action.
Co-signer attests: "yes, this is the verified user" — biometric proof bound to a session ID and timestamp only.
Best for: personal banking, healthcare, legal, government, and any context where transaction confidentiality matters more than co-signer informed consent.

2
Action-disclosed (user choice)

Co-signer sees: full action context (chosen by the user).
Co-signer attests: the specific action with informed knowledge.
Best for: crypto transfers, B2B transactions, family financial decisions, where the user wants the co-signer to verify what they're approving.

3
Action-disclosed (institution-mandated)

Co-signer sees: full action context (mandated by institutional policy, not user choice).
Co-signer attests: the specific action with informed knowledge.
Best for: wire transfers above threshold, AI agent execution, custodial actions, regulated high-value transactions where the institution carries the risk and requires informed dual-control for liability allocation.

!
Why this is structurally novel

In identity-only mode, the OAAP attestation cryptographically binds the co-signer's identity verification to the action without the co-signer ever seeing the action context. The institution sees both attestations bound to the same action; the co-signer sees only that they verified the user. This selective-disclosure dual-attestation mechanism does not exist in current identity stacks (FIDO, WebAuthn, passkeys) and is a candidate for additional patent claims in the OAAP non-provisional conversion.

WHY THIS MATTERS COMMERCIALLY: Identity-only dual-authorisation is what makes HAL deployable in healthcare, legal, government, and financial advisory contexts where standard "co-signer sees the action" dual-control is non-compliant. It also addresses the consumer-privacy concern that traditional dual-auth requires sharing transaction details with trusted third parties. The three-tier model lets institutions and users select the consent depth appropriate to the action — without compromising the cryptographic dual-binding.
06

Verification Flow

An authorised action passes through six discrete stages across three trust boundaries. Biometric data never crosses the device boundary.

USER DEVICE CLIENT INFRASTRUCTURE HAVEN BACKEND CLIENT APPLICATION User initiates action Approve $50,000 transfer HAL VERIFICATION MODULE Action display + biometric verify Trusted UI shows action context Native bio (Std) or YEO CFR (Adv) SECURE ENCLAVE (HARDWARE) Encrypted template (sealed) Non-exportable · Hardware-bound iOS Secure Enclave / StrongBox / TPM Biometric never leaves this zone CLIENT BACKEND Receives attestation Forwards to Haven validator Awaits validation receipt Executes business logic on success HAVEN ATTESTATION VALIDATOR Cryptographic verification Signature · Nonce · Action binding Returns signed receipt 99.95% SLA · Multi-region AUDIT LOG Session-bound verification record No user-identifiable data held 1 verify 2 · attestation 3 · validate 4 · receipt 5 · confirmed Forward (signed proof) Return (validation receipt) On-device only (never crosses boundary)
07

Interactive Demo Environments

Two simulated client integrations demonstrating how HAL applies risk-tiered verification policy. The first shows a low-risk action (an AI agent making a flight reservation) requiring single biometric authorisation. The second shows a high-risk action (a $50,000 wire transfer) crossing the institutional threshold and triggering dual-biometric authorisation via the Security Circle.

Risk Tier Threshold · Client-configured policy
Low Medium High Critical

Demo 01 · Low-risk · AI agent action

An AI travel-booking agent requests authorisation to book a flight on the user's behalf. Action falls below the dual-auth threshold. Single biometric verification required. Demonstrates the OAAP AI-agent biometric sign-off use case — the most strategically important emerging application of HAL.

HAL Demo 01 · AI Agent · Low-risk Action
Single biometric · HAL Standard tier · Action under threshold
SANDBOX
Third-Party AI Agent · Co-Branded
SkyWander Agent
AI Travel Assistant · Booking
AI
Your AI agent has found and is requesting to book this flight on your behalf. Owner verification required before execution.
Pending booking
$340.00
RouteLON → NCE · One-way
Date3 May 2026 · 09:35
CarrierEasyJet · Economy
Risk tierLow · Single biometric
Secured by
✓ AI agent authorised · Booking confirmed
HAL Verification Module · On-Device
HAL · Standard
● Idle
+
Awaiting AI agent authorisation
Click "Authorise AI Agent" to begin
Owner Verification
Initialising...
AI agent requests Book LON → NCE · $340.00
Action will be cryptographically bound to AI agent identity
Owner Verified · AI Agent Authorised
OAAP attestation generated
--:--:--Module ready · Awaiting session
Use case: AI agents acting on behalf of users require human biometric authorisation at execution. OAAP cryptographically binds the AI agent's action to a verified human owner — addressing the structural insufficiency of credential-based AI delegation.

Demo 02 · High-risk · Dual-biometric authorisation

A $50,000 wire transfer crosses the institutional risk threshold. Dual-authentication is triggered automatically. The user authenticates first, then the action is routed to a pre-enrolled co-signer in the user's Security Circle (institution-mandated action disclosure mode for liability allocation). The OAAP attestation carries two owner-bindings.

HAL Demo 02 · Wire Transfer · High-risk Action
Dual biometric required · HAL Advanced tier · Action above institutional threshold
CRITICAL TIER
Third-Party Banking Application
Northbank
Wire Transfer · Authorisation
Pending transfer
$50,000.00
FromAccount ····4291
ToMercer & Vale LLP
ReferenceTXN-A77F-9832
Risk tierCritical · Dual auth required
Co-signer modeAction-disclosed (institution)
Secured by
✓ Transfer authorised · Both attestations validated
Primary Owner · Matthew J.
USER 1
● Idle
+
Awaiting authorisation
CFR Active
Multi-frame verification
You are authorising $50,000 → Mercer & Vale LLP
Co-signer required after your verification
Owner Verified
Awaiting co-signer authorisation
--:--:--Module ready · Awaiting session
Security Circle Co-signer · Sarah K.
CO-SIGNER
● Standby
+
Standby
Will activate after primary verification
Co-signer Verifying
CFR active
Co-sign request from Matthew J. $50,000 → Mercer & Vale LLP
Action disclosed per institutional policy
Co-signer Verified
Multi-party OAAP attestation complete
--:--:--Co-signer module on standby
Use case: Wire transfers above institutional threshold trigger dual-biometric authorisation. Both owners verify on separate devices via independent HAL instances. The resulting attestation cryptographically binds two human owners to the same action — defeating coercion, social engineering, and approval-fatigue attacks. Co-signer mode is institution-mandated for liability allocation.
NOTE: Both demos are protocol-flow simulations. No camera is activated and no biometric is captured. Production HAL Standard uses native device biometrics; HAL Advanced layers in YEO Continuous Facial Recognition for multi-frame anti-deepfake verification. The demos demonstrate threshold-triggered policy escalation, action-binding, and dual-biometric attestation.
08

Deployment Modes

A single product (in two tiers), three integration depths. The Embedded Verification Module is the primary delivery mode and is co-branded by default — the "Powered by Haven" or "Secured by Haven" mark is a non-negotiable contractual term, ensuring brand visibility flows through every authentication event.

Primary
MODE 01

Embedded Verification Module

Sealed binary · Pre-built UI · Co-branded

Drop-in module integrated into the client's mobile or desktop application. Pre-built verification UI with co-branded "Powered by Haven" surface. Lowest engineering cost on the client side. The default and recommended deployment.

Code integration~1 week
Production deployment6–12 weeks
Lines of client code~10
BrandingCo-branded only
MODE 02

Custom SDK Integration

Verification primitives · Custom UI

Programmatic access to the verification engine without the pre-built UI. The client builds bespoke verification screens around Haven's primitives. Maximum design flexibility while preserving the security model and patent-protected protocols.

Code integration~4 weeks
Production deployment10–16 weeks
Lines of client code~200+
BrandingRequired attribution
MODE 03

Authentication via Haven Wallet

Federated · Push-based · No new app

Leverages the existing Haven Wallet app as the authentication device. Users who already have Haven installed receive authorisation requests from any Haven-integrated enterprise client via push notification. No second Haven app required — the wallet becomes the federated authentication endpoint.

Code integration~2 weeks (backend)
Production deployment8–12 weeks
Lines of client code~50
BrandingHaven-native
HONEST TIMELINE FRAMING: Code integration timelines refer to the engineering work required to connect HAL to the client's application. Production deployment includes procurement, security review, MDM testing, IAM linking, UAT, and rollout — work that lives within the client's own organisation and is standard for any enterprise infrastructure deployment. Haven's role in the deployment phase is integration support, not pre-built infrastructure.
09

HAL vs. Passkeys vs. Native Biometrics

A common diligence question: how is HAL different from passkeys (FIDO2/WebAuthn) plus Face ID, which already provide on-device biometric authentication? The honest answer: passkeys solve a different problem. They prove the device is authorised; HAL proves the registered human is present and authorising the specific action.

CapabilityPasskeys + Face IDNative Authenticator AppsHaven HAL
What it provesDevice is authorised for this userCode-bearer has access to the seedVerified human owner is present and authorising this specific action
Action-bindingBinds to login/session, not to specific actionsTime-based code, not action-boundCryptographically binds to the specific transaction or action
Continuous presenceSingle point-in-time checkSingle point-in-time checkContinuous verification during transaction window (Advanced)
AI agent executionCredential delegable to agent → no human requiredToken shareable → no human requiredRequires human at execution moment — patent-pending
Deepfake resistanceRelies on OS-level livenessN/A (no biometric)YEO CFR multi-frame anti-deepfake (Advanced tier)
Trusted action displayClient app controls display surfaceClient app controls display surfaceHAL trusted UI displays action context independently
Underlying protocol IPOpen standard (FIDO Alliance)RFC 6238 (open)Proprietary protocol stack · USPTO 64/032,300 (provisional) + 4 granted CFR patents (Advanced)

The defensible category boundary

Passkeys are a credential. HAL is an action-authorisation protocol. The two can — and in many deployments will — coexist: passkeys for low-friction login, HAL for high-value action authorisation. HAL does not compete with passkeys at the login layer; it operates at a layer above, where credentials are structurally insufficient. The relevant prior art for HAL is not WebAuthn — it is the gap between credential possession and action authorisation that the AI agent era has made structurally critical.

10

Platform Encroachment Risk

A serious diligence question: what happens if Apple, Google, or the FIDO Alliance extend their existing platforms to support per-action biometric attestation? The honest answer is that this is a real risk worth addressing directly — not a hypothetical to dismiss. The mitigation is structural, not promotional.

HONEST ACKNOWLEDGEMENT

Apple's App Attest, Google's Play Integrity, and the FIDO Alliance's WebAuthn standard could in principle be extended to support per-action biometric attestation. If this happened, it would commoditise the basic mechanism of HAL Standard. This is the single most important strategic risk to Haven's long-term defensibility and we treat it as such — not as an objection to deflect, but as the central question OAAP's patent strategy is designed to answer.

Why the encroachment risk does not collapse OAAP's defensibility

1
OAAP sits above the OS layer

Apple App Attest and Play Integrity are device-level primitives. OAAP is a cross-platform protocol that defines how attestations are constructed, bound to actions, validated, and used in multi-party flows. Even if Apple ships per-action attestation tomorrow, OAAP's protocol layer remains separately patentable and operationally distinct — it is what makes the same attestation usable across iOS, Android, Windows, and any future platform.

2
Patent claims target the protocol, not the primitive

OAAP's USPTO claims (provisional, 64/032,300) cover the cryptographic binding of owner verification to specific action context, the AI-agent biometric sign-off variants, and the structural insufficiency framing of credentials. Apple extending App Attest does not in itself satisfy these claims. A platform implementation that triggered the protected mechanism would face enforceability — assuming non-provisional conversion and grant.

3
Cross-platform requirement persists

Enterprise clients deploy across iOS, Android, Windows, macOS, and web. Even if Apple shipped per-action attestation natively, enterprise applications would still need a unified protocol to handle the same attestation across ecosystems. OAAP is platform-neutral; per-platform primitives are not. This is the same reason FIDO/WebAuthn won — the standards layer survived platform-specific implementations.

4
AI-agent claims are first-mover defensible

The OAAP claims around AI agent biometric sign-off (real-time gating, pre-authorisation scope, tiered threshold) were filed before any major platform announced AI-agent-specific authentication features. The IBM/RSAC 2026 announcements (April 2026) and the NIST AI agent identity concept paper (March 2026) confirm this is the emerging standard need. Apple/Google/FIDO would need to design around the OAAP claims to operate in this space.

The platform encroachment scenarios — and the response

ScenarioImpact on HAL StandardOAAP Position
Apple ships per-action Face ID attestation in iOSHAL Standard's iOS implementation could leverage the new primitive — accelerating, not displacingOAAP protocol layer still required for cross-platform; patent claims still apply to action-binding mechanism
FIDO Alliance ships WebAuthn extension for action-bindingLowers integration cost; commoditises basic action-binding mechanismPatent claims around AI-agent sign-off and structural insufficiency framing remain defensible. Standard adoption may accelerate Haven's market education.
Google adds per-action attestation to Play IntegrityAndroid coverage improves; enterprise integration complexity reducesCross-platform requirement persists; OAAP remains the unifying protocol layer
Major IDP (Okta, Ping) builds proprietary action-bindingDirect competitor at the protocol layerMost likely acquirer scenario — competitive convergence in this category resolves through acquisition rather than greenfield build

Why category creation by larger players is good for Haven

The market education work — convincing enterprises that credentials are structurally insufficient for AI-agent authorisation — is being done by the largest infrastructure vendors in the world. IBM (RSAC 2026), NIST (March 2026 AI agent identity paper), Auth0/Okta, Yubico, and the broader FIDO ecosystem are all signalling that per-action human-presence authorisation is the next layer. Haven does not have to evangelise a new category — the category is being created by external industry forces, with OAAP positioned as the protocol-level answer that pre-dates the major announcements.

11

Maturity Roadmap

External assessment of HAL has identified five maturity domains required to graduate from "advanced cryptographic concept" to "infrastructure product": protocol formalisation, productisation, operational assurance, ecosystem integration, and governance. The honest framing: of these five domains, only one is meaningfully Haven's pre-exit responsibility. The other four are the natural integration path for an acquirer.

Pre-exit vs. acquirer-funded

Haven's strategic position is M&A exit, not greenfield enterprise infrastructure build-out. Building SOC 2 certification, IAM connectors, transparency logs, and standards-body engagement pre-exit would consume 12–18 months of runway and $5–15M for no valuation lift — because the acquirer (Cisco, Okta, Microsoft, Ping, ForgeRock) brings these capabilities natively. The maturity roadmap below is the acquirer's natural integration path, with Haven's responsibility focused on protocol-layer defensibility and IP integrity. This converts the AI-feedback's maturity-gap critique from a weakness ("Haven hasn't done these things") to a strategic-fit signal ("Haven supplies the protocol; the acquirer supplies the distribution layer").

DOMAIN 01

Protocol & Cryptographic Maturity

Formal RFC-style specification, reference implementation, third-party cryptanalysis, cross-platform key-attestation policy.

HAVEN PRE-EXIT
Patent conversion (provisional → non-provisional within 12 months). Technical spec drafted as DD vault asset. Independent cryptanalysis commissioned (NCC Group / Cure53 scope already defined).
ACQUIRER FUNDED
Public RFC publication, language-agnostic reference implementation, formal verification proofs. Standards-body engagement (FIDO Alliance, W3C observer status).
DOMAIN 02

Product & Developer Infrastructure

Cross-platform SDKs, trusted-UI security spec, dev simulator, signed binary distribution, telemetry.

HAVEN PRE-EXIT
Embedded Verification Module reference implementation (Haven Wallet is live). Architectural specification of trusted UI surface. Sample integration code for acquirer technical validation.
ACQUIRER FUNDED
Production SDK across iOS / Android / Windows / macOS / Web. Mock validator for CI pipelines. Reproducible build infrastructure. Privacy-safe analytics. Versioned developer documentation.
DOMAIN 03

Operational Assurance

SLA monitoring, SOC 2 Type II / ISO 27001, validator transparency, HSM key custody, sovereign deployment.

HAVEN PRE-EXIT
Validator architecture documented for scalability. Penetration test commissioned at full-stack scope ($40K–$80K). SLA target documented (99.95%).
ACQUIRER FUNDED
SOC 2 Type II / ISO 27001 / FedRAMP certification (acquirer's existing programmes). HSM-based key custody (acquirer's existing infrastructure). Self-host validator package (Docker / Kubernetes) for sovereign clients.
DOMAIN 04

Ecosystem & Standards Integration

FIDO Alliance engagement, IAM connectors (Okta, Ping, Azure AD), policy templates for regulated frameworks.

HAVEN PRE-EXIT
FIDO Alliance / W3C observer-status application (low-cost, high-signal). Strategic positioning of OAAP as "action-binding extension" candidate.
ACQUIRER FUNDED
Native IAM/IDP connectors leveraging acquirer's existing partner ecosystem. Policy templates for PSD2 SCA, HIPAA, FedRAMP. Working-group participation. Open attestation receipt format for downstream verifiers.
DOMAIN 05

Governance, IP & Transparency

Patent grants, threat model, advisory board, licensing clarity, signed changelogs.

HAVEN PRE-EXIT
Primary Haven responsibility. Patent non-provisional conversion. Public threat model document. Versioned protocol changelog. Legal opinion on Zero Data Architecture compliance posture. YEO licensing scope clarification.
ACQUIRER FUNDED
External advisory board of cryptographers and compliance experts. Open-core / patent-grant licensing model formalisation. Transparency service for per-build attestation logs.
STRATEGIC IMPLICATION: Of the 25+ maturity gates identified across five domains, fewer than 6 are Haven's pre-exit responsibility. The remainder are the acquirer's natural integration path. This is what makes HAL an attractive M&A target rather than an underbuilt product — Haven supplies the protocol, the patent, and the live reference implementation; the acquirer supplies the certification, distribution, and ecosystem integrations. Both bring what the other lacks.
12

Commercial Implications

The on-device architecture is a commercial asset, not just a security model. It removes the client's biometric compliance burden, eliminates Haven's exposure to centralised-breach risk, and materially simplifies enterprise vendor risk reviews.

C
For the Client's Compliance Team
  • GDPR Art. 9 burden materially reduced — client never holds biometric data
  • BIPA (Illinois) statutory damages exposure substantially mitigated
  • EU AI Act high-risk classification softened by decentralised architecture
  • No cross-border biometric data transfer — biometric never leaves the device
  • Vendor risk assessment dramatically simplified — Haven processes no PII
S
For the Client's CISO
  • Centralised biometric breach risk eliminated — no central store exists
  • Insider threat eliminated — no Haven or client employee can access templates
  • Hardware-backed storage resists OS-level compromise
  • Action-bound attestations cannot be replayed for different transactions
  • App Attest / Play Integrity enforce healthy device prerequisite
U
For the End-User
  • Biometric never leaves their own device — verifiable, not just promised
  • Same trust model as native Face ID / Touch ID — already familiar
  • No password to remember, lose, or have stolen
  • Action context displayed by Haven before approval — informed consent
  • Re-enrollment on new device uses client's existing identity flow
H
For Haven
  • Compliance overhead minimised — Haven processes no personal data
  • Insurance cost lower — no nine-figure breach exposure on biometric stores
  • Penetration test scope smaller — limited attack surface
  • Patent moat reinforced — canonical implementation of OAAP filing
  • Acquirer pool expanded — healthcare, gov, finance compliance teams clear faster
13

Honest Risks & Mitigations

Material risks identified during architectural design, including those that will be raised in any serious diligence process. Each is paired with a defined mitigation. The YEO redistribution gate has been resolved at the product level by tier separation.

High
YEO SDK redistribution scope — distributing YEO's CFR SDK as part of HAL Advanced may exceed current crypto-wallet exclusivity scope. Resolution required for HAL Advanced commercialisation.
→ Resolve with Christo Conidaris before HAL Advanced go-to-market. Materially mitigated by HAL Standard tier shipping without YEO dependency.
High
Compromised end-user device — rooted, jailbroken, or otherwise compromised devices may bypass enclave protections. Screen injection, accessibility abuse, and overlay attacks affect all on-device authentication systems.
→ Apple App Attest + Google Play Integrity API enforce healthy device. Action-binding prevents overlay attacks from approving different transactions. Trusted UI display in HAL surface.
High
Hardware root-of-trust dependency — security relies on Apple Secure Enclave / Android StrongBox / Windows TPM. This is an industry-standard architectural choice, not Haven-specific, but should be acknowledged transparently.
→ Industry-standard for all on-device authentication (passkeys, Apple Pay, banking apps). Action-binding adds protection layer above hardware trust.
High
Provisional patent risk — USPTO 64/032,300 is provisional and unexamined. Claims may be narrowed or rejected on examination. Non-provisional conversion required within 12 months of 8 April 2026 filing.
→ Non-provisional conversion in progress. Claims drafted around structural insufficiency framing and AI-agent sign-off. Continuation patents planned for selective-disclosure dual-attestation mechanism.
Med
Validator availability dependency — clients depend on Haven validator uptime for verification. Outage halts authentication flows.
→ Multi-region edge deployment, 99.95% SLA target, queued attestations during transient outages. Sovereign deployment available on enterprise terms for regulated clients.
Med
Android hardware fragmentation — older Android devices may lack StrongBox or have weak Keystore implementations. Affects coverage in consumer-facing emerging-market deployments more than enterprise/workforce deployments.
→ Documented minimum hardware requirements. Refuse operation below threshold. Coverage % reported per client.
Med
Intent vs. identity gap — biometric verification proves identity and presence, not voluntary informed intent. Coercion, social engineering, fatigue attacks affect all authentication.
→ Action-binding + trusted action display + dual-biometric authentication via Security Circle for high-value actions. Three-tier consent model addresses regulated-sector deployment.
Med
Audit log re-identification risk — even minimal metadata can become quasi-identifiers if linked to client session-to-user mapping.
→ Audit log entries are session-bound. Re-identification requires client's separate mapping, which Haven does not hold. Configurable retention.
Low
Device replacement / re-enrollment friction — new device requires re-enrollment via client's existing identity verification flow.
→ Recovery & Identity-Gated Biometric Rebinding protocol promoted to first-class architectural component.
Low
Brand customisation requests — client design teams may resist Haven attribution requirement.
→ Co-branded model is non-negotiable for standard pricing. Custom enterprise terms available at premium pricing for clients requiring full white-label.