Skip to content
UIAF

Test Scenarios

Edition 3.1.1

This is a prose conformance catalog: payload shapes are validated by the fixture suite in CI; browser and storage behavior remains manually verifiable (browser devtools — Application tab for storage, Network tab for endpoint traffic) until an automated harness exists. No claim of an executable conformance suite is made, and no raw scenario count is accepted as coverage evidence — coverage is the generated traceability of every testable requirement to at least one scenario.

Storage names are governed solely by the storage-key registry; events are exactly session, conversion, and identify per the event registry.

Taxonomy

Section titled “Taxonomy”
CodeCategory
IDIdentity Lifecycle
ATTAttribution
CONConsent
BRWBrowser Landscape
XDCross-Device & Cross-Domain
CNVConversion Events
PREPre-Consent Signal Capture
DLVPayload & Delivery
DSRData Rights (control plane)
SECSecurity & Ingestion
POLPolicy Profiles (non-default)

Scenario IDs are UIAF-T-<CODE>-NNN, globally unique and stable after publication; retired IDs become tombstones and are never reused. Every active scenario names its conformance class(es) (Applies to: — Client, Server Integration, Endpoint) and the requirement IDs it verifies (Verifies:). Negative scenarios (Type: negative) prove a declared rejection or prohibition. A legacy cross-reference table at the end preserves citations of the pre-3.0 numbering.

Identity Lifecycle

Section titled “Identity Lifecycle”

UIAF-T-ID-001 — New visitor: server-minted UID with mandatory re-read

Section titled “UIAF-T-ID-001 — New visitor: server-minted UID with mandatory re-read”
  • Applies to: Client, Server Integration, Endpoint
  • Verifies: UIAF-04-AUX-001, UIAF-04-AUX-003, UIAF-02-COOKIE-002, UIAF-01-CONF-001
  • Type: positive
  • Given a first visit with no uiaf_uid cookie and resolved consent permitting persistent identity, when the winning coordinator calls POST /api/uiaf/cookie (create), then the server mints the UID and issues Set-Cookie; the client treats the response value as candidate-only, re-reads the browser-held cookie before any persistence write or send, and only the re-read value is adopted.

UIAF-T-ID-002 — No client path mints or injects a persistent UID

Section titled “UIAF-T-ID-002 — No client path mints or injects a persistent UID”
  • Applies to: Client, Server Integration, Endpoint
  • Verifies: UIAF-02-COOKIE-001, UIAF-09-ID-001, UIAF-04-AUX-001, UIAF-04-AUX-003, UIAF-01-CONF-002
  • Type: negative
  • Given any state (including endpoint unreachable), when client code attempts to write uiaf_uid via document.cookie/Cookie Store, or a request body carries a UID to the cookie route, then no client-side persistent UID exists on any path, the body-supplied UID is rejected with 400 and no cookie is set, and identity remains indeterminate or uid: null rather than a browser-minted value.

UIAF-T-ID-003 — Return visitor: valid divergent server cookie is authoritative

Section titled “UIAF-T-ID-003 — Return visitor: valid divergent server cookie is authoritative”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-04-AUX-001, UIAF-02-COOKIE-002
  • Type: positive
  • Given a valid uiaf_uid cookie that diverges from script-storage state, when identity resolves, then the browser-held valid cookie wins, the client adopts it and updates only its own script-storage mirror; no client-side convergence write touches the cookie.

UIAF-T-ID-004 — Issuance coordination stays inside its boundary

Section titled “UIAF-T-ID-004 — Issuance coordination stays inside its boundary”
  • Applies to: Client
  • Verifies: UIAF-02-ISSUE-001, UIAF-09-ID-003
  • Type: negative
  • Given Web Locks available, when UID issuance or recovery runs outside the uiaf-identity-issuance lock, re-reads state outside the boundary, or reuses the session-allocator lock uiaf-session-alloc:<session_id> for issuance, then the implementation is nonconforming; conforming behavior re-reads cookie, recovery state, and consent inside the boundary with only the winning coordinator calling the endpoint (best-effort wake-up path where Locks is unavailable, convergence eventual).

UIAF-T-ID-005 — Atomic pair write rolls back on failure

Section titled “UIAF-T-ID-005 — Atomic pair write rolls back on failure”
  • Applies to: Client
  • Verifies: UIAF-02-PAIR-001
  • Type: negative
  • Given script persistence of UID and uiaf_recovery in the selected storage classes, when either write fails (e.g. QuotaExceededError), then both roll back: a script-storage UID without its paired credential is never created or retained.

UIAF-T-ID-006 — Authorized recovery of a previously issued UID

Section titled “UIAF-T-ID-006 — Authorized recovery of a previously issued UID”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-04-AUX-002, UIAF-02-COOKIE-002
  • Type: positive
  • Given a cleared cookie but intact script storage holding the UID mirror and paired uiaf_recovery, with the base persistence predicate satisfied and continuity policy enabled, when recover is called with the credential only, then the server validates binding/expiry/rotation and re-issues the cookie; the client re-reads the browser-held cookie before persisting or sending.

UIAF-T-ID-007 — Recovery refused on credential failure

Section titled “UIAF-T-ID-007 — Recovery refused on credential failure”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-04-AUX-002
  • Type: negative
  • Given an expired, revoked, or rotated-out uiaf_recovery credential (or continuity policy disabled), when recover is attempted, then the server refuses, no identity is set, and the observable outcome is a denial — never a silent new identity under the old UID.

UIAF-T-ID-008 — Cloned tab: session ownership is never manufactured

Section titled “UIAF-T-ID-008 — Cloned tab: session ownership is never manufactured”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-09-SESS-001, UIAF-04-SESS-001
  • Type: negative
  • Given a duplicated tab sharing uiaf_session_state, when the clone cannot acquire the exclusive uiaf-session-alloc:<session_id> lock within the deadline (or a live competing owner exists), then it conservatively rekeys — overwriting only its cloned state with a fresh UUID-v4 and next_seq: 0 under the fresh lock — and never allocates sequence numbers on a session it does not own; a corrupt or oversize state also mints a new session.

UIAF-T-ID-009 — SPA route change continues the session

Section titled “UIAF-T-ID-009 — SPA route change continues the session”
  • Applies to: Client
  • Verifies: UIAF-04-SESS-001, UIAF-02-COOKIE-002
  • Type: positive
  • Given an authorized SPA session, when the route changes without a top-level navigation, then no re-initialization occurs, uiaf_session_state continues (strictly increasing sequence, no reuse), and authoritative reads still precede any send.

UIAF-T-ID-010 — Subdomain navigation with Domain-scoped cookie

Section titled “UIAF-T-ID-010 — Subdomain navigation with Domain-scoped cookie”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-04-AUX-001, UIAF-02-COOKIE-002
  • Type: positive
  • Given the identity cookie set with Domain on the registrable domain, when the user navigates between subdomains, then the same server-set UID is read everywhere; script-storage mirrors are per-subdomain and re-synced from the authoritative cookie, never the reverse.

UIAF-T-ID-011 — Ephemeral mode cannot claim the persistent-identity profile

Section titled “UIAF-T-ID-011 — Ephemeral mode cannot claim the persistent-identity profile”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-01-CONF-002, UIAF-01-CONF-001
  • Type: negative
  • Given a deployment without same-origin server or serverless participation, when it operates in explicitly nonpersistent ephemeral mode, then it must not claim persistent-identity-profile conformance; a claim without server participation is nonconforming.

