[OAUTH-WG] Re: DPoP/RFC9449 - out-of-band public keys and no "jwk" in the header? OAuth 2.1?

[Brian Campbell <[e-mail]>]

Hi Ollie,

Have you taken a look at the WIMSE Workload to Workload Authentication
(formerly Service to Service)
https://datatracker.ietf.org/doc/html/draft-ietf-wimse-s2s-protocol ?
Offhand, it sounds like it might be applicable.

On Tue, Jul 15, 2025 at 9:47 AM Chalk, Ollie (DSIT) <[e-mail]>
wrote:

> OFFICIAL
>
> Hey OAuth authors,
>
>
>
> I’m from the UK government and I’m looking at standardising service‑to‑service
> authentication across UK public‑sector, and I’d like to stipulate OAuth
> bearer tokens with DPoP characteristics.
>
> I am hoping insights and answers will help me shape an internal RFC (
> https://github.com/govuk-digital-backbone/request-for-comments/blob/rfc-001-proposal/rfcs/001-jwt-service-to-service-authentication.md
> ).
>
>    1. *Key delivery:* My understanding is that DPoP currently requires a
>    jwk in the header. Would it be feasible to have an out-of-band public
>    key mechanism? Like the private_key_jwt approach – where keys are
>    resolved via the issuer (iss) and the header does not explicitly
>    include the jwk?
>       1. Resource servers could then authorise based on the issuer’s URL
>       (e.g. matching trusted domains like *.gov[.]uk) and fetch public
>       keys directly from a DID document or JWK Set URL at a known location.
>       2. Would removing the explicit jwk from the header undermine
>       security assumptions behind RFC 9449?
>    2. *Replay protections:* We'd still maintain jti, htu, and htm for
>    replay protection and uniqueness. Would omitting jwk from the header
>    compromise these protections, or could it be equally secure assuming
>    trusted issuer resolution?
>
> Here’s a simplified illustration of what we'd ideally use as a DPoP proof:
>
> {
>
>   "typ": "dpop+jwt",
>
>   "alg": "ES256"
>
> }
>
> .
>
> {
>
>   "iss": https[:]//example.service[.]gov[.]uk,
>
>   "jti": "12345",
>
>   "htu": https[:]//example[.]com/oauth/token,
>
>   "htm": "POST",
>
>   "iat": 1751892664
>
> }
>
> .SIG
>
>
>
> Where the resource server (at example[.]com in this example) retrieves
> the public key from
> https[:]//example.service[.]gov[.]uk/.well-known/jwks.json or similar.
>
>
>
> Am I misunderstanding something fundamental about RFC 9449? Is this more
> of an OAuth 2.1 query?
>
> Any guidance or clarification you can offer would be greatly appreciated.
>
>
>
> Thanks in advance,
>
> Ollie
>
> OFFICIAL
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._