SHA256

History

Paperclip 3a01cc651f approval-service: Phase-1 content-binding approval service (DEV-608) New services/approval-service with the Session → Preview → Confirm pipeline required by DEV-606/DEV-608: * POST /api/v1/sessions starts a Pocket-ID-bound approval session. * POST /api/v1/approvals/preview renders content server-side, computes H_content = sha256(canonical JSON), stores the (nonce, salt, canonical, challenge) tuple and returns the human verification digits plus the WebAuthn challenge = nonce \|\| H_content. * POST /api/v1/approvals/confirm verifies the WebAuthn assertion against the stored challenge, DSSE-signs the Approval statement via the signing-service (key_ref=trust-api/approval-signer-2026-q4), submits to the transparency-log, and returns {approval_id, attestation_ref, log_index}. TLog failures leave the row at attestation-pending for the reconciler. * db/trust/migrations/0004_approval_sessions.{up,down}.sql: new tables approval_sessions, approval_previews, approvals (schema matches the Phase 1 store contract). * internal/content: canonical JSON + H_content + 6-digit verification code (byte-compatible with signing-service/internal/canonical). * internal/webauthn: stdlib-only Phase-1 verifier; wire shape stays WebAuthn-compatible for the Phase-2 swap to go-webauthn/webauthn. * internal/signer, internal/tlog: HTTP clients mapping 5xx / connection errors to typed ErrSignerUnavailable / ErrTLogUnavailable so the HTTP layer can return 502 for signing failures and persist attestation-pending on TLog failure. * internal/service.Orchestrator ties the pipeline together and persists the Approval BEFORE the TLog submit (never return a log_index for an un-persisted approval). Tests cover: happy path, tampered H_content → 400, expired challenge → 403, signer 5xx + conn-refused → 502, TLog failure → row stays attestation-pending, duplicate confirm → 409, session expired → 403. go vet clean, go test ./... passes. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-25 19:42:06 +00:00
..
trust	approval-service: Phase-1 content-binding approval service (DEV-608)	2026-10-25 19:42:06 +00:00
README.md	db+ci: Agent Registry schema (agents + agent_keys), Phase-1 seed, migrate up/down CI (DEV-607)	2026-10-25 19:23:20 +00:00

Paperclip 3a01cc651f approval-service: Phase-1 content-binding approval service (DEV-608)

New services/approval-service with the Session → Preview → Confirm
pipeline required by DEV-606/DEV-608:

* POST /api/v1/sessions starts a Pocket-ID-bound approval session.
* POST /api/v1/approvals/preview renders content server-side, computes
  H_content = sha256(canonical JSON), stores the (nonce, salt, canonical,
  challenge) tuple and returns the human verification digits plus the
  WebAuthn challenge = nonce || H_content.
* POST /api/v1/approvals/confirm verifies the WebAuthn assertion against
  the stored challenge, DSSE-signs the Approval statement via the
  signing-service (key_ref=trust-api/approval-signer-2026-q4), submits
  to the transparency-log, and returns {approval_id, attestation_ref,
  log_index}. TLog failures leave the row at attestation-pending for
  the reconciler.

* db/trust/migrations/0004_approval_sessions.{up,down}.sql: new tables
  approval_sessions, approval_previews, approvals (schema matches the
  Phase 1 store contract).

* internal/content: canonical JSON + H_content + 6-digit verification
  code (byte-compatible with signing-service/internal/canonical).
* internal/webauthn: stdlib-only Phase-1 verifier; wire shape stays
  WebAuthn-compatible for the Phase-2 swap to go-webauthn/webauthn.
* internal/signer, internal/tlog: HTTP clients mapping 5xx / connection
  errors to typed ErrSignerUnavailable / ErrTLogUnavailable so the
  HTTP layer can return 502 for signing failures and persist
  attestation-pending on TLog failure.
* internal/service.Orchestrator ties the pipeline together and persists
  the Approval BEFORE the TLog submit (never return a log_index for
  an un-persisted approval).

Tests cover: happy path, tampered H_content → 400, expired challenge
→ 403, signer 5xx + conn-refused → 502, TLog failure → row stays
attestation-pending, duplicate confirm → 409, session expired → 403.
go vet clean, go test ./... passes.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

2026-10-25 19:42:06 +00:00

trust

