End-to-End Client Continuity from the First Request

How Plumbus works

Plumbus treats sender-constraint as an enforcement concern, not an authentication concern. Instead of embedding sender binding into authentication material, it enforces sender binding externally, at the service boundary, treating authentication material as an opaque value. This decouples enforcement from how authentication is issued or represented — and allows it to be layered onto existing systems without modification.

In practice, Plumbus is placed on the communication path between the platform frontend and backend. There is no alternative location where sender continuity can be enforced consistently.

From this position, Plumbus introduces a small set of communication primitives between the frontend and backend. These primitives are produced, injected, and processed exclusively by Plumbus. They are transparent to the platform and meaningless outside Plumbus.

This makes sender-constrained authentication the infrastructural baseline.

Browser setup

The application page may be served independently. The Plumbus Service Worker is always served by Plumbus.

When the page is loaded, the Service Worker is installed and activated. It generates and persists cryptographic key material locally.

From this point on, in-scope requests fall under Plumbus enforcement.

sequenceDiagram
  autonumber
  box Client
  participant B as Browser
  participant DB as IndexedDB (local)
  participant SW as Plumbus FE (Service Worker)
  end
  box Server
  participant PL as Plumbus BE (reverse-proxy)
Configuration
  participant RS as Resource Service
  participant WS as Web Server (static HTML)
  end

  
    B->>WS: GET / (page load)
    WS-->>B: HTML
    B->>PL: GET /plumbus-sw.js
    PL-->>B: plumbus-sw.js (configuration embedded)
    B->>SW: Install Service Worker
    activate SW
    B->>SW: Activate Service Worker / claim clients

    SW->>SW: Generate sender key pair
    SW->>DB: Persist key material
    deactivate SW
          

Authentication and sender binding

Plumbus ensures that configured requests are sender-constrained by injecting Proof-of-Possession on the frontend and enforcing its mandatory presence and validity on the backend. This establishes a shared context key: the client claims possession of a key, and Plumbus verifies that claim on every request.

When authentication material is issued, Plumbus issues a binding artifact that enables use of the authentication material with the designated client key only, closing the loop between proof and authorization.

sequenceDiagram
  autonumber
  box Client
  participant B as Browser
  participant DB as IndexedDB (local)
  participant SW as Plumbus FE (Service Worker)
  end
  box Server
  participant PL as Plumbus BE (reverse-proxy)
  participant IDP as Identity Provider
  end

  B->>SW: POST /login (credentials)

  critical Plumbs: Proof-of-Possession
    SW->>SW: 🔏 Create DPoP (signed canonical request blob)
    SW->>PL: POST /login (credentials) + x-DPoP: 🔏 (contains 🔑)
    PL->>PL: Verify 🔏 using 🔑
  end

  PL->>IDP: POST /login (credentials)
  IDP-->>PL: 📄 authentication material

  critical Plumbus: binding
    PL->>PL: Issue 📨 (bind 📄 ⇄ 🔑)
    PL-->>SW: 📄 + 📨
    SW->>DB: Persist 📨
  end

  SW-->>B: Authentication complete (📄)
          

If the Plumbus-specific sections are removed, the flow reduces to a classic authentication exchange between the browser and the identity provider.

Enforcement

Plumbus enforces sender constraints on every configured request at the service boundary. For each request, Proof-of-Possession and the binding artifact are evaluated to determine whether the presented authentication material is legitimate for use.

sequenceDiagram
  autonumber
  box Client
  participant B as Browser
  participant SW as Plumbus FE (Service Worker)
  end
  box Server
  participant PL as Plumbus BE (reverse-proxy)
  participant RS as Resource Service
  end

  B->>SW: POST /private/api + 📄 authentication material

  critical Plumbus: Proof-of-Possession 🔑
    SW->>SW: 🔏 Create X-DPoP (signed canonical request blob)
    SW->>PL: POST /private/api + 📄 + 📨 binding artifact + X-DPoP 🔏 (contains 🔑)
    PL->>PL: Verify DPoP signature using 🔑
    PL->>PL: Verify 📄 and 🔑 match 📨
  end

  alt enforcement passes
    PL->>RS: POST /private/api + 📄 authentication material
    RS-->>PL: Response
    PL-->>SW: Response
    SW-->>B: Response
  else enforcement fails
    PL-->>SW: Reject (401 Unauthorized)
    SW-->>B: Error
  end
          

If the Plumbus-specific steps are removed, the flow reduces to a plain authorized request carrying authentication material only.

Security hygiene

Plumbus turns sender-constrained authentication into an infrastructural property, enforcing the right to use authentication material consistently at the service boundary while leaving existing authentication and authorization models unchanged.

This is how sender-constrained enforcement fits into a layered security hygiene model.