[illera88]

DPoP currently requires a Web Crypto private key, preventing callers from using external signers such as Secure Enclave, TPM, or HSM keys through the existing request helpers. Accept { publicKey, sign } alongside CryptoKeyPair:

const DPoP = oauth.DPoP(client, {
  publicKey,
  sign: (bytes) => nativeSigner.sign(bytes),
})

The callback receives the exact JWS signing input and returns raw signature bytes. The library retains proof construction, serialization, nonce tracking, and JWT assembly; signing failures prevent the request from being sent.

All 267 tests pass, along with type, documentation example, formatting, and package checks. Added signature-verification, nonce-retry, and failure-path coverage, and separately exercised the callback with a real macOS Secure Enclave key.

[panva]

I think this can already be handled with the existing headers and customFetch affordances.

For token endpoint and PAR requests, you can supply an externally signed proof through options.headers. For protected resource requests, pass it through the headers argument. Neither requires a DPoP handle, and resource requests automatically select Authorization: DPoP … when the dpop header is present.

Alternatively, customFetch lets you generate and attach the proof immediately before sending the request. When injecting a proof there for protected resource requests, also update the authorization scheme to DPoP. For AS requests, leave the configured client authentication intact.

Proof construction and nonce tracking would live in your integration with either approach.