[Openid-specs-ab] Representation of infinite duration/timestamp

[David Waite]

> On Jun 18, 2025, at 3:20 PM, Nick Watson via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> Hi all,
> 
> Is there a recommended or canonical way to represent an infinite duration or timestamp? This has come up in a couple of contexts: (1) the session_lifetime claim in IPSIE OIDC SL1 <https://openid.net/specs/ipsie-openid-connect-sl1-profile-1_0.html#section-3.3.1-5>, e.g. for low-risk applications that can afford infinite sessions for convenience, and (2) an upcoming refresh token expiration spec I'm drafting.

My reading was that the intention was to create a mechanism to mandate a call-home was required to continue providing authenticated access on the RP. From this profile and the levels document, it looks like conveyance of a limited session lifetime is currently required to support IPSIE as both a RP and OP.

That said, there appear to be quite a few gaps in communicating expected behavior that would need to be answered for interoperable profiles.

  * For instance, is this conveying a one week timeout where a user is forced into a partial web reauthentication, or a 15 minute timeout where the expectation is that a new id_token is being fetched via a refresh grant?

  * What should the user experience be for the first example vs the second example - for instance, if the OP is temporarily unavailable.

  * In the refresh scenario, would it make sense to attempt to fetch a refreshed id_token before expiry to prevent a bad user experience, e.g. locking up the UI every so often while API calls try to verify access is still allowed?


From further describing expected behavior, it may be that an infinite duration and not supporting session_lifetime actually convey the same expected behavior.

> There are a couple of options I'm considering:
> 
> 1. Omit the field. The primary drawback here is that you can't distinguish between "no expiration" and "service doesn't support the spec". This option could potentially be coupled with mandatory updates to authz server metadata so that it's unambiguous whether the server supports the spec.

Server metadata and/or client registration might be appropriate to negotiate profile usage, but my expectation again from the reading is that if you support the spec, the intention is that implementations MUST specify a finite lifetime and MUST honor received lifetimes.

-DW

P.S. I’m curious the purpose of indicating refresh token expiration. In a sense, the refresh tokens and refresh grant provide a mechanism to treat access tokens like stateless authorizations as a temporary cache of a centralized AS’s policy decisions. The client doesn’t know whether it will get a new refresh token or not, and the new access token could conceivably be meant to be interpreted differently by resource servers to reflect policy changes and metadata changes over time.

In that light, I’m not sure when I would indicate a refresh token was going to expire in the future as a static bit of knowledge, since I could instead just refuse to give a new access token during a future refresh (after token expiry) to get the same behavior. Is the goal to attempt to reduce latency, or is it perhaps meant to support a novel refresh behavior?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250619/69b6f836/attachment.htm>