CCDP Distribution

This document defines the static browser resources and proving assets required by CCDP. CCDP owns the protocol routes, fragments, roles, navigations, and versions; this document owns their HTTP, response, artifact-compatibility, and publication contract. Build scripts, source-module APIs, dependency releases, and serving software are implementation choices, not protocol requirements.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Distribution boundary

One CCDP Distribution is served from one canonical ccdpOrigin under the CCDP origin policy: HTTPS, or HTTP on exact localhost and 127.0.0.1 hosts. It contains:

• every protocol resource for each supported CCDP version, including one self-contained Callback artifact containing its supported implementations;
• one version list naming its included CCDP versions and shared platform ceremony versions; and
• their bundled JavaScript, workers, WASM, circuits, and libID-owned assets.

The resource graph distinguishes distributed assets from external assets. Browsers prefetch and fetch external resources at their declared absolute URLs; the static build does not download or mirror them. External asset availability and readable CORS remain release-qualified dependencies rather than guarantees supplied by this host.

The OAuth Bridge separately serves ceremony configuration and the registered Callback document. Any profile-defined Bridge service is separate from this static Distribution. The Bridge retrieves the public Callback artifact server-side and inserts its deployment data before serving it; this does not change the document’s OAuth Bridge origin. Requests to the OAuth Platform, OAuth Bridge, Notary Service, and public platform APIs are protocol traffic rather than CCDP assets.

The Distribution may be the canonical libID release or an operator-selected replacement. Replacing it changes the code-supply-chain authority for Callback and proof generation.

One Distribution may serve any number of independently operated OAuth Bridges. It does not enumerate or register them: each Bridge selects a ccdpOrigin, which serves the same public resources to all of them. An Application runs only platform/version pairs that Distribution’s version list names and it implements; no shared deployment system is required.

HTTP contract

The Distribution is static and request-invariant. It sets no cookies, serves no unrelated same-origin application API, and performs no request-time compilation, templating, source resolution, archive extraction, or remote asset fetch.

Protocol resources

• REQ-DIST-01 (upholds SP-CCDP-01): The Distribution MUST serve the resources with the request invariance, executable-source restrictions, and response policies below.

The Distribution exposes the exact versioned resources defined by CCDP. Their fragments, roles, and execution contexts remain CCDP rules.

Prefetch and Prover contain their clearing bootstrap and entry code directly, with no browser-visible code manifest or second entry-script request. They may load implementation-private immutable chunks.

The aggregate Callback artifact is retrieved server-side by OAuth Bridges; the contract below defines its configuration slot, embedded startup, and the response they serve.

Each supported path has one decoded representation and response policy. Accept-Encoding may select only a Brotli or gzip transfer representation defined below. Conditional caching may return 304 Not Modified; otherwise query values, request headers, Origin, Referer, cookies, and user agent cannot select different bytes, policy, embedded configuration, or implementation. A nonempty query may receive the same static resource, but its clearing bootstrap rejects before protocol execution. Only GET and HEAD are defined. Protocol resources never redirect. Unknown paths and versions return an inert failure without fallback or redirect. For a directory path that serves no resource, the Distribution MAY instead redirect to the same-origin path with a trailing slash appended. That destination returns an inert failure; neither response executes CCDP code. Other methods execute no CCDP code.

The not-found response is static HTML containing no script, style, link, form, redirect, or protocol data.

Versioned protocol resources, the aggregate Callback artifact, and version list use Cache-Control: no-cache and an ETag so a path may receive compatible implementation updates. A breaking protocol change publishes new versioned routes and adds its implementation to the Callback artifact. The content-addressed Worker instead uses Cache-Control: public, max-age=31536000, immutable. The Bridge serves its configured Callback response with no-store, independently of its own upstream artifact cache.

All protocol resources send their exact media type and X-Content-Type-Options: nosniff. Top-level documents additionally send Referrer-Policy: no-referrer and are not frameable. Document CSP begins with default-src 'none', object-src 'none', base-uri 'none', form-action 'none', and frame-ancestors 'none'; admits only the exact build-generated entry code, resources, and network sources needed by that document; and uses neither JavaScript 'unsafe-inline' nor 'unsafe-eval'. Document-owned inline styles may use style-src 'unsafe-inline'; no caller markup, executable code, or styling input is part of this contract.

