From 59d66d937891504ad4701f61d7a2d522061fd435 Mon Sep 17 00:00:00 2001 From: Roberto Iskandarani Date: Mon, 27 Jul 2026 16:35:05 -0300 Subject: [PATCH 1/2] 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 0cb0053..0840244 100644 --- a/oauth-sdk-conformance-catalog.yaml +++ b/oauth-sdk-conformance-catalog.yaml @@ -2083,6 +2083,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\ @@ -2102,13 +2103,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 c00114f699dcaf60c0e3be58261cbbe584777097 Mon Sep 17 00:00:00 2001 From: Roberto Iskandarani Date: Mon, 3 Aug 2026 10:19:52 -0300 Subject: [PATCH 2/2] =?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 0840244..f7cbabb 100644 --- a/oauth-sdk-conformance-catalog.yaml +++ b/oauth-sdk-conformance-catalog.yaml @@ -2106,6 +2106,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: @@ -2114,7 +2117,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: