Catalog: add the RFC 9449 multi-header invalid_dpop_proof carve-out - #2
Conversation
f6b7c09 to
59d66d9
Compare
|
Added commit This closes the catalog carry-over flagged in the cs-sdk error-mapping review: the scenario table previously asserted only
|
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.
…ode mapping 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.
c00114f to
181f51a
Compare
…atalog_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.
181f51a to
f95e456
Compare
2 participants
What
Adds a
dpop_multi_headerrow to theerror_scenariosofrfc6750-error-response-must-map-error-codes, plusRFC9449in that case'sstandard_refsand a rationale note scoping the carve-out.Why
RFC 9449 §4.3 #1 requires that a request carry not more than one
DPoPheader field. Unlike the other DPoP proof-validation failures — which RFC 6750 §3.1 maps toerror="invalid_token"— RFC 9449 §7.1 prescribeserror="invalid_dpop_proof"for this rejection, still on theDPoPscheme.The catalog currently models only
dpop_error → invalid_token / DPoP, so SDKs implementing the §4.3 cardinality check have nowhere to pin a conformance assertion for the divergent error code. The rust-sdk already carries the mapping with unit coverage and a deliberate carve-out comment in its catalog-pinned conformance case, deferred until this row exists; other SDKs implementing §4.3 hit the same gap.Once merged, downstream SDK conformance suites can restore the assertion inside the catalog-pinned case.
Landing consequence
The two scenario rows tighten the stable case
rfc6750-error-response-must-map-error-codes: suites that have not implemented either mapping go red when they adopt this catalog revision (skippedonly exists at case granularity). cs-sdk and rust-sdk already implement and assert both mappings; the remaining SDKs are tracked in #4 and pick the rows up when they bump their catalog pin.