@adcp/sdk 16.0.0-beta.9 → 16.1.0

package/docs/migration-14.x-rc-worksheet.md

@@ -16,8 +16,8 @@ pin using `ADCP_VERSION` inside that tarball.
 
 | Fact | Value |
 | --- | --- |
-| Checkout `package.json` version | `@adcp/sdk@16.0.0-beta.9` |
-| npm integrity | registry-derived after publication; run `npm view @adcp/sdk@16.0.0-beta.9 dist.integrity` |
+| Checkout `package.json` version | `@adcp/sdk@16.1.0` |
+| npm integrity | registry-derived after publication; run `npm view @adcp/sdk@16.1.0 dist.integrity` |
 | Node.js runtime | `^20.19.0 || >=22.12.0` |
 | Default AdCP wire release | `3.2.5` |
 | Maintained wire releases | `v3`, `3.0.0`, `3.0`, `3.0.1`, `3.0.2`, `3.0.3`, `3.0.4`, `3.0.5`, `3.0.6`, `3.0.7`, `3.0.8`, `3.0.9`, `3.0.10`, `3.0.11`, `3.0.12`, `3.0.13`, `3.0.14`, `3.0.15`, `3.0.16`, `3.0.17`, `3.0.18`, `3.0.19`, `3.0.20`, `3.0.21`, `3.0.22`, `3.0.23`, `3.0.24`, `3.0.25`, `3.1.0`, `3.1`, `3.1.1`, `3.1.2`, `3.1.3`, `3.1.4`, `3.1.5`, `3.1.6`, `3.1.7`, `3.1.8`, `3.1.9`, `3.1.10`, `3.1.11`, `3.1.12`, `3.1.13`, `3.1.14`, `3.1.15`, `3.1.16`, `3.1.17`, `3.1.18`, `3.1.19`, `3.1.20`, `3.1.21`, `3.1.22`, `3.1.23`, `3.1.24`, `3.1.25`, `3.1.26`, `3.1.27`, `3.1.28`, `3.1.29`, `3.2.1`, `3.2`, `3.2.2`, `3.2.3`, `3.2.4`, `3.2.5` |
@@ -26,8 +26,8 @@ pin using `ADCP_VERSION` inside that tarball.
 For a checkout at the published release commit, install the exact package version:
 
 ```bash
-npm install --save-exact '@adcp/sdk@16.0.0-beta.9'
-npm view '@adcp/sdk@16.0.0-beta.9' dist.integrity
+npm install --save-exact '@adcp/sdk@16.1.0'
+npm view '@adcp/sdk@16.1.0' dist.integrity
 ```
 
 ### Required and optional peers

package/docs/migration-agent-identity-3.3.md

