@blamejs/core 0.14.20 → 0.14.22

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.14.x
 
+- v0.14.22 (2026-06-04) — **RFC 9101 signed request objects: a JAR request-object builder, a classical JWS signer for external interop, and pushed authorization requests that carry `request=`.** The framework can now mint JWT-Secured Authorization Requests, completing the JAR surface whose verify side (`b.auth.jar.parse`) shipped in v0.12.31 with the builder documented as waiting on a classical signer. `b.auth.jws.sign` is that signer — a compact-JWS producer for RS / PS / ES / EdDSA keys that exists strictly for interop with external ecosystems (authorization servers and relying parties that require classical algorithms); the framework's own tokens stay on the PQC-first signer. `b.auth.jar.build` mints the RFC 9101 request object on top of it, and `pushAuthorizationRequest` composes both so a pushed authorization request can carry the signed `request=` parameter — the FAPI 2.0 message-signing client shape. The OAuth client-attestation builder now composes the same promoted signer internally, with identical wire output. **Added:** *`b.auth.jar.build` — RFC 9101 request-object builder* — Mints the JWT-Secured Authorization Request: header `typ: oauth-authz-req+jwt` (RFC 9101 §10.8), `iss` = the client_id and `aud` = the authorization server (§5), `response_type` and `client_id` required as claims (§4), and every authorization parameter carried as a claim. A params object containing `request` or `request_uri` is refused (§4 forbids nesting), reserved-claim collisions are refused, and a `params.client_id` that disagrees with `opts.clientId` is refused. The JWT carries a short `exp` (default 5 minutes, `expiresInMs`-overridable), `nbf`, and a random `jti` for FAPI 2.0 message signing. The signing algorithm derives from the supplied key; `none` is impossible. Round-trips against the existing `b.auth.jar.parse` verifier. · *`b.auth.jws.sign` — classical compact-JWS signer for external interop* — Signs a compact JWS with an RS / PS / ES (P-256/P-384/P-521) / EdDSA key, deriving the algorithm from the key per RFC 7518 §3.1 and refusing `none`, HMAC, and algorithm/key mismatches; a caller-supplied `header.alg` cannot override the derived algorithm (algorithm-substitution closed). This primitive exists for interop with external ecosystems that require classical JOSE — JAR request objects, attestation JWTs, and similar cross-vendor surfaces. It is never the framework-internal token default: `b.auth.jwt` remains the PQC-first signer for the framework's own tokens. · *Pushed authorization requests can carry a signed request object (RFC 9126 §3)* — `pushAuthorizationRequest` accepts a `signedRequestObject` option (`{ key, alg?, kid?, audience?, expiresInMs? }`). When present, the authorization parameters are minted into a JAR request object and the PAR body carries `request=<jwt>` plus only the client-authentication material RFC 9126 allows alongside it; the bare authorization parameters are not duplicated in the form. Absent, the existing plain-form path sends the same key/value set as before. · *`validateOpts.assignOwnEnumerable` — shared prototype-safe claim merge* — Consolidates the own-enumerable key merge with prototype-pollution and reserved-key guards that the request-object builder, the classical signer, and the client-attestation builder all need. Existing call sites compose it; behavior is unchanged. **Changed:** *OAuth client-attestation signing composes the promoted classical signer* — The attestation builder's private JWS assembly moved to the shared `b.auth.jws.sign` internals. Wire output is identical — same headers, claim order, algorithm selection, and accepted-algorithm set — and the `auth-oauth/attestation-*` error codes are preserved, so operators routing alerts on those codes see no change. · *Object key-copy sites compose the prototype-safe merge* — The long-running-operation status reader, the deny-path response-header merge, the HTTP client's cross-origin redirect header strip, and the trace-log logger wrapper now copy keys through `validateOpts.assignOwnEnumerable` instead of raw bracket-assign loops, so a `__proto__`/`constructor`/`prototype` key in the source object can never graft onto the copy. Behavior is otherwise unchanged. **Removed:** *Maintainer planning note removed from the repository* — `memory/specs/node-26-map-getorinsert-migration.md` — a maintainer-local planning note that had been committed since v0.11.2 — is gone from the repository (it was never part of the npm package). The Node 26 detector allowlists in the pattern catalog now carry their per-site annotations standalone, and `SECURITY.md` / `.pinact.yaml` no longer reference maintainer-local note paths. **Security:** *`jar.parse` returns prototype-safe authorization params (CWE-1321)* — A verified request object whose payload carried a `__proto__` claim (JSON.parse materializes it as an own key) previously grafted that claim's value onto the returned `params` object's prototype chain — a signature from a registered-but-malicious client was sufficient. The params object is now built through the prototype-safe merge; `__proto__`/`constructor`/`prototype` claim names are inert and are not copied. · *`jws.sign` refuses `b64` and `crit` protected-header members* — RFC 7797 `b64: false` changes the JWS signing input (the payload is signed raw, not base64url-encoded) and RFC 7515 §4.1.11 `crit` promises the producer implements every extension it names. The signer always base64url-encodes the payload and implements no header extensions, so passing either member through minted a JWS whose header advertised semantics its signature was not computed under — a compliant verifier derives a different signing input or refuses the critical header. Both members are now refused with `auth-jwt-external/sign-unsupported-header`; unencoded-payload support would land as an explicit feature, not a header pass-through. **Detectors:** *raw-key-copy-loop-bypasses-assign-own-enumerable* — Refuses raw `out[keys[i]] = src[keys[i]]` bracket-assign copy loops in `lib/` — the shape behind the `jar.parse` finding. Key-copy sites compose `validateOpts.assignOwnEnumerable`; the two genuinely-different bodies (audit-chain hash canonicalization, schema-shape transforms) carry allowlist entries with structural reasons. · *jose-header-passthrough-without-b64-crit-refusal* — Any caller-supplied JOSE protected-header pass-through must name-refuse `b64`/`crit` before signing. · *no-tracked-internal-notes gate* — The pattern catalog now refuses any tracked file under `memory/`, `notes/`, or `.scratch*` paths at commit time. **Migration:** *No action required; everything is additive* — The JAR builder, the classical signer, the PAR `signedRequestObject` option, and the shared merge helper are new surface. Existing `jar.parse` callers, attestation flows, and plain PAR requests behave exactly as before.
+
+- v0.14.21 (2026-06-04) — **SCIM Bulk forward references, an atomic api-encrypt replay gate, OID4VCI `x5c` proofs, HEAD responses without bodies, and a sweep that makes every accepted option do what its documentation says.** This release closes correctness and conformance gaps across recently shipped standards surfaces, plus a framework-wide sweep for options that were accepted but never read. SCIM `/Bulk` resolves `bulkId` cross-references regardless of operation order; the `apiEncrypt` middleware closes a concurrent-replay window on multi-replica session stores and validates its numeric options at boot; OID4VCI accepts `x5c` holder-key binding; `problemDetails` spreads its documented `extensions` object as RFC 9457 sibling members; `openapiServe` / `asyncapiServe` answer HEAD without a body; and a batch of entry points now throw on mistyped numeric options instead of silently defaulting. Options whose documented behavior was never implemented are now wired; options that could never do anything are removed and refuse as unknown. **Removed:** *Options that could never do anything now refuse as unknown* — The sweep removed accepted-but-impossible option keys: the `securityTxt` / `traceLogCorrelation` / tracer / TLS-RPT `audit` keys (these surfaces emit no audit rows), TLS-RPT `reportingMta` (not an RFC 8460 report field), `dsr.create` `observability` and create-time `verifyContext` (the per-call `process()` option of the same name is unchanged), `breakGlass.init` `now` (a single init-time timestamp cannot coherently override later time reads), WCAG `checkAll`, mail-deploy `compliance`, and bucket-ops `ca` (TLS trust is owned by the PQC agent — use `NODE_EXTRA_CA_CERTS` or `opts.agent`). Passing one of these now throws the standard unknown-option error. **Fixed:** *SCIM `/Bulk` resolves `bulkId` cross-references regardless of operation order (RFC 7644 §3.7.2)* — Forward references (an operation referencing a resource a later operation creates — the shape Okta and Entra emit) now execute in dependency order; circular references are refused with status 409; a reference to an undeclared `bulkId`, or to an operation that failed, fails that operation with `invalidValue`. References are resolved on BOTH surfaces the spec allows: operation data (`"value": "bulkId:u1"`) and the operation path (`PATCH /Groups/bulkId:g1` targeting a group created in the same request) — path references order, substitute, and fail exactly like data references. Previously an unresolvable reference passed the literal `bulkId:<id>` token through to your resource adapter as if it were a real id. The Bulk response keeps results in original request order, and `failOnErrors` still short-circuits. · *OID4VCI `x5c` holder-key binding implemented (RFC 7515 §4.1.6; OID4VCI §8.2.1.1)* — The proof-JWT verifier named `x5c` as a valid holder-key binding in its own error message but always refused `x5c`-only proofs. The certificate chain is now shape-validated (standard base64 DER, leaf first), the leaf certificate's public key becomes the holder key at the same self-asserted trust level as an inline `jwk`, and a new optional `validateX5c(chainDerBuffers, header)` hook lets the issuer enforce chain trust (PKI anchoring, EKU checks, attestation-CA allowlists) before the key is accepted. · *OID4VCI expired `c_nonce` refuses with a typed error* — A wallet whose access token outlived the shorter `c_nonce` TTL hit an untyped `TypeError` from the nonce comparison; issuance now refuses with `auth-oid4vci/c-nonce-expired` so handlers keying on typed codes respond correctly. The refusal direction is unchanged — no credential was ever minted on this path. · *OID4VP DCQL numeric claim-path segments must be non-negative integers (OpenID4VP 1.0 §7.1.1)* — A query carrying `-1`, `1.5`, `NaN`, or `Infinity` as an array-index segment previously validated and then silently never matched; it now throws at build time, surfacing the malformed query to the verifier author instead of degrading to a silent non-match. · *`problemDetails` `extensions` spread as sibling members (RFC 9457 §3.2)* — `send` and `create` documented an `extensions` object as the way to attach extension members, but emitted it as a literal nested `extensions` member instead. The keys now land as top-level siblings; reserved fields (`type` / `title` / `status` / `detail` / `instance`) cannot be overridden by an extension key, prototype-pollution-shaped keys are dropped, and a direct top-level key wins on collision. · *`cspReport` honors `audit: false`* — The documented audit knob was accepted but never read; the `csp.violation` audit row fired unconditionally for every report. `audit: false` now suppresses the row while reports are still normalized and delivered to `onReport`. The default (audit on) is unchanged, and `maxBytes` now throws at config time on a non-positive-integer value instead of silently reverting to 64 KiB. · *`openapiServe` / `asyncapiServe` HEAD responses carry no body (RFC 9110 §9.3.2)* — Both middlewares advertised GET/HEAD but answered HEAD with the full JSON / YAML document as a body. HEAD now returns the GET headers (including `Content-Length`) with an empty body, matching the rest of the framework's document-serving middlewares. · *Config-time numeric options throw on bad input across entry points* — A mistyped numeric option now throws at `create()` instead of silently becoming the default or garbage downstream: `scimServer` `maxPageSize` (a non-number propagated `NaN` into your `impl.list({ count })` and `ServiceProviderConfig`), `mail.send.deliver` `retry.maxAttempts` / `timeouts.mxLookupMs` / `timeouts.perHostMs`, the `redis` client `db` / `connectTimeoutMs` / `commandTimeoutMs` / `maxReconnectAttempts` (a non-numeric value made the reconnect-cap check false and silently disabled the bound entirely), `pubsub` cluster `pollIntervalMs` / `retentionMs` / `pruneEveryMs`, and SQS queue `visibilityTimeoutSec` / `waitTimeSec` (`0` short-polling stays valid). · *Accepted-but-unread options now do what their documentation says* — The db-backed `config` reloader's `audit` knob gates its `config.reload.*` rows; `honeytoken` honors the documented injectable audit sink (`{ audit: yourSink }`) instead of always emitting to the global sink; `dora`'s `observability` knob gates its report counter, and that counter now actually emits (it previously called a method the observability module doesn't export, and the failure was swallowed); flag evaluation-context `tenantKey` sets the tenant axis; the WCAG `aria` / `forms` / `tables` sub-scanners stamp `scopeUrl` on every finding so direct callers can correlate findings to a source document; `safeRedirect`'s documented `base` lets a same-origin absolute URL pass without an explicit allowlist (cross-origin still refused); and object-store bucket operations honor a per-call `actor` override on audit rows. **Security:** *api-encrypt concurrent-replay window closed (CWE-367)* — On a multi-replica session store, two concurrent requests carrying the same valid counter could both pass the monotonic replay check and execute twice — an attacker who captured one encrypted request could replay it concurrently and have a non-idempotent route run twice. The per-session path now claims each `(session, counter)` tuple through the same atomic nonce store the bootstrap path uses; exactly one concurrent request wins and the loser is refused with the standard rejection shape. The claim lives until the session expires (not just the staleness window), so a failed best-effort session write cannot re-open the tuple for late replay. The bootstrap response counter is also persisted correctly on serializing session stores, fixing a response-replay false positive on the second request of a session. · *api-encrypt envelope metadata is authenticated (AEAD-bound)* — The envelope's plaintext fields — `_ts`, `_nonce`, `_sid`, `_ctr` — were not bound into the ciphertext, so a captured request could be replayed past the staleness window with a rewritten `_ts`, and a captured response could be replayed to the client under a bumped `_ctr` (the client's monotonic check reads the plaintext field). Every request and response envelope now binds its metadata as AEAD associated data on both protocol halves; any rewrite fails authenticated decryption and is refused (server: standard rejection; client: typed `CLIENT_RESPONSE_TAMPERED`). The client also advances its response counter only after authenticated decryption, so a refused forgery cannot poison the monotonic check and block subsequent genuine responses. · *api-encrypt numeric options validated at boot* — A mistyped `replayWindowMs` (for example the string `"5m"`) made the timestamp-staleness comparison always false and silently disabled that replay defense. `replayWindowMs`, `maxDecryptedBytes`, and `pruneIntervalMs` now throw at config time across `create`, `client`, and `httpClient.encrypted`. **Detectors:** *Three new codebase-pattern gates* — An option key accepted by a validation allowlist must be read by the file that accepts it (an accepted-but-never-read key is an advertised knob with no implementation); entry-point numeric options must validate rather than coerce-or-default (`Number(opts.x) || DEFAULT` swallows exactly the typo the config-time tier exists to surface); and a dispatcher that admits HEAD must suppress the response body somewhere in the same file. **Migration:** *Delete removed option keys; everything else is a behavioral fix or additive* — If you pass one of the removed keys listed under Removed, delete it — it did nothing before and now throws the standard unknown-option error. Callers passing valid options see conforming behavior with no code change; the new `validateX5c` hook and the per-finding `scopeUrl` stamp are additive. · *apiEncrypt middleware and client must upgrade together* — Binding the envelope metadata into the AEAD changes what the ciphertext authenticates, so a pre-0.14.21 client cannot talk to a 0.14.21 middleware or vice versa — mixed-version peers fail authenticated decryption and are refused. Both halves ship in this package; a single service upgrading normally is unaffected. If separate services pin different framework versions and speak apiEncrypt to each other, upgrade them together.
+
 - v0.14.20 (2026-06-02) — **OAuth Rich Authorization Requests and client attestation, a sealed-field unseal rate cap, DMARC forensic-report parsing, monitor-mode browser-isolation headers, and FedCM / Storage-Access fetch-metadata.** This release extends several standards surfaces the framework already covered in part. The OAuth client gains RFC 9396 Rich Authorization Requests: a typed `authorizationDetails` array is validated before the request and the granted details in the token response are cross-checked, refusing a grant the OP broadened beyond what was asked. The client also gains the OAuth 2.0 Attestation-Based Client Authentication primitives — it can build the `OAuth-Client-Attestation` / `-PoP` JWT pair and verify an inbound attestation. Sealed-field reads gain an opt-in unseal-failure rate cap that throttles a decryption-oracle / brute-force burst against attacker-written sealed columns (CWE-307). The inbound mail stack gains a DMARC forensic (RUF) report parser, the inverse of the aggregate-report parser. On the browser side, the security-headers middleware adds report-only COOP / COEP / Document-Policy variants for safe cross-origin-isolation rollout plus the embedder Require-Document-Policy and Service-Worker-Allowed headers, and the fetch-metadata middleware recognizes the FedCM `webidentity` destination and the Storage-Access request headers first-class. Observability adds a batch of current OpenTelemetry semantic-convention attributes. Every addition is additive or opt-in: an operator who sets no new option, and configures no rate cap, sees prior behavior unchanged. **Added:** *OAuth client: RFC 9396 Rich Authorization Requests (`authorizationDetails`)* — The OAuth / OIDC client accepts an `authorizationDetails` array (RFC 9396 §2 — each element a typed object) on the authorization and pushed-authorization-request paths; it is validated at config time (every element must be an object carrying a string `type`) and serialized as the `authorization_details` parameter, with a cap on the serialized payload. When `verifyAuthorizationDetails` is set, the granted `authorization_details` returned in the token response (RFC 9396 §7) is cross-checked against the request, and a grant that exceeds what was requested is refused — defending against an upstream broadened-grant privilege escalation. Without `authorizationDetails`, the request is unchanged. · *OAuth 2.0 Attestation-Based Client Authentication* — `b.auth.oauth.buildClientAttestation` and `buildClientAttestationPop` mint the `OAuth-Client-Attestation` JWT (a client-backend-signed assertion binding a per-instance key, `typ: oauth-client-attestation+jwt`) and its per-instance `OAuth-Client-Attestation-PoP` proof; `verifyClientAttestation` validates the pair, including the alg allowlist (`ATTESTATION_ALGS`), the audience, and a constant-time `jti` check. This is the wallet / per-device client-authentication shape used in OpenID4VCI and the EUDI Wallet, an alternative to a shared `client_secret`. · *`b.cryptoField.configureUnsealRateCap` — sealed-field decryption-oracle throttle* — An opt-in per-(actor, table, column) sliding-window cap on sealed-column unseal failures. A DB-write attacker who can place crafted `vault:` / `vault.aad:` bytes in sealed columns can force KEM decapsulation / AEAD verification on attacker-controlled input on every read; past `threshold` failures within `windowMs`, further unseal attempts for that tuple are refused for `cooldownMs` with a typed `CryptoFieldRateError` and a distinct `system.crypto.unseal_rate_exceeded` audit event (CWE-307; OWASP ASVS v5 §2.2.1; NIST SP 800-63B §5.2.2). Default off — with no cap configured, `unsealRow` behaves exactly as before (null the field, emit `system.crypto.unseal_failed`); the cap is count-based and lazily pruned, with no background timer. · *`b.mail.dmarc.parseForensicReport` — RFC 6591 forensic (RUF) report parser* — Parses a DMARC failure (forensic) report: a `multipart/report; report-type=feedback-report` message (RFC 6591 §3) whose `message/feedback-report` subpart carries the `Feedback-Type: auth-failure` fields, with the required-field set validated (`Auth-Failure` and the other §3.1 fields) and a part-count and byte cap bounding a hostile report. It is the inbound inverse of the aggregate-report path, so an operator ingesting RUF mail has a parser symmetric with the existing aggregate parser and the v0.14.19 aggregate builder. · *Monitor-mode cross-origin-isolation and embedder headers* — `b.middleware.securityHeaders` gains `coopReportOnly`, `coepReportOnly`, and `documentPolicyReportOnly` — set a policy string to emit the matching `*-Report-Only` header so a UA evaluates and reports violations without enforcing, the safe way to stage a COOP / COEP / Document-Policy rollout (WHATWG HTML cross-origin isolation; W3C Document Policy). `requireDocumentPolicy` emits the embedder `Require-Document-Policy` a parent demands of subframes, and `serviceWorkerAllowed` emits `Service-Worker-Allowed` to broaden a service worker's registration scope (W3C Service Workers). All default off. · *fetch-metadata: FedCM `webidentity` and Storage-Access headers* — `b.middleware.fetchMetadata` recognizes the `webidentity` `Sec-Fetch-Dest` (a FedCM credentialed request) first-class and adds `deniedDest` — a list of destinations refused outright on the gated methods regardless of site, so a `webidentity` request hitting a route that is not an identity endpoint is refused. `allowStorageAccess` (default true) governs whether a request carrying `Sec-Fetch-Storage-Access: active` / `inactive` (the Storage Access API headers) is allowed, and `strictDest` throws at config time on an `allowedDest` / `deniedDest` value outside the known `Sec-Fetch-Dest` vocabulary, catching a typo at boot. · *OpenTelemetry semantic-convention attributes* — The observability semantic-convention map gains a batch of current stable attributes: `peer.service`, the `faas.*` function attributes (`name` / `version` / `instance` / `trigger`), `deployment.environment.name`, `telemetry.distro.*`, `otel.scope.*`, and a Kubernetes subset (`k8s.cluster.name` and the node / container / cronjob / daemonset / job / replicaset / statefulset names), so a span or metric carrying these keys is recognized and emitted under the canonical name. **Fixed:** *`b.auth.sdJwtVc.holder` signed the key-binding JWT with a non-key-derived algorithm* — The holder helper defaulted the key-binding JWT (KB-JWT) signing algorithm to a fixed `ES256` regardless of the holder key type, so a non-EC-P-256 holder key produced a presentation that either could not be built (an Ed25519 or P-384 key) or whose KB-JWT header advertised `ES256` while the signature used the actual key — a self-invalid token a verifier rejects. The algorithm is now derived from the holder key: ES256 / ES384 by EC curve, EdDSA for Ed25519 / Ed448, and ML-DSA-87 / ML-DSA-65 for an ML-DSA key. An RSA holder key, which has no supported KB-JWT algorithm, is refused at `holder.create` with a clear error instead of producing a broken presentation. An EC P-256 holder key, and any explicit `algorithm`, behave exactly as before. **Security:** *Throttle a sealed-column decryption oracle (opt-in)* — `b.cryptoField.configureUnsealRateCap` lets an operator bound repeated unseal failures against sealed columns, so an attacker who can write crafted bytes into a sealed field cannot hammer the KEM / AEAD verify path indefinitely while only an off-band alert rule notices the burst (CWE-307). It is opt-in because a sensible threshold and window depend on a deployment's legitimate sealed-read volume; the always-on defense (null the field plus an audit event on every unseal failure) is unchanged. · *Refuse a broadened OAuth grant* — With `verifyAuthorizationDetails` enabled, the OAuth client refuses a token response whose granted `authorization_details` exceed the requested set (RFC 9396 §7), so a compromised or misbehaving authorization server cannot silently widen a client's authorization beyond what the request asked for. **Migration:** *No action required; additions are additive or opt-in* — The OAuth `authorizationDetails` request parameter, the granted-details cross-check, the client-attestation builders / verifier, the sealed-field unseal rate cap, the DMARC forensic-report parser, the monitor-mode and embedder browser headers, the fetch-metadata FedCM / Storage-Access options, and the new OpenTelemetry attribute keys are all additive or opt-in. A client that passes no `authorizationDetails`, an operator who calls no `configureUnsealRateCap`, and a security-headers / fetch-metadata configuration that sets none of the new options all see prior behavior byte-for-byte unchanged. The one behavior change is the SD-JWT VC holder fix: a `b.auth.sdJwtVc.holder` built with an RSA holder key is now refused at `holder.create` (RSA has no supported KB-JWT algorithm; it previously produced a self-invalid presentation) — switch such a holder to an EC P-256 / P-384, Ed25519, or ML-DSA key. EC P-256 holders and any explicit `algorithm` are unaffected.
 
 - v0.14.19 (2026-06-02) — **ZIP64 write completes large-archive support, plus a PKCE-downgrade defense, SCIM Bulk, OID4VCI kid-resolution, SPF macros, DMARC report building, and OpenAPI 3.2.** This release fills out several standards the framework previously read but could not write, or advertised but did not fully implement. The ZIP writer now emits ZIP64, so archives larger than 65535 entries or 4 GiB are produced instead of refused (the reader gained ZIP64 in the previous release; the two now round-trip). The OAuth client refuses an OP whose discovery metadata advertises PKCE methods without S256 — closing a stripped-S256 downgrade. The SCIM server gains opt-in Bulk operations, the OID4VCI issuer accepts a kid-resolution hook for EUDI-Wallet attested-key proofs (and a latent cache-cleanup crash on the issuance path is fixed), the inbound SPF check expands RFC 7208 macros and evaluates the exists mechanism, a DMARC aggregate-report builder is the inverse of the existing parser, and the OpenAPI emitter supports 3.2 with webhooks and a JSON Schema dialect. Every behavior-changing addition is opt-in or additive: classic archives emit byte-for-byte unchanged, OpenAPI still defaults to 3.1.0, SCIM Bulk stays disabled unless configured, and the PKCE refusal only fires for an OP that explicitly advertises a non-S256 method set. **Added:** *`b.archive.zip` writes ZIP64* — When an archive exceeds 65535 entries, or any entry's compressed/uncompressed size or local-header offset exceeds 4 GiB, the writer now emits ZIP64 — the classic field carries the `0xFFFF`/`0xFFFFFFFF` sentinel and a ZIP64 extended-information extra field (header id `0x0001`) plus a ZIP64 EOCD record and locator are written (APPNOTE 6.3.10 §4.3.14 / §4.3.15 / §4.4.8 / §4.5.3). Archives within the classic limits emit byte-for-byte unchanged, and `b.archive.read.zip` reads the ZIP64 output transparently. Previously the writer refused past 65535 entries. · *`b.middleware.scimServer` opt-in SCIM 2.0 Bulk operations* — A `/Bulk` POST endpoint (RFC 7644 §3.7) with `maxOperations` / `maxPayloadSize` caps, `bulkId` cross-reference resolution (§3.7.2), and `failOnErrors` short-circuiting, advertised in `ServiceProviderConfig` when enabled via `opts.bulk`. The request body is read through the bounded stream reader. Bulk stays disabled (and `/Bulk` returns 501) unless `opts.bulk` is set. · *`b.auth.oid4vci` accepts a `resolveKid` proof-key hook* — An OID4VCI proof JWT that carries a header `kid` without an inline `jwk` (the EUDI-Wallet attested-key shape) can now be verified by supplying `create({ resolveKid(kid, header) })`, which maps the key id to a holder key. The resolved key passes the same alg/key-type cross-check (CVE-2026-22817) as the inline path before import and becomes the credential's `cnf` binding. Without a resolver, a kid-only proof is still refused, exactly as before. · *SPF macro expansion + `exists`; DMARC aggregate-report builder* — `b.mail.spf.verify` now expands RFC 7208 §7 macros (`%{i}`/`%{s}`/`%{l}`/`%{d}`/`%{o}`/`%{h}`/`%{v}` with the reverse / digit-count / delimiter transformers and `%%`/`%_`/`%-` escapes) and evaluates the `exists` mechanism (§5.7); the §4.6.4 DNS-lookup and void-lookup ceilings still bound every macro-driven query. New `b.mail.dmarc.buildAggregateReport` serializes a DMARC aggregate (RUA) report to RFC 7489 Appendix C XML — the inverse of `parseAggregateReport` — with optional gzip and XML-metacharacter escaping of observed identifiers. · *OpenAPI 3.2 — webhooks and `jsonSchemaDialect`* — `b.openapi.create({ openapi: "3.2.0" })` opts into OpenAPI 3.2; a `webhook(name, method, opts)` builder registers top-level `webhooks` (API-initiated out-of-band operations), and `jsonSchemaDialect` declares the document's default JSON Schema dialect. `parse()` accepts 3.1.x or 3.2.x and validates webhook operations (including dangling-security references) with the same rules as paths. 3.1.0 stays the default emitted version and existing 3.1 documents are unchanged. **Fixed:** *OID4VCI issuance crashed on cache cleanup* — The pre-authorized-code exchange and credential-issuance paths called `.delete()` on their internal `b.cache` stores, which expose `del()` — so the cleanup step threw and the issuance flow could not complete end-to-end. The three call sites now use `del()`. **Security:** *PKCE-downgrade defense for OAuth / OIDC clients* — The OAuth client already mandates PKCE-S256 on its own side but never inspected the OP's published `code_challenge_methods_supported`. It now refuses, at `authorizationUrl` / `pushAuthorizationRequest`, an OP whose discovery metadata advertises that field without `"S256"` (plain-only / empty) — blocking a stripped-S256 downgrade that would otherwise drive the client into an authorization request the OP claims it cannot verify (RFC 9700 §4.13, RFC 7636). An OP that does not publish the field, and static-endpoint clients that perform no discovery, are unaffected. **Migration:** *No action required; additions are additive or opt-in* — ZIP64 write is additive — archives within the classic 65535-entry / 4 GiB limits emit identical bytes, and the writer simply no longer refuses larger ones. SCIM Bulk, the OID4VCI `resolveKid` hook, the DMARC report builder, and OpenAPI 3.2 are all opt-in (OpenAPI still defaults to 3.1.0). The SPF `exists` mechanism, previously returning permerror, now evaluates per RFC 7208 — `b.mail.spf.verify` returns a verdict and refuses nothing. The PKCE-downgrade refusal only fires for an OP that explicitly advertises a non-S256 PKCE method set.

