TTL is mandatory 5 minute period if not specified

[msporny]

The specification currently states that if a TTL isn't specified, it's 5 minutes. This is a problem for offline use cases where organizations might not want to use the TTL and do not want to presume it is 5 minutes.

The specification needs to make TTL completely optional with no minimum timeout assumed unless stated.

[davidlehn]

Note the current spec text for credentialSubject.ttl text has 300000 ms default, which is 5 minutes.

[jandrieu]

Based on the meeting today, it seems like there was consensus to

1. Make respecting the TTL a SHOULD as a way to indicate that clients are supposed to check again at that frequency, but if they can't, it doesn't invalidate any still valid statuslist from a previous check.
2. Explain the pattern with TTL for refresh, but validUntil for a longer expiry, to enable regular checks, but supporting validity for batched/ intermittently offline scenarios.
3. If TTL is not present, no TTL is forced (no default TTL value)

That's my recollection.

[iherman]

The issue was discussed in a meeting on 2024-09-27

• no resolutions were taken

View the transcript

4.6. TTL is mandatory 5 hour period if not specified (issue vc-bitstring-status-list#174)

See github issue vc-bitstring-status-list#174.

Manu Sporny: Moving on. The next issue has to do with the time to live (TTL) feature.
… The spec currently states TTL default is 5 hours.
… The status list becomes invalid after 5 hours. Some implementations do not want to do this. Retail stores sometimes go offline for a week at a time.
… They still want to be able to process things after a 5 hour timeout.
… An option here would be to state TTL is completely optional with no TTL default. This would allow others to profile this and constrain TTL per their use case.

Joe Andrieu: +1 TTL optional.

Brent Zundel: Do we know the reasons it was not wrote optional in the first place.

Manu Sporny: MikeProrock wrote this language. We should ask him.

Brent Zundel: I can do that.

Joe Andrieu: What does the language say should happen after TTL has been passed.

Manu Sporny: See https://w3c.github.io/vc-bitstring-status-list/#bitstringstatuslistcredential.

Brent Zundel: See https://w3c.github.io/vc-bitstring-status-list/#:~:text=credentialSubject.ttl.

Joe Andrieu: I have issues with this language. It feels like an application related thing. That the Verifier should refresh the cache.
… Sometimes they will not be able to. So saying that they MUST NOT use cached data is an overreach.

Manu Sporny: I agree, but the problem with weakening it makes the TTL kind of irrelevant.
… many of us do not like the TTL at all. Potential for conflicting representations with HTTP headers.
… Additionally there is the validFrom and validUntil fields.
… This is a questionable/problematic feature.
… A few implementations plan on just ignoring it anyway.
… For those that want it, they can use it but there are dangers.

Kevin Dean: Wondering if it would not be acceptable to state that if the target is unreachable, the Verifier may proceed with the older cache of the status list.
… I think TTL is an important parameter in some cases.
… It should be the application can decide what to do if it is unreachable.

Brent Zundel: I would be in favor of Kevin's suggestion.

Dmitri Zagidulin: Puzzled why we are discussing the valid issues of TTL. This is a direct redundancy of validUntil.
… two problems. 2 fields that do the same thing. Secondly, should we make the TTL property optional.

Paul Dietrich: +1.

Joe Andrieu: I agree with dmitriz.
… It feels like if we enshrine it as a property that is optional we are giving people the option to advertise something that is confusing and optional.
… It introduces the wrong mental model.

Gabe Cohen: Fine with removing it. Wondering if there is some aspect of this property that is useful though.

Kevin Dean: +1 to that.

Will Abramson: wes-smith: Adding some nuance. The TTL and validUntil are not the same thing. TTL is around how long the cache of the status list. Wheras validUntil is on the core credential.

Brent Zundel: +1 to Wes.

Gabe Cohen: They are different but conflicting.

Manu Sporny: The use case around TTL is, you want to set a long expiration time for your status list. But tell the verifiers that you may make changes within a certain window.
… TTL is around caching semantics.
… That said, http caching headers are about this too.
… A counterpoint is that you might not have access to the system that fetched the status list. This is where TTL on the status list itself may be useful.

Joe Andrieu: reputing the usecase. because this is MUST it says that the status list is not valid after the TTL.
… Therefore you would have to expire.

Will Abramson: wes-smith: Responding to JoeAndrieu. I agree if TTL has expired you can't use it. The verifier would fail to verify because the status list has expired.

Joe Andrieu: This still does not make TTL and validUntil the same.
… Does that make sense?
… You can use an expired credential. Validation happens after verification.
… This language says I cannot use it in conformant software.
… This prevents the usecase that manu mentioned. If it is a MUST that the list is no longer valid then it excludes this usecase.

Manu Sporny: concrete proposal to shift the language to a MAY. This makes the semantics different from validUntil. You can continue to use it past the TTL.
… Any objections to this change to the TTL field.
… This will make the TTL field a purely optional thing.
… If it is there, then you should check.

Will Abramson: Are we saying the TTL will have no default value there?

Manu Sporny: I would suggest it doesnt have a default value. Because it is usecase specific.
… e.g. a trading floor might have microseconds.
… I dont think picking a value makes sense.
… applications can profile it.

David Lehn: The issue says 5 hours, but the spec currently says 5 minutes.

Brent Zundel: Sounds like there is enough input for someone to raise a PR.

Manu Sporny: yep, I can take that.

Brent Zundel: Any other issues.

[msporny]

PR #186 has been raised to address this issue. This issue will be closed once PR #186 has been merged.