UIAF-T-ID-012 — Identity group cross-constraints hold on every payload

Section titled “UIAF-T-ID-012 — Identity group cross-constraints hold on every payload”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-04-ID-001
  • Type: positive
  • Given any emitted payload, when its identity group is assembled, then a resolution_method of cookie, localstorage_recovery, or sessionstorage_recovery carries a non-null uid; ephemeral carries uid: null and confidence: "low"; is_new: true carries a non-null uid with resolution_method: "cookie"; uid: null carries is_new: false; and confidence is derived — high only for an authoritative cookie read, a fresh issuance, or a post-crosscheck credential-verified recovery, medium only for a credential-verified recovery adopted before the authoritative crosscheck, low for ephemeral or indeterminate resolution — and the shared reference validator rejects every other combination.

UIAF-T-ID-013 — Endpoint rejects incoherent identity combinations

Section titled “UIAF-T-ID-013 — Endpoint rejects incoherent identity combinations”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-04-ID-001
  • Type: negative
  • Given a payload whose identity object claims ephemeral with a non-null UID or non-low confidence, a cookie/recovery method with uid: null, is_new: true without a non-null UID and resolution_method: "cookie", uid: null with is_new: true, or a confidence value inconsistent with its resolution path, when the endpoint validates the body, then the shared reference validator rejects it before identity resolution, attribution processing, or downstream disclosure.

Attribution

Section titled “Attribution”

UIAF-T-ATT-001 — First campaign visit mints a touch

Section titled “UIAF-T-ATT-001 — First campaign visit mints a touch”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-03-TOUCH-001, UIAF-03-CAPTURE-001
  • Type: positive
  • Given resolved consent permitting attribution and a navigation carrying UTM parameters with a reliable external-navigation boundary, when capture runs, then a bounded touchpoint with the required scalar keys and a fresh UUID-v4 touch_id is stored; first_touch is set write-once and count reflects one accepted touch record.

UIAF-T-ATT-002 — Two campaigns, one session: boundary vs. window dedup

Section titled “UIAF-T-ATT-002 — Two campaigns, one session: boundary vs. window dedup”
  • Applies to: Client
  • Verifies: UIAF-03-TOUCH-001
  • Type: positive
  • Given an accepted touch, when a second arrival occurs, then with a reliable boundary a new touch is always accepted (new touch_id, even for identical normalized values), while without one the fingerprint/window fallback may honestly collapse two indistinguishable UTM-only arrivals inside the window; last_touch reflects the latest accepted touch and first_touch never changes.

UIAF-T-ATT-003 — Direct visit neither mints nor overwrites

Section titled “UIAF-T-ATT-003 — Direct visit neither mints nor overwrites”
  • Applies to: Client
  • Verifies: UIAF-03-TOUCH-001
  • Type: negative
  • Given stored attribution and a direct arrival (no allowlisted signal, no cross-site provenance, no trusted boundary metadata), when capture evaluates, then no touch is minted and last_touch/count are unchanged — a direct visit never overwrites campaign attribution.

UIAF-T-ATT-004 — Click-ID capture is permission-gated

Section titled “UIAF-T-ATT-004 — Click-ID capture is permission-gated”
  • Applies to: Client
  • Verifies: UIAF-03-CAPTURE-001, UIAF-02-CONSENT-001
  • Type: negative
  • Given effective ad_storage: denied with analytics allowed, when a navigation carries gclid, then the click ID is not captured into any store or payload while UTM campaign fields are; consent is re-read immediately before capture, not assumed from earlier state.

UIAF-T-ATT-005 — Expired click IDs: pruned live, frozen entries dropped whole

Section titled “UIAF-T-ATT-005 — Expired click IDs: pruned live, frozen entries dropped whole”
  • Applies to: Client
  • Verifies: UIAF-03-RETAIN-001, UIAF-04-RETRY-001
  • Type: negative
  • Given a stored click ID whose expires_at has passed, when stores are read and retries drain, then the expired value is removed from live stores and omitted only during pre-freeze assembly; a frozen retry body containing any expired occurrence is terminally dropped whole — never edited, redacted, or resent under the same event_id.

UIAF-T-ATT-006 — Non-allowlisted parameters are never captured

Section titled “UIAF-T-ATT-006 — Non-allowlisted parameters are never captured”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-08-MIN-001, UIAF-03-CAPTURE-001
  • Type: negative
  • Given a landing URL carrying unregistered query parameters (session tokens, search text, PII-shaped values), when capture runs, then only registered UTM keys, registered click-ID keys, and explicitly configured custom parameters within their bounds are read; everything else is ignored at the parse boundary.

UIAF-T-ATT-007 — Attribution lives in localStorage, never cookies

Section titled “UIAF-T-ATT-007 — Attribution lives in localStorage, never cookies”
  • Applies to: Client
  • Verifies: UIAF-08-MIN-004, UIAF-03-STORE-001
  • Type: negative
  • Given a conforming deployment, when storage is inspected, then uiaf_attribution exists only in localStorage (no attribution cookie of any name exists — a tested absence), and cookie headers carry identity only.

UIAF-T-ATT-008 — Storage loss mints rather than reconstructs

Section titled “UIAF-T-ATT-008 — Storage loss mints rather than reconstructs”
  • Applies to: Client
  • Verifies: UIAF-03-STORE-001, UIAF-03-TOUCH-001
  • Type: positive
  • Given cleared attribution storage, when the next attribution-carrying arrival is accepted, then a fresh touch (new touch_id) is minted; prior touch identifiers are never reconstructed from any secondary source.

UIAF-T-ATT-009 — Attribution completeness derives by four-way precedence

Section titled “UIAF-T-ATT-009 — Attribution completeness derives by four-way precedence”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-04-EP-001
  • Type: positive
  • Given a normalized payload with a present last_touch, when _meta.attribution_completeness is derived from the frozen body, then any non-empty click_ids object yields full; otherwise any non-null source, medium, campaign, term, or content yields utm_only; otherwise any non-null referrer or landing_url yields request_context_only; otherwise it yields none, and the endpoint accepts each correctly derived value.

UIAF-T-ATT-010 — Endpoint rejects a declared completeness mismatch

Section titled “UIAF-T-ATT-010 — Endpoint rejects a declared completeness mismatch”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-04-EP-001
  • Type: negative
  • Given a frozen payload whose actual last_touch content derives one of full, utm_only, request_context_only, or none, when _meta.attribution_completeness declares any other member of that four-value set, then the shared reference validator rejects it as attribution_completeness_incoherent before endpoint processing.
Section titled “Consent”

UIAF-T-CON-001 — Explicit T0 site policy

Section titled “UIAF-T-CON-001 — Explicit T0 site policy”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-07-CONSENT-005, UIAF-07-CONSENT-011
  • Type: positive
  • Given a deployment with an explicit no-consent-mechanism policy for its audited jurisdictional scope, when UIAF initializes, then lifecycle is not_applicable with source: site_policy, all four observed signals not_applicable, and effective permissions from the site policy; deploying a CMP later is a fresh initialization (T0 ↔ Tn transition).

UIAF-T-CON-002 — Full consent resolves to full capability

Section titled “UIAF-T-CON-002 — Full consent resolves to full capability”
  • Applies to: Client
  • Verifies: UIAF-07-CONSENT-011, UIAF-07-CONSENT-008
  • Type: positive
  • Given a CMP grant of all four signals, when the adapter delivers them, then lifecycle enters resolved, the effective vector allows persistent identity and ad capture, and the display tier is derived last from the effective vector.

