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

[Michael Jones]

Omit the claim.


________________________________
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on behalf of Nick Watson via Openid-specs-ab <openid-specs-ab at lists.openid.net>
Sent: Wednesday, June 18, 2025 2:20:44 PM
To: openid-specs-ab at lists.openid.net <openid-specs-ab at lists.openid.net>
Cc: Nick Watson <nwatson at google.com>
Subject: [Openid-specs-ab] Representation of infinite duration/timestamp

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.

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.

2. Use ISO 8601 values with an additional "infinite" keyword. This is explicit but somewhat heavyweight (compared to ints), and existing 8601 parsers would need to be extended/wrapped to handle "infinite".

3. Use -1. This keeps fields numeric, but it's ugly and likely still requires special handling by clients.

4. Set arbitrary large values (order of years) and assume that's good enough. This is how cookies work, so there's some parallel there. The downside being that it doesn't really communicate what it intends, and some clients may end up implementing logic like "a value larger than X indicates infinite".

Curious to hear the group's thoughts.

Nick

--
Nick Watson | Software Engineer | nwatson at google.com<mailto:nwatson at google.com> | (781) 608-3352
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250619/4bedce5c/attachment.htm>