**Session Date/Time:** 11 May 2026 17:00

# [OAUTH](../wg/oauth.html)

**Interim Meeting Minutes**

**Date:** 2026-05-18

## Summary
The OAUTH Working Group held an interim meeting to discuss the progress of [draft-ietf-oauth-refresh-token-expiration](https://datatracker.ietf.org/doc/draft-ietf-oauth-refresh-token-expiration/). The session focused on updates made since the last presentation in Montreal, the relationship between refresh token lifetimes and authorization lifetimes, and potential integration with token introspection. The group expressed that the document is maturing quickly and may be ready for Working Group Last Call (WGLC) in the near future.

## Key Discussion Points

### Refresh Token and Authorization Expiration
**Nick Watson** presented [OAuth RT Expiration](https://datatracker.ietf.org/meeting/interim-2026-oauth-02/materials/slides-interim-2026-oauth-02-sessa-oauth-rt-expiration-00), providing an overview of the draft's objectives and recent changes.

*   **Core Concepts:** The draft distinguishes between the validity of a refresh token (a mechanism to obtain access tokens) and "authorization expiration" (the broader resource owner authorization).
*   **Motivating Use Case:** Google’s Gmail scopes implementation highlighted a need for clients to know when background access will stop so they can properly inform users and manage re-authorization.
*   **Updates since Montreal:**
    *   Added support for out-of-band updates (how clients/AS should behave if a user modifies lifetimes directly at the AS).
    *   Clarified that no new error codes are needed; `invalid_grant` remains sufficient.
    *   Added a section on the relationship of expiration to individual scopes to address edge cases where different scopes might have different lifetimes.
    *   Renamed metadata fields and updated examples based on feedback from **Vanshaj Singhania**.
*   **Per-Scope Expiration:** **Nick Watson** noted that a paragraph was added to address scenarios where a client might have multiple authorization flows for different scopes. The current approach is for the Authorization Server (AS) to return the minimum expiration value to avoid unexpected access failures.
*   **Token Introspection:** **Vanshaj Singhania** had suggested expanding the draft to include token introspection. **Nick Watson** asked the group for feedback on allowing clients to retrieve expiration information via the introspection endpoint. **Maxwell Gerber** noted that introspection typically supports refresh tokens, making this a clean integration. **Nick Watson** indicated he would add this to the draft.
*   **Relationship between RT and Authorization Lifetimes:** **Maxwell Gerber** inquired about cases where a refresh token might have an indefinite lifetime while a specific scope has a finite authorization expiration. **Nick Watson** clarified that the draft recommends the refresh token timeout should not exceed the authorization expiration to prevent buggy implementations.
*   **AS Policy vs. User Intent:** **Vanshaj Singhania** observed that refresh token timeouts are often fixed AS policy (e.g., "must be used every N days"), whereas authorization expiration is often a joint decision between the AS and the end user. **Nick Watson** agreed and noted the security considerations section warns against letting RT expiration exceed authorization expiration.

## Decisions and Action Items
*   **Decision:** The draft will be expanded to include support for token introspection, allowing clients to query authorization and refresh token expiration status.
*   **Action Item:** **Nick Watson** to update [draft-ietf-oauth-refresh-token-expiration](https://datatracker.ietf.org/doc/draft-ietf-oauth-refresh-token-expiration/) based on the discussion, specifically regarding introspection and the relationship between omitted RT timeouts and finite authorization expiration.

## Next Steps
*   **Hannes Tschofenig** noted the lack of controversy and suggested the document is nearing completion. 
*   **Rifaat Shekh-Yusef** and **Hannes Tschofenig** discussed the timeline for Working Group Last Call (WGLC). While the original plan was to discuss status in Vienna, the chairs may initiate WGLC earlier if the next revision addresses the remaining feedback.
*   The next interim meeting is scheduled for June 1st.

***

**Reference Materials:**
*   [Chairs Slides](https://datatracker.ietf.org/meeting/interim-2026-oauth-02/materials/slides-interim-2026-oauth-02-sessa-chairs-slides-00)
*   [OAuth RT Expiration Slides](https://datatracker.ietf.org/meeting/interim-2026-oauth-02/materials/slides-interim-2026-oauth-02-sessa-oauth-rt-expiration-00)