RFC 9449 security guarantees

RFC 9449 describes a Proof-of-Possession model in which authentication credentials are bound to a cryptographic sender (see §1, §3).

This model provides the following guarantees:

• Sender-constrained credentials — authentication material can only be used by the client holding the corresponding private key (§3, §8).
• Replay resistance — stolen or leaked credentials cannot be replayed from another device or execution context (§8.1).
• Per-request proof of possession — each protected request includes cryptographic proof of key possession (§4).
• Client-context continuity — multi-step flows must originate from the same cryptographic sender (implied by the binding and verification model in §4, §8).

Why these guarantees remain largely theoretical

RFC 9449 assumes an architecture in which authorization servers and resource servers cooperate to issue and enforce sender-constrained credentials (§5, §7).

In practice, this requires:

• identity-provider support for DPoP-bound credentials
• changes to token formats (e.g. embedded confirmation claims)
• resource-server logic that understands and enforces bound tokens

As a result, RFC 9449 guarantees are typically unavailable for session cookies, legacy authentication systems, proprietary credentials, or environments where the IdP or token format cannot be changed.

How Plumbus enables them

Plumbus enables RFC 9449 sender-constraint guarantees externally, at the service boundary.

Instead of embedding key binding into authentication material, Plumbus enforces the same Proof-of-Possession semantics alongside existing credentials, preserving the guarantees described in §4 and §8.

• authentication material is treated as an opaque value
• requests are accepted only when accompanied by valid proof of possession
• proof verification and replay protection occur before application logic

Plumbus does not:

• inspect, parse, or modify authentication material
• replace or interfere with identity providers
• introduce tracking, fingerprinting, or behavioral identification
• alter application-level authentication or authorization logic

Why this model

• Seamless adoption — no changes to authentication or application code.
• Gradual rollout — enforcement can be enabled selectively and expanded over time.
• Distributed by design — enforcement scales without centralized bottlenecks.
• Stateless by design — no shared authentication or identity state is introduced.
• Contained failure modes — enforcement failures affect request handling only.