UIAF-T-CON-003 — Tier is display-only, never a behavioral switch

Section titled “UIAF-T-CON-003 — Tier is display-only, never a behavioral switch”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-07-CONSENT-008, UIAF-09-CONSENT-001
  • Type: negative
  • Given any resolved state, when producer code branches on a stored tier number instead of the effective permission vector, then it is nonconforming: behavior keys off lifecycle/status and the four effective permissions; tier is derived shorthand for display.

UIAF-T-CON-004 — Analytics-only state strips ad members

Section titled “UIAF-T-CON-004 — Analytics-only state strips ad members”
  • Applies to: Client
  • Verifies: UIAF-07-CONSENT-012, UIAF-04-ATTR-001
  • Type: positive
  • Given analytics allowed with ad_storage: denied, when the transition applies, then click-ID members are stripped from uiaf_attribution while campaign fields persist, and subsequent payloads carry no click IDs.

UIAF-T-CON-005 — Downgrade purge matrix and queue predicate

Section titled “UIAF-T-CON-005 — Downgrade purge matrix and queue predicate”
  • Applies to: Client
  • Verifies: UIAF-07-CONSENT-012, UIAF-07-CONSENT-004, UIAF-08-PURGE-001, UIAF-09-ID-002
  • Type: negative
  • Given queued retries and stored identity, when any effective-permission decrease lands, then the purge matrix runs for exactly the loss class (never less), the queue predicate re-evaluates every entry synchronously before any transmission, and unsatisfied entries are purged/dropped — a downgrade never leaks a pre-downgrade payload.

UIAF-T-CON-006 — Dormant state: purge and silence

Section titled “UIAF-T-CON-006 — Dormant state: purge and silence”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-07-CONSENT-009, UIAF-08-PURGE-001
  • Type: negative
  • Given explicit rejection or enforced restriction, when the dormant state enters, then the uiaf_uid/uiaf_recovery pair, session state, and attribution are purged per the matrix and no data-plane request of any kind is made while dormant; re-consent leaves dormancy only through ordinary resolution.

UIAF-T-CON-007 — GPC in a binding jurisdiction

Section titled “UIAF-T-CON-007 — GPC in a binding jurisdiction”
  • Applies to: Server Integration, Client
  • Verifies: UIAF-07-CONSENT-001
  • Type: positive
  • Given Sec-GPC: 1 and a jurisdiction in the dated gpc_binding_jurisdictions configuration, when consent evaluates, then the GPC overlay denies ad_storage, ad_user_data, and ad_personalization before CMP state; analytics remains per CMP unless gpc_strict is configured.

UIAF-T-CON-008 — GPC is an overlay, never a source; accept-all does not override

Section titled “UIAF-T-CON-008 — GPC is an overlay, never a source; accept-all does not override”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-07-CONSENT-011, UIAF-07-CONSENT-001
  • Type: negative
  • Given a binding-jurisdiction GPC signal and a subsequent generic accept-all CMP click, when the effective vector derives, then the ad signals remain denied (the generic click does not override the signal), and consent.source never carries a GPC value — GPC is an independent overlay, not a source.

UIAF-T-CON-009 — Dirty projection: what triggers a session and what cannot

Section titled “UIAF-T-CON-009 — Dirty projection: what triggers a session and what cannot”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-07-CONSENT-013, UIAF-04-DIRTY-001, UIAF-09-BASE-001, UIAF-08-CONSENT-001
  • Type: negative
  • Given a stored uiaf_dirty_baseline, when only consent_record_id rotates, then projection bytes are identical and no session fires; when source or state_updated_at materially changes, projection bytes differ and an authorized session may fire. The baseline advances only on 2xx or durable enqueue; no raw CMP string appears anywhere — the opaque receipt reference points to the separately retained consent record, whose system of record remains the CMP.

UIAF-T-CON-010 — Consent transitions are serialized and re-read at every boundary

Section titled “UIAF-T-CON-010 — Consent transitions are serialized and re-read at every boundary”
  • Applies to: Client
  • Verifies: UIAF-09-WAKE-001, UIAF-07-CONSENT-007, UIAF-09-CONSENT-002, UIAF-02-CONSENT-001
  • Type: negative
  • Given a mid-session consent change while a payload is being assembled in another tab, when capture, persistence, queueing, drain, or send proceeds, then authoritative consent is re-read immediately before each of those boundaries (and on init, focus/visibility return, and pageshow persisted: true); transitions are serialized so no producer acts on a stale read, with cross-tab convergence via the consent wake-up channel.

UIAF-T-CON-011 — Reconcile-on-init runs first

Section titled “UIAF-T-CON-011 — Reconcile-on-init runs first”
  • Applies to: Client
  • Verifies: UIAF-07-CONSENT-003, UIAF-09-ID-004
  • Type: negative
  • Given stored state inconsistent with current authoritative consent (e.g. identity present after an offline withdrawal), when UIAF initializes, then reconcile-on-init executes before any pending/anonymous flow or send: stored state is purged or rebuilt to match the authoritative state before anything else observes it.

UIAF-T-CON-012 — GPC binding jurisdictions live in dated configuration only

Section titled “UIAF-T-CON-012 — GPC binding jurisdictions live in dated configuration only”
  • Applies to: Server Integration, Client
  • Verifies: UIAF-07-CONSENT-014
  • Type: negative
  • Given a deployment treating observed GPC as binding, when the jurisdiction set is maintained as prose or as a code constant, then it is nonconforming: the set exists only as dated site-policy configuration — a gpc_binding_jurisdictions record carrying the jurisdiction list and a last_reviewed date under quarterly review — and gpc.applicable derives from that current, dated configuration; the default overlay forces exactly the three ad-purpose permissions to denied and never alters analytics_storage by itself, the dated gpc_strict option extends the overlay to analytics_storage: denied, and neither key adds a wire field or alters the data-plane consent-object shape.

UIAF-T-CON-013 — state_updated_at follows the adapter contract

Section titled “UIAF-T-CON-013 — state_updated_at follows the adapter contract”
  • Applies to: Server Integration, Client
  • Verifies: UIAF-07-CONSENT-015
  • Type: negative
  • Given a consent-source adapter, when state_updated_at is derived from read, event, receipt, hydration, or serialization time — or invented fresh per read — then it is nonconforming: the value is the source record’s trustworthy last-material-change time (stable across unchanged rereads), or, where the source cannot supply one, the persisted first-observation freeze of the current record, replaced only when the record itself materially changes; an adapter that can do neither leaves the integration in lifecycle pending (reason unavailable), and a deployment never switches strategies silently between reads.

UIAF-T-CON-014 — Server-unreadable consent record fails closed without churn

Section titled “UIAF-T-CON-014 — Server-unreadable consent record fails closed without churn”
  • Applies to: Server Integration, Client
  • Verifies: UIAF-07-CONSENT-016
  • Type: negative
  • Given a consent record resolvable in the browser but unreadable to server middleware, when requests are processed, then the server fails closed — consent treated as unresolved for that request, deny-before-use, no persistent-identity issuance or refresh against the unobservable record — and the client, after a bounded deployment-configured set of attempts, treats the deployment as operating in the client-only degraded profile rather than retrying indefinitely; a permanent create/recovery churn loop against the fail-closed server is non-conforming.

UIAF-T-CON-015 — GCM-source deployments persist their own consent receipt