Resource	Form	Additional response contract
Callback artifact	self-contained HTML template at /ccdp/callback.html, retrieved server-side by OAuth Bridges	text/html; charset=utf-8, no-cache and ETag, with exact executable hashes in CSP. No browser CORS permission is needed for this retrieval. The configured response follows Served response.
Version list	JSON at /ccdp/versions.json, fetched cross-origin by the Application	application/json; charset=utf-8, no-cache and ETag, Access-Control-Allow-Origin: *, and Cross-Origin-Resource-Policy: cross-origin. No other Distribution resource sends a CORS header.
Prefetch	top-level non-isolated HTML	Cross-Origin-Opener-Policy: unsafe-none and no COEP. Script/worker sources remain same-origin; connect-src admits local assets and the pinned external asset origins.
Prover	top-level HTML	Document-Isolation-Policy: isolate-and-require-corp, Cross-Origin-Opener-Policy: unsafe-none, and no COEP.
Prover isolation fallback	top-level HTML at /ccdp/v{CCDPVersion}/prover/fallback	Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp. Same Prover entrypoint, fragment contract, and non-isolation response rules.
Worker	self-contained module Service Worker JavaScript at /ccdp/worker.{hash}.js	text/javascript; charset=utf-8, immutable caching, and Service-Worker-Allowed: /. Every Prefetch in a release registers this same script with scope: '/'; it remains compatible with every included CCDP version and passes unrelated requests through unchanged. Code is same-origin; connect-src also admits the pinned Aztec CRS origins for asset caching.

The Distribution may publish smaller Brotli and gzip transfer representations. It selects an available representation admitted by Accept-Encoding (including quality values), otherwise the original. A compressed response keeps the original media type and policy, declares its Content-Encoding, and varies on Accept-Encoding. Decoding produces the exact original bytes. Native serving software may supply validators and transfer framing; the protocol requires no custom compression or ETag implementation.

Both Prover responses close script and worker sources to the build-generated same-origin graph and toolchain-required blob: workers. Every context that fetches distributed assets, including Prefetch, Prover, the Service Worker, and dedicated workers, admits 'self' in connect-src; same-origin HTTP assets must not be accidentally excluded by an HTTPS-only source list.

Prover additionally admits https: wss: for declared external assets and secure notary WebSockets. Its local notary WS sources are ws://localhost:* ws://127.0.0.1:*. Both Prover responses include these fixed sources for default and custom ports. Dedicated workers include the corresponding sources where they perform asset or notary requests. No resource admits a general http: or ws: source. Generated policy does not add upgrade-insecure-requests or otherwise force local requests to TLS. Script and worker loading remains same-origin under either permitted scheme; these fetch exceptions admit no remote code. The Distribution embeds no selected notary address, profile, or environment override; one byte-identical response supports the same admitted origins in local and hosted deployments. Selection changes no asset or cache key. This policy permits those network schemes and explicit loopback hosts, not just the selected notary; application code enforces destination selection.

Every context fetching an external resource admits its declared request origins, including fallback origins, without allowing external executable code. Requests use noncredentialed readable CORS under both Prover responses, including any declared Range requests; opaque responses and no-cors are not substitutes. Availability and CORS policy remain external dependencies.

Every context that compiles WASM, including dedicated proof and TLSNotary workers, includes script-src 'wasm-unsafe-eval' alongside its code sources. This permits WASM compilation, not JavaScript string evaluation. External execution worker scripts additionally carry Cross-Origin-Embedder-Policy: require-corp. They have their own CSP; they do not rely on the document’s CSP. Blob workers inherit their creator’s policy. Worker profiles admit only their required script, asset, and protocol connections, and worker-src admits same-origin or blob: children only for workers that spawn them. The Service Worker only caches bytes and keeps ports: it needs no WASM compilation permission.

Each request-invariant Prover response supports multiple platform profiles and arbitrary notary origins satisfying the origin policy. For browser-exchange profiles, token and identity exchanges use the browser notarization adapter, with code-owned platform destinations rather than caller-selected endpoints. CSP does not constrain the runtime-selected notary to an exact origin: compromised Prover code can use every network class admitted by the response.

Callback artifact

• REQ-DIST-02 (upholds SP-CCDP-01): The Distribution MUST publish Callback according to the insertion, browser-entry, and served-response contracts below; the Bridge MUST validate and configure it according to that same contract.

GET /ccdp/callback.html supplies a complete Callback document for OAuth Bridges to configure and serve at their registered redirect URI. It executes on that Bridge’s origin, without a separate shell, HTTP redirect, or browser-side entry-script fetch.

