peer-provider-templates

Peer provider capture templates

Turn an authenticated website request into a provider template that PeerAuth can capture safely and the attestation service can verify.

Protect the boundary

• Treat browser requests, responses, cookies, tokens, and customer data as sensitive. Never paste them into a public issue, skill, commit, or PR.
• Keep raw captures local and short-lived. Share only sanitized field shapes, selectors, and synthetic examples.
• Use browser/network access already authorized for this exact integration. Ask only if access to the required account or capture is not authorized.
• Never persist secrets in paramNames, metadata rows, logs, fixtures, or screenshots.

Use the current TEE model

A provider template is a capture and metadata contract. It tells PeerAuth which request to observe or replay and which non-secret values to expose. PeerAuth encrypts the authenticated session material; the attestation service owns the verification policy and signed result.

Do not add retired Reclaim-only fields to a new template:

• proofEngine
• skipRequestHeaders
• secretHeaders
• responseMatches
• responseRedactions
• additionalProofs

The public provider service removes these keys. If a legacy consumer still needs one, stop and identify that exact consumer before changing the template.

Read runtime-contract.md before changing a provider that spans PeerAuth, mobile, or the attestation service.

Workflow

1. Define the proof statement

Record:

• platform and region;
• flow: buyer payment, identity, or seller capture;
• stable actionType;
• exact values the verifier must establish;
• where each value appears in the website;
• affected provider, client catalog, and attestation transformer owners.

For payment verification, start with recipient identifier, amount, timestamp, settlement status, currency when applicable, and the intent-binding inputs. Prefer stable platform IDs over mutable display names or handles.