Section titled “UIAF-T-CON-015 — GCM-source deployments persist their own consent receipt”
  • Applies to: Server Integration
  • Verifies: UIAF-07-CONSENT-017
  • Type: negative
  • Given a deployment in a consent-required jurisdiction whose consent source is gcm (Google Consent Mode persists no consent choices), when it operates without its own Art 7(1)-adequate consent receipt — recorded signal values, the timestamp of the user’s choice, the UIAF/CMP-integration version, and request provenance, retained server-side and surfaced via the payload’s opaque consent_record_id — then it is non-conforming in those jurisdictions; the CMP-as-system-of-record deferral covers cmp_* sources only and never the GCM-only path.

UIAF-T-CON-016 — TCF→four-signal mapping fails closed on ambiguity

Section titled “UIAF-T-CON-016 — TCF→four-signal mapping fails closed on ambiguity”
  • Applies to: Server Integration, Client
  • Verifies: UIAF-07-CONSENT-018
  • Type: negative
  • Given a deployment sourcing consent from a TCF-capable CMP, when effective permissions derive, then a reviewed, dated TCF→four-signal mapping exists as configuration; each effective permission is allowed only where the corresponding TCF purposes/consents are affirmatively present in the consent record, and any ambiguity — unmapped purposes, legitimate-interest-only bases where consent is required, or conflicting purpose/vendor state — fails closed to denied; collapsing a TCF record into four binary signals without the reviewed mapping is nonconforming.

Browser Landscape

Section titled “Browser Landscape”

Spec 05 is intentionally requirement-free (dated browser evidence); these scenarios verify how the contract behaves under documented browser conditions.

UIAF-T-BRW-001 — Safari: server-set cookie resilience

Section titled “UIAF-T-BRW-001 — Safari: server-set cookie resilience”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-04-AUX-001, UIAF-02-COOKIE-002
  • Type: positive
  • Given Safari with a first-party-aligned server-set uiaf_uid, when the user returns after more than seven days without interaction, then the server-set cookie is still present under current documented behavior (no ITP-specific cap, no guarantee), is re-read authoritatively, and identity continues.

UIAF-T-BRW-002 — Safari: script-writable purge and the recovery path

Section titled “UIAF-T-BRW-002 — Safari: script-writable purge and the recovery path”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-02-COOKIE-001, UIAF-04-AUX-002
  • Type: negative
  • Given WebKit’s seven-day no-interaction purge of script-writable storage, when storage is purged, then the conforming client never compensates by writing the cookie via script; continuity, where policy permits, flows only through the server-verified recovery contract, and absent that the visit proceeds with uid: null or a fresh create.

UIAF-T-BRW-003 — Brave: expired cookie is absent; fresh create

Section titled “UIAF-T-BRW-003 — Brave: expired cookie is absent; fresh create”
  • Applies to: Client, Server Integration, Endpoint
  • Verifies: UIAF-04-AUX-003, UIAF-02-COOKIE-002
  • Type: positive
  • Given Brave’s six-month first-party-cookie cap, when the capped cookie expires and the user returns, then the absent/malformed cookie is treated exactly as expired: a fresh create mints a new UID under the base predicate (no refresh of a still-valid cookie ever occurs on this route).

UIAF-T-BRW-004 — Cleared site data: mint, never reconstruct

Section titled “UIAF-T-BRW-004 — Cleared site data: mint, never reconstruct”
  • Applies to: Client
  • Verifies: UIAF-09-ID-001, UIAF-03-STORE-001
  • Type: negative
  • Given the user clears all site data, when the next visit occurs, then a new identity is minted server-side and new touches are minted on acceptance; nothing reconstructs the previous UID or touch identifiers from any residue.

UIAF-T-BRW-005 — Extension blocking and the relay path

Section titled “UIAF-T-BRW-005 — Extension blocking and the relay path”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-08-TRUST-002
  • Type: positive
  • Given a content blocker with generic path rules active, when delivery uses the same-origin relay on a non-tracker-shaped path, then server-side forwarding to the endpoint proceeds outside the extension’s reach; client-side requests remain subject to blocking and their loss is honest loss.

UIAF-T-BRW-006 — Cookie attribute misconfiguration is nonconforming

Section titled “UIAF-T-BRW-006 — Cookie attribute misconfiguration is nonconforming”
  • Applies to: Server Integration
  • Verifies: UIAF-08-COOKIE-001
  • Type: negative
  • Given a deployment issuing uiaf_uid, when the cookie lacks Secure, or uses a SameSite value the contract forbids for this cookie, then the deployment is nonconforming; conforming attributes follow the registry entry exactly.

UIAF-T-BRW-010 — Retired (tombstone)

Section titled “UIAF-T-BRW-010 — Retired (tombstone)”

Legacy “Browser update changes tracking rules” retired 2026-07-19: browser-behavior change management is handled by the dated evidence ledgers and release-gate re-verification, not by a test scenario. ID never reused.

Cross-Device & Cross-Domain

Section titled “Cross-Device & Cross-Domain”

UIAF-T-XD-001 — Authenticated logins link across devices

Section titled “UIAF-T-XD-001 — Authenticated logins link across devices”
  • Applies to: Client, Server Integration, Endpoint
  • Verifies: UIAF-06-EVID-001, UIAF-08-HASH-003
  • Type: positive
  • Given the same user authenticates on two devices, when each device emits identify with typed, profile-normalized (versioned normalization_profile), hashed evidence and verification metadata, then the endpoint associates the two UIDs deterministically under tenant binding; identical digests in different tenants never associate, and repeated identical evidence never inflates confidence.

UIAF-T-XD-002 — Unverified input is never identify evidence

Section titled “UIAF-T-XD-002 — Unverified input is never identify evidence”
  • Applies to: Client
  • Verifies: UIAF-06-EVID-002, UIAF-06-EVID-001
  • Type: negative
  • Given a newsletter, contact, or lead form submission without authenticated/verified state, when producers assemble events, then no identify is emitted from that input: evidence requires a closed verification object with an accepted state and method.

UIAF-T-XD-003 — Malformed evidence is rejected

Section titled “UIAF-T-XD-003 — Malformed evidence is rejected”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-08-HASH-001, UIAF-08-HASH-002, UIAF-06-EVID-003
  • Type: negative
  • Given candidate identifiers, when input is empty, un-normalized, raw (unhashed), carries key_version with sha256, or omits it with hmac_sha256, then the producer rejects before freeze and the endpoint rejects before processing: empty input yields null (never a hash), raw identifiers never enter any payload, and digest/algorithm/profile fields must satisfy the closed schema.

UIAF-T-XD-004 — Cross-domain handoff happy path

Section titled “UIAF-T-XD-004 — Cross-domain handoff happy path”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-04-AUX-004, UIAF-04-AUX-005, UIAF-06-HANDOFF-001
  • Type: positive
  • Given an allowlisted clean target, when the same-origin form POST /api/uiaf/handoff mints a single-use bounded token and the target server redeems it server-to-server before render, then the browser lands on a clean URL (303 before render), the UID aliases idempotently where policy permits, and no token appears in logs, scripts, or rendered pages.

UIAF-T-XD-005 — Handoff failure branches never leak or mint

Section titled “UIAF-T-XD-005 — Handoff failure branches never leak or mint”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-04-AUX-004, UIAF-04-AUX-005, UIAF-06-HANDOFF-001
  • Type: negative
  • Given an expired, replayed, or unknown token (shared non-enumerating 410), wrong tenant/audience/purpose (403), malformed input (400), or redemption/storage failure (503), when the target handles the failure, then it proceeds as an ordinary first-party visit — no unconditional UID mint, no client-render or replaceState fallback, no raw-token retention, and a valid existing target cookie is never overwritten.

