From 2f480b44ce5efad6a00b0ffeaba11a9cedd87c70 Mon Sep 17 00:00:00 2001 From: Roberto Iskandarani Date: Mon, 27 Jul 2026 16:35:05 -0300 Subject: [PATCH 1/3] Encode the RFC 9449 multi-header invalid_dpop_proof carve-out The www_authenticate error-mapping case pinned every DPoP failure to invalid_token. RFC 9449 section 7.1 prescribes invalid_dpop_proof for the section 4.3 multi-header rejection; add that row as the one DPoP carve-out, leaving the other proof failures on invalid_token. --- oauth-sdk-conformance-catalog.yaml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/oauth-sdk-conformance-catalog.yaml b/oauth-sdk-conformance-catalog.yaml index 570e59a..1506f17 100644 --- a/oauth-sdk-conformance-catalog.yaml +++ b/oauth-sdk-conformance-catalog.yaml @@ -2098,6 +2098,7 @@ cases: standard_refs: - "RFC6750" - "RFC9068" + - "RFC9449" surface: "sdk-verifier.error-response" priority: "high" requirement_summary: "RFC 9068 §4 requires resource servers to handle errors as described in RFC 6750 §3.1. The SDK MUST\ @@ -2117,13 +2118,18 @@ cases: - error_type: "dpop_error" expected_error_code: "invalid_token" expected_scheme: "DPoP" + - error_type: "dpop_multi_header" + expected_error_code: "invalid_dpop_proof" + expected_scheme: "DPoP" stimulus: operation: "www_authenticate(error)" expected: outcome: "accept" www_authenticate_format: " error=\"\", error_description=\"\"" rationale: "RFC 9068 §4 delegates error handling to RFC 6750 §3 which mandates specific error codes in WWW-Authenticate\ - \ challenges. Without an SDK helper, every adapter must reimplement this mapping, risking inconsistency." + \ challenges. Without an SDK helper, every adapter must reimplement this mapping, risking inconsistency. The RFC 9449\ + \ §4.3 multi-header rejection is the one DPoP carve-out: §7.1 prescribes invalid_dpop_proof for it, while the other\ + \ DPoP proof failures stay on invalid_token." - id: "rfc9728-prm-dpop-fields-should-be-advertised-when-dpop-is-supported" title: "PRM should advertise DPoP signing algorithms and binding requirement when DPoP is configured" standard_refs: From 01e109d5b464bda8f482ed85740f7b5b98fea6f0 Mon Sep 17 00:00:00 2001 From: Roberto Iskandarani Date: Mon, 3 Aug 2026 10:19:52 -0300 Subject: [PATCH 2/3] =?UTF-8?q?Catalog:=20add=20dpop=5Fnot=5Fsupported=20?= =?UTF-8?q?=E2=86=92=20Bearer/invalid=5Ftoken=20row=20to=20error-code=20ma?= =?UTF-8?q?pping?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The rfc6750-error-response-must-map-error-codes scenario table asserted only dpop_error → invalid_token + DPoP; it was under-specified for the bearer-only case. DPoPNotSupported is a DPoPError subclass but the resource is bearer-only, so its WWW-Authenticate challenge uses the Bearer scheme with invalid_token (RFC 6750 §3), not DPoP. Add the row and note the carve-out in the rationale so every SDK maps it uniformly. --- oauth-sdk-conformance-catalog.yaml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/oauth-sdk-conformance-catalog.yaml b/oauth-sdk-conformance-catalog.yaml index 1506f17..a3c7e2e 100644 --- a/oauth-sdk-conformance-catalog.yaml +++ b/oauth-sdk-conformance-catalog.yaml @@ -2121,6 +2121,9 @@ cases: - error_type: "dpop_multi_header" expected_error_code: "invalid_dpop_proof" expected_scheme: "DPoP" + - error_type: "dpop_not_supported" + expected_error_code: "invalid_token" + expected_scheme: "Bearer" stimulus: operation: "www_authenticate(error)" expected: @@ -2129,7 +2132,8 @@ cases: rationale: "RFC 9068 §4 delegates error handling to RFC 6750 §3 which mandates specific error codes in WWW-Authenticate\ \ challenges. Without an SDK helper, every adapter must reimplement this mapping, risking inconsistency. The RFC 9449\ \ §4.3 multi-header rejection is the one DPoP carve-out: §7.1 prescribes invalid_dpop_proof for it, while the other\ - \ DPoP proof failures stay on invalid_token." + \ DPoP proof failures stay on invalid_token. DPoPNotSupported is the inverse case: the resource is bearer-only, so its\ + \ challenge uses the Bearer scheme with invalid_token rather than DPoP." - id: "rfc9728-prm-dpop-fields-should-be-advertised-when-dpop-is-supported" title: "PRM should advertise DPoP signing algorithms and binding requirement when DPoP is configured" standard_refs: From f95e456a93677d1bc2c6ea0fc8b7941d647d7de5 Mon Sep 17 00:00:00 2001 From: Roberto Iskandarani Date: Tue, 4 Aug 2026 12:19:42 -0300 Subject: [PATCH 3/3] Correct the RFC 9449 7.1 scope in the error-mapping rationale; bump catalog_version Section 7.1 designates invalid_dpop_proof for any proof deemed invalid under the 4.3 criteria, not only the multi-header rejection - the rationale no longer claims exclusivity, says designates rather than prescribes for a SHOULD-level code, and names the neutral snake_case dpop_not_supported token. requirement_summary now includes invalid_dpop_proof among the codes the helper must emit. catalog_version bumps to 2026-08-04 covering the semantics changes. --- oauth-sdk-conformance-catalog.yaml | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/oauth-sdk-conformance-catalog.yaml b/oauth-sdk-conformance-catalog.yaml index a3c7e2e..15049e2 100644 --- a/oauth-sdk-conformance-catalog.yaml +++ b/oauth-sdk-conformance-catalog.yaml @@ -1,7 +1,7 @@ --- schema_version: "1.0" catalog_id: "oauth-sdk-conformance-catalog" -catalog_version: "2026-04-22" +catalog_version: "2026-08-04" source_baseline: intent: "Language-neutral OAuth SDK conformance catalog shared across SDK implementations." @@ -2102,8 +2102,8 @@ cases: surface: "sdk-verifier.error-response" priority: "high" requirement_summary: "RFC 9068 §4 requires resource servers to handle errors as described in RFC 6750 §3.1. The SDK MUST\ - \ provide a helper that maps authentication errors to 'invalid_token' and authorization errors to 'insufficient_scope'\ - \ in a WWW-Authenticate header value." + \ provide a helper that maps authentication errors to 'invalid_token', authorization errors to 'insufficient_scope',\ + \ and a DPoP proof deemed invalid under RFC 9449 §4.3 to 'invalid_dpop_proof' in a WWW-Authenticate header value." setup: error_scenarios: - error_type: "token_expired" @@ -2130,10 +2130,10 @@ cases: outcome: "accept" www_authenticate_format: " error=\"\", error_description=\"\"" rationale: "RFC 9068 §4 delegates error handling to RFC 6750 §3 which mandates specific error codes in WWW-Authenticate\ - \ challenges. Without an SDK helper, every adapter must reimplement this mapping, risking inconsistency. The RFC 9449\ - \ §4.3 multi-header rejection is the one DPoP carve-out: §7.1 prescribes invalid_dpop_proof for it, while the other\ - \ DPoP proof failures stay on invalid_token. DPoPNotSupported is the inverse case: the resource is bearer-only, so its\ - \ challenge uses the Bearer scheme with invalid_token rather than DPoP." + \ challenges. Without an SDK helper, every adapter must reimplement this mapping, risking inconsistency. RFC 9449 §7.1\ + \ designates invalid_dpop_proof for a proof deemed invalid under the §4.3 criteria; the dpop_multi_header row profiles\ + \ that designation for the §4.3 item 1 cardinality rejection. dpop_not_supported is the inverse case: the resource is\ + \ bearer-only, so its challenge uses the Bearer scheme with invalid_token rather than DPoP." - id: "rfc9728-prm-dpop-fields-should-be-advertised-when-dpop-is-supported" title: "PRM should advertise DPoP signing algorithms and binding requirement when DPoP is configured" standard_refs: