How Plumbus works

Relationship to RFC 9449 (DPoP)

Plumbus follows the Proof-of-Possession model defined in RFC 9449, where a client proves possession of a private key on each protected request and the server verifies that proof before processing the request.

RFC 9449 binds access tokens to a public key by embedding confirmation (cnf) claims into the token at issuance time. This requires changes to the authorization server and token format, and requires resource-side validation logic to enforce the binding.

Plumbus applies the same sender-constrained model externally, without modifying tokens or identity-provider behavior. Instead of embedding key confirmation into authentication material, Plumbus externalizes the binding into a separate, Plumbus-minted binding token enforced at the service boundary.

This allows Plumbus to enforce Proof-of-Possession semantics externally, without changes to existing authentication flows, token formats, or identity infrastructure.

Request flow (high level)

Frontend App
  └─(auth material)→ Plumbus FE Agent
        └─(auth material + PoP proof)→ Plumbus Enforcement Layer
              └─(forward if verified)→ Resource Service

1. System model

Plumbus integrates into the frontend execution context and into the request path directly in front of the protected resource service.

Presence at these two points allows Plumbus to enforce Proof-of-Possession semantics on configured request paths while remaining transparent to application logic.

Requests outside configured scope are not subject to enforcement and are forwarded unchanged. Requests within configured scope are forwarded only if all verification steps succeed.

2. Client-side behavior

The client’s role is limited to producing a cryptographic proof for each request that matches configured policy.

• the client holds a non-exportable private key
• for each configured request, the client produces a Proof-of-Possession value
• the proof demonstrates possession of the private key at request time

3. Client key properties

The Proof-of-Possession key used by Plumbus has the following properties:

• the key pair is generated locally in the client context
• the private key is non-exportable and non-extractable
• the private key never leaves the client context and is never transmitted
• the key is generated randomly

4. Request structure

A request that matches configured policy consists of the following parts:

• Authentication material — whatever the system already uses (headers, cookies, tokens). Plumbus treats this as an opaque value and does not inspect or parse it.
• Binding token — a Plumbus-minted token that must accompany the authentication material on every request within configured scope.
• Proof-of-Possession data — per-request cryptographic proof produced by the client.

The proof is computed over a deterministic representation of the request, sufficient to allow server-side verification of authenticity and freshness.

Authentication material is not modified, wrapped, or re-issued.

5. Server-side verification

For each incoming request that matches configured policy, Plumbus performs the following checks:

• Proof verification — the signature is verified against the client’s public key.
• Freshness enforcement — the proof is validated against freshness rules.
• Binding token verification — the binding token is validated as a Plumbus-minted artifact and checked for consistency with the authentication material and the client public key.

Decision
Requests outside configured scope are forwarded unchanged.
Requests within configured scope are forwarded only if all verification steps succeed; otherwise they are rejected.

6. Enforcement model

Plumbus enforces Proof-of-Possession without introducing application-level identity, session state, or centralized control.

• no session store is created
• no identity database is added
• no fingerprinting, tracking, or stable user or device identifiers are used
• no inference or heuristic classification is applied
• no central control plane or shared enforcement bottleneck is introduced

Enforcement is applied independently at each configured service boundary.

All enforcement decisions are derived from request-local cryptographic proof and explicit configuration.

The Proof-of-Possession key is used solely to prove request origination. It is not intended to identify a physical device or a user.

This design limits attack surface and is intended to result in predictable behavior under failure.

7. Failure modes

Plumbus has explicit and contained failure behavior for requests that match configured policy.

Requests that do not match configured policy are forwarded unchanged.

In all cases of rejection:

• authentication state remains unchanged
• no partial forwarding occurs

Removing Plumbus restores the original request flow.

8. Configuration boundary

Plumbus behavior is fully determined by explicit configuration policy.

Proof-of-Possession enforcement, freshness enforcement, and binding-token requirements are applied strictly according to declared configuration. Plumbus does not infer behavior or introduce implicit rules.

Detailed wire formats, configuration options, and integration steps are covered in the integration documentation.