This document compares PulseProof Sentinel Protocol, abbreviated PPS, with common authentication mechanisms.
The goal is not to claim that PPS is universally better than other protocols. Each mechanism has a different deployment model and threat model.
Protocol: PulseProof Sentinel Protocol
Abbreviation: PPS
Protocol Version: 1
Status: Experimental
Internet-Draft: draft-hezami-pulseproof-sentinel
WebAuthn/FIDO2 is preferred for browser-based passkey authentication.
TOTP is simple and widely deployed but uses shared secrets.
Push 2FA is user-friendly but often proprietary and online.
SMS OTP is weak and should be avoided where possible.
PPS is designed for OTP-like, offline, terminal-friendly, transaction-aware,
duress-aware, and threshold-based flows using asymmetric proofs.
PPS is not a WebAuthn replacement.
It is a specialized protocol for scenarios where WebAuthn is unavailable or insufficient.
| Scenario | Recommended Mechanism |
|---|---|
| Browser passwordless login | WebAuthn/FIDO2 |
| Browser 2FA with passkeys | WebAuthn/FIDO2 |
| Simple low-risk 2FA | TOTP, if acceptable |
| Legacy OTP input form | PPS or TOTP |
| Offline terminal authentication | PPS |
| Transaction signing with amount confirmation | PPS |
| Silent duress signaling | PPS |
| Offline multi-device approval | PPS |
| Push-style consumer 2FA | Push 2FA or WebAuthn |
| High-security enterprise login | WebAuthn/FIDO2, optionally plus PPS |
| IoT or constrained device authentication | PPS, if crypto support exists |
| Capability | SMS OTP | TOTP | Push 2FA | Challenge-Response OTP | WebAuthn / FIDO2 | PPS |
|---|---|---|---|---|---|---|
| Server stores shared secret | Usually | Yes | Usually | Sometimes | No | No |
| Primary proof | Possession of SIM | HMAC shared secret | Proprietary app/server channel | HMAC or asymmetric challenge | Public-key signature | Public-key signature |
| Offline capable | No | Yes | No | Sometimes | Limited | Yes |
| Works with legacy OTP input fields | Yes | Yes | No | Sometimes | No | Yes |
| Phishing resistance | Low | Low | Medium | Medium | High | High when full Pulse Token is used |
| Replay protection | Weak | Time-window based | Server-controlled | Challenge-based | Strong | Strong |
| Transaction amount confirmation | No | No | Sometimes | Rare | Possible with payment extensions | Yes, with AmountMark |
| Silent duress support | No | No | Rare | No | No standard mechanism | Optional |
| Offline multi-device threshold approval | No | No | No | No | Limited | Optional |
| Suitable for constrained terminals | Low | High | Low | Medium | Low | High |
| Suitable for browser passkey flows | No | No | No | No | Excellent | Possible, but WebAuthn preferred |
| Open wire format | No | RFC 6238 | Usually proprietary | Varies | W3C standard | Yes |
| Server breach impact | High | High | Depends | Depends | Low | Low |
| Human-enterable fallback | Yes | Yes | No | Sometimes | No | Optional Trust Code |
TOTP is defined in RFC 6238.
TOTP uses:
code = HMAC(shared_secret, time)
PPS replaces the shared secret with an asymmetric key.
Pulse = Sign(private_key, time + rp + nonce + counter + context + policy)
PPS advantages over TOTP:
PPS disadvantages compared with TOTP:
Use TOTP when:
Use PPS when:
SMS OTP is widely deployed but has serious weaknesses.
PPS provides:
Avoid SMS OTP where possible.
Use PPS, TOTP, WebAuthn, or another stronger mechanism instead.
Push 2FA sends a notification to a user’s device.
Example:
Are you trying to sign in?
[Deny] [Approve]
PPS can support push-like UX through QR or deep links, but the proof itself is an open, signed, verifiable artifact.
PPS can also work without push infrastructure.
PPS is more suitable for:
Challenge-response OTP mechanisms, such as OATH OCRA, improve security by binding OTP generation to a server challenge.
PPS uses public-key signatures by default and adds optional modules for:
PPS is designed for modern implementation stacks and open interoperability.
WebAuthn and FIDO2 are strong phishing-resistant authentication standards.
WebAuthn uses:
WebAuthn is not always ideal for:
PPS is not a WebAuthn replacement.
PPS is designed for environments where WebAuthn is unavailable or insufficient.
PPS provides:
For browser passkeys:
Use WebAuthn/FIDO2.
For offline OTP replacement, transaction signing, constrained terminals,
duress-aware flows, or threshold approval:
Consider PPS.
PPS can also be used alongside WebAuthn as a secondary proof layer.
Example:
User logs in with WebAuthn.
High-value withdrawal requires PPS threshold approval.
FROST is a threshold signature scheme.
PPS version 1 threshold mode is simpler:
n-of-m independent Ed25519 signatures over the same payload
This is multisignature, not a true threshold signature.
PPS v1 multisig:
True threshold signatures:
PPS may define a FROST-based profile in a future version.
Blockchain multisig is usually tied to transaction authorization on a distributed ledger.
PPS is not a blockchain protocol.
However, PPS threshold mode can be used for similar UX:
multiple devices approve one action
PPS is lighter and suitable for centralized relying parties.
| UX Property | TOTP | Push 2FA | WebAuthn | PPS |
|---|---|---|---|---|
| User types code | Yes | No | No | Optional |
| User approves prompt | No | Yes | Yes | Yes |
| QR login possible | Sometimes | Sometimes | Sometimes | Yes |
| Offline code possible | Yes | No | Limited | Yes |
| Transaction amount visible | No | Sometimes | Possible | Yes |
| Duress hidden approval | No | Rare | No | Optional |
| Multi-device approval | No | No | Limited | Optional |
| Works without browser | Yes | Yes | No | Yes |
| Security Property | TOTP | Push 2FA | WebAuthn | PPS |
|---|---|---|---|---|
| Shared secret on server | Yes | Usually | No | No |
| Public-key proof | No | Sometimes | Yes | Yes |
| Origin binding | Weak | Medium | Strong | Strong when RP-bound |
| Session binding | Weak | Medium | Strong | Strong with nonce |
| Transaction binding | Weak | Medium | Possible | Strong with context + AmountMark |
| Silent duress | No | Rare | No | Optional |
| Forward-secure rotation | No | Rare | No | Optional |
| Offline threshold | No | No | Limited | Optional |
| Replay protection | Medium | Medium | Strong | Strong |
| Deployment Property | TOTP | Push 2FA | WebAuthn | PPS |
|---|---|---|---|---|
| Easy to add to legacy login forms | Yes | Medium | No | Yes |
| Requires browser support | No | No | Yes | No |
| Requires push infrastructure | No | Yes | No | No |
| Requires hardware authenticator | No | No | Optional | Optional |
| Works on constrained devices | Yes | No | No | Yes, with crypto support |
| Open implementation possible | Yes | Limited | Yes | Yes |
| Suitable for fintech transaction signing | Weak | Medium | Possible | Strong |
| Suitable for offline terminals | Yes | No | Limited | Yes |
PPS can coexist with existing authentication methods.
A practical migration path:
Phase 1:
Keep TOTP enabled.
Allow users to register PPS devices.
Phase 2:
Encourage PPS for high-value actions.
Phase 3:
Require PPS for sensitive operations.
Keep TOTP fallback for low-risk actions.
Phase 4:
Deprecate TOTP for users with PPS devices.
Provide recovery options.
A recommended deployment model:
Primary browser authentication:
WebAuthn/FIDO2
Secondary or special-purpose authentication:
PPS for offline approval, transaction signing, duress, threshold,
constrained devices, or legacy OTP flows
Example:
User logs in with WebAuthn.
High-value withdrawal requires PPS threshold approval.
SMS OTP has known weaknesses:
Avoid SMS OTP where possible.
TOTP is acceptable for low-risk systems where:
WebAuthn is preferred for:
PPS is suitable when you need:
PPS is not a universal replacement for WebAuthn, TOTP, or Push 2FA.
It is a specialized protocol for scenarios where existing methods are insufficient.
Its main value is combining:
asymmetric proof
+
offline capability
+
OTP-like UX
+
transaction binding
+
duress signaling
+
threshold approval
+
open wire format
For browser authentication, WebAuthn/FIDO2 remains the preferred mechanism.
For offline, terminal-friendly, transaction-aware, duress-aware, or threshold-based flows, PPS provides a useful complementary protocol.