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) <Ollie.Chalk= [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]> > *Date: *Monday, 10 November 2025 at 23:12 > *To: *Chalk, Ollie (DSIT) <[email protected]> > *Cc: *[email protected] <[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) <Ollie.Chalk= > [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] > To unsubscribe send an email to [email protected] > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
