Problem. Solid-OIDC's DPoP requires the resource server to verify an asymmetric signature on every request. For high-request-rate clients — bulk reads, agents, chatty apps — that per-request public-key verification is a measurable throughput bottleneck.
Proposal. DPoP-SK is an opt-in, negotiated profile that keeps DPoP as the mandatory baseline. After a single DPoP proof at session establishment, it derives a symmetric session key (HKDF over an RFC 5705 TLS exporter) and authenticates subsequent requests with a fast RFC 9421 HMAC-SHA-256 signature instead of a per-request asymmetric proof. It negotiates via RFC 9728 and uses RFC 4303-style verify-then-mark anti-replay. Servers that don't implement it simply continue using DPoP.
Draft. https://github.com/jeswr/solid-specs/tree/main/specs/dpop-sk
Live preview. https://jeswr.github.io/solid-specs/specs/dpop-sk/
Status. Unofficial editor's draft, offered for the group's consideration and discussion — not a request for adoption.
Problem. Solid-OIDC's DPoP requires the resource server to verify an asymmetric signature on every request. For high-request-rate clients — bulk reads, agents, chatty apps — that per-request public-key verification is a measurable throughput bottleneck.
Proposal. DPoP-SK is an opt-in, negotiated profile that keeps DPoP as the mandatory baseline. After a single DPoP proof at session establishment, it derives a symmetric session key (HKDF over an RFC 5705 TLS exporter) and authenticates subsequent requests with a fast RFC 9421 HMAC-SHA-256 signature instead of a per-request asymmetric proof. It negotiates via RFC 9728 and uses RFC 4303-style verify-then-mark anti-replay. Servers that don't implement it simply continue using DPoP.
Draft. https://github.com/jeswr/solid-specs/tree/main/specs/dpop-sk
Live preview. https://jeswr.github.io/solid-specs/specs/dpop-sk/
Status. Unofficial editor's draft, offered for the group's consideration and discussion — not a request for adoption.