package/index.js

@@ -32,7 +32,7 @@ _tls.DEFAULT_MIN_VERSION = "TLSv1.3";
  *                 error-handler, body-parser, csp-nonce, compression,
  *                 health, api-encrypt), httpClient, websocket,
  *                 websocketChannels, nonceStore
- *   Auth:         auth.{password,totp,passkey,jwt,oauth,lockout}, authHeader
+ *   Auth:         auth.{password,totp,passkey,jwt,jws,oauth,jar,lockout}, authHeader
  *   Render:       template, render, staticServe, forms, errorPage
  *   App:          createApp, jobs, mail, mailBounce, scheduler,
  *                 appShutdown
@@ -247,6 +247,10 @@ var auth = {
   jwt:      Object.assign({},
               require("./lib/auth/jwt"),
               { verifyExternal: require("./lib/auth/jwt-external").verifyExternal }),
+  // Classical-JOSE signer (RS/PS/ES/EdDSA) for external-ecosystem interop —
+  // OPs/RPs that require a classical-signed request object / assertion. Never
+  // the framework-internal token default; b.auth.jwt stays PQC-only.
+  jws:      { sign: require("./lib/auth/jwt-external").signExternal },
   oauth:    require("./lib/auth/oauth"),
   jar:      require("./lib/auth/jar"),
   lockout:  require("./lib/auth/lockout"),

package/lib/auth/jar.js

@@ -15,14 +15,26 @@
  *   can verify they arrived exactly as the client sent them.
  *
  *   <code>b.auth.jar.parse(jar, opts)</code> verifies an incoming
- *   request object: the signature is checked through
- *   <code>b.auth.jwt.verifyExternal</code> (mandatory <code>algorithms</code>
- *   allowlist — no <code>alg: "none"</code>, no HMAC-vs-RSA confusion,
- *   no JWE-on-a-JWS-verifier), <code>iss</code> is pinned to the
- *   expected <code>clientId</code>, <code>aud</code> to this server's
- *   issuer identifier, the request object's <code>client_id</code>
- *   claim must match the client, and the authorization parameters are
- *   returned with the JWT envelope claims stripped.
+ *   request object (the authorization-server side): the signature is
+ *   checked through <code>b.auth.jwt.verifyExternal</code> (mandatory
+ *   <code>algorithms</code> allowlist — no <code>alg: "none"</code>, no
+ *   HMAC-vs-RSA confusion, no JWE-on-a-JWS-verifier), <code>iss</code>
+ *   is pinned to the expected <code>clientId</code>, <code>aud</code> to
+ *   this server's issuer identifier, the request object's
+ *   <code>client_id</code> claim must match the client, and the
+ *   authorization parameters are returned with the JWT envelope claims
+ *   stripped.
+ *
+ *   <code>b.auth.jar.build(params, opts)</code> mints a request object
+ *   (the client side): the authorization-request parameters become
+ *   claims of a JWT signed with the client's classical key via
+ *   <code>b.auth.jws.sign</code> (RS/PS/ES/EdDSA — the interop algs an
+ *   authorization server accepts), typed <code>oauth-authz-req+jwt</code>,
+ *   with <code>iss</code>/<code>aud</code> pinned and a short FAPI-2
+ *   <code>exp</code>. <code>build</code> and <code>parse</code>
+ *   round-trip. The framework's own tokens stay PQC-signed
+ *   (<code>b.auth.jwt</code>); JAR signs classically only because no
+ *   standard authorization server verifies a PQC request object today.
  *
  *   <strong>Anti-nesting (RFC 9101 §6.3):</strong> a request object
  *   may not itself carry a <code>request</code> or <code>request_uri</code>
@@ -35,33 +47,48 @@
  *   shapes against a JWKS public-key trust source. JAR adds the
  *   request-object-specific bindings on top.
  *
- *   <strong>Emitting</strong> a request object (the client side) is
- *   deferred-with-condition: it requires signing with the client's
- *   key under a classical JWS algorithm (RS256 / ES256 / EdDSA), and
- *   the framework's own JWT signer (<code>b.auth.jwt.sign</code>) is
- *   PQC-only (ML-DSA / SLH-DSA) for the tokens the framework itself
- *   issues — a PQC-signed request object would not interoperate with
- *   any standard authorization server today. blamejs sits on the
- *   authorization-server side here (it verifies client request
- *   objects); client-side emission re-opens when a classical
- *   <code>b.auth.jws.sign</code> primitive lands or operators surface
- *   the need. Until then clients sign their request objects with
- *   their existing JOSE tooling.
+ *   The request object is signed with a classical JWS algorithm
+ *   (RS/PS/ES/EdDSA) because no standard authorization server verifies a
+ *   PQC-signed request object today; the framework's own JWT signer
+ *   (<code>b.auth.jwt.sign</code>) stays PQC-only (ML-DSA / SLH-DSA) for
+ *   the tokens blamejs itself issues. <code>build</code> composes
+ *   <code>b.auth.jws.sign</code> for the classical signature — the
+ *   client-side emission this module previously left to the operator's
+ *   own JOSE tooling now ships in-framework.
  *
  * @card
- *   RFC 9101 JWT-Secured Authorization Request (server side) — verify
- *   the OAuth request object with mandatory alg allowlist, iss +
- *   client_id binding, audience pinning, and anti-nesting.
+ *   RFC 9101 JWT-Secured Authorization Request — build the client
+ *   request object (classical JWS, typed, iss/aud-pinned, short exp) and
+ *   verify it on the server with mandatory alg allowlist, client_id
+ *   binding, and anti-nesting.
  */
 
 var jwtExternal = require("./jwt-external");
 var validateOpts = require("../validate-opts");
+var C = require("../constants");
+var bCrypto = require("../crypto");
 var { defineClass } = require("../framework-error");
 
 var AuthJarError = defineClass("AuthJarError", { alwaysPermanent: true });
 
 var JAR_TYP = "oauth-authz-req+jwt";
 
+// RFC 9101 §4 — a request object MUST carry response_type + client_id as
+// claims (they are REQUIRED OAuth 2.0 authorization-request parameters).
+var REQUIRED_REQUEST_PARAMS = ["response_type", "client_id"];
+
+// Claims the builder sets itself from opts (iss = client_id, aud =
+// audience) plus the JWT lifetime claims it mints (exp/nbf/iat/jti).
+// Operator params colliding with iss / aud are refused so a params.iss
+// can't shadow the builder-pinned issuer; the lifetime claims are owned by
+// the builder's exp/nbf/jti opts, not by free-form params.
+var BUILDER_OWNED_CLAIMS = ["iss", "aud", "exp", "nbf", "iat", "jti"];
+
+// Default request-object lifetime. FAPI-2 message-signing wants a short
+// window; 5 minutes mirrors the attestation-PoP floor and is overridable
+// via opts.expiresInMs.
+var DEFAULT_JAR_EXPIRES_MS = C.TIME.minutes(5);
+
 // JWT-standard claims that are request-object envelope metadata, not
 // OAuth authorization parameters — stripped from the returned params.
 var ENVELOPE_CLAIMS = ["iss", "aud", "exp", "iat", "nbf", "jti"];
@@ -164,16 +191,151 @@ async function parse(jar, opts) {
       "jar.parse: request object must not carry `request` or `request_uri` (RFC 9101 §6.3)");
   }
 