The artifact bundles the supported CCDP Callback implementations and their dependencies. Its version-independent path lets the browser select a bundled implementation from OAuth state, including Google fragment returns which the Bridge cannot see. It contains no Bridge configuration and cannot accept a connection until configured; a direct visit clears URL input and fails locally on the missing deployment data.

Configuration insertion

The artifact contains the semantic equivalent of:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <title>libID</title>
  </head>
  <body>
    <main id="libid-root"></main>
    <script id="libid-callback-config" type="application/json">__LIBID_CALLBACK_CONFIG__</script>
    <script type="module">/* complete bundled Callback code */</script>
  </body>
</html>

The artifact contains exactly one configuration marker, in this non-executable data block. The bridge substitutes serialized deployment data there, never JavaScript source. Serialization escapes < as \u003c so data cannot terminate the script element or introduce markup. Missing or repeated markers reject the artifact. No callback request value participates in substitution.

The inserted data is one unversioned JSON list, [allowedOrigins, ccdpOrigin], using the Bridge’s effective allowlist:

[
  ["https://app.example", "*.app.example", "https://lib.id"],
  "https://lib.id"
]

There is no version-keyed wrapper, input-declaration block, or Bridge-side CCDP version list. Every bundled Callback implementation receives a deeply frozen copy of the same list. The first two positions require a nonempty, duplicate-free allowlist whose members are canonical origins, origin patterns, or *, and which holds the configured CCDP origin as an exact member, and that origin itself. Origins use the CCDP origin policy, including its HTTP localhost exception; the second position is one exact origin. The Bridge validates every member before insertion and normalizes none. In the browser, Callback checks the second position and its literal membership in the first, and the popup endpoint it constructs checks the members themselves. These match the effective admission set and public CeremonyConfig respectively. The list contains no secrets. Neither URL input nor an upstream artifact supplies deployment values.

Compatible evolution preserves existing positions, types, and meanings. New optional trailing inputs may be defaulted when absent by newer implementations and ignored by older ones. New CCDP versions using that compatible contract require no Bridge change. A new required input, or an incompatible interpretation of an existing one, requires an explicit input-contract version and corresponding Bridge support, except as a coordinated upgrade.

A coordinated upgrade widens the member type of an existing position and adds no input. It takes no input-contract version, and instead binds deployment order: a deployment must not configure a widened member until the Callback its selected Distribution publishes reads that member kind. Admitting origin patterns and * in the allowlist position is such an upgrade. No input-contract version is defined until a change falls outside this exception.

This is a data-insertion contract, not a UI template or renderer API. Callback owns its code and presentation. Its dependencies are bundled into this HTML rather than loaded relative to the bridge or fetched from the Distribution by the browser.

Browser entry

The bundled Callback implementations own URL clearing, version dispatch, and startup/failure UI; the Bridge does not implement them. A live document keeps the code and configuration it received.

The embedded Callback code, before rendering, storage, error reporting, or any network use:

1. bounds and copies the raw query and fragment, then clears both with history.replaceState while retaining the same path;
2. requires exactly one routing state and reads its v<version>. prefix;
3. rejects a malformed version or one absent from its bundled implementations;
4. requires a JSON input list, validates the inputs the selected implementation reads itself, leaves each allowlist member to the popup endpoint that receives it, and freezes the list and captured location; and
5. enters the selected Callback implementation once, without another browser-side entry-script request.

Oversized or malformed input is cleared and renders only fixed failure text. A version absent from the bundle, including a retired version, displays a package-owned message such as This ceremony version is no longer supported. Update the application and try again. It establishes no connection, emits no protocol message, and never substitutes another version. No retired transport or failure-message implementation is retained for this screen. Applications need no version-specific failure UI and receive no protocol notification of this local failure; their ordinary cancellation/connection-failure handling remains.

Missing or malformed required inputs likewise render fixed local failure text without establishing a connection or emitting a protocol message.

No platform credential is parsed here. The selected Callback authenticates the Application against its configured allowlist, by exact member, by pattern member, or by *, and binds the observed exact origin before the captured return can leave this document, then follows CCDP. The popup endpoint holding the allowlist runs that test; a noncanonical claimed origin fails before membership.

Served response

For one active artifact/configuration pair, HTML and headers are invariant across requests. Nothing is derived from request Origin, Referer, query, fragment, platform, or ceremony. The completed response uses:

