Open Arsenal

See the stars

Proofora Specification

Home / Proofora / Proofora Specification

Proofora

Human Proof. Device Trust.

Overview

Proofora is a blockchain-based identity and authentication protocol designed to establish cryptographically verifiable relationships between a human identity, an identity credential, and authorized devices.

Proofora uses video-based liveness verification, randomized biometric snapshot selection, cryptographic image commitments, challenge-response authentication, blockchain-backed credential records, and device-bound cryptographic keys. The protocol is designed to minimize the exposure of biometric information while providing independently verifiable proof of identity and trusted device ownership.

Proofora is designed as a modular system. Core modules provide the fundamental identity, cryptographic, authentication, privacy, and device capabilities required by the protocol. Optional plugin modules extend the system with additional verification methods, identity providers, blockchain networks, compliance systems, recovery mechanisms, and application integrations.

Design Principles

  • Human-controlled identity
  • Cryptographically verifiable authentication
  • Privacy-preserving biometric verification
  • Local custody of sensitive biometric material
  • Blockchain-backed credential verification
  • Device-bound authentication
  • Challenge-response security
  • Replay resistance
  • Credential and device revocation
  • Cryptographic auditability
  • Modular architecture
  • Plugin extensibility
  • Vendor-neutral implementation
  • Interoperable identity credentials
  • Human control over automated processes
  • No unnecessary storage of biometric information on-chain

Core Modules

Identity Enrollment Module

The Identity Enrollment Module manages creation of a Proofora identity credential.

The module shall:

  • Initiate a new identity enrollment session.
  • Generate unique enrollment identifiers.
  • Establish cryptographic enrollment challenges.
  • Associate enrollment information with a cryptographic identity commitment.
  • Prevent duplicate or conflicting enrollment sessions where policy requires it.
  • Maintain enrollment state throughout the verification process.
  • Support credential versioning.
  • Support credential expiration where required.
  • Support credential revocation.

Liveness Verification Module

The Liveness Verification Module establishes that the individual participating in enrollment is physically present and is not simply presenting a photograph, recording, or other replayed representation.

The module shall:

  • Initiate a video-based liveness session.
  • Generate randomized liveness challenges.
  • Capture required video frames.
  • Analyze facial movement and response to randomized prompts.
  • Detect presentation attacks where supported.
  • Detect replayed or manipulated video where supported.
  • Produce a signed liveness verification result.
  • Associate the verification result with the enrollment session.
  • Avoid storing raw liveness video unless explicitly authorized by policy.

Snapshot Capture Module

The Snapshot Capture Module creates standardized biometric image inputs from the verified liveness session.

The module shall:

  • Capture ten enrollment snapshots.
  • Apply defined image resolution requirements.
  • Apply a canonical image format.
  • Apply a defined color space and color representation.
  • Record required capture metadata.
  • Associate each snapshot with the enrollment session.
  • Preserve the original capture ordering.
  • Generate a unique cryptographic identifier for each snapshot.
  • Randomly select four snapshots for identity enrollment.

The random selection process shall be cryptographically unpredictable and resistant to manipulation by either the client or server.

Biometric Canonicalization Module

The Biometric Canonicalization Module ensures that biometric image data is converted into a consistent representation before cryptographic processing.

The module shall:

  • Normalize image dimensions.
  • Normalize color representation.
  • Normalize required image metadata.
  • Establish deterministic encoding.
  • Establish deterministic pixel or pixel-block ordering.
  • Remove unsupported or non-deterministic metadata where required.
  • Produce a canonical representation suitable for cryptographic hashing.

The canonicalization process shall be deterministic so that the same authorized input produces the same cryptographic representation.

Pixel and Block Hashing Module

The Pixel and Block Hashing Module converts canonical biometric image data into cryptographically verifiable components.

The module shall support:

  • Individual pixel hashing where required by an implementation.
  • Pixel-block hashing for scalable verification.
  • Coordinate-aware hashing.
  • Channel-aware hashing.
  • Timestamp binding.
  • Image identifier binding.
  • Canonical format binding.
  • Cryptographic salt or nonce usage where appropriate.
  • Cryptographic hash algorithm versioning.

A hash input shall bind the relevant image data to its associated metadata so that changes to the image, representation, capture context, or required metadata invalidate the resulting commitment.

Merkle Commitment Module

The Merkle Commitment Module converts hashed image components into independently verifiable cryptographic commitments.

