IETF Internet-Draft Protocol Version 1 Status: Experimental License: Apache-2.0

PulseProof Sentinel Protocol

Time-bound asymmetric authentication proofs for offline, OTP-style, transaction-signing, duress-aware, and multi-device flows.

What is PPS?

An open protocol that replaces shared OTP secrets with signed asymmetric proofs

PulseProof Sentinel Protocol, abbreviated PPS, is an experimental open authentication protocol that replaces shared-secret TOTP-style codes with signed, time-bound, asymmetric proofs called Pulses.

Instead of storing OTP secrets on the server, PPS verifiers store only public keys.

totp-model.txt
# TOTP
code = HMAC(shared_secret, time)

# Server stores:
# - shared secret
# - counter / time window
pps-model.txt
# PPS
Pulse = Sign(private_key, time + rp + nonce + counter + context + policy)

# Server stores:
# - public key only
# - no shared OTP secret
Positioning

Designed to complement WebAuthn/FIDO2, not replace it

WebAuthn remains the preferred mechanism for browser-based passkey authentication. PPS targets operational gaps where WebAuthn is unavailable or insufficient.

Where WebAuthn is preferred

For browser-based passkey authentication, phishing-resistant login, and platform authenticator flows, WebAuthn/FIDO2 remains the recommended standard.

Where PPS fits

PPS is designed for offline authentication, legacy OTP forms, QR/deep-link flows, constrained terminals, transaction signing, silent duress, and threshold approval.

PPS targets operational gaps

  • Offline or semi-offline authentication
  • Legacy OTP input forms
  • QR-code and deep-link authentication
  • Constrained hardware terminals
  • Point-of-sale and IoT devices
  • Human-visible transaction confirmation
  • Silent duress signaling
  • Offline multi-device threshold approval
Core Features

A compact, technology-neutral protocol for modern authentication flows

PPS combines asymmetric proofs, deterministic CBOR encoding, and optional advanced security modules for transaction signing, duress, threshold approval, and more.

Asymmetric time-bound proofs

Authentication is based on signed Pulses, not shared OTP secrets.

No shared OTP secret

Verifiers store only public keys, reducing server breach impact.

Offline-capable

Pulse generation can work without a live network round-trip.

Forward-secure ratcheting

Optional key rotation helps limit exposure from key compromise.

Silent duress signaling

Optional Honey-Pulse mechanism for coercion-aware authentication.

Threshold approval

Optional offline n-of-m multi-device approval for sensitive actions.

Transaction AmountMark

Optional human-visible amount checksum embedded in the Trust Code.

Dynamic policy binding

Optional server-issued policy hash bound to each Pulse.

Context binding

Optional environmental and session context binding using deterministic CBOR.

Ecosystem

Specification, core implementation, and framework integration

The PPS ecosystem is split into a protocol specification, a framework-agnostic PHP implementation, and a Laravel integration package.

pulseproof-sentinel Protocol specification and documentation
Spec

The canonical PulseProof Sentinel Protocol specification, documentation, and protocol-level reference materials.

pps-php Core PHP implementation
PHP

Framework-agnostic PHP implementation of PPS: Pulse creation, verification, storage backends, Trust Code, duress, threshold, and transaction signing.

laravel-pps Laravel integration package
Laravel

Laravel bridge for PPS: service provider, routes, controller, facade, config, migrations, and storage integration built on top of pps-php.

Packages

Sample implementation in PHP

A reference implementation is available in PHP as a framework-agnostic core package, plus a Laravel integration package.

Core PHP package

Install the framework-agnostic PPS core implementation.

composer require pps-protocol/pps-php

Laravel package

Install the Laravel integration built on top of the PPS core package.

composer require pps-protocol/laravel-pps

Experimental status

PPS is experimental and has not been independently audited. It should not be used in production without cryptographic review, security audit, interoperability testing, and operational risk assessment.