From aa005cded008f939c20e11b49b6c8dfd67b35386 Mon Sep 17 00:00:00 2001 From: "siros-release-notes-bot[bot]" <319452536+siros-release-notes-bot[bot]@users.noreply.github.com> Date: Thu, 10 Sep 2026 20:01:46 +0000 Subject: [PATCH 1/2] docs: add release notes for v0.20.0 --- RELEASE_NOTES.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES.md index 16cbc10..871035a 100644 --- a/RELEASE_NOTES.md +++ b/RELEASE_NOTES.md @@ -4,6 +4,21 @@ `release-notes:` markers; edit the prose inside a fence freely — regeneration only ever rewrites the fence it was asked to rewrite. --> + +## [v0.20.0] - 2026-09-10 + +### Added +- **Client-held DPoP keys**: New `sign_client_auth` action allows clients to hold their own DPoP private keys instead of the engine generating them. For each authenticated request, the engine now requests fresh signatures (DPoP proofs and wallet attestation PoPs) from the client with request-specific parameters. This ensures `cnf == DPoP key` because clients use one key for both, and eliminates replay of stale attestations. (#318) +- **Automatic mode detection**: The engine probes clients at the first authenticated request and adapts per-flow—client-held mode if the client answers `sign_client_auth`, legacy mode (engine-generated keys) if the client doesn't respond or times out. Pre-resolved attestations or renewals with `dpop_jwk` skip the probe and use legacy mode. (#318) + +### Changed +- **Renewal flow**: `flow_complete` now returns `dpop_key_id` (client-held mode) instead of `dpop_jwk`, and `flow_start` accepts `dpop_key_id` to resume flows with client-held keys. (#318) +- **Notification endpoint**: DPoP-bound notifications now work in both client-held and legacy modes after flow completion by abstracting the signing mechanism. (#318) + +### Fixed +- **Documentation**: The WebSocket protocol spec now documents `sign_client_auth`, `request_attestation`, and renewal fields that were previously undocumented. (#318) + + ## [v0.19.0] - 2026-09-07 From 4995e890ca84758f820dd56cb06bd0818979430c Mon Sep 17 00:00:00 2001 From: Leif Johansson Date: Thu, 10 Sep 2026 22:12:18 +0200 Subject: [PATCH 2/2] Say what dpop_key_id is for on renewal Co-Authored-By: Claude Fable 5.1 --- RELEASE_NOTES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES.md index 871035a..c25f680 100644 --- a/RELEASE_NOTES.md +++ b/RELEASE_NOTES.md @@ -12,7 +12,7 @@ - **Automatic mode detection**: The engine probes clients at the first authenticated request and adapts per-flow—client-held mode if the client answers `sign_client_auth`, legacy mode (engine-generated keys) if the client doesn't respond or times out. Pre-resolved attestations or renewals with `dpop_jwk` skip the probe and use legacy mode. (#318) ### Changed -- **Renewal flow**: `flow_complete` now returns `dpop_key_id` (client-held mode) instead of `dpop_jwk`, and `flow_start` accepts `dpop_key_id` to resume flows with client-held keys. (#318) +- **Renewal flow**: in client-held mode `flow_complete` returns `dpop_key_id` instead of the private `dpop_jwk`, and a renewal `flow_start` sends `dpop_key_id` back so the engine asks the client to sign with the key the refresh token is bound to. `dpop_jwk` keeps working for tokens issued by older backends. (#318) - **Notification endpoint**: DPoP-bound notifications now work in both client-held and legacy modes after flow completion by abstracting the signing mechanism. (#318) ### Fixed