approval-service: Phase-1 content-binding approval service (DEV-608)

2026-10-25 19:42:06 +00:00

README.md

db+ci: Agent Registry schema (agents + agent_keys), Phase-1 seed, migrate up/down CI (DEV-607)

2026-10-25 19:23:20 +00:00

README.md

ProofedMesh Database Layer

Alle Postgres-Schemas von ProofedMesh werden mit golang-migrate versioniert. Entscheidungsgrundlage: siehe ADR-0004.

Layout

db/
├── README.md              — diese Datei
├── trust/
│   ├── migrations/
│   │   ├── 0001_per_diem_rates.up.sql
│   │   ├── 0001_per_diem_rates.down.sql
│   │   ├── 0002_agents.up.sql
│   │   ├── 0002_agents.down.sql
│   │   ├── 0003_agent_keys.up.sql
│   │   └── 0003_agent_keys.down.sql
│   └── seeds/
│       └── 0001_phase1_agents.sql
└── expense/
    └── migrations/        — kommt im Phase-4-Rollout der DB-App

Seeds werden nicht von migrate versioniert — sie sind idempotentes Bootstrap-SQL für Phase-1-Fixturen (z.B. die drei Agent-Identitäten) und werden per psql -f oder äquivalentem Kubernetes-Job eingespielt. Jeder Seed MUSS ON CONFLICT … DO NOTHING / IF NOT EXISTS verwenden, damit mehrfaches Einspielen nach einem migrate down/up-Zyklus keine Duplikate produziert.

Jede logische Datenbank bekommt ein eigenes migrations/-Verzeichnis. Die Migrationstabelle (schema_migrations) wird je Datenbank separat gepflegt. Pro Postgres-Instanz können mehrere logische Schemas liegen — die Migrationen schreiben SQL mit CREATE SCHEMA IF NOT EXISTS und SET search_path.

Konventionen

Dateinamen: NNNN_description.up.sql + .down.sql (vierstellige Nummer, Snake-Case).
Nummerierung streng monoton. Fehlerhafte Migrationen werden nie umnummeriert — immer durch eine neue Migration korrigiert.
Immutable Business-Felder werden per BEFORE UPDATE-Trigger gesichert (siehe per_diem_rates).
Postgres-Extensions werden am Anfang der Migration eingezogen (CREATE EXTENSION IF NOT EXISTS …).
Jede up.sql MUSS ein down.sql haben; die down.sql DARF im Business-Fall unvollständig oder destruktiv sein, muss das dann aber im Kommentar sagen.

Lokal ausführen

Voraussetzung: eine lokale Postgres (z.B. docker run --rm -p 5432:5432 -e POSTGRES_PASSWORD=postgres postgres:16) und die migrate-CLI (brew install golang-migrate / apt install migrate / go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest).

# Up (alle noch nicht angewandten Migrationen)
migrate -path db/trust/migrations \
  -database "postgres://postgres:postgres@localhost:5432/trust?sslmode=disable" up

# Down um eine Version
migrate -path db/trust/migrations \
  -database "postgres://postgres:postgres@localhost:5432/trust?sslmode=disable" down 1

# Aktuelle Version anzeigen
migrate -path db/trust/migrations \
  -database "postgres://postgres:postgres@localhost:5432/trust?sslmode=disable" version

In Prod

Rollout als dedizierter Kubernetes-Job (job-migrate-trust) VOR dem Rolling-Update der trust-api-Pods. Siehe ADR-0004 → Ausführungsmodell.
Trust-API startet nur, wenn schema_migrations.dirty = false und die höchste Version die vom Code erwartete erreicht.
Rollback ist ein manueller Prozess mit CTO-Freigabe.

CI

Der Job db in .forgejo/workflows/validate.yml macht pro PR und main-Push:

Startet postgres:16-alpine als Container.
migrate up → prüft, dass per_diem_rates, agents und agent_keys angelegt sind.
migrate down 2 → prüft, dass agents und agent_keys wieder entfernt sind, per_diem_rates aber bleibt (Trenn-Test).
migrate up erneut und spielt db/trust/seeds/0001_phase1_agents.sql zweimal ein (Idempotenz-Test, Erwartung: genau 3 Seed-Zeilen).

Lint (sqlfluff / pg_format) ist noch nicht aktiviert — kommt in einem separaten Heartbeat.