Verify a consent chain

A §6(10) chain is verifiable evidence. You can verify it inside the tenant, or hand the records to a third party who verifies them against the tenant's published key — no secret required.

Signing modes: the default signer is HMAC — fast, suitable for dev and single-node deployments, but symmetric (both sides share the key). For non-repudiable signing, enable AWS KMS by setting DPDP_SIGNER=kmsand pointing it at your KMS key ARN. In KMS mode the private key never leaves AWS; the corresponding public key is published in the tenant's JWKS so anyone can verify offline.

Verify the whole tenant chain

curl -X POST $API/v1/admin/verify-chain -H "authorization: Bearer sk_live_…"
# → { "valid": true, "records": 5021, "brokenAt": null }

Independent verification (offline, zero-PII, no trust in NoIdMe)

Fetch the tenant's public key set (JWKS), then verify a set of records. The verifier is neutral and stateless — it receives no PII, requires no secret, and produces the same result whether run against the NoIdMe endpoint or any third-party host. A regulator, auditor, or counterparty can verify independently:

curl $API/v1/verify/jwks/<tenantId>          # the published public key(s)
curl -X POST $API/v1/verify -d '{"records":[ ...records... ]}'
# → { "valid": true, "authenticityChecked": true, "keySource": "tenant-published", "kid": "…" }

What "valid" proves

• The records form an unbroken hash chain (no insert/edit/delete).
• The head signature matches the tenant's published key (authenticity), when in ECDSA/KMS mode. In HMAC mode the chain integrity is verified but the signature is not independently authenticatable by a third party without the shared secret.
• Tampering any field flips valid to false and reports brokenAt.
• The published JWKS (/v1/verify/jwks/<tenantId>) lets regulators, auditors, or counterparties verify offline — without trusting NoIdMe or holding any secret.