UIAF-T-XD-006 — Client-side hashing is a constrained last resort

Section titled “UIAF-T-XD-006 — Client-side hashing is a constrained last resort”
  • Applies to: Client
  • Verifies: UIAF-08-HASH-004, UIAF-08-HASH-001
  • Type: negative
  • Given a pure-SPA architecture with no server hashing surface, when browser-side SHA-256 preprocessing is used, then it operates only under the documented last-resort constraints — normalized bounded input, no raw identifier ever stored or transmitted, no keyed customer digests in the browser (the browser never holds the key).

Conversion Events

Section titled “Conversion Events”

UIAF-T-CNV-001 — Purchase conversion under full consent

Section titled “UIAF-T-CNV-001 — Purchase conversion under full consent”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-04-EP-001, UIAF-08-RET-002
  • Type: positive
  • Given resolved full consent, when application code fires conversion with a valid snake-case conversion_name and a conversion_id key (value string-or-null), then the frozen payload validates against the schema and the shared reference validator and is accepted exactly once downstream.

UIAF-T-CNV-002 — Identifier-shaped conversion_id is rejected at all three points

Section titled “UIAF-T-CNV-002 — Identifier-shaped conversion_id is rejected at all three points”
  • Applies to: Client, Server Integration, Endpoint
  • Verifies: UIAF-04-EP-001
  • Type: negative
  • Given a pattern-valid visible-ASCII conversion_id that is email- or identifier-shaped, when validation runs, then the prohibited-content rules reject it at the producer pre-freeze, at the endpoint pre-processing, and in the shared reference validator — the pattern is a portability boundary, prohibited-content is the privacy boundary.

UIAF-T-CNV-003 — Conversion under denied/dormant state does not send

Section titled “UIAF-T-CNV-003 — Conversion under denied/dormant state does not send”
  • Applies to: Client
  • Verifies: UIAF-07-CONSENT-009, UIAF-09-CONSENT-001
  • Type: negative
  • Given the dormant (all-denied) state, when application code fires a conversion, then no data-plane request is made — there is no minimal or reduced conversion payload; producers branch on the effective vector and the event’s own authorization, and the outcome is honest loss.
Section titled “Pre-Consent Signal Capture”

UIAF-T-PRE-001 — Pending context: vocabulary-gated three keys in memory only

Section titled “UIAF-T-PRE-001 — Pending context: vocabulary-gated three keys in memory only”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-09-CTX-001, UIAF-07-CONSENT-002, UIAF-03-PEND-001
  • Type: positive
  • Given lifecycle pending and a server-injected request context, when the closed {utm_source, utm_medium, utm_campaign} object is evaluated, then each member is admitted only on an exact match against the controller-configured vocabulary after the frozen normalization pipeline, the result lives in current-document memory only, and navigation loss is expected behavior.

UIAF-T-PRE-002 — Pending state fails closed on every surface

Section titled “UIAF-T-PRE-002 — Pending state fails closed on every surface”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-03-PEND-001, UIAF-07-CONSENT-006, UIAF-07-CONSENT-002, UIAF-09-CTX-001, UIAF-07-CONSENT-010
  • Type: negative
  • Given lifecycle pending, when any code path attempts a UIAF cookie/localStorage/sessionStorage write (encryption does not exempt), a data-plane request, retention of an excluded surface (utm_term, utm_content, referrer, landing URL, click IDs, identifiers, timestamps), a vocabulary miss, an over-bound member, or a leakage sink (durable caches, service workers, hydration state, third-party-readable globals, logs), then each fails closed: member null, whole-context null, or no action — never truncation, never a partial context, never a send.

UIAF-T-PRE-003 — Post-resolution mapping is minimal

Section titled “UIAF-T-PRE-003 — Post-resolution mapping is minimal”
  • Applies to: Client
  • Verifies: UIAF-07-CONSENT-002, UIAF-03-PEND-001
  • Type: negative
  • Given consent resolves affirmatively with a pending context alive in the current document, when an independently authorized touchpoint is created, then it receives only the admitted source/medium/campaign mappings; term, content, referrer, landing, click IDs, and custom fields are never reconstructed from the pending phase.

UIAF-T-PRE-004 — CMP absent, late, or blocked: stay pending, stay silent

Section titled “UIAF-T-PRE-004 — CMP absent, late, or blocked: stay pending, stay silent”
  • Applies to: Client
  • Verifies: UIAF-07-CONSENT-011, UIAF-03-PEND-001
  • Type: negative
  • Given a CMP expected but blocked by an extension or loading late, when UIAF initializes, then lifecycle stays pending (internal reason recorded, all effective permissions denied, silent) with zero data-plane requests; not_applicable arises only under the explicit T0 policy, never from mechanism absence alone.

UIAF-T-PRE-005 — Pending context never survives pagehide or a BFCache restore

Section titled “UIAF-T-PRE-005 — Pending context never survives pagehide or a BFCache restore”
  • Applies to: Client
  • Verifies: UIAF-03-PEND-002
  • Type: negative
  • Given a pending-consent context held in current-document memory, when the page fires pagehide or a pageshow with persisted === true restores a BFCache snapshot, then the context is dropped so no snapshot can carry it, and nothing held from before the restore is used until authoritative consent has been re-evaluated; no-store is never treated as a memory-lifecycle control, and no conformance path relies on unload listeners.

Payload & Delivery

Section titled “Payload & Delivery”

UIAF-T-DLV-001 — Freeze once, retry byte-identically

Section titled “UIAF-T-DLV-001 — Freeze once, retry byte-identically”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-09-DLV-001, UIAF-04-DIRTY-001
  • Type: positive
  • Given an authorized event, when the body is frozen (UTF-8 RFC 8785) and a retry occurs, then the retry resends the identical frozen bytes under the same immutable event_id, and the dirty baseline advances only on 2xx or durable enqueue; when that durably enqueued entry later drops terminally (TTL, capability loss, stale click bytes), then the baseline it advanced is purged, forcing re-evaluation against an absent baseline so still-current state is re-emitted rather than silently treated as delivered.

UIAF-T-DLV-002 — Endpoint dedup and conflict rejection

Section titled “UIAF-T-DLV-002 — Endpoint dedup and conflict rejection”
  • Applies to: Endpoint
  • Verifies: UIAF-04-EP-003, UIAF-04-EP-001, UIAF-08-RET-002
  • Type: negative
  • Given an accepted event_id, when the same event_id arrives again with a different canonical body, then it is rejected; identical retries deduplicate within the ≥72-hour dedup window, ordering follows (session_id, session_seq) with receipt-time tiebreak, and raw-body validation precedes all processing.

UIAF-T-DLV-003 — Terminal failures are terminal; 429 is the bounded carve-out

Section titled “UIAF-T-DLV-003 — Terminal failures are terminal; 429 is the bounded carve-out”
  • Applies to: Client
  • Verifies: UIAF-04-EP-002
  • Type: negative
  • Given a delivery attempt, when the response is a 429, then the attempt is retryable: the byte-identical frozen body is resent under the same event_id, honoring a Retry-After hint only when it parses as non-negative delta-seconds or a future HTTP-date within the bounded 3,600-second ceiling — an absent, malformed, or excessive hint falls back to the standard bounded backoff. When the response is any other 4xx, or an unexpected final 3xx, then the entry is terminal (observe/drop; the 3xx is a configuration/protocol failure) — never retried and never treated as success; only network failure, 5xx, and the bounded 429 carve-out are retryable.