@@ -3,7 +3,7 @@
 The experimental identity rollout is tracked in
 [adcp-client#3233](https://github.com/adcontextprotocol/adcp-client/issues/3233).
 This release implements the rollout behind explicit experimental configuration.
-The SDK's default `ADCP_VERSION` remains **3.2.4**. Experimental client/server
+The SDK's default `ADCP_VERSION` remains **3.2.5**. Experimental client/server
 instances select the 3.3 carrier and apply the pinned draft overlays to the
 released bundle; they do not regenerate or replace the public 3.2 types.
 Upstream PRs remain open, so the experiment can change before graduation.
@@ -126,18 +126,44 @@ final UTF-8 body, covers the selected `Signature-Agent` member and digest,
 uses a fresh 64-byte nonce, and refuses automatic HTTP redirects. A request
 carries exactly one `web-bot-auth` signature and one `Signature-Agent` member:
 relays were removed from the profile, `signWebBotAuth` throws on `relay: true`
-and on a request that already carries signature fields, and the verifier
-answers a second signature (of any profile) or a second `Signature-Agent`
-member with 403. Signing keys are Ed25519 or RSA-PSS-SHA512 (2048 to 4096
-bits, e = 65537); ES256 stays on the AdCP RFC 9421 profile, and
+and on a request that already carries signature fields. The verifier reads
+only the `Signature-Input` member tagged `web-bot-auth` and ignores members
+with other tags, such as a CDN's own signature. It answers a second
+`web-bot-auth` signature or a second `Signature-Agent` member with 403.
+Signing keys are Ed25519 only; ES256 stays on the AdCP RFC 9421 profile, and
 `createWebBotAuthFetch`, `createWebhookEmitter` and `createAdcpServer` refuse
-a P-256 Web Bot Auth key at wire-up.
+a P-256 or RSA Web Bot Auth key at wire-up.
+
+This also changes two helpers outside the experiment. `verifySignature` and
+`verifySignatureAsync`, which `@adcp/sdk/signing/server` exports, no longer
+verify `rsa-pss-sha512`: they return `false` for it, as for any algorithm they
+don't support. Only Web Bot Auth used it, and the AdCP RFC 9421 profile allows
+only `ed25519` and `ecdsa-p256-sha256`. A caller that verifies RSA-PSS
+signatures with these helpers needs to verify them with `node:crypto` or
+WebCrypto instead.
+
+The covered `Signature-Agent` member must be exactly the canonical https origin
+string, compared as received: a lowercase host, no default port, and no path
+(not even `/`), query, fragment, or userinfo. Any other value, including an
+`http://` origin, is a 403 before any directory fetch. The signers apply the
+same rule: `signWebBotAuth`, `createSignedSignatureDirectory` and
+`createWebBotAuthFetch` canonicalize the agent origin they are given and throw a
+`TypeError` when it is not https, such as `http://localhost:3000`. There is no
+http opt-in. The member's `type`
+parameter is a Token (WBA section 5.2.1), and the verifier accepts
+`type=directory` as a Token or as a String. It ignores a member of any other
+type, which leaves no member to resolve (403).
 
 `SignatureDirectoryResolver` derives the directory from the covered canonical
-origin. Directories must be signed (WBA Appendix B.1): it validates a
-possession signature for every key, covering `"@authority";req` and
-`content-digest`, and the exact body digest before caching keys. An unsigned
-directory is a discovery failure. Its audit proof retains the signed body and
+origin. Directories must be signed (WBA Appendix B.1): it uses each Ed25519
+key that has a valid possession signature, covering `"@authority";req` and
+`content-digest`, and validates the exact body digest before caching keys. It
+ignores every other key and any signature it made: a key the profile cannot
+use, such as a P-256 key, a key it cannot import, such as an Ed25519 key with
+no `x` (RFC 7517 section 5), and a key without a valid signature (WBA Appendix
+B.1; directory draft section 5). An unsigned directory, one with no validly
+signed Ed25519 key, or one that publishes private key material for any key,
+usable or not, is a discovery failure. Its audit proof retains the signed body and
 headers. Verification requires this resolver so context-free JWKS adapters cannot
 attribute a key to an arbitrary origin. Discovery uses HTTPS, DNS pinning, no redirects, a 256 KiB cap, a
 5-second connect bound and 10-second total bound, at most 64 keys, and bounded
@@ -155,8 +181,7 @@ Serve the exact JWS at `/.well-known/governance-revocations.json` and refresh it
 before `next_update` (the command defaults to five minutes). Pass `--snapshot`
 to sign a list of revoked key thumbprints and optional reasons/dates.
 `createSignedOriginRevocationList` provides the same authoring API. The SDK
-signs and verifies revocation lists with directory keys: EdDSA for Ed25519 keys
-and PS512 for RSA keys (a P-256 key cannot be published in a key directory). Observed key revocations are permanent;
+signs and verifies revocation lists with Ed25519 directory keys, as EdDSA. Observed key revocations are permanent;
 refresh failures use the last verified list only within the published grace
 window. Staleness follows the list's signed `next_update`, never the polling
 interval: the verifier re-polls at least every polling interval (at most 30
@@ -336,7 +361,12 @@ operator) to the signer's operator, or a two-link chain through the account
 operator, is accepted. The
 intersection must cover the actual brand IDs, countries, scope, signer-origin
 narrowing and temporal window. A restrictive published grant cannot be
-superseded by seller fallback. A trust 200 disables brand.json authority;
+superseded by seller fallback. A grant's `grantee` must be a registrable domain
+under the pinned PSL snapshot (`alice.github.io` is one; `github.io` and
+`media.agency.com` are not). A grant whose `grantee` is not one covers no claim
+and does not block seller fallback, but its scopes still count for
+`exclusive_grants`. `createTrustRecord` and `adcp identity trust-validate` refuse
+such grantees. A trust 200 disables brand.json authority;
 authoritative absence alone permits explicit legacy policy. An established
 identity lacking a grant gets `PERMISSION_DENIED` with
 `{ scope: 'agent', reason: 'grant_absent' }`. No account or live buy is changed.
@@ -379,16 +409,19 @@ released schemas:
 
 | PR | Pinned head | Surface |
 | --- | --- | --- |
-| [7894](https://github.com/adcontextprotocol/adcp/pull/7894) | `e24eeb090c4365707641099cbbb45f9945c6d6e0` | WBA wire profile (`wba-profile.mdx`), profile selectors, directory and request vectors |
+| [7894](https://github.com/adcontextprotocol/adcp/pull/7894) | `9f472d63900b99efcd9ed05b5d0bb75552c3b9d6` | WBA wire profile (`wba-profile.mdx`), profile selectors |
 | [8121](https://github.com/adcontextprotocol/adcp/pull/8121) | `f5973ac0267b1b94d714c55fc4e3ad8fc2511350` | Origin identity and key-free trust v1 |
 | [8162](https://github.com/adcontextprotocol/adcp/pull/8162) | `5c9914c5c382cc32f3d2ad7842942e548c414705` | Ratified identity, coexistence, revocation |
 | [8168](https://github.com/adcontextprotocol/adcp/pull/8168) | `45540941dfd61e80ab8a463f780cb147c82a32f0` | Relationship and principal response arms |
-| [8169](https://github.com/adcontextprotocol/adcp/pull/8169) | `3ce6a14d7afaa71fa78ddf2223ed0421e01205ae` | Grants, trust schema, grant_absent |
+| [8169](https://github.com/adcontextprotocol/adcp/pull/8169) | `3ce6a14d7afaa71fa78ddf2223ed0421e01205ae` | Grants, trust schema, grant_absent; the registrable-domain `grantee` rule and its schema description from `eabe46048530c08a34e6eee6e4d15d7848e01c57` |
 | [8170](https://github.com/adcontextprotocol/adcp/pull/8170) | `8d3591e70e9a717c7fdfb513360a796fba24ca9a` | Onboarding additions only; its old trust key fields are excluded |
 | [8177](https://github.com/adcontextprotocol/adcp/pull/8177) | `b663f8e4235fe4276c73fb9bac6db491b2252bbf` | Reporting authentication omission |
+| [8298](https://github.com/adcontextprotocol/adcp/pull/8298) | `f44785a5b65db93988f30ad3d23ba5849f1a1d5e` | WBA interop harness, directory and request vectors |
 
-The vectors in `test/fixtures/wba-profile/` are byte-identical to #7894 at that
-head and are all graded except the governance-token vectors (see `PINNED.json`).
+The vectors in `test/fixtures/wba-profile/` are byte-identical to #8298 at that
+head (see `PINNED.json`), which carries the #7894 profile and vectors. Every
+vendored request and directory vector is graded, and the interop harness
+(adcontextprotocol/adcp#8298) grades `scenarios.json`.
 
 Verification runs in Cloudflare's `http-message-sig` (signature base, coverage,
 window, algorithm and cryptographic checks); the SDK adds the profile rules in
@@ -413,7 +446,7 @@ so verification can run in a CDN or middleware in front of the AdCP server.
   reason is logged, never sent. A 429 for local load shedding (directory fetch
   limiter, replay-store `rate_abuse`) carries `Retry-After` instead.
 - Every signed request carries `created`, `expires` (at most 300 seconds
-  later), `keyid`, `alg` (`ed25519` or `rsa-pss-sha512`) and a `nonce` of 64
+  later), `keyid`, `alg` (`ed25519`) and a `nonce` of 64
   bytes, unpadded Base64URL or canonical padded Base64 (Cloudflare's default).
   The former 16-byte floor is gone: a shorter nonce is a 403. Replay state is
   keyed on the nonce bytes, so the two encodings of one nonce collide.
@@ -454,14 +487,14 @@ so verification can run in a CDN or middleware in front of the AdCP server.
   back off on 429 or 503.
 - `@target-uri` and `@authority` are taken from the target URI as received
   (RFC 9421 §2.2.2), never canonicalized; canonical origins identify the signer
-  only. Ed25519 and RSA-PSS-SHA512 keys are supported; RSA-PSS uses WebCrypto
-  where the runtime has it, so it also works on Cloudflare workerd.
+  only. Web Bot Auth is Ed25519 only, and it also works on Cloudflare workerd.
   `test/fixtures/wba-interop/` holds fixtures verified in both directions against
   Cloudflare's `web-bot-auth`; they already used signed directories and are
   unchanged.
-The #7894 governance-token vectors are vendored but not graded: ratified R4
-keeps the RFC 9421 discovery chain for governance through 3.3, and the profile
-page leaves document signing to a separate decision. `PINNED.json` records this.
+#7894 drops the governance-token checks and the `governance/` vectors from the
+WBA profile. Governance moves to the AdCP layer under a separate R4 erratum,
+which moves JWS artifacts, governance included, to the identity's WBA key
+directory in 3.3. This change leaves the SDK's governance code as it is.
 The buyer default onboarding field is `profiles.adcp.onboarding`, matching the
 schema; the design's `record_profiles` wording names the schema definition.
 

package/docs/migration-reporting-storage-package.md

@@ -1,6 +1,6 @@
 # Reliable Reporting storage moved to `@adcp/reporting-storage`
 
-**Applies to:** SDK 16 beta. **Kind:** breaking, by design. There are no re-export shims: the moved subpaths are gone from `@adcp/sdk`.
+**Applies to:** SDK 16. **Kind:** breaking, by design. There are no re-export shims: the moved subpaths are gone from `@adcp/sdk`.
 
 The Reliable Reporting storage implementations now ship as their own package, `@adcp/reporting-storage`, on its own version line. `@adcp/sdk` keeps the protocol layer. If you import anything from `@adcp/sdk/reporting/gcs`, `/s3`, `/azure` or `/bigquery`, or the PostgreSQL store, row storage, managed delivery or notification activity from `@adcp/sdk/reporting/ledger`, or `createPostgresReliableReportingProductionService` from `@adcp/sdk/reporting/service`, change those imports. Nothing else changes on the wire, in the database schema, or in the ledger's behavior.
 
@@ -11,10 +11,10 @@ Why: storage keeps its own release cadence, as Auth.js, LangGraph and OpenTeleme
 1. Install the package next to the SDK. `@adcp/sdk` is a peer dependency of it, so the host keeps exactly one copy:
 
    ```bash
-   npm install @adcp/sdk@beta @adcp/reporting-storage@beta
+   npm install @adcp/sdk@^16.0.0 @adcp/reporting-storage@~0.1.0
    ```
 
-   Pin the storage package with `~` (`"@adcp/reporting-storage": "~0.1.0-beta.0"` while SDK 16 is in beta, `"~0.1.0"` after a stable release; a prerelease version is not matched by `~0.1.0`): it is pre-1.0 and every export is experimental. The cloud SDKs are optional peers of the new package, not of `@adcp/sdk` any more, so keep `@aws-sdk/client-s3`, `@azure/storage-blob` and `@google-cloud/storage` in your own dependencies for the providers you use.
+   Pin the storage package with `~` (`"@adcp/reporting-storage": "~0.1.0"`; this stable range does not match the earlier `0.1.0-beta.0` prerelease): it is pre-1.0 and every export is experimental. The cloud SDKs are optional peers of the new package, not of `@adcp/sdk` any more, so keep `@aws-sdk/client-s3`, `@azure/storage-blob` and `@google-cloud/storage` in your own dependencies for the providers you use.
 
 2. Change the imports using the table below, then run `tsc --noEmit`. A moved name on `@adcp/sdk/reporting/ledger` or `/service` is `TS2305: Module '"@adcp/sdk/reporting/ledger"' has no exported member 'PostgresReportingLedgerStore'`; a deleted subpath is `TS2307: Cannot find module '@adcp/sdk/reporting/gcs'`. At runtime the deleted subpaths fail with `ERR_PACKAGE_PATH_NOT_EXPORTED`, and a stale CommonJS `require` of a moved name on a kept subpath destructures to `undefined` and fails later as `X is not a constructor`, so grep JavaScript too (see [Self-grade](#self-grade)).
 

package/docs/releases/16.0.0.md

@@ -0,0 +1,20 @@
+# SDK 16.0.0
+
+SDK 16 is the stable AdCP 3.2 release line. Its default protocol pin is **3.2.5**, with maintained AdCP 3.0 and 3.1 compatibility. Install it with `npm install @adcp/sdk@^16.0.0`.
+
+## Upgrade from SDK 15
+
+- **AdCP 2 support is removed.** Sellers must support AdCP 3 capability discovery. Retired adapters, types, schema bundles and `allowV2` configuration are removed. See the [AdCP 2 retirement guide](../migration-drop-adcp-2.md).
+- **Reliable Reporting storage has its own package.** Install `@adcp/reporting-storage@~0.1.0` alongside the SDK and update the moved imports. The storage package remains experimental and pre-1.0 even though SDK 16 is stable. See the [package migration](../migration-reporting-storage-package.md) and [stability policy](../guides/REPORTING-STABILITY.md).
+- **Reporting row storage uses the protocol field names and source-timezone period dates.** Apply the migration and update custom object providers as described in the [row storage alignment guide](../migration-reporting-row-storage-alignment.md). Re-apply the warehouse sink migration when upgrading existing BigQuery sinks; see the [SDK changelog](https://github.com/adcontextprotocol/adcp-client/blob/main/CHANGELOG.md#1600).
+- **Compliance notice codes use the canonical names.** Replace `request_signing.required` with `request_signing_required_in_4_0` and `webhook_signing.legacy_hmac_fallback.removed` with `legacy_hmac_fallback_removed_in_4_0` in comparisons and dashboard keys.
+
+The [changelog](https://github.com/adcontextprotocol/adcp-client/blob/main/CHANGELOG.md#1600) includes the complete SDK 16 changes, including creative wire selection, account sync, property-list workflows and reporting fixes. Use the [release-bound upgrade worksheet](../migration-14.x-rc-worksheet.md) to check the exact package, runtime, peers and protocol bundle.
+
+SDK 16.0.0 also includes [#3350](https://github.com/adcontextprotocol/adcp-client/pull/3350): legacy creative delivery maps asset keys to the selected format's declared asset IDs, including image, click URL and tracker slots, while preserving occupied or ambiguous keys. See [creative delivery](../guides/CREATIVE-DELIVERY.md).
+
+## AdCP 3.3 preview
+
+The explicit `@adcp/sdk/identity-3.3` opt-in remains experimental. Promoting SDK 16 does not graduate that API or change the default wire pin to AdCP 3.3. See the [experimental identity guide](../migration-agent-identity-3.3.md).
+
+SDK 17 beta is the next release line for adopting the published AdCP 3.3 beta bundle. SDK 16 stays on AdCP 3.2 while that work proceeds. The `latest` channel stays on stable releases and `beta` carries the SDK 17 previews; a preview is published only once its protocol bundle is available and its integration passes validation.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@adcp/sdk",
-  "version": "16.0.0-beta.9",
+  "version": "16.1.0",
   "description": "AdCP SDK — client, server, and compliance harnesses for the AdContext Protocol (MCP + A2A)",
   "workspaces": [
     ".",