OFFICIAL Apologies if I’m not conveying clearly!
In my experience, the RS either knows the constraints and conditions of the token via a shared format with the AS or is an access token specific JWT anyway. I’ve also seen in more simpler services/APIs that the RS and AS are the same or the AS may not even strictly exist if the RS is directly receiving a known bearer token format. As I don’t think anyone has immediately decried the idea, I’ll suggest an I-D where I can hopefully articulate more clearly and bring that back to the mailing list. If anyone is interested in supporting the draft (and I’d appreciate that greatly) then let me know. Thanks, Ollie OFFICIAL From: Warren Parad <[email protected]> Date: Tuesday, 11 November 2025 at 13:21 To: Chalk, Ollie (DSIT) <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [OAUTH-WG] Re: Token Issuance/Introspection via Header (Authentication-Info?) Ollie, I'll have to admit I'm a bit confused about how this would work in practice. In order for this to "reduce calls to the AS introspection endpoint", then the RS would have to know the constraints of a valid token without calling the AS. This also means the RS and AS are separate entities/services/applications/etc. In that scenario, how would you expect the RS to know without calling the AS what the expiry should be? On Tue, Nov 11, 2025 at 1:09 PM Chalk, Ollie (DSIT) <[email protected]<mailto:[email protected]>> wrote: OFFICIAL Thanks Max - and separate thanks to Neil and Aaron (I’ll create an issue on the step-up draft). > but it wants the client to go get a different token anyway? In some cases, the RS could save the round-trip by issuing/returning the next token inline (either minted by the AS via back-channel/token-exchange, or as an RS-scoped continuation token). The idea is optimisation. > How does the RS know what the client is going to do next? Perhaps a contrived example, but something like: * Client PUT /file with access token -> RS * RS -> 200 OK {“processing”: true} - Authentication-Info: access_token=“abc” expires_in=7200 * (old token expired, so client can no longer put/post new file) * Client GET /status with new access token -> RS * (new token only has rights to perform get status request etc.) * RS -> 200 OK {“processed”: true} - Authentication-Info: access_token=“” expires_in=0 The other flow I’m considering is if a client produces a JWT as a bearer, the RS could ‘swap' for an access token, something like: * Client GET with bearer JWT (client has JWKS URI and CIMD) -> RS * RS gets remote resources, verifies sig and authorises client -> 200 OK - Authentication-Info: access_token=“abc” expires_in=7200 * (RS essentially saying - great thanks for the valid JWT but let's use an opaque string now so you don’t have to sign a JWT and I don't need to look up keys etc.) * Client GET with AT -> RS ... * (Client could still respond with a JWT and get a valid response, but RS is indicating a preferred token) > client is already given the expires_in in the original token response from > the AS, and can store that value alongside the token today. I haven't run > into a situation where the expiry of a token updates over time. Yeah, valid! I suppose this could be a way to roll the expiry? > token introspection endpoint today to retrieve the same set of information True - just thinking it might be a way to optimise and reduce queries to the AS. Thanks, Ollie OFFICIAL From: Max Gerber <[email protected]<mailto:[email protected]>> Date: Monday, 10 November 2025 at 23:12 To: Chalk, Ollie (DSIT) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: [OAUTH-WG] Token Issuance/Introspection via Header (Authentication-Info?) > A motivating use case is where a client presents a valid bearer token to a > resource server, and the server wishes to signal that a newer or > context-specific token should now be used for subsequent requests. Authentication-Info is used on successful requests, right? So this would mean that the RS didn't fail the request, but it wants the client to go get a different token anyway? I suppose the RS could inform the client that the client could have used a more tightly-scoped token to perform the same request, but I don't know how the RS could tell the client to get a more tightly-scoped token for future requests. How does the RS know what the client is going to do next? if the client reads resource A first, it might update resource B or delete resource C in the next request. Do you have a more complete real world example of context-specific scoping? > The same header could also convey updated token information, such as revised > expiry time: > e.g. Authentication-Info: token_type="Bearer", expires_in=3351 If the client knows that its token is close to expiry, the client can perform a token refresh in advance, instead of waiting for the token to expire and retrying a failed request. However: - The client is already given the expires_in in the original token response from the AS, and can store that value alongside the token today. I haven't run into a situation where the expiry of a token updates over time. - If the AS supports it, the client can use the RFC 7662<https://datatracker.ietf.org/doc/html/rfc7662> token introspection endpoint today to retrieve the same set of information Best, Max On Mon, Nov 10, 2025 at 12:43 PM Chalk, Ollie (DSIT) <[email protected]<mailto:[email protected]>> wrote: OFFICIAL Hi all - great to meet some of you in Montreal! I’ve been exploring an idea for an OAuth extension that would allow a resource server (or authorisation server) to issue or indicate details about tokens in a HTTP response header. A seemingly obvious candidate is to use the existing Authentication-Info header. e.g. Authentication-Info: token_type="Bearer", expires_in=3600, access_token="YWNjZXNzX3Rva2VuIQ" A motivating use case is where a client presents a valid bearer token to a resource server, and the server wishes to signal that a newer or context-specific token should now be used for subsequent requests. The same header could also convey updated token information, such as revised expiry time: e.g. Authentication-Info: token_type="Bearer", expires_in=3351 New metadata fields could support discovery and registration: * token_response_modes_supported (AS metadata) * token_response_mode (client metadata / DCR) Before drafting an Internet-Draft, I wanted to ask if there’s prior work or existing discussion in this area (I did a quick search of the mailing list), and whether there’s interest in standardising such a mechanism. Thanks, Ollie OFFICIAL _______________________________________________ OAuth mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ OAuth mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