UIAF-T-DLV-004 — Permission-lapsed retry entries drop whole

Section titled “UIAF-T-DLV-004 — Permission-lapsed retry entries drop whole”
  • Applies to: Client
  • Verifies: UIAF-04-RETRY-001, UIAF-07-CONSENT-004, UIAF-03-RETAIN-001
  • Type: negative
  • Given queued entries with immutable required_permissions/purpose/destinations, when permissions no longer satisfy an entry (downgrade, expiry), then the entry is dropped whole — never redacted, rerouted, or resent under the same event_id; a sanitized emission is an independently authorized new logical event.

UIAF-T-DLV-005 — Unload beacon: queue acceptance is not acknowledgement

Section titled “UIAF-T-DLV-005 — Unload beacon: queue acceptance is not acknowledgement”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-04-EP-005, UIAF-04-EP-006
  • Type: positive
  • Given an unload-path send, when sendBeacon returns true, then that is user-agent queue acceptance only — the dirty baseline does not advance on it unless the entry was durably enqueued under a purpose that permits that storage; cross-origin JSON beacons require the endpoint’s explicit preflight handling or a safelisted body via content negotiation.

UIAF-T-DLV-006 — Unload without durable permission is honest loss

Section titled “UIAF-T-DLV-006 — Unload without durable permission is honest loss”
  • Applies to: Client
  • Verifies: UIAF-04-EP-006, UIAF-04-EP-005
  • Type: negative
  • Given an unload-path event whose purpose does not permit durable queueing, when the beacon is not acknowledged, then the event is honestly lost — it is neither persisted for later retry nor counted as delivered, and no success signal is fabricated.

UIAF-T-DLV-007 — One delivery owner per automatic session

Section titled “UIAF-T-DLV-007 — One delivery owner per automatic session”
  • Applies to: Server Integration, Client
  • Verifies: UIAF-09-OWN-001, UIAF-09-BASE-001, UIAF-04-DIRTY-001
  • Type: negative
  • Given both server and client capable of emitting the automatic session, when a server emits without holding delivery ownership and the byte-identical baseline representation, then it is nonconforming: exactly one owner computes the canonical JCS projection against uiaf_dirty_baseline, and uncoordinated producers must not emit automatic sessions.

UIAF-T-DLV-008 — Queue entry shape is closed and byte-exact

Section titled “UIAF-T-DLV-008 — Queue entry shape is closed and byte-exact”
  • Applies to: Client
  • Verifies: UIAF-04-RETRY-002
  • Type: positive
  • Given a durably enqueued event, when its uiaf_retry_queue entry is written and later drained, then the entry is exactly { payload, enqueued_at, attempts, next_attempt_at, bytes, required_permissions, purpose, destinations } with no additional members; payload is a JSON string whose UTF-8 encoding is byte-identical to the frozen RFC 8785 body (recovery is exactly UTF-8 encoding, never re-serialization); enqueued_at/next_attempt_at are integer Unix seconds in range and attempts an integer in range; and required_permissions/purpose/destinations reference the consent contract’s permission names and the deployment’s configured vocabularies — a malformed entry is dropped individually and a whole-map parse failure treats the queue as absent, each with one bounded diagnostic.

UIAF-T-DLV-009 — One-shot trigger lifecycle stays in-document

Section titled “UIAF-T-DLV-009 — One-shot trigger lifecycle stays in-document”
  • Applies to: Client
  • Verifies: UIAF-04-TRIG-001
  • Type: positive
  • Given a current-document create/recovery trigger, when its delivery attempt fails without durable enqueue, then it returns to pending under the bounded in-document retry schedule (at most 3 further attempts, bounded backoff with jitter); a consent downgrade that de-authorizes the event moves it to terminal and cancels scheduled work; navigation or document destruction moves an unconsumed trigger to expired with no cross-document replay; and exhausting the schedule without a 2xx or durable enqueue abandons the trigger as honest loss.

UIAF-T-DLV-010 — Session reasons derive exactly, in registry order

Section titled “UIAF-T-DLV-010 — Session reasons derive exactly, in registry order”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-04-REASON-001
  • Type: positive
  • Given a session payload, when event_data.reasons is assembled, then it contains session_open iff identity.session_start is true, identity_created iff identity.is_new is true, identity_recovered iff identity.resolution_method is localstorage_recovery or sessionstorage_recovery, attribution_touch iff attribution.is_new_touch is true, and consent_change iff the consent component of the dirty projection differs from the supplied baseline where that comparison is available; multiple values appear in registry order, while a projection-only identity transition with none of those conditions uses the empty array, and the shared reference validator rejects an incoherent set.

UIAF-T-DLV-011 — Malformed session reason sets are rejected

Section titled “UIAF-T-DLV-011 — Malformed session reason sets are rejected”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-04-REASON-001
  • Type: negative
  • Given either a projection-only identity transition for which all five registered reason conditions are false or a session for which several conditions are true, when event_data.reasons is assembled, then the projection-only case accepts exactly the empty array, while a fabricated or unknown value, a value whose condition is false, an omitted value whose condition is true, or multiple true values outside registry order is rejected by the shared reference validator.

Data Rights (control plane)

Section titled “Data Rights (control plane)”

UIAF-T-DSR-001 — A UID never authenticates a data-subject request

Section titled “UIAF-T-DSR-001 — A UID never authenticates a data-subject request”
  • Applies to: Server Integration, Endpoint
  • Verifies: UIAF-08-DSR-001, UIAF-04-AUX-007
  • Type: negative
  • Given an erasure/access/portability request presenting only a uiaf_uid, a derived hash, or a uiaf_recovery credential, when the deployment processes it, then the request is refused pending authenticated verification through the deployment’s own account/identity channel — none of those values proves account ownership.

UIAF-T-DSR-002 — Verified erasure cascades

Section titled “UIAF-T-DSR-002 — Verified erasure cascades”
  • Applies to: Client, Server Integration, Endpoint
  • Verifies: UIAF-08-DSR-002, UIAF-08-DSR-003
  • Type: positive
  • Given an authenticated, verified erasure, when it executes, then the browser clears every UIAF store atomically and the backend drives the privileged downstream cascade across the deployment’s stores with asynchronous status reporting.

UIAF-T-DSR-003 — Deletion is not future opt-out

Section titled “UIAF-T-DSR-003 — Deletion is not future opt-out”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-08-DSR-004
  • Type: negative
  • Given completed erasure, when the same person visits again under permitting consent, then a new identity may be minted — erasure removed history and did not create a persistent suppression marker; future processing is governed by consent state alone (there is no uiaf_optout, a tested absence).

UIAF-T-DSR-004 — Revocation call contract

Section titled “UIAF-T-DSR-004 — Revocation call contract”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-04-AUX-006, UIAF-08-REVOKE-001, UIAF-09-CTRL-001
  • Type: negative
  • Given browser-initiated revocation, when the call is made, then it is same-origin, CSRF-protected, idempotent, non-enumerating, and control-plane tombstone-only — it writes no persistent browser marker, is never queued for retry, is not itself an erasure, and the local purge plus dormant transition proceed on their own predicates even if the network call fails.

UIAF-T-DSR-005 — Purge scope matches the loss class exactly