The module shall:

  • Construct Merkle trees from image hashes or image blocks.
  • Generate a Merkle root for each enrolled snapshot.
  • Generate inclusion proofs for selected image components.
  • Verify Merkle inclusion proofs.
  • Support cryptographic algorithm versioning.
  • Support replacement of deprecated cryptographic algorithms through credential versioning.

The four selected enrollment snapshots shall produce independent commitments that can be combined into an identity commitment.

Identity Commitment Module

The Identity Commitment Module combines the cryptographic commitments produced during enrollment into a verifiable identity commitment.

The module shall:

  • Generate commitments for each selected snapshot.
  • Combine the four snapshot commitments.
  • Bind commitments to the enrollment credential.
  • Bind commitments to credential version information.
  • Bind commitments to required enrollment metadata.
  • Generate a final identity commitment.
  • Prevent unauthorized modification of enrolled commitments.
  • Support credential rotation without unnecessarily exposing historical biometric information.

Cryptographic Key Module

The Cryptographic Key Module manages the keys used to authenticate users, devices, credentials, and protocol messages.

The module shall:

  • Generate asymmetric key pairs.
  • Maintain public and private key relationships.
  • Protect private keys using secure local storage where available.
  • Support hardware-backed key storage where available.
  • Sign authentication challenges.
  • Verify digital signatures.
  • Support key rotation.
  • Support key revocation.
  • Support credential versioning.
  • Prevent private keys from being transmitted to authentication servers.

Authentication Challenge Module

The Authentication Challenge Module provides randomized challenge-response authentication.

The module shall:

  • Generate cryptographically secure authentication challenges.
  • Bind challenges to authentication sessions.
  • Prevent challenge reuse.
  • Include expiration information.
  • Support randomized selection of committed biometric components.
  • Request cryptographic proofs for selected image components.
  • Require proof of possession of the appropriate private key.
  • Validate signatures.
  • Reject expired, malformed, duplicated, or previously consumed challenges.

Proof Verification Module

The Proof Verification Module validates authentication proofs presented by a user’s device.

The module shall verify:

  • Challenge validity.
  • Digital signatures.
  • Credential validity.
  • Identity commitment integrity.
  • Merkle inclusion proofs.
  • Requested biometric commitment relationships.
  • Device authorization.
  • Credential status.
  • Revocation status.
  • Protocol version compatibility.
  • Replay protection requirements.

Authentication shall only succeed when all required verification conditions are satisfied.

Device Identity Module

The Device Identity Module gives each authorized device an independent cryptographic identity.

The module shall:

  • Generate a unique device key pair.
  • Register the device public key with the user’s identity credential.
  • Bind devices to identity credentials.
  • Authenticate devices independently.
  • Support multiple authorized devices.
  • Support device-specific credentials.
  • Support device key rotation.
  • Support device revocation.
  • Maintain device authorization status.

A device shall not be considered trusted solely because it possesses an account password or session token.

Device Pairing Module

The Device Pairing Module establishes trust when a new device is added to an existing identity.

The module shall:

  • Require authentication from an already authorized identity or device.
  • Generate a cryptographic pairing challenge.
  • Verify the new device key.
  • Bind the new device to the identity credential.
  • Record the authorization event.
  • Support user confirmation.
  • Prevent unauthorized device enrollment.
  • Support pairing expiration.
  • Support cancellation of pending pairings.

Device Authentication Module

The Device Authentication Module continuously establishes that a connected device remains an authorized device.

The module shall:

  • Authenticate device public keys.
  • Perform challenge-response authentication.
  • Detect revoked devices.
  • Detect invalid credentials.
  • Prevent unauthorized credential duplication.
  • Support secure session establishment.
  • Support device-specific authentication policies.
  • Support device reauthentication.

Device Revocation Module

The Device Revocation Module allows an authorized identity to remove trust from a device.

The module shall:

  • Revoke device credentials.
  • Record device revocation status.
  • Prevent revoked devices from authenticating.
  • Support immediate or policy-based revocation.
  • Support replacement device enrollment.
  • Preserve appropriate audit records.

Revoking a device shall not automatically revoke the user’s entire identity unless explicitly required by policy.

Blockchain Registry Module

The Blockchain Registry Module provides a verifiable distributed record for Proofora identity and device state.

The blockchain registry may contain:

  • Identity commitments.
  • Credential identifiers.
  • Credential versions.
  • Credential status.
  • Issuer identifiers.
  • Device public keys.
  • Device authorization status.
  • Revocation records.
  • Credential rotation records.
  • Timestamp information.
  • Cryptographic protocol versions.
  • Audit commitments.