-  var params = {};
-  var keys = Object.keys(payload);
-  for (var i = 0; i < keys.length; i++) {
-    if (ENVELOPE_CLAIMS.indexOf(keys[i]) === -1) params[keys[i]] = payload[keys[i]];
-  }
+  // Authorization parameters = every claim minus the JWT envelope.
+  // assignOwnEnumerable skips the prototype-pollution sentinel keys — a
+  // verified-but-hostile request object carrying a `__proto__` claim
+  // (JSON.parse materializes it as an own key) must not graft onto the
+  // returned params object's prototype chain (CWE-1321).
+  var params = validateOpts.assignOwnEnumerable({}, payload, ENVELOPE_CLAIMS);
   return { params: params, claims: payload };
 }
 
+/**
+ * @primitive b.auth.jar.build
+ * @signature b.auth.jar.build(params, opts)
+ * @since     0.14.22
+ * @status    stable
+ * @compliance soc2
+ * @related   b.auth.jar.parse, b.auth.jws.sign
+ *
+ * Mint an RFC 9101 request object — the client side of JWT-Secured
+ * Authorization Requests. The authorization-request parameters in
+ * <code>params</code> become claims of a JWT signed with the client's
+ * classical key, ready to send as the <code>request</code> parameter (or
+ * pushed through PAR). The inverse of <code>b.auth.jar.parse</code>; the
+ * two round-trip.
+ *
+ * The protected header carries <code>typ: "oauth-authz-req+jwt"</code>
+ * (RFC 9101 §10.8 — explicit typing closes the cross-JWT-confusion vector
+ * where a token minted for another purpose is replayed as a request
+ * object). <code>iss</code> is set to <code>opts.clientId</code> and
+ * <code>aud</code> to <code>opts.audience</code> — the authorization
+ * server's issuer identifier (RFC 9101 §5; the FAPI 2.0 message-signing
+ * profile requires both). <code>response_type</code> and
+ * <code>client_id</code> are REQUIRED claims (RFC 9101 §4); the builder
+ * refuses if either is absent from <code>params</code>. A request object
+ * <strong>MUST NOT</strong> nest <code>request</code> /
+ * <code>request_uri</code> (RFC 9101 §4) — supplying either in
+ * <code>params</code> is refused at build, the mirror of
+ * <code>parse</code>'s anti-nesting check.
+ *
+ * <code>exp</code> defaults to 5 minutes (FAPI-2 wants a short signing
+ * window; tune via <code>opts.expiresInMs</code>); <code>nbf</code> is set
+ * to <code>iat</code> and a random <code>jti</code> is minted so the AS can
+ * single-use the object. The signing <code>alg</code> is derived from
+ * <code>opts.key</code> via <code>b.auth.jws.sign</code> (RS/PS/ES/EdDSA);
+ * <code>alg: "none"</code> is impossible — the signer refuses it. This is
+ * the classical-interop path: the framework's own tokens stay PQC-signed.
+ *
+ * @opts
+ *   {
+ *     clientId:      string,           // required — → iss + must equal params.client_id
+ *     audience:      string,           // required — AS issuer identifier → aud
+ *     key:           KeyObject|PEM|JWK, // required — client's classical signing key
+ *     alg?:          string,           // JWS alg override (default inferred from the key)
+ *     kid?:          string,           // protected-header kid (JWKS selection at the AS)
+ *     expiresInMs?:  number,           // exp = iat + this (default: 5m; positive int)
+ *   }
+ *
+ * @example
+ *   var ro = b.auth.jar.build(
+ *     { response_type: "code", client_id: "s6BhdRkqt3",
+ *       redirect_uri: "https://app/cb", scope: "openid", state: "xyz" },
+ *     { clientId: "s6BhdRkqt3", audience: "https://as.example.com", key: clientKey, kid: "c1" });
+ *   // → "eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWF1dGh6LXJlcStqd3QiLCJraWQiOiJjMSJ9..."
+ */
+function build(params, opts) {
+  if (params === null || typeof params !== "object" || Array.isArray(params)) {
+    throw new AuthJarError("auth-jar/bad-params",
+      "jar.build: params must be a plain object of authorization-request parameters");
+  }
+  validateOpts.requireObject(opts, "jar.build", AuthJarError, "auth-jar/bad-opts");
+  validateOpts(opts, ["clientId", "audience", "key", "alg", "kid", "expiresInMs"], "jar.build");
+  validateOpts.requireNonEmptyString(opts.clientId, "jar.build: clientId", AuthJarError, "auth-jar/bad-client-id");
+  validateOpts.requireNonEmptyString(opts.audience, "jar.build: audience", AuthJarError, "auth-jar/bad-audience");
+  if (opts.key === undefined || opts.key === null) {
+    throw new AuthJarError("auth-jar/no-key", "jar.build: key (the client's signing key) is required");
+  }
+  validateOpts.optionalNonEmptyString(opts.alg, "jar.build: alg", AuthJarError, "auth-jar/bad-alg");
+  validateOpts.optionalNonEmptyString(opts.kid, "jar.build: kid", AuthJarError, "auth-jar/bad-kid");
+  validateOpts.optionalPositiveInt(opts.expiresInMs, "jar.build: expiresInMs", AuthJarError, "auth-jar/bad-expiry");
+
+  // RFC 9101 §4 — a request object MUST NOT itself carry request /
+  // request_uri (recursion / confused-deputy vector). Refuse at build, the
+  // mirror of parse's anti-nesting check.
+  if (params.request !== undefined || params.request_uri !== undefined) {
+    throw new AuthJarError("auth-jar/nested-request",
+      "jar.build: params must not carry `request` or `request_uri` " +
+      "(RFC 9101 §4 — a request object cannot nest another)");
+  }
+  // The builder owns iss/aud and the JWT lifetime claims — a params key
+  // colliding with one would either shadow a builder-pinned binding (iss /
+  // aud) or fight the exp/nbf/jti the builder mints. Refuse so the operator
+  // routes lifetime through opts.expiresInMs and the identity bindings
+  // through clientId / audience.
+  for (var bi = 0; bi < BUILDER_OWNED_CLAIMS.length; bi += 1) {
+    var owned = BUILDER_OWNED_CLAIMS[bi];
+    if (Object.prototype.hasOwnProperty.call(params, owned)) {
+      throw new AuthJarError("auth-jar/reserved-claim",
+        "jar.build: params must not set the builder-owned claim '" + owned +
+        "' (iss/aud come from clientId/audience; exp/nbf/iat/jti are minted by the builder)");
+    }
+  }
+  // RFC 9101 §4 — response_type + client_id are REQUIRED request parameters.
+  for (var ri = 0; ri < REQUIRED_REQUEST_PARAMS.length; ri += 1) {
+    var req = REQUIRED_REQUEST_PARAMS[ri];
+    if (params[req] === undefined || params[req] === null || params[req] === "") {
+      throw new AuthJarError("auth-jar/missing-required-param",
+        "jar.build: params is missing the required '" + req + "' claim (RFC 9101 §4)");
+    }
+  }
+  // An explicit params.client_id MUST match opts.clientId — the iss the
+  // builder pins. A divergence is an operator mistake that would mint an
+  // object parse() then refuses on the client_id-mismatch path.
+  if (params.client_id !== opts.clientId) {
+    throw new AuthJarError("auth-jar/client-id-mismatch",
+      "jar.build: params.client_id ('" + params.client_id + "') must equal opts.clientId ('" +
+      opts.clientId + "')");
+  }
+
+  var nowSec = Math.floor(Date.now() / C.TIME.seconds(1));
+  var ttlMs = typeof opts.expiresInMs === "number" ? opts.expiresInMs : DEFAULT_JAR_EXPIRES_MS;
+  var claims = {
+    iss: opts.clientId,                                   // RFC 9101 §5 — iss = client_id
+    aud: opts.audience,                                   // RFC 9101 §5 — aud = AS issuer identifier
+    iat: nowSec,
+    nbf: nowSec,
+    exp: nowSec + Math.floor(ttlMs / C.TIME.seconds(1)),  // FAPI-2 short window
+    jti: bCrypto.toBase64Url(bCrypto.generateBytes(16)),  // single-use marker for the AS
+  };
+  // Every authorization-request parameter becomes a claim. Proto-pollution
+  // sentinels skipped; builder-owned claims passed as reserved so a stray
+  // collision (already refused above) can never shadow the minted set.
+  validateOpts.assignOwnEnumerable(claims, params, BUILDER_OWNED_CLAIMS);
+
+  // Sign through the classical-JWS primitive (b.auth.jws.sign). The typed
+  // header + alg-from-key + none-refusal all live there.
+  return jwtExternal.signExternal(claims, {
+    privateKey: opts.key,
+    alg:        opts.alg,
+    kid:        opts.kid,
+    typ:        JAR_TYP,
+  });
+}
+
 module.exports = {
   parse:        parse,
+  build:        build,
   JAR_TYP:      JAR_TYP,
   AuthJarError: AuthJarError,
 };

