feat(sep-1932): DPoP discovery signals (stacked on #528) - #529

Stacked on #528 -> #527 -> #395 (PieterKas/conformance:dpop-server, head dd9fd77). This branch contains those commits plus 5d213b9. Rebase onto main once #528, #527, and #395 merge.

The new commit (5d213b9) is the only one to review.

What each check asserts

#395 checks that a malformed proof is rejected. It does not check how a client that has never met the server learns that DPoP is required, or that the advertisement matches what the server enforces.

This assumes SEP-1932 will require the server to advertise DPoP - which @PieterKas proposed (and I agree with!). With that assumption, a missing DPoP challenge or a missing Protected Resource Metadata field is a failure. Missing algs stays a WARNING because RFC 9449 §7.1 says SHOULD.

sep-1932-server-advertises-dpop

RFC 9449 §7.1, graded SHOULD for algs from "An algs parameter SHOULD be included to signal to the client the JWS algorithms that are acceptable for the DPoP proof JWT. The value of the parameter is a space-delimited list of JWS alg (Algorithm) header values ([RFC7515], Section 4.1.1)."

An unauthenticated POST, no Authorization and no DPoP header.

• 401 with a DPoP challenge that includes algs: SUCCESS
• algs missing: WARNING
• No DPoP scheme: FAILURE

The resource_metadata parameter is captured from the DPoP challenge, or from a sibling challenge when the DPoP one does not carry it (RFC 9728 §5.1).

sep-1932-server-prm-dpop

RFC 9728 §2 marks both fields OPTIONAL. Assuming SEP-1932 requires them, absence is a failure.

Fetched from resource_metadata when the challenge has it, otherwise the path-based well-known URL, otherwise the root one. Same order as the client metadata-discovery scenarios. A resource_metadata URL that does not return a document is not replaced by a different well-known document.

• dpop_signing_alg_values_supported present, non-empty, and asymmetric only: the field half is satisfied. none or HS* is FAILURE, same rule as sep-1932-as-no-none-alg (RFC 9449 §11.6). Absent or empty: FAILURE
• dpop_bound_access_tokens_required present as a boolean: the field half is satisfied. Absent: FAILURE
• Metadata unreachable: not testable (FAILURE)

sep-1932-server-prm-consistency

An unbound token (omitCnf), presented as Bearer with no DPoP header. Gated on the positive proof.

• Metadata says required and the server accepts: FAILURE
• Metadata says required and the server rejects with 401: SUCCESS
• Metadata says not required, or is silent, and the server rejects with 401: FAILURE ("server requires DPoP but does not advertise it")
• Metadata says not required, or is silent, and the server accepts: INFO

Testing

• DPoP server scenario tests pass (16), including the omit-fields, unbound-bearer, none, and missing-algs fixtures
• eslint + prettier — clean on the touched files

Made with Cursor