The blockchain registry shall not require storage of raw biometric images, raw liveness video, private keys, passwords, or other unnecessary sensitive information.

Credential Module

The Credential Module manages the lifecycle of Proofora credentials.

The module shall support:

  • Credential issuance.
  • Credential activation.
  • Credential verification.
  • Credential expiration.
  • Credential rotation.
  • Credential suspension.
  • Credential revocation.
  • Credential recovery.
  • Credential versioning.
  • Credential migration.

Credentials shall contain only the information necessary to perform their intended verification functions.

Issuer Module

The Issuer Module manages organizations or systems authorized to issue or attest to Proofora credentials.

The module shall:

  • Identify credential issuers.
  • Verify issuer authorization.
  • Sign credential records.
  • Maintain issuer status.
  • Support issuer key rotation.
  • Support issuer revocation.
  • Support multiple issuer types.
  • Support independently verifiable issuer records.

Privacy Module

The Privacy Module establishes requirements for protecting biometric and identity information.

The module shall:

  • Keep raw biometric information under user-controlled or explicitly authorized custody where possible.
  • Prevent unnecessary biometric information from being placed on-chain.
  • Minimize personally identifiable information.
  • Separate identity commitments from unnecessary personal information.
  • Support selective disclosure.
  • Support privacy-preserving verification.
  • Provide consent controls.
  • Support credential revocation.
  • Support data retention policies.
  • Support deletion of locally stored biometric material where permitted by credential policy.

Replay Protection Module

The Replay Protection Module prevents previously captured authentication material from being reused.

The module shall:

  • Generate unique authentication challenges.
  • Bind responses to individual sessions.
  • Track consumed challenges where required.
  • Require fresh signatures.
  • Require expiration timestamps.
  • Reject previously used authentication responses.
  • Detect duplicated authentication attempts.

Secure Communication Module

The Secure Communication Module protects communication between users, devices, identity providers, and verification services.

The module shall:

  • Establish authenticated connections.
  • Encrypt sensitive communications.
  • Verify endpoint identities.
  • Protect against message modification.
  • Protect against replay.
  • Support cryptographic session establishment.
  • Support protocol version negotiation.

Audit Module

The Audit Module provides verifiable records of security-relevant events without unnecessarily exposing sensitive information.

The module shall support records for:

  • Identity enrollment.
  • Liveness verification.
  • Credential issuance.
  • Credential rotation.
  • Device enrollment.
  • Device pairing.
  • Device authentication.
  • Device revocation.
  • Credential revocation.
  • Recovery operations.
  • Authentication failures.
  • Security policy changes.

Audit records should use cryptographic commitments or other privacy-preserving mechanisms where appropriate.

Recovery Module

The Recovery Module provides controlled recovery from lost credentials, lost devices, or compromised authentication material.

The module shall support configurable recovery methods including:

  • Recovery devices.
  • Hardware security keys.
  • Recovery codes.
  • Multi-device authorization.
  • Multi-party recovery.
  • Issuer-assisted recovery.
  • Credential replacement.
  • Device replacement.

Recovery operations shall require stronger verification than ordinary authentication where appropriate.

Policy Module

The Policy Module controls protocol behavior and security requirements.

Policies may define:

  • Liveness requirements.
  • Snapshot requirements.
  • Number of selected enrollment snapshots.
  • Hashing algorithms.
  • Merkle tree algorithms.
  • Authentication challenge requirements.
  • Device authorization requirements.
  • Credential expiration.
  • Recovery requirements.
  • Revocation requirements.
  • Data retention.
  • Privacy requirements.
  • Issuer requirements.
  • Geographic or regulatory requirements.

Policies shall be versioned and cryptographically identifiable.

Optional Plugin Modules

Alternative Biometric Plugin

Provides additional biometric verification methods while preserving the core Proofora credential and authentication architecture.

External Identity Provider Plugin

Connects Proofora to external identity providers while maintaining cryptographic credential verification.

Government Identity Plugin

Provides integration with government-issued identity systems where authorized and legally supported.

Financial KYC Plugin

Provides integration with financial institution KYC and customer verification workflows.

Business Verification Plugin

Supports organizational identity, business verification, beneficial ownership verification, and authorized representative credentials.

Zero-Knowledge Proof Plugin

Provides zero-knowledge verification capabilities that allow users to demonstrate possession of qualifying credentials without unnecessarily revealing the underlying identity information.

