One action.
Verifiable evidence.

Choose the human approval point

Biometric authorization is a deliberate tradeoff: it adds friction in exchange for stronger assurance. Use it where a service needs human sign-off, rather than interrupting every step of a workflow.

An agent workflow can allow many earlier steps to run autonomously. A service can require human-attended authorization at a selected point, such as sending a prepared message, publishing a finished article, or granting a defined permission.

The app presents the exact request. The person authorizes it through the biometric gate. The receiving backend checks a receipt tied to that action before accepting it. The receipt does not certify the agent’s reasoning, earlier work, or future behavior.

Permission grants have a specific scope

If the protected action grants permission, the application must bind the permission’s exact scope to what is authorized. The receiving service remains responsible for enforcing its permitted actions, resources, duration, and limits.

Block posting without fresh approval

Require fresh biometric authorization for each protected post or comment. The receiving backend rejects submissions with missing, spent, or mismatched receipts. The approval is bound to the exact content and receiving service; it cannot authorize a burst of different posts.

Under that policy, a thousand accepted posts need a thousand separate approvals. This blocks unattended publication without fresh sign-off and adds human time to the cost of mass spam. AI can still help people draft their posts.

Enforce the gate on the receiving backend

Check the exact action binding, challenge, expiry, and replay state before accepting each protected submission. Apply the service’s account, moderation, and rate-limit rules alongside the receipt. The approval cost applies to accepted protected actions, not to sending network requests.

This requires fresh approval for each post. A one-time permission to let an agent post later has a different scope; it does not create an approval step for each subsequent submission.

The authorization flow

Each action carries evidence of its authorization. First, enrollment gives the app a credential for its protected phone key. Then each protected action follows this flow.

1. The service issues a challenge.

   A one-time, expiring request identifies the receiving service and the applicable policy. The service keeps the state needed to enforce replay rules.

2. The app prepares the exact action.

   The content is encoded deterministically and hashed. The app shows an action preview before authorization; changing protected content changes the action binding.

3. The platform gates the hardware key.

   The service’s trusted iPhone app requests Face ID or Touch ID for a key held in the Secure Enclave. Passcodes, passwords, SMS, and software keys cannot authorize a protected action.

4. The SDK prepares a presentation.

   The proof binds the action to its challenge, service, policy, and expiration. The presented proof hides the underlying device key and credential.

5. The receiving backend verifies and accepts.

   The backend verifies the proof and its claims, compares them to the expected request, applies its policy, and enforces expiry and replay protection before accepting the action.

Inside the evidence

An attestation is the evidence when issued; a receipt is that evidence when presented. It carries concrete claims and bindings, rather than an unqualified human=true flag.

{
  "action": "hash of the exact protected content",
  "service": "the intended receiving service",
  "policy": "named policy and version",
  "challenge": "one-time server challenge",
  "expires": "the validity boundary",
  "authorization": "qualifying hardware key",
  "profile": "the applicable assurance profile"
}

The frozen specification defines the actual encoding and verification rules. The summary above is explanatory JSON, not an SDK response or a valid receipt.

What an integration needs

A mobile prompt is one part of a larger trust and verification flow. The receiving service remains responsible for its own product and abuse policy.

Designed around minimal disclosure

The privacy goal is to establish useful action-level claims while avoiding a universal cross-service identity.

• Biometrics stay local. Raw face and fingerprint data never enter Enthade systems.
• Presentations hide credentials. The underlying device key and credential are hidden in the presented proof.
• Credentials stay separate across apps. Each service’s app uses separate credentials and issuer keys. Within a service, repeat-use markers and service-specific identifiers can link a credential’s actions. There is no shared credential or universal identifier across services.
• Raw signals stay on-device. The planned Presence layer processes privacy-sensitive sensor data locally by default; only derived assessments may leave the device.
• Logs hold cryptographic references. Planned transparency infrastructure records commitments: references that can be checked without publishing the underlying data. It records these and checkpoints, rather than posts, faces, or usernames.

Privacy has operational boundaries

The attester checks the app and device evidence; the issuer issues credentials. The current design separates these roles, but those services could combine their records. Network metadata, timing, accounts, and a receiving service’s own records also affect privacy.

“No raw biometrics” is a concrete design commitment. “Completely anonymous” or “untrackable” would overstate the model.

What the evidence can establish

Protocol, Integrity, and Presence answer different questions. Presence is probabilistic and planned outside the frozen v0.1 scope. Stronger evidence must still be described according to what was actually evaluated.

Failure cannot become a weaker pass

Missing, expired, revoked, invalid, or inconclusive required evidence cannot count as approval. If biometrics are unavailable, a protected action cannot satisfy the policy. Recovery may permit enrollment of a new qualifying key; recovery itself never signs the protected action.

Device credentials are not people

Credential and account restrictions can raise the cost of abuse. They do not establish one unique person. Reinstall and key lifecycle behavior matter; ballot eligibility and person-level uniqueness remain separate responsibilities.

Keep protocol and policy separate

The protocol defines the rules independent implementations must agree on to verify evidence. A policy names the requirements a particular service chooses for its protected actions.

Policies are named and versioned. Changing a policy should change future requirements without silently changing what an earlier receipt meant.

The ecosystem around the foundation

Enthade SDK supplies implementation libraries. Enthade Forum exercises the flow in a first-party app. Enthade Verify is the envisioned hosted service; Presence adds adaptive assessments; Log adds public transparency. These components have different maturity levels.

What exists today

Implementation overview · 1 October 2026

A few useful terms

Protected action

An action a service’s policy requires to carry authorization evidence.

Relying party

The service receiving the action and checking the evidence.

Assurance profile

A published, versioned description of which device and app evidence qualifies, and what it means.

Attestation / receipt

Evidence issued for authorization is called an attestation. When presented to the receiving service, it is called a receipt.

Action binding

The connection that lets a service check that the receipt belongs to the exact action it is about to accept.

Nullifier

A repeat-use marker. It lets a service spot reuse of the same credential under a particular rule. It does not identify a unique person.

Human-attended

An action with evidence that a person was present and intentionally authorized it. This does not establish who wrote the content or identify a unique person.