• Cross-Origin-Opener-Policy: unsafe-none, without COEP;
• Content-Type: text/html; charset=utf-8, X-Content-Type-Options: nosniff, Cache-Control: no-store, and Referrer-Policy: no-referrer;
• CSP beginning with default-src 'none', object-src 'none', base-uri 'none', form-action 'none', and frame-ancestors 'none';
• frame-src 'none'; Callback creates no frame;
• connect-src 'none' without a configured carrier fallback; an optional fallback admits only the fixed sources it needs;
• style-src 'unsafe-inline' for package-owned inline styles; and
• script-src containing only the build-generated hashes for the bundled executable code, with no external script source, JavaScript 'unsafe-inline', or 'unsafe-eval'.

The bridge combines the artifact’s executable hashes with its own deployment-specific policy, not an upstream policy permitting arbitrary sources. Data substitution does not change executable bytes. Artifact and matching policy update atomically; compatible UI changes require no manual stylesheet hash, theme, or styling configuration.

The Bridge accepts only a successful HTML artifact with the required unique data slot and hash-only executable script policy. It performs substitution on the decoded body and composes the final HTML and headers as one unit. Upstream cache and transfer headers are not copied: the source artifact is revalidated, while the configured browser response is non-cacheable.

Version list

• REQ-DIST-06: The Distribution MUST publish the version list below, naming exactly its included CCDP versions and their shared platform/version pairs; the Application MUST validate it by that contract. Necessity: an Application must select only protocol and profile versions its Distribution supports.

GET /ccdp/versions.json returns one object with exactly these fields:

Field	Contract
ccdpVersions	Nonempty, duplicate-free, ascending array of included CCDP version numbers; positive integers no greater than 9007199254740991, so JSON readers preserve them exactly
platforms	Object keyed by exact platform identifiers; each value is a nonempty, duplicate-free, ascending array of unsigned 16-bit platform ceremony versions

Object key order carries no meaning.

{"ccdpVersions":[1],"platforms":{"github":[1],"google":[1],"x":[1]}}

The path is unversioned, beside /ccdp/callback.html: the set is a property of the Distribution, not of one CCDP version. Every included CCDP version has its Prefetch and Prover resources and bundled Callback implementation, and each Prover supports exactly the listed platform/version pairs. A release cannot advertise a pair that works under only some of its included CCDP versions. The shared Worker supports every included version’s resource graph and continuity needs; all versions in one release register the same build-pinned Worker URL at root scope, rather than replacing that registration with competing version-specific scripts.

The Application fetches the list cross-origin without credentials or redirects; the Bridge contract owns how it selects versions and clients from the list and the public record. Before Prefetch, it checks membership of the CCDP version it will use; an absent version refuses the ceremony before navigation. It does not reinterpret another CCDP version as compatible. Readers validate the whole record, including values under unknown platform keys, then ignore versions or platforms they do not implement. Missing or extra top-level fields, wrong types, out-of-range integers, empty version arrays, duplicates, or non-ascending arrays refuse the whole resource.

Worker selection

• REQ-DIST-08: The Publisher MUST pin the content-addressed Worker URL below into every Prefetch in its release. The Prefetch document MUST dispatch selected-profile fetches only to that matching Worker. Necessity: a compatible redeployment must not report successful prefetch of an earlier release’s resource graph.

/ccdp/worker.{hash}.js serves the exact self-contained Worker script identified by hash: the lowercase hexadecimal SHA-256 of its uncompressed JavaScript bytes, including its embedded complete resource graph. This is a Worker-content hash, not a distribution-build, release, or commit identifier. Unchanged Worker bytes retain their URL; changes to its code or embedded graph produce a new URL. Other distribution changes alone do not change it. This path is an immutable file, not a query-based cache buster or an alias to the latest Worker.

Prefetch uses the URL embedded in its own code, without a discovery request or a forced network update check for an already matching Worker. It registers with scope: '/' and selects the Worker with that exact script URL, waiting until it can accept dispatch. A changed URL updates the same root registration through the browser’s installation lifecycle; it creates no build-specific scope. An older active Worker is not a substitute, even if it recognizes the same platform ceremony version. A waiting or installing replacement must be ready to accept dispatch before Prefetch proceeds; a timeout cannot select the old Worker instead.

Only the matching Worker’s dispatch acknowledgement permits Event(prefetch-dispatch, finished); downloads need not finish. Failure follows Prefetch to Authorization, before OAuth. This adds no CCDP message or runtime content-hash verification. Immutable paths identify release bytes; they do not guarantee retention of earlier releases.