package/lib/auth/jwt-external.js

@@ -109,6 +109,14 @@ function _b64urlDecode(s) {
   return Buffer.from(padded, "base64");
 }
 
+// EC named-curve → the one ES* alg whose hash matches it (RFC 7518 §3.4).
+// A P-256 key signs ES256 and only ES256; the curve fixes the hash, so a
+// header alg of ES384 over a P-256 signature is self-inconsistent and a
+// conforming verifier rejects it. Naming the binding here lets the signer
+// derive the right header alg from the key instead of trusting a caller-
+// supplied alg the key can't actually produce.
+var _EC_CURVE_ALG = { prime256v1: "ES256", secp384r1: "ES384", secp521r1: "ES512" };
+
 function _verifyParamsForAlg(alg) {
   if (alg === "RS256") return { hash: "sha256", padding: nodeCrypto.constants.RSA_PKCS1_PADDING };
   if (alg === "RS384") return { hash: "sha384", padding: nodeCrypto.constants.RSA_PKCS1_PADDING };
@@ -124,6 +132,104 @@ function _verifyParamsForAlg(alg) {
     "alg '" + alg + "' is not supported by verifyExternal");
 }
 
+// _toPrivateKey — import the operator's classical signing key from any of
+// the three shapes node:crypto understands (KeyObject / PEM string|Buffer /
+// private JWK). The PQC framework signer (lib/auth/jwt.js) never travels
+// this path; this is the classical-interop importer only.
+function _toPrivateKey(value, label) {
+  if (!value) {
+    throw new AuthError("auth-jwt-external/sign-no-key", label + ": privateKey is required");
+  }
+  if (value instanceof nodeCrypto.KeyObject) return value;
+  try {
+    if (typeof value === "string" || Buffer.isBuffer(value)) {
+      return nodeCrypto.createPrivateKey({ key: value, format: "pem" });
+    }
+    if (typeof value === "object" && value.kty) {
+      return nodeCrypto.createPrivateKey({ key: value, format: "jwk" });
+    }
+  } catch (e) {
+    throw new AuthError("auth-jwt-external/sign-bad-key",
+      label + ": private key parse failed: " + ((e && e.message) || String(e)));
+  }
+  throw new AuthError("auth-jwt-external/sign-bad-key",
+    label + ": privateKey must be a PEM string/Buffer, private JWK object, or KeyObject");
+}
+
+// _resolveSignAlg — derive the JWS `alg` for a private key, validating any
+// explicit override against what the key can actually produce. A signer
+// that emitted a fixed `alg` header while signing with an incompatible key
+// (e.g. an `ES256` header over an Ed25519 signature) would mint a token no
+// conforming verifier accepts; deriving the alg from the key — or refusing
+// an incompatible explicit alg BEFORE signing — closes that self-invalid
+// shape. RFC 7518 §3.1 maps each `alg` to the key type it requires.
+function _resolveSignAlg(explicitAlg, privateKey, label) {
+  var kty = privateKey.asymmetricKeyType;
+  var defaultAlg, compatible;
+  if (kty === "ec") {
+    var curve = (privateKey.asymmetricKeyDetails && privateKey.asymmetricKeyDetails.namedCurve) || "";
+    defaultAlg = _EC_CURVE_ALG[curve];
+    if (!defaultAlg) {
+      throw new AuthError("auth-jwt-external/sign-key-unsupported",
+        label + ": EC curve '" + curve + "' has no JWS alg (use P-256 / P-384 / P-521)");
+    }
+    compatible = [defaultAlg];                       // an EC curve pins exactly one ES alg
+  } else if (kty === "rsa") {
+    defaultAlg = "RS256";
+    compatible = ["RS256", "RS384", "RS512", "PS256", "PS384", "PS512"];
+  } else if (kty === "rsa-pss") {
+    defaultAlg = "PS256";
+    compatible = ["PS256", "PS384", "PS512"];        // an RSA-PSS key cannot produce an RS* signature
+  } else if (kty === "ed25519" || kty === "ed448") {
+    defaultAlg = "EdDSA";
+    compatible = ["EdDSA"];
+  } else {
+    throw new AuthError("auth-jwt-external/sign-key-unsupported",
+      label + ": key type '" + String(kty) + "' is not a supported JWS signing key (EC / RSA / Ed25519 / Ed448)");
+  }
+  if (explicitAlg === undefined || explicitAlg === null) return defaultAlg;
+  if (explicitAlg === "none" || REFUSED_ALGS.indexOf(explicitAlg) !== -1) {
+    throw new AuthError("auth-jwt-external/sign-alg-refused",
+      label + ": alg '" + explicitAlg + "' is refused (HMAC / none are never valid for an asymmetric signer)");
+  }
+  if (SUPPORTED_CLASSICAL_ALGS.indexOf(explicitAlg) === -1) {
+    throw new AuthError("auth-jwt-external/sign-alg-unsupported",
+      label + ": alg '" + explicitAlg + "' is not a supported classical JWS algorithm (" +
+      SUPPORTED_CLASSICAL_ALGS.join(", ") + ")");
+  }
+  if (compatible.indexOf(explicitAlg) === -1) {
+    throw new AuthError("auth-jwt-external/sign-alg-key-mismatch",
+      label + ": alg '" + explicitAlg + "' is incompatible with the " + kty +
+      " key (compatible: " + compatible.join(", ") + ")");
+  }
+  return explicitAlg;
+}
+
+// _signCompactJws — produce the compact JWS serialization (protected
+// header . payload . signature) for an already-resolved alg + imported
+// private key. Header and payload are JCS-independent here: they are
+// serialized exactly once by the signer, base64url-encoded, and that byte
+// string IS the signing input, so there is no canonicalization gap a
+// verifier could diverge on.
+function _signCompactJws(header, payload, privateKey, alg) {
+  var params = _verifyParamsForAlg(alg);
+  var headerB64  = bCrypto.toBase64Url(Buffer.from(JSON.stringify(header), "utf8"));
+  var payloadB64 = bCrypto.toBase64Url(Buffer.from(JSON.stringify(payload), "utf8"));
+  var signingInput = headerB64 + "." + payloadB64;
+  var input = Buffer.from(signingInput, "ascii");
+  var sig;
+  if (params.hash === null) {
+    sig = nodeCrypto.sign(null, input, privateKey);     // EdDSA — no prehash
+  } else {
+    var keyParam = { key: privateKey };
+    if (params.padding !== undefined)     keyParam.padding     = params.padding;
+    if (params.saltLength !== undefined)  keyParam.saltLength  = params.saltLength;
+    if (params.dsaEncoding !== undefined) keyParam.dsaEncoding = params.dsaEncoding;
+    sig = nodeCrypto.sign(params.hash, input, keyParam);
+  }
+  return signingInput + "." + bCrypto.toBase64Url(sig);
+}
+
 function _jwkToKey(jwk) {
   try { return nodeCrypto.createPublicKey({ key: jwk, format: "jwk" }); }
   catch (e) {
@@ -512,12 +618,119 @@ async function verifyExternal(token, opts) {
   return { header: header, claims: payload };
 }
 
+/**
+ * @primitive b.auth.jws.sign
+ * @signature b.auth.jws.sign(claims, opts)
+ * @since     0.14.22
+ * @status    stable
+ * @compliance soc2
+ * @related   b.auth.jar.build, b.auth.jar.parse
+ *
+ * Mint a compact JWS (RFC 7515) over <code>claims</code> using a classical
+ * asymmetric algorithm — RS/PS256/384/512, ES256/384/512, or EdDSA. This
+ * primitive exists strictly for <strong>interop with external ecosystems</strong>:
+ * OAuth/OIDC OPs and RPs (and the wallet / FAPI profiles built on them)
+ * require a request object / assertion signed with a classical JWS alg, and
+ * the framework's own token signer (<code>b.auth.jwt.sign</code>) is
+ * PQC-only (ML-DSA / SLH-DSA). It is <strong>never the framework-internal
+ * token default</strong>; <code>lib/jwt.js</code> remains the signer for
+ * tokens blamejs itself issues. The verify counterpart is
+ * <code>b.auth.jwt.verifyExternal</code>; this is its inverse for the cases
+ * where blamejs is the client emitting a signed object to a third party.
+ *
+ * The signing <code>alg</code> is derived from the key type (RFC 7518 §3.1)
+ * so the header alg always matches the signature the key can actually
+ * produce; an explicit <code>opts.alg</code> is validated against the key
+ * and refused if incompatible. <code>alg: "none"</code> and HMAC algs are
+ * refused outright — an asymmetric signer never emits them. The protected
+ * header always carries <code>alg</code>; <code>typ</code> and <code>kid</code>
+ * are set from <code>opts</code> when supplied (callers minting a typed
+ * object such as a JAR request object pass <code>typ</code>). Extra
+ * <code>opts.header</code> members pass through with two refusals:
+ * <code>b64</code> (RFC 7797 unencoded payload — it changes the signing
+ * input, which this signer always base64url-encodes) and <code>crit</code>
+ * (RFC 7515 §4.1.11 — it promises extension semantics the signer does not
+ * implement). Emitting either would produce a JWS whose header claims
+ * semantics its signature was not computed under.
+ *
+ * @opts
+ *   {
+ *     privateKey:  KeyObject|PEM|JWK,  // required — classical signing key
+ *     alg?:        string,             // override; default inferred from the key (RS256 / ES256/384/512 / PS256 / EdDSA)
+ *     typ?:        string,             // protected-header typ (e.g. "oauth-authz-req+jwt")
+ *     kid?:        string,             // protected-header kid (JWKS key selection)
+ *     header?:     object,             // extra protected-header members (alg/typ/kid reserved; b64/crit refused)
+ *   }
+ *
+ * @example
+ *   var jws = b.auth.jws.sign(
+ *     { iss: "client", aud: "https://as.example.com", response_type: "code" },
+ *     { privateKey: clientKey, typ: "oauth-authz-req+jwt", kid: "c1" });
+ *   // → "eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWF1dGh6LXJlcStqd3QifQ..."
+ */
+function signExternal(claims, opts) {
+  if (claims === null || typeof claims !== "object" || Array.isArray(claims)) {
+    throw new AuthError("auth-jwt-external/sign-bad-claims",
+      "jws.sign: claims must be a plain object");
+  }
+  validateOpts.requireObject(opts, "jws.sign", AuthError, "auth-jwt-external/sign-bad-opts");
+  validateOpts(opts, ["privateKey", "alg", "typ", "kid", "header"], "auth.jws.sign");
+  if (opts.alg !== undefined && opts.alg !== null) {
+    validateOpts.requireNonEmptyString(opts.alg, "jws.sign: alg", AuthError, "auth-jwt-external/sign-bad-alg");
+  }
+  if (opts.typ !== undefined && opts.typ !== null) {
+    validateOpts.requireNonEmptyString(opts.typ, "jws.sign: typ", AuthError, "auth-jwt-external/sign-bad-typ");
+  }
+  if (opts.kid !== undefined && opts.kid !== null) {
+    validateOpts.requireNonEmptyString(opts.kid, "jws.sign: kid", AuthError, "auth-jwt-external/sign-bad-kid");
+  }
+  validateOpts.optionalPlainObject(opts.header, "jws.sign: header", AuthError, "auth-jwt-external/sign-bad-header",
+    "must be a plain object of extra protected-header members");
+  // RFC 7797 `b64: false` changes the JWS signing input (the payload is
+  // signed raw, not base64url-encoded) and RFC 7515 §4.1.11 `crit`
+  // promises the producer implements every extension it names.
+  // _signCompactJws always base64url-encodes the payload and implements
+  // no header extensions, so passing either member through would mint a
+  // JWS whose header advertises semantics its signature was not computed
+  // under — a compliant verifier derives a different signing input (or
+  // refuses the critical header). Refused until those semantics are
+  // actually implemented.
+  if (opts.header !== undefined && opts.header !== null &&
+      (Object.prototype.hasOwnProperty.call(opts.header, "b64") ||
+       Object.prototype.hasOwnProperty.call(opts.header, "crit"))) {
+    throw new AuthError("auth-jwt-external/sign-unsupported-header",
+      "jws.sign: header members 'b64' (RFC 7797 unencoded payload) and 'crit' " +
+      "(RFC 7515 §4.1.11 critical extensions) are not supported — the signer " +
+      "always base64url-encodes the payload and implements no critical extensions");
+  }
+
+  var key = _toPrivateKey(opts.privateKey, "jws.sign");
+  var alg = _resolveSignAlg(opts.alg, key, "jws.sign");
+
+  // Extra protected-header members first (alg/typ/kid reserved so a
+  // caller-supplied header object can never override the signer-set alg —
+  // the canonical alg-substitution shape), then the reserved members.
+  var header = validateOpts.assignOwnEnumerable({}, opts.header, ["alg", "typ", "kid"]);
+  header.alg = alg;
+  if (opts.typ !== undefined && opts.typ !== null) header.typ = opts.typ;
+  if (opts.kid !== undefined && opts.kid !== null) header.kid = opts.kid;
+
+  return _signCompactJws(header, claims, key, alg);
+}
+
 module.exports = {
   verifyExternal:           verifyExternal,
+  signExternal:             signExternal,
   SUPPORTED_CLASSICAL_ALGS: SUPPORTED_CLASSICAL_ALGS,
   REFUSED_ALGS:             REFUSED_ALGS,
   // Shared JOSE defenses — routed from oauth.verifyIdToken /
   // oid4vci proof verify / sd-jwt-vc.verify / openid-federation.
   _assertAlgKtyMatch:       _assertAlgKtyMatch,
   _issuerMatches:           _issuerMatches,
+  // Classical-JWS signer internals — composed by oauth.js's attestation
+  // builders so the alg-from-key + compact-JWS bodies live in exactly one
+  // place (the classical-JOSE domain owner).
+  _toPrivateKey:            _toPrivateKey,
+  _resolveSignAlg:          _resolveSignAlg,
+  _signCompactJws:          _signCompactJws,
 };