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

[Aaron Parecki]

Mike, do you have a recommendation for how to mitigate the drawbacks to
that option that Nick discussed?






On Wed, Jun 18, 2025 at 7:47 PM Michael Jones via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> *This message originated outside your organization.*
>
> ------------------------------
>
> 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://urldefense.com/v3/__https://openid.net/specs/ipsie-openid-connect-sl1-profile-1_0.html*section-3.3.1-5__;Iw!!PwKahg!8SN2XVexavT6ox4IaR5XhGu4hSF07kT0qjLnxpo6VBysfpOjvJiUdWYJ1oXAj5Xwn3pFOH970B50GGKR2GBqayL7PQwbQNXT$>,
> 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 | (781) 608-3352
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250618/4e8907cc/attachment-0001.htm>