Prover isolation

• REQ-DIST-03 (upholds SP-CCDP-01): The Prover and its host MUST preserve the isolation, fragment, and root-registration behavior described below.

CCDP has one logical Prover. The primary response requests Document Isolation Policy without severing the opener; an unisolated arrival uses the same-origin fallback response through the popup transport’s isolation replacement. The two responses are not separate CCDP participants or phases.

Both execute the same Prover implementation and fragment contract. They capture and clear incoming fields before other work and preserve that capture through replacement. Neither exposes readiness or executes proof work before isolation and connection establishment succeed. If the fallback is still unisolated, establishment fails; it does not loop or silently prove without shared memory.

Both paths resolve the canonical root-scope Worker registration, whose scope does not change with its content-addressed script URL. The host and participants uphold the popup transport’s same-registration continuity prerequisite. Successful DIP avoids replacement; fallback needs no second window or extra user action. This mechanism does not repair an opener already severed by the OAuth Platform; authenticated carrier fallback is a separate popup-transport concern.

Proving assets

• REQ-DIST-04: The Distribution MUST preserve the asset URL, byte, metadata, and selected-profile resource contracts below. Necessity: Prefetch and Prover must share compatible assets without runtime source negotiation.

GET /ccdp/assets/* is the Distribution’s static proving-resource namespace, not a CCDP API or versioned protocol route. Locally served proving resources other than the protocol resources resolve there; Aztec CRS requests retain their upstream URLs. CCDP assigns no structure to the suffix: versioned code pins each exact path, while protocol code neither enumerates nor parses the namespace.

Each asset response:

• has a canonical path with no query, fragment, mutable alias, or redirect;
• serves one immutable byte sequence with its exact media type and nosniff;
• uses Cross-Origin-Resource-Policy: same-origin; and
• uses Cache-Control: public, max-age=31536000, immutable.

A release pins the resource graph for every supported platform ceremony version. Requests, fragments, messages, and Application inputs cannot replace that graph. Every local path referenced by published code exists; no browser-visible asset catalog or request-time source resolution is required. External resources retain their declared URLs. Prefetch and execution resolve the same selected-profile resources, including shared resources, so their downloads and caches are reusable.

Browser cache reconciliation

• REQ-DIST-07: The Worker MUST attempt to reconcile its managed proving-asset cache on activation against the complete resource graph of its release. Necessity: obsolete releases must not accumulate indefinitely in this cache, while still-required shared resources remain reusable.

One Worker-owned operation compares cached request keys with the union required by every included CCDP and platform ceremony version, including declared external resources. A key includes the exact URL and byte range when present. With storage accessible, reconciliation deletes entries absent from that union and leaves referenced entries unchanged. It neither guesses asset versions from filenames nor removes a resource merely because the current ceremony uses a different platform. Distinct revisions or ranges still required by supported profiles coexist.

Reconciliation touches only the Worker’s managed asset cache, not unrelated origin storage or the browser’s automatic HTTP cache. Storage denial or a cleanup error is a cache-maintenance failure, not a ceremony failure; ordinary fetching remains available. Individual asset downloads need no separate version-management or eviction operation. Browser eviction and release changes can still cause cache misses; this policy guarantees no durable recovery for an older live ceremony.

Publication and compatibility

• REQ-DIST-05: The Publisher MUST activate a locally asset-complete release that serves the latest compatible release of each CCDPVersion it includes, and no URL referenced only by an earlier compatible release. Necessity: an origin serves one self-contained release at a time, and unchanged bytes stay reusable across releases.

Activation is asset-complete: every immutable resource referenced by an updated protocol resource or Worker is retrievable with its final bytes and response metadata before that update becomes reachable. The version list becomes reachable no earlier than all named CCDP resources, their compatible shared Worker, and the resources of every platform/version pair it names. The external Aztec request set is qualified before promotion; CDN availability cannot be made atomic with local deployment, and a later outage still fails proving if no usable cache is present.

An origin serves one release at a time; activation switches it whole. An unchanged asset retains its URL across compatible releases. Changed bytes or execution-relevant metadata receive a new immutable URL, and the new release does not serve the URLs it replaced: a ceremony running across the switch can fail and is started again. The Publisher chooses which CCDPVersions a release includes; each included version serves its latest compatible release. Runtime content hashing is not required; release-qualified, content-addressed, and build-generated immutable paths all satisfy this contract.

Asset revisions change CCDPVersion or PlatformCeremonyVersion only when their observable protocol or proof semantics change.

Security Considerations

This contract supports SP-CCDP-01 under ASM-CCDP-01 and ASM-CCDP-02. The publisher controls executable browser code: headers and content-addressed paths do not protect against a malicious publisher or compromised release. CSP limits accidental source expansion, not the publisher’s authority. Request-invariant Prover policy deliberately permits classes of secure network origins; runtime destination checks, not CSP, bind a ceremony to its Bridge and notary. Local HTTP exceptions are confined to the popup origin policy.

The version list gates which CCDP and platform ceremony versions an Application runs; a wrong list withholds or fails ceremonies and releases nothing.

Callback deployment inputs are non-executable trusted configuration. Their insertion cannot depend on OAuth ingress, change script bytes, or introduce markup. The Bridge keeps that configured response separate from its upstream artifact cache. Fragments do not reach this Distribution’s HTTP service.

Unreachable external resources can prevent proving despite an atomic local deployment. Neither caching nor release qualification guarantees later CDN availability. Common and platform specifications retain proof and trust-root authority; this document selects no ledger verification keys.

Conformance

Publishers, static hosts, Bridge artifact consumers, and Application version-list readers implement the roles above. The package’s build and deployment tests may qualify them with any serving software that produces these observable responses.

• TEST-DIST-01 (exercises REQ-DIST-01): GET/HEAD serve invariant decoded bytes and policy; conditional/encoding responses preserve them. Protocol and asset resources never redirect; unknown paths are inert. Any directory slash redirect stays on the same origin and ends in an inert failure. Both isolation profiles support allowed local and external requests without admitting remote executable code.
• TEST-DIST-02 (exercises REQ-DIST-02): Exactly one data marker is inserted safely; executable hashes remain valid; missing/duplicate slots fail. Query and fragment state select a supported bundled Callback without another script request; missing/retired versions fail locally. Callback forbids frames and, without a configured optional carrier fallback, network connections. Its policy does not interpolate ccdpOrigin as a CSP source or impose extra hostname syntax on that canonical origin.
• TEST-DIST-03 (exercises REQ-DIST-03): Primary isolation or one replacement establishes the same participant; retained fragments survive.
• TEST-DIST-04 (exercises REQ-DIST-04): Empty-cache Prefetch and execution use the same declared resource graph; shared resources are reusable, and ranged external responses remain readable under both isolation profiles.
• TEST-DIST-05 (exercises REQ-DIST-05): Unchanged assets keep URLs, changed bytes get new URLs, and paths referenced only by an earlier compatible release are no longer served. No updated document, Worker, or version-list entry becomes reachable before its local dependencies. External availability is qualified, not reported as atomic.
• TEST-DIST-06 (exercises REQ-DIST-06): GET and HEAD serve the exact version-list record as application/json; charset=utf-8 with no-cache, an ETag, nosniff, Access-Control-Allow-Origin: *, and Cross-Origin-Resource-Policy: cross-origin, without redirect; no other resource sends a CORS header. Every advertised CCDP version has all its resources, supports exactly the shared platform pairs, and uses the release’s same root Worker script. A missing CCDP version is refused before Prefetch. Unknown platform keys and unsupported versions are ignored only after validating their values; missing or extra fields, wrong types, out-of-range integers, and empty, duplicate-bearing, or non-ascending arrays refuse the whole record.
• TEST-DIST-07 (exercises REQ-DIST-07): Activate a Worker over a cache containing retained, superseded, shared, and unrelated entries. Reconciliation removes only obsolete managed entries; unchanged assets and all revisions/ranges needed by any included profile survive, even when not used by the currently selected platform. Repeating reconciliation is harmless. Storage denial or deletion failure does not prevent fetching and proving.
• TEST-DIST-08 (exercises REQ-DIST-08): The Worker filename matches the SHA-256 of its decoded body, including under compressed transfer, and its response is immutable with root scope allowed. Unchanged Worker bytes keep the URL across an unrelated distribution change; changing Worker code or an embedded asset URL changes it. Every included CCDP version pins the same URL. Reusing a matching Worker needs no forced update/discovery request. With an older active Worker and an unchanged platform/version identifier, Prefetch waits for and dispatches to the new matching Worker in the same root registration, including when initially waiting or installing. A stalled or failed replacement never dispatches to the old Worker or reports prefetch-dispatch finished.