If the RS is directly issuing tokens, is this any different to Set-Cookie? Both indicate that a client should use a particular bearer token for future requests.
> On 10 Nov 2025, at 20:44, Chalk, Ollie (DSIT) > <[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]