Hardware Security Plugin

Integrates hardware security keys, secure elements, trusted platform modules, hardware wallets, and other hardware-backed cryptographic systems.

Blockchain Network Plugin

Allows Proofora to operate with different blockchain networks or distributed ledger systems.

The plugin shall abstract blockchain-specific functionality from the Proofora core protocol.

Decentralized Identity Plugin

Provides compatibility with decentralized identity systems and interoperable verifiable credential standards.

Compliance Plugin

Provides configurable regulatory and compliance workflows without embedding jurisdiction-specific requirements into the core protocol.

Fraud Detection Plugin

Provides additional fraud detection and risk analysis capabilities while keeping the core authentication protocol independent from any particular fraud detection provider.

Risk Scoring Plugin

Provides configurable risk assessment using authentication context, device history, credential status, and other authorized signals.

Biometric Matching Plugin

Provides optional biometric matching capabilities for systems that require additional identity verification.

Device Reputation Plugin

Maintains optional cryptographic reputation information for authorized devices based on configurable security policies.

Notification Plugin

Provides user notifications for enrollment, authentication, device pairing, credential changes, revocation, recovery, and security events.

Recovery Provider Plugin

Allows users or organizations to integrate external recovery services without making any single recovery provider mandatory.

Enterprise Identity Plugin

Provides enterprise account management, administrative controls, organizational policies, and workforce identity integration.

API Integration Plugin

Provides standardized interfaces for applications and services that need to request Proofora authentication.

Authentication Gateway Plugin

Allows Proofora verification to operate as an authentication gateway for applications, networks, services, and infrastructure.

Security Requirements

Proofora implementations shall:

  • Use modern cryptographic algorithms.
  • Use cryptographically secure random number generation.
  • Protect private keys from unauthorized access.
  • Protect authentication challenges from replay.
  • Authenticate devices independently.
  • Validate all cryptographic proofs.
  • Validate credential status before authentication.
  • Support credential and device revocation.
  • Prevent unauthorized modification of identity commitments.
  • Protect against tampering with biometric enrollment data.
  • Protect against manipulated timestamps.
  • Protect against challenge prediction.
  • Protect against credential replay.
  • Protect against unauthorized device enrollment.
  • Provide secure error handling.
  • Avoid exposing sensitive information through authentication errors.

Cryptographic algorithms shall be replaceable through versioned protocol components so that the system can migrate away from compromised or deprecated algorithms.

Privacy Requirements

Proofora implementations shall follow data minimization principles.

Raw biometric images should remain outside the blockchain and should only be retained when explicitly required and authorized.

The protocol should prefer cryptographic commitments, proofs, and selective disclosure over transmission of raw biometric information.

Implementations should clearly distinguish between:

  • Biometric source data.
  • Biometric commitments.
  • Identity credentials.
  • Device credentials.
  • Public keys.
  • Private keys.
  • Authentication proofs.
  • Blockchain records.
  • Audit records.

Users should be able to determine which authorized services may access information associated with their identity credential, subject to applicable credential and legal requirements.

Blockchain Requirements

The blockchain layer shall function as a verifiable trust and state layer rather than a repository for raw biometric information.

The protocol shall support blockchain-independent identity and credential logic so that implementations can use different compatible blockchain networks.

Blockchain-dependent functionality shall be isolated behind defined interfaces.

The system shall support:

  • Credential registration.
  • Credential status.
  • Device registration.
  • Device authorization.
  • Device revocation.
  • Identity commitment registration.
  • Credential rotation.
  • Issuer registration.
  • Issuer status.
  • Cryptographic audit commitments.

Interoperability

Proofora should support interoperability with established cryptographic identity, authentication, decentralized identity, and verifiable credential standards where those standards are compatible with the protocol’s privacy and security requirements.

Interoperability modules shall not require the Proofora core to depend on a single vendor, blockchain, identity provider, biometric provider, or authentication service.

Human Control

Proofora shall maintain human control over identity enrollment, credential authorization, device pairing, recovery, and revocation.

Automated systems may assist with liveness verification, fraud detection, risk analysis, and authentication processing, but security-sensitive identity decisions shall be governed by explicitly defined policies and provide appropriate mechanisms for human review where required.

Versioning

Every Proofora credential, cryptographic commitment, protocol implementation, and security-sensitive policy shall support version identification.

