SanctifAI Trust

SanctifAI Trust — Proof of Human

Version 1.3.1 · Last updated 2026-08-17. This skill and its reference.md share one version; the changelog is at the end. If a copy of this file (e.g. an external mirror) shows a different version, the lower one is stale.

SanctifAI Trust turns a unit of human work into a verifiable Proof of Human attestation: a person confirms presence with WebAuthn (Touch ID / Windows Hello / passkey), and the platform records a privacy-preserving participation plus an optional on-chain seal and a public certificate URL + QR code. Raw task data never leaves the browser — only 0x+SHA-256 commitments are sent.

Use this skill when a user wants to prove a human did something (approved a wire, reviewed content, signed off a release, completed a gig task) and get a participation_id + certificate_url back.

No package install required. You integrate by calling the REST API directly (embedded path) or by including one hosted `

The script exposes `createAttestation`, `detectExtension`, `isReady`,
`waitForReady`, and `sha256Hex` on `window.SanctifAIPresence`. Identity comes from
the worker's extension config, so the attestation binds to the **worker** and is
portable across the customers they work for.

## Hard rules

1. **Default to embedded; obtain credentials, don't dodge to the extension.**
   Embedded needs `TRUST_TENANT_ID` + `TRUST_API_KEY` on the backend — have them
   or prompt the user. A missing key is never a reason to pick the extension.
2. **Target production** `https://trust.sanctifai.com`. A local Trust site is docs
   only unless confirmed to run the full API with your tenant allowlist.
3. **Never ship a Trust API key to client JavaScript.** Embedded → mint the
   session on the backend. Extension → the key lives in the worker's extension.
4. **`task_type` / `domain` are fixed 3-letter codes** (see Taxonomy codes).
   Descriptive labels go in `task_subtype` (≤ 200 chars) or inside
   `taskData`/`resultData` before hashing — never in a code field.
5. **`taskData` / `resultData` stay raw on the client** — they are hashed into
   `0x`+SHA-256 commitments; only hashes are transmitted.
6. **No PII on the public certificate.** Fields that can appear on the certificate
   or proof URL — especially `task_subtype`, labels inside `taskData`/`resultData`,
   and any display metadata — must **not** contain personally identifiable
   information (names, emails, phone numbers, account numbers, government IDs,
   full addresses, etc.). Use opaque internal IDs for `user_id` (e.g.
   `emp_a8f3c2`, not `jane.doe@company.com`). The Tenant ID is already scoped to
   the integrator; do not embed customer PII in tenant-facing attestation payloads.
   Put human-readable detail in your own app/database; keep Trust payloads
   pseudonymous.
7. **Register production origin(s) + RP ID** with the tenant, or the API's
   allowlist rejects the domain.
8. **`rp_id` is the hostname only** (e.g. `app.example.com`, or `localhost` in dev).
9. **The attestation step runs in a browser** (it calls `navigator.credentials`).

## Before you ask the user to test (smoke test)

Sanity-check the wiring **without** completing a real attestation:

```txt
- POST /api/webauthn/registration/options  → returns challenge_id + options
- POST /api/presence/start                  → returns session_id
- POST /api/presence/options                → returns options.challenge

If any of these returns HTML, a 401/403, or a CORS error, fix the base URL, API key, or origin allowlist before going further — don't prompt the user yet.

A 400 is not a credential verdict. Auth is checked only after the body validates, so a bogus key with an invalid body returns the same 400 as a real key with an invalid body. Confirm the key with a valid body: valid body + real key → 200, valid body + bogus key → 401. You haven't verified the key until you've seen the 200. (And a 307 → /login means the base URL is right but the path is wrong — see reference.md troubleshooting.)

UI acceptance criteria

A complete UI shows, after a successful attestation:

- participation_id
- certificate_url  (clickable link — open it to confirm the public proof renders)
- qr_url           (rendered as a QR image, not just a link)
- verification_url (if present — the on-chain explorer link)
- clear error guidance when the reviewer has not enrolled a passkey

Verify it worked

A successful call returns JSON with a non-empty participation_id and a certificate_url. Open the certificate_url to confirm the public proof renders.

Deeper material

• reference.md — REST endpoints, full taxonomy code lists, obtaining credentials, one-time passkey enrollment, the Origin-forwarding rule for proxied enrollment, error/troubleshooting tables, CORS/same-origin-proxy guidance, response shapes.
• Docs: https://trust.sanctifai.com

Changelog

This skill shares one version with reference.md. Record which version you built against; a version mismatch between the published copy and a mirror means one is stale.

• 1.3.1 — 2026-08-17. Corrected the signup section: there is no free trial. The Developer plan is free forever (100 attestations/month, 1 tenant, unlimited reviewers, 30-day audit history); the previously documented "7-day trial" and its "10 users" limit never existed. Added a pointer to the pricing page. reference.md unchanged; version kept in lockstep.
• 1.3.0 — 2026-08-15. No change to this skill's guidance; reference.md gained the excludeCredentials-now-populated note and a consistent error envelope (code + error on every family). Version kept in lockstep.
• 1.2.0 — 2026-08-14. No change to this skill's guidance; reference.md gained the GET /api/v1/participations list endpoint, the per-tenant rate-limit contract, the v1 read error shape, an advanced-POST-create note, and a bond_eligible default fix. The former internal docs/api/* reference was retired in favour of reference.md as the single published contract. Version bumped to keep the set in lockstep.
• 1.1.0 — 2026-08-14. Reset window stated (calendar month, UTC). Smoke-test note that a 400 is not a credential verdict (real-key/bogus-key pair) and the 307 → /login path hint. Full detail — the GET /api/v1/participations read endpoints, Origin-allowlist validation in the proxy, the two error-envelope shapes, display_name/QR/excludeCredentials clarifications — landed in reference.md at the same version.
• 1.0.0 — 2026-08-11. Baseline after TRU-85: idempotency_key required (UUID, backend-generated); full registration/verify body incl. clientExtensionResults; 404 No WebAuthn credentials found attributed to presence/options as the enrollment trigger.