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

[Andrii Deinega]

I guess an OP can announce whether it supports "IPSIE OIDC SL1"
through its metadata so there won't be any ambiguity when this claim
is omitted.

I also find the name of the claim (session_lifetime) a bit misleading
as it represents the expected lifetime of the RP session by an OP.

For those who are interested, there is a discussion on context #2 or
"refresh_token_expires_in" at
https://github.com/oauth-wg/oauth-v2-1/issues/187.

All the best,
Andrii

On Wed, Jun 18, 2025 at 8:00 PM Aaron Parecki via Openid-specs-ab
<openid-specs-ab at lists.openid.net> wrote:
>
> 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, 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
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab