Solid-OIDC mandates DPoP ([[RFC9449]]) sender-constrained access tokens, which cost the resource server one asymmetric signature verification on every request. This profile, DPoP-SK, defines a negotiated, optional fast path that preserves proof-of-possession while amortizing the asymmetric operation: the client presents one ordinary DPoP proof to a session establishment endpoint; both parties obtain a short-lived symmetric session key — either derived from TLS Exported Keying Material ([[RFC8446]] Section 7.5, [[RFC5705]]) so that no key material crosses the wire and the key is useless on any other TLS connection, or (for browser clients, which cannot access TLS exporters) generated by the server and delivered once under TLS. Subsequent requests carry an HTTP Message Signature ([[RFC9421]]) using the hmac-sha256 algorithm over a fixed covered-component set, with an [[RFC4303]]-style sliding-window counter for replay protection. DPoP remains the mandatory, always-accepted baseline: DPoP-SK is advertised through OAuth 2.0 Protected Resource Metadata ([[RFC9728]]), is invisible to clients that do not opt in, and never weakens what the server will accept.

This document is an unofficial editor's draft. It has no standing whatsoever: it is not a work item of the W3C Solid Community Group and is not endorsed by that group, by W3C, or by anyone else. It is published to solicit review before any proposal for adoption.

This specification is design-first, implementation-pending: it graduates Sections 4–6 of the reviewed design proposal [[HTP-POP]] into normative text, after an adversarial review pass recorded in . There are no implementations yet (); the reference implementation is planned in solid-server-rs.

Drafting disclosure: this draft was prepared with AI assistance (Claude Fable 5, Anthropic), working from the cited design proposal and the primary sources referenced throughout, and is awaiting review by its human editor. Errors introduced in drafting are the tooling's, not the cited sources'.

Introduction

A Solid resource server verifying DPoP performs, per authenticated request, one asymmetric signature verification over a fresh proof JWT: RFC 9449 requires the server to check, among other things, that "the DPoP HTTP request header field value is a single and well-formed JWT" whose "JWT signature verifies with the public key contained in the jwk JOSE Header Parameter" ([[RFC9449]] Section 4.3). Because the proof payload (jti, iat, htu) is new on every request, this verification cannot be memoized. CPU profiling of a production-shaped Solid server attributes roughly half of the authenticated-path CPU to exactly this per-request ECDSA verification once access-token verification is cached ([[SSRS-BENCH]]; analysis in [[HTP-POP]] Section 1).

Yet the property being re-proven — possession of the private key bound into the access token's cnf.jkt confirmation ([[RFC9449]] Section 6.1) — is constant across a client's whole session. DPoP-SK proves it once, with a full-strength DPoP proof, and then re-attests it per request with one HMAC-SHA256 and an O(1) replay-window check.

Terminology

session establishment endpoint

The resource-server endpoint, discovered via metadata (), at which a client exchanges one DPoP-authenticated request for a DPoP-SK session.

session key (K)

The 32-byte symmetric key shared between one client keypair/token pair and one resource server for the lifetime of one DPoP-SK session.

session identifier (session_id)

An opaque, unguessable identifier the server mints for the session; carried per request as the [[RFC9421]] keyid parameter.

channel binding flavour (cb)

Either tls-exporter (the key is derived from TLS Exported Keying Material and the session is pinned to the TLS connection) or none (the key is server-generated and TLS-delivered; the session is not connection-bound).

attestation

The per-request [[RFC9421]] hmac-sha256 message signature, tagged dpop-sk, that replaces the per-request DPoP proof inside a session.

ath, jkt

As in [[RFC9449]]: ath is "a base64url encoding of the SHA-256 hash of the ASCII encoding of the associated access token's value" (Section 4.2); jkt is "the base64url encoding of the JWK SHA-256 Thumbprint (according to [[RFC7638]]) of the DPoP public key" (Section 6.1).

Conformance classes: a DPoP-SK resource server (RS) and a DPoP-SK client. Requirements on "the server" and "the client" below bind those classes respectively.

Overview

Client                                             Resource Server
  |                                                       |
  |  (0) GET /.well-known/oauth-protected-resource        |  RFC 9728 discovery
  |<------------------------------------------------------|  pop_session member
  |                                                       |
  |  (1) POST {establishment endpoint}                    |  full RFC 9449 §4.3
  |      Authorization: DPoP <token>  +  DPoP: <proof>    |  verification — once
  |      { "cb": "tls-exporter" | "none" }                |
  |<-- 201 { session_id, cb, alg, expires_in,             |
  |          key? (cb=none) / confirm? (cb=tls-exporter) }|
  |                                                       |
  |      both sides now hold K (32 bytes)                 |
  |                                                       |
  |  (2..n) GET /resource                                 |  per request:
  |      Authorization: DPoP <token>      (no DPoP hdr)   |  1 session lookup
  |      Signature-Input: sig=(...);keyid=...;nonce=N;    |  1 HMAC-SHA256
  |                       tag="dpop-sk"                   |  1 O(1) window check
  |      Signature: sig=:...:                             |
  |<-- 200 ... or 401 WWW-Authenticate: DPoP (fall back)  |
  

The establishment request is verified with the server's unmodified DPoP machinery, so establishment is exactly as strong as today's per-request check. Any failure at any later point returns the standard DPoP challenge, and the client either re-establishes or falls back to plain per-request DPoP — both full-strength proof-of-possession mechanisms.

Discovery and negotiation

The server advertises DPoP-SK in its OAuth 2.0 Protected Resource Metadata document ([[RFC9728]], well-known path /.well-known/oauth-protected-resource) using the extension member pop_session. RFC 9728 requires that "any metadata parameters that are not understood MUST be ignored" (Section 3.2), so the member is invisible to non-adopting clients.

{
  "resource": "https://pod.example",
  "authorization_servers": ["https://idp.example"],
  "dpop_bound_access_tokens_required": true,
  "dpop_signing_alg_values_supported": ["ES256", "EdDSA"],
  "pop_session": {
    "endpoint": "https://pod.example/.pop/session",
    "algs": ["hmac-sha256"],
    "channel_bindings": ["tls-exporter", "none"],
    "profile": "https://w3id.org/jeswr/dpop-sk/v1"
  }
}
  

endpoint (REQUIRED)

The session establishment endpoint URL. It MUST use the https scheme and SHOULD be same-origin with resource.

algs (REQUIRED)

Attestation algorithms offered, as names from the [[RFC9421]] HTTP Signature Algorithms registry. This version of the profile defines exactly one: hmac-sha256 ([[RFC9421]] Section 3.3.3).

channel_bindings (REQUIRED)

The channel binding flavours offered: tls-exporter and/or none. A server MUST NOT advertise tls-exporter on any deployment where it does not terminate TLS in the same process that evaluates requests (a TLS-terminating proxy makes the exporter unavailable and the binding unsound).

profile (REQUIRED)

The URI https://w3id.org/jeswr/dpop-sk/v1, identifying this version of this profile. Clients MUST ignore a pop_session member whose profile they do not recognise.

A server MAY additionally direct clients to the metadata document from any 401 challenge using the resource_metadata parameter of WWW-Authenticate ([[RFC9728]] Section 5.1).

A client MUST NOT attempt establishment unless the metadata offers an algorithm and a channel binding flavour it supports. Negotiation is exact-match and fail-closed; the downgrade rules are consolidated in .

Session establishment

POST /.pop/session HTTP/2
Host: pod.example
Authorization: DPoP <access-token>
DPoP: <proof>
Content-Type: application/json

{ "cb": "tls-exporter" }
    

HTTP/2 201
Content-Type: application/json
Cache-Control: no-store

{
  "session_id": "AAECAwQFBgcICQoLDA0ODw",
  "cb": "tls-exporter",
  "alg": "hmac-sha256",
  "expires_in": 300,
  "confirm": "gvocwuudE9yiXXU5jINFTekorDybyEj_tQWPljW8eRA"
}
    

HTTP/2 201
Content-Type: application/json
Cache-Control: no-store

{
  "session_id": "AAECAwQFBgcICQoLDA0ODw",
  "cb": "none",
  "alg": "hmac-sha256",
  "expires_in": 300,
  "key": "EBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8"
}
    

EKM = TLS-Exporter("EXPERIMENTAL-dpop-sk-v1", context = "" (zero-length), 32 bytes)

PRK = HKDF-Extract(salt = ASCII(session_id), IKM = EKM)
K   = HKDF-Expand(PRK,
                  info = ASCII("dpop-sk/v1") || 0x00 || ASCII(ath) || 0x00 || ASCII(jkt),
                  L = 32)
      

session_id → {
  K,                          // the session key
  token_hash,                 // SHA-256 of the ASCII access token (the ath preimage check)
  jkt,                        // the token's cnf.jkt at establishment
  verified_identity,          // the WebID / verified-token context injected downstream
  token_exp, expires_at,      // both enforced per request
  replay_window,              // high-water mark + bitmap (see §8)
  cb, conn_id?                // conn_id pinned iff cb=tls-exporter
}
      

Per-request attestation

GET /alice/private/doc HTTP/2
Host: pod.example
Authorization: DPoP <access-token>
Signature-Input: sig=("@method" "@target-uri" "authorization");\
  created=1720000000;keyid="AAECAwQFBgcICQoLDA0ODw";\
  alg="hmac-sha256";nonce="1";tag="dpop-sk"
Signature: sig=:hPkuPd32xbb4hUjR/hjbj0Cp445ZfWoOgrcq8+f3I3g=:
    

Anti-replay: the sliding window

The nonce parameter carries a per-session counter: the client MUST start at 1 and assign strictly increasing values — never reusing one — and SHOULD increment by exactly 1 (gaps are tolerated but waste window space). Values MUST fit in an unsigned 64-bit integer, and a client that could exhaust the space MUST re-establish first (at 2⁶⁴−1 values this is theoretical). Servers MUST reject non-numeric, zero, or >64-bit values at parse time.

The server maintains, per session, the receive window of [[RFC4303]] Section 3.4.3: a high-water mark H (the highest authenticated counter value — RFC 4303's "right edge of the window represents the highest, validated Sequence Number") and a bitmap covering exactly the W values H − W + 1 … H (the window includes H itself). W MUST be at least 128 and SHOULD be 1024. (RFC 4303's own minimum of 32 and default of 64 target IPsec; HTTP/2 multiplexing routinely completes more concurrent requests out of order, which is precisely what the window — as opposed to a strictly-increasing rule, which would spuriously reject valid in-flight requests — exists to tolerate.)

For a received counter value n (after the signature verified — see below):

• n > H: advance the window (shift the bitmap by n − H, set H = n), mark n. Accept.
• H − W + 1 ≤ n ≤ H: if the bitmap bit for n is set, reject (duplicate); otherwise mark it and accept.
• n ≤ H − W: reject (below the window).

Verify-then-mark is normative. Mirroring [[RFC4303]] Section 3.4.3 — "the receive window is updated only if the integrity verification succeeds" — the window MUST NOT be consulted-and-mutated, advanced, or shifted for any request whose HMAC has not verified. This ordering means a forged request can neither burn a counter value nor advance the window (a state-DoS on the session). The signature-verify + window check-and-mark pair for one session MUST be atomic with respect to concurrent requests (a per-session lock or equivalent compare-and-swap), so two concurrent copies of the same counter value cannot both pass.

Session lifetime, rotation, revocation, termination

• Lifetime. expires_in MUST NOT exceed the remaining lifetime of the bound access token, and SHOULD NOT exceed 300 seconds. The bound is the revocation story: token or signing-key revocation propagates within one session window, because re-establishment re-runs the full verifier against current issuer state. Servers MUST enforce both the session expiry and the token expiry on every request.
• Rotation. There is no in-place rekey in this version: rotation is re-establishment (one DPoP round). Clients MAY re-establish before expiry and overlap the old and new sessions.
• Forced rekey. The server MAY invalidate any session at any time and answer its next attested request with the standard challenge — the same server-controlled-freshness philosophy as the RFC 9449 Section 9 server-provided nonce, which lets a server "limit the lifetime of DPoP proofs" at moments of its choosing ([[RFC9449]] Section 11.2). Clients MUST tolerate this at any moment (it is indistinguishable from expiry).
• Termination. A client SHOULD terminate a session it will not use again (e.g. on logout) by sending DELETE to the session establishment endpoint, attested under the session itself (the keyid names the session to delete; the REQUIRED covered set applies). The server MUST verify the attestation like any other request before deleting, and respond 204. Server-side eviction, LRU pressure, and restarts are always-safe alternatives.
• State loss. All session state is disposable: its loss costs exactly one extra full DPoP verification per client. Implementations MUST NOT persist K to durable storage.

