The related work that comes to mind is the step-up authentication RFC https://datatracker.ietf.org/doc/rfc9470/ as well as the individual draft for step-up authorization: https://datatracker.ietf.org/doc/draft-lombardo-oauth-step-up-authz-challenge-proto/
On Mon, Nov 10, 2025 at 12:44 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]