Protocol versions shall identify compatible:

  • Cryptographic algorithms.
  • Image canonicalization rules.
  • Hashing rules.
  • Merkle tree rules.
  • Credential formats.
  • Authentication challenge formats.
  • Device authentication methods.
  • Blockchain registry formats.

Version changes shall not silently invalidate existing credentials without a defined migration or revocation process.

Extensibility

Proofora shall maintain a stable core protocol while allowing optional functionality to be implemented through plugins.

Plugins shall:

  • Use defined interfaces.
  • Maintain independent version information.
  • Not modify core credential semantics without explicit compatibility requirements.
  • Not require users to adopt unrelated plugins.
  • Clearly identify external dependencies.
  • Respect Proofora privacy and security requirements.
  • Support secure removal or replacement.

Verification Lifecycle

A standard Proofora authentication lifecycle shall follow this general process:

  • Establish an authentication session.
  • Identify the credential and authorized device.
  • Generate a cryptographically secure challenge.
  • Randomly select the required verification component.
  • Request the corresponding cryptographic proof.
  • Produce a signed response on the user’s authorized device.
  • Produce any required Merkle inclusion proof.
  • Verify the identity commitment.
  • Verify the device public key.
  • Verify credential status.
  • Verify revocation status.
  • Validate challenge freshness.
  • Establish the authenticated session.

Enrollment Lifecycle

A standard Proofora enrollment lifecycle shall follow this general process:

  • Start an identity enrollment session.
  • Perform video-based liveness verification.
  • Capture ten standardized snapshots.
  • Canonicalize the snapshots.
  • Randomly select four snapshots.
  • Generate cryptographic image or block hashes.
  • Construct Merkle trees.
  • Generate four snapshot commitments.
  • Generate the identity commitment.
  • Generate the user’s identity credential.
  • Generate the appropriate cryptographic key material.
  • Register required public commitments with the blockchain registry.
  • Securely retain authorized local credential material.
  • Complete enrollment.

Device Enrollment Lifecycle

A standard device enrollment lifecycle shall follow this general process:

  • Initiate device pairing.
  • Authenticate an existing authorized identity or device.
  • Generate a cryptographic key pair on the new device.
  • Generate a pairing challenge.
  • Verify the new device public key.
  • Obtain required user authorization.
  • Register the device.
  • Bind the device to the identity credential.
  • Record the device authorization state.
  • Complete secure device authentication setup.

Specification Branding License (SBL)

Standard

Optional

License & Notice Requirements

Proofora is released under the GNU Affero General Public License v3.0 or later (AGPL-3.0+).

By contributing to any Open Arsenal project, you agree that your contributions will also be released under this license.

Please note the following:

  • All contributions must comply with the AGPL-3.0+ terms.
  • Under Section 7 of the license, all redistributions, forks, and derivative works must preserve attribution to Roxanne Ardary and roxanneardary.com.
  • Proofora specifications are free to use with attribution. A Specification Branding License can be negotiated upon request.
  • The project’s notice.md file tracks attribution requirements and contributor acknowledgments. Any update that adds new contributors or modifies attribution should also update notice.md.
  • When submitting a pull request, ensure that any new files maintain the attribution headers where applicable.
  • Network-deployed versions of this software must also remain fully AGPL-3.0+ compliant, including exposure of source code modifications when applicable under the license.

For full legal details, please refer to the AGPL-3.0+ license and the project’s notice.md file.

Notice – Proofora

Attribution Requirement: Under Section 7 of the AGPL 3.0+ license, all redistributions, forks, and derivative works, including network-deployed versions of this project, must provide attribution to Roxanne Ardary and roxanneardary.com.

Contributors

This file tracks contributors and their specific contributions to the project.

  • Roxanne Ardary, roxanneardary.com – August 23, 2026
    Created the repository for Proofora, a blockchain-based identity and authentication protocol providing cryptographic human proof and trusted device authentication.
  • [Add other contributors here] – [Date]
    [Describe contribution in one sentence]

License – Proofora

This repository is licensed under the GNU Affero General Public License v3.0 or later (AGPL-3.0+).

Key Points

  • You are free to use, modify, and distribute the code.
  • All redistributions, forks, and derivative works or network-deployed versions must also be licensed under AGPL-3.0+ and provide attribution to Roxanne Ardary and roxanneardary.com as required under Section 7 of the license.
  • The software is provided “as is,” without warranty of any kind.

For the full license text, see GNU AGPL-3.0 License.

Related posts:

MolecularAI

CryptoGate

NarrativeLayer