End-to-End Client Continuity from the First Request

How Plumbus works

Plumbus treats context continuity as an enforcement concern, not an identity concern. Instead of embedding sender binding into authentication material, it enforces context continuity 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 context continuity can be enforced consistently.

From this position, Plumbus introduces two primitives between the frontend and backend: a DPoP proof on every request, and a binding artifact issued at authentication. These are produced, injected, and processed exclusively by Plumbus. They are transparent to the platform and meaningless outside Plumbus.

This makes context continuity enforcement 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 context binding

Plumbus enforces context continuity by injecting a DPoP proof on every configured request and verifying it at the service boundary. This establishes a shared client 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 ties the authentication material to the client key — enabling use of the material only from the client context that authenticated.

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 context continuity on every configured request at the service boundary. For each request, the DPoP proof and the binding artifact are evaluated to determine whether the presented authentication material is valid for the current client context.

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 makes context continuity an infrastructural property, enforcing that only the client context that authenticated can use its authentication material — consistently at the service boundary, without changing existing authentication or authorization models.

This is how context continuity enforcement fits into a layered security model.