Fallback and no-downgrade rules

The consolidated fail-closed rules:

1. A DPoP-bound access token is NEVER accepted without a valid proof-of-possession: either a valid RFC 9449 proof or a valid DPoP-SK attestation. There is no bearer fallback under any failure mode. (Consequence: stripping the Signature/Signature-Input fields from an attested request yields a request with no PoP at all, which is rejected.)
2. DPoP-SK never displaces DPoP: a request carrying a valid DPoP proof and no dpop-sk-tagged signature MUST be processed as plain DPoP, always, on every server. Falling back from DPoP-SK to DPoP is not a security downgrade — both are full-strength PoP; the fast path is a performance property, not a security ceiling.
3. A request carrying a dpop-sk-tagged signature is processed under this profile exclusively (): an invalid attestation is a 401, even if a valid DPoP header is also present. This removes any incentive to corrupt an attestation in transit hoping for laxer processing, and removes ambiguity about which mechanism authenticated a request.
4. Channel-binding negotiation is exact-match, both ways: the server MUST NOT create a session under a different flavour than requested (400 instead), and the client MUST discard a session whose response cb differs from its request. A client that requires tls-exporter can therefore never be silently degraded to none.
5. The attestation algorithm is fixed at establishment. The server MUST verify with the session's algorithm only, regardless of any alg parameter on the request ([[RFC9421]] Section 7.3.4's key/algorithm-mixup guidance), and MUST reject a mismatching alg parameter.
6. Servers MUST NOT advertise, and clients MUST NOT use, tls-exporter across any TLS-terminating intermediary, and the flavour REQUIRES TLS 1.3 ().

Security considerations

Privacy considerations

session_id is a per-client identifier visible to the resource server for the session's lifetime. It is strictly server-scoped, is never shared across origins, and its correlation power is a subset of what the server already holds (the access token, the WebID, the DPoP key thumbprint). Session TTLs bound its lifetime; clients wanting unlinkability across interactions should simply not establish sessions (plain DPoP has the same per-token linkability). No new information is exposed to any third party.

Conformance and implementation status

There are no implementations of this profile as of this draft. This document deliberately precedes code: the design proposal it graduates ([[HTP-POP]] Section 9) requires an adversarial review round (recorded in ) before any implementation. The planned reference implementation is the "Tier 2" work item in solid-server-rs (an establishment handler, a bounded session store, RFC 9421 base reconstruction and HMAC verification, and a client helper library for the suite's applications); the throughput motivation is recorded in that repository's committed bench records [[SSRS-BENCH]] and MUST be re-measured, not assumed, once the implementation exists. Interoperability claims in this document are therefore claims about cited specifications, not about deployed behaviour.

A conforming DPoP-SK resource server implements: the metadata advertisement (), the establishment endpoint () for at least one flavour, per-request verification (), the sliding window (), the lifetime rules (), and all rules in . A conforming DPoP-SK client implements discovery, establishment for at least one flavour, attestation construction, the counter discipline, and the client-side rules in .

Registration considerations

This unofficial draft requests no registrations. For the record:

• The exporter label EXPERIMENTAL-dpop-sk-v1 is private-use per [[RFC5705]] Section 4 and would be replaced by a registered EXPORTER- label on standards adoption.
• The metadata member pop_session is an unregistered extension member, legal under [[RFC9728]] Section 2 ("Additional protected resource metadata parameters MAY also be used") and ignored by non-implementers per its Section 3.2; standards adoption would register it (Specification Required, per RFC 9728 Section 8.1).
• The signature tag dpop-sk is an application-chosen [[RFC9421]] tag parameter value; RFC 9421 defines the parameter for exactly this use and requires no registration of values.