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? * 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. * 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
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
