Architecture

Protocol architecture

KIFP defines a layered architecture separating biometric verification, identity management, transaction authorization, policy enforcement, and cross-domain federation into independently verifiable components.

Five-layer trust model

Each layer operates independently with cryptographic boundaries. No layer implicitly trusts another.

Edge Layer

Certified Edge Appliances perform biometric capture, matching, and liveness detection within a secure execution environment. Biometric data never leaves the device. Only a signed match result with device attestation is transmitted to the cloud layer.

Identity Layer

The Root Authority issues Federated Identity Keys (FIK) — persistent, hash-based identity anchors bound to verified biometric enrollment. FIKs serve as the cryptographic root for all derived authorization tokens.

Authorization Layer

Retailer-Scoped Authorization Tokens (RSAT) are short-lived, per-transaction JWTs scoped to a specific merchant cluster and store. Signed with per-transaction ECDSA P-256 keys that are rotated after every issuance.

Policy Layer

A governance-driven policy engine evaluates RSATs against configurable rules: risk thresholds, amount limits, geographic constraints, consent scope, and merchant category. Every routing decision is logged with full provenance.

Federation Layer

Multi-root federation enables cross-domain identity verification through Federated Identity Assertions (FIA) — domain-scoped, non-linkable tokens exported only under governance control. Three federation tiers support sovereign, bilateral, and full federation models.

Authorization lifecycle

From edge attestation to immutable audit record in under two seconds.

Edge Attestation

Device key verified. Firmware integrity confirmed. Store binding validated.

Biometric Verification

Local match performed in secure element. Liveness check passed. Signed result generated.

RSAT Issuance

Root Authority validates attestation, issues retailer-scoped token with per-transaction key.

Cryptographic Verification

Verifier validates RSAT signature, checks revocation status, confirms scope and expiry.

Policy Routing

Authorization decision applied. Transaction routed per governance policy. Audit record immutable.

Cryptographic Properties

Per-transaction key isolation

Every RSAT is signed with a unique ECDSA P-256 key pair generated for that specific transaction. Private keys are destroyed immediately after signing. No key persists beyond a single authorization event.

ES256 (ECDSA P-256) — mandatory in KIFP v1.0
Per-transaction key generation in HSM or secure element
Automatic rotation eliminates key management surface area
Post-quantum readiness: Dilithium placeholder fields in token structure
Full key lifecycle audit trail for compliance evidence

Signing Algorithm

ES256 (P-256)

Key Lifetime

Single transaction

RSAT TTL

15–120 seconds

FIA TTL

≤ 60 seconds

PQ Target

ML-DSA (Dilithium)

Nonce Enforcement

JTI uniqueness

Integration

API-first protocol integration

Every KIFP operation is an API call. RSAT verification, policy evaluation, revocation checking, and audit retrieval are available through structured REST endpoints.

View Documentation

verify-rsat.ts

// Verify a Retailer-Scoped Authorization Token
const result = await keyidentity.rsat.verify({
  token: rsat_token,
  policy: "gpol:keyidentity:rsat-retail:v2",
  options: {
    enforce_key_rotation: true,
    check_revocation: true,
    audit_trail: true,
  },
});

if (result.verified) {
  const route = await keyidentity.policy.evaluate({
    rsat_id: result.jti,
    merchant_cluster: "mc:acme-retail:cluster-northeast",
    store_id: "store:acme-retail:42",
  });

  // route.decision: "allow" | "deny" | "manual_review"
}

kifp-event.json

// KIFP authorization event payload
{
  "event": "rsat.verified",
  "kifp_version": "1.0",
  "timestamp": "2026-02-16T14:30:00Z",
  "data": {
    "jti": "455a0e30-41c6-4f85-a1f9-bd79995c3bf7",
    "root_id": "root:keyidentity:primary",
    "fik_ref": "root:keyidentity:primary.sha256:a1b2...",
    "merchant_cluster_id": "mc:acme-retail:cluster-northeast",
    "store_id": "store:acme-retail:42",
    "risk_score": 12,
    "decision": "allow",
    "route": "standard_processing",
    "sig_suite": "ES256",
    "pq_ready": true
  }
}

Request an architecture review

Our protocol engineering team is available for detailed architecture reviews with prospective deployment partners.

Request Private Briefing Access Secure Demo