Section titled “UIAF-T-DSR-005 — Purge scope matches the loss class exactly”
  • Applies to: Client
  • Verifies: UIAF-09-ID-002, UIAF-08-PURGE-001, UIAF-08-PURGE-002
  • Type: negative
  • Given any loss event (ad-signal loss, analytics loss, revocation, erasure, dormant), when purge runs, then the scope matches the loss class for every applicable storage mechanism — never less (leaving prohibited data) and never silently more (destroying independently permitted state) — including the legacy purge-only keys per the storage registry.

UIAF-T-DSR-006 — Revocation route carries a closed suppression body

Section titled “UIAF-T-DSR-006 — Revocation route carries a closed suppression body”
  • Applies to: Server Integration, Endpoint
  • Verifies: UIAF-08-REVOKE-002
  • Type: negative
  • Given the dedicated same-origin revocation route (POST /api/uiaf/revoke), when a request arrives, then the body is strict JSON carrying the previous UID and nothing else — any additional field fails validation; where both the body and the inbound uiaf_uid cookie carry a UID, the body value is authoritative for the tombstone; a 2xx means the tombstone was accepted (recorded or already present), a 4xx applies no tombstone effect and never distinguishes an unknown from a known UID; repeat delivery is idempotent and duplicates are accepted without error while the client remains one-shot; and local purge proceeds regardless of the response.

UIAF-T-DSR-007 — Revoked UIDs are suppressed at the endpoint

Section titled “UIAF-T-DSR-007 — Revoked UIDs are suppressed at the endpoint”
  • Applies to: Endpoint
  • Verifies: UIAF-08-REVOKE-003
  • Type: positive
  • Given a recorded revocation tombstone for a UID, when a data-plane event carrying that UID arrives — a buggy or malicious client can keep sending under cached state — then the endpoint suppresses it without effect: no identity resolution, no attribution write, no downstream disclosure; client-side silence after revocation is a client obligation, necessary but not sufficient, so suppression is endpoint-enforced, not only client-promised.

Security & Ingestion

Section titled “Security & Ingestion”

UIAF-T-SEC-001 — The browser holds no secrets

Section titled “UIAF-T-SEC-001 — The browser holds no secrets”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-08-TRUST-001, UIAF-04-EP-004
  • Type: negative
  • Given any conforming deployment, when browser code or its requests are inspected, then no ingest shared secret or privileged credential exists in the browser, and SameSite, Path, CORS, or first-party naming are never described or relied on as authentication or isolation.

UIAF-T-SEC-002 — Relay derives provenance

Section titled “UIAF-T-SEC-002 — Relay derives provenance”
  • Applies to: Server Integration, Endpoint
  • Verifies: UIAF-08-TRUST-002, UIAF-04-EP-004
  • Type: positive
  • Given the recommended same-origin relay, when a browser submission passes through, then the relay applies validation, origin policy, and rate limits, forces _meta.emitter to client, and holds the downstream authentication; only an authenticated server-to-server channel ever asserts emitter: "server".

UIAF-T-SEC-003 — Forged public ingest has zero privileged effect

Section titled “UIAF-T-SEC-003 — Forged public ingest has zero privileged effect”
  • Applies to: Endpoint
  • Verifies: UIAF-08-TRUST-003, UIAF-04-EP-004, UIAF-04-EP-001
  • Type: negative
  • Given a public direct-ingest endpoint, when an attacker submits schema-valid forged payloads, then they are treated as untrusted data subject to bounds, quotas, and abuse monitoring with zero privileged or control-plane effects — the endpoint never claims forgery rejection for provenance-unknown traffic generally, but an affirmative _meta.emitter: server assertion on this unauthenticated ingress is hard-rejected with a 4xx, never marked untrusted and admitted; invalid bodies are rejected by raw-body validation.

UIAF-T-SEC-004 — Control-plane operations use control routes

Section titled “UIAF-T-SEC-004 — Control-plane operations use control routes”
  • Applies to: Server Integration, Endpoint
  • Verifies: UIAF-08-TRUST-004, UIAF-04-AUX-007
  • Type: negative
  • Given revocation/erasure/access needs, when an implementation attempts them through the data-plane schema or ingest route, then it is nonconforming — control-plane operations run on dedicated control routes with their own authentication and contracts, and no payload event expresses them.

UIAF-T-SEC-005 — Cookie route request-evidence battery

Section titled “UIAF-T-SEC-005 — Cookie route request-evidence battery”
  • Applies to: Server Integration, Endpoint
  • Verifies: UIAF-04-AUX-003, UIAF-08-TLS-003
  • Type: negative
  • Given POST /api/uiaf/cookie, when requests arrive with Sec-Fetch-Site: cross-site, a missing/invalid Origin, a non-JSON content type, or excessive rate, then each is rejected per the route contract (valid Origin with absent Sec-Fetch-Site is accepted); any direct-ingest CORS configuration allowlists explicit origins, never *.

UIAF-T-SEC-006 — Cookie attributes follow the registry

Section titled “UIAF-T-SEC-006 — Cookie attributes follow the registry”
  • Applies to: Server Integration
  • Verifies: UIAF-08-COOKIE-001
  • Type: negative
  • Given issued UIAF cookies, when attributes are audited, then Secure is always set and the SameSite discipline of the registry entry holds; violations are nonconforming regardless of environment.

UIAF-T-SEC-007 — Logs never carry raw identifiers or tokens

Section titled “UIAF-T-SEC-007 — Logs never carry raw identifiers or tokens”
  • Applies to: Server Integration, Endpoint
  • Verifies: UIAF-08-LOG-001, UIAF-08-LOG-003, UIAF-04-AUX-005
  • Type: negative
  • Given access and application logging across all routes, when logs are inspected, then raw PII, raw UIDs, recovery credentials, and handoff tokens are absent (the token suppressed from redirect logs too); redaction applies at the earliest controllable boundary.

UIAF-T-SEC-008 — Transport policy is explicit

Section titled “UIAF-T-SEC-008 — Transport policy is explicit”
  • Applies to: Server Integration, Endpoint
  • Verifies: UIAF-08-TLS-001, UIAF-08-LOG-002
  • Type: positive
  • Given website↔endpoint exchanges, when transport is configured, then HTTPS (TLS 1.2+) is universal and transport-layer IP handling is configured with stated retention and purpose — IP-at-transport is acknowledged, never smuggled into the payload.

UIAF-T-SEC-009 — Payload minimization boundaries

Section titled “UIAF-T-SEC-009 — Payload minimization boundaries”
  • Applies to: Client, Endpoint
  • Verifies: UIAF-08-MIN-002, UIAF-08-MIN-003, UIAF-08-LOG-004
  • Type: negative
  • Given payload assembly, when a body would contain an IP address, then it fails validation — the payload never carries IP; page paths follow the sanitization guidance, and classification labels remain metadata that never substitute for enforcement.

UIAF-T-SEC-010 — Injected context is escaped; validator initializes first

Section titled “UIAF-T-SEC-010 — Injected context is escaped; validator initializes first”
  • Applies to: Server Integration, Client
  • Verifies: UIAF-01-CODE-001, UIAF-08-TLS-002, UIAF-04-INIT-001
  • Type: negative
  • Given server-rendered pages injecting UIAF context, when the injected value is serialized into HTML or a script block without exact output-context escaping, then it is an XSS sink and nonconforming; conforming deployments escape per context and initialize the shared reference validator and producer runtime before any untrusted page code executes.

UIAF-T-SEC-011 — First hop rejects over-length requests before buffering

Section titled “UIAF-T-SEC-011 — First hop rejects over-length requests before buffering”
  • Applies to: Server Integration, Endpoint
  • Verifies: UIAF-04-EP-007
  • Type: negative
  • Given the first hop (same-origin relay or public ingest) enforcing a hard Content-Length ceiling — 40,960 bytes recommended — when a request exceeds it, then the request is rejected with 413 before the body is buffered or parsed; the 32,768-byte body ceiling and the sub-object caps are post-parse ceilings on the canonical (JCS) form and are no substitute for this guard.

UIAF-T-SEC-012 — Cookie route closed shapes and exhaustive status map

Section titled “UIAF-T-SEC-012 — Cookie route closed shapes and exhaustive status map”
  • Applies to: Server Integration, Endpoint
  • Verifies: UIAF-04-AUX-008
  • Type: negative
  • Given POST /api/uiaf/cookie, when a request body is anything other than exactly {} (create) or { "uiaf_recovery": "<credential>" } (recover) — an additional member, a duplicate member, or any body UID — then it fails validation (any body UID is 400); every denial is the non-enumerating 403 with exactly {"error": "denied"}; a 200 carries exactly {uid, recovery} — issuance with Set-Cookie and non-null recovery (a rotated credential supersedes its predecessor, refused thereafter), no-set with both null and no Set-Cookie; the only statuses are 200/400/403/429/5xx; and the response uid is candidate-only until the mandatory post-response cookie re-read.

UIAF-T-SEC-013 — emitter: server on unauthenticated ingress is hard-rejected

Section titled “UIAF-T-SEC-013 — emitter: server on unauthenticated ingress is hard-rejected”
  • Applies to: Endpoint, Server Integration
  • Verifies: UIAF-08-TRUST-005
  • Type: negative
  • Given a payload asserting _meta.emitter: server arriving on unauthenticated ingress — direct public ingest, or a relay hop that has not authenticated its sender — when the endpoint evaluates it, then it is hard-rejected with a 4xx, never marked untrusted and processed, and the rejection does not enumerate accepted UIDs; the mark-untrusted-and-proceed handling applies to provenance-unknown traffic generally, while an affirmative server assertion from an unauthenticated source is a known forgery class, and the relay forcing browser-originated _meta.emitter to client keeps legitimate relayed traffic out of this rejection path.

UIAF-T-SEC-014 — Pre-parse size ceiling is earlier than the canonical-body cap

Section titled “UIAF-T-SEC-014 — Pre-parse size ceiling is earlier than the canonical-body cap”
  • Applies to: Server Integration, Endpoint
  • Verifies: UIAF-08-TRUST-006
  • Type: negative
  • Given the first hop receiving a UIAF request body — the same-origin relay, or the endpoint on direct ingest — when a body’s Content-Length exceeds the hard ceiling (at or below 40 KiB recommended), then it is rejected with 413 Payload Too Large before buffering or parsing: the ceiling guards the parser, so it cannot itself depend on parsing, and it is a separate, earlier control than the 32 KiB post-JCS canonical-body cap — a non-canonical body under the raw ceiling can still exceed the post-parse cap and fails closed there.

UIAF-T-SEC-015 — Receipt of an event never authorizes downstream privileged effects

Section titled “UIAF-T-SEC-015 — Receipt of an event never authorizes downstream privileged effects”
  • Applies to: Endpoint
  • Verifies: UIAF-08-RET-003
  • Type: negative
  • Given a downstream system receiving a schema-valid data-plane event, when matching, audience admission, or any control-plane consequence would follow, then those privileged effects follow the downstream system’s own consent ledger and authentication — never the mere arrival of the payload.

Policy Profiles (non-default)

Section titled “Policy Profiles (non-default)”

UIAF-T-POL-001 — Restricted measurement is opt-in and self-documented

Section titled “UIAF-T-POL-001 — Restricted measurement is opt-in and self-documented”
  • Applies to: Server Integration, Endpoint
  • Verifies: UIAF-08-RET-001, UIAF-01-CONF-001
  • Type: positive
  • Given a deployment enabling the restricted-measurement profile, when it operates, then the profile is explicitly non-default, separately configured, and carries its own documented lawful basis, minimization, aggregation, retention, and conformance rules per the controller’s documentation duties.

UIAF-T-POL-002 — The default core never pre-resolution-transmits

Section titled “UIAF-T-POL-002 — The default core never pre-resolution-transmits”
  • Applies to: Client, Server Integration
  • Verifies: UIAF-03-PEND-001, UIAF-07-CONSENT-006
  • Type: negative
  • Given a default deployment (no restricted profile), when any component transmits measurement data before consent resolution, then it is nonconforming: pre-resolution transmission exists only inside the explicitly enabled restricted profile, never in the default core.

Waivers

Section titled “Waivers”

No reviewed waivers are currently recorded: every testable requirement maps to at least one scenario above. Non-automatable behavior is verified manually per the prose-catalog policy; if a requirement ever becomes unmappable, it receives a waiver row here (requirement, rationale, owner, review date) rather than silent omission.

RequirementRationaleOwnerReview date

Legacy cross-reference

Section titled “Legacy cross-reference”

Pre-3.0 citations (category + ordinal of the retired 61-scenario catalog) map as follows. Retired rows are preserved as history; their content was re-based into the referenced stable IDs or superseded by the 3.0 contract.

LegacyDisposition
Identity #1, #14UIAF-T-ID-001
Identity #2UIAF-T-ID-003
Identity #3UIAF-T-ID-006
Identity #4UIAF-T-BRW-004
Identity #5UIAF-T-BRW-001
Identity #6, #7UIAF-T-BRW-002
Identity #8UIAF-T-ID-008
Identity #9, #10UIAF-T-ID-010
Identity #11Retired — private-mode behavior is dated evidence (Spec 05/FAQ), not a contract scenario
Identity #12UIAF-T-ID-009
Identity #13Retired — third-party iframe embedding is out of the conformance contract
Identity #15UIAF-T-ID-011
Attribution #1, #6UIAF-T-ATT-001
Attribution #2, #8UIAF-T-ATT-002
Attribution #3UIAF-T-ATT-003
Attribution #4, #5UIAF-T-ATT-004
Attribution #7UIAF-T-ATT-005
Attribution #9Retired — AI-referrer classification carries no bound evidence row (omit-by-default)
Attribution #10UIAF-T-ATT-006
Consent #1, #14UIAF-T-CON-001
Consent #2UIAF-T-CON-002
Consent #3UIAF-T-CON-004
Consent #4, #15UIAF-T-PRE-001
Consent #5, #8UIAF-T-CON-006
Consent #6, #11UIAF-T-CON-010
Consent #7UIAF-T-CON-005
Consent #9UIAF-T-CON-007
Consent #10UIAF-T-CON-008
Consent #12UIAF-T-PRE-004
Consent #13UIAF-T-CON-011
Browser #1, #2, #3UIAF-T-BRW-002
Browser #4UIAF-T-BRW-001
Browser #5, #6UIAF-T-BRW-003
Browser #7, #8UIAF-T-BRW-005
Browser #9UIAF-T-BRW-004
Browser #10UIAF-T-BRW-010 (tombstone)
Cross-Device #1, #2, #5UIAF-T-XD-001
Cross-Device #3UIAF-T-XD-004
Cross-Device #4UIAF-T-XD-005
Conversion #1, #2UIAF-T-CNV-001
Conversion #3UIAF-T-CNV-003 (re-based: the denied/dormant state sends nothing — the retired reduced-payload behavior is superseded)
Pre-Consent #1UIAF-T-PRE-001
Pre-Consent #2UIAF-T-PRE-002
Pre-Consent #3UIAF-T-PRE-004