PR #2 adds two rows to the scenario table of the stable case rfc6750-error-response-must-map-error-codes:
Because the rows tighten an existing case id, an SDK suite that has not implemented either mapping goes red when it adopts the catalog revision — skipped exists only at case granularity, so a single row cannot be deferred without skipping the whole mapping case.
Status by SDK:
Note: the SDK suites pin the catalog by commit SHA, so the new rows only land when each repo bumps its pin — do the mapping work in the same change as the bump.
PR #2 adds two rows to the scenario table of the stable case
rfc6750-error-response-must-map-error-codes:dpop_multi_header→invalid_dpop_proof/DPoP(RFC 9449 §7.1, exercising the §4.3 Add rfc9449-introspection-response-must-expose-cnf-jkt #1 rejection)dpop_not_supported→invalid_token/Bearer(RFC 6750 §3.1; RFC 9449 §7.1 scopes the DPoP challenge to resources requiring DPoP)Because the rows tighten an existing case id, an SDK suite that has not implemented either mapping goes red when it adopts the catalog revision —
skippedexists only at case granularity, so a single row cannot be deferred without skipping the whole mapping case.Status by SDK:
Note: the SDK suites pin the catalog by commit SHA, so the new rows only land when each repo bumps its pin — do the mapping work in the same change as the bump.