search

w3c / vc-bitstring-status-list

A privacy-preserving mechanism to publish status information for Verifiable Credentials.
https://w3c.github.io/vc-bitstring-status-list/
Other
22 stars 19 forks source link

TTL is mandatory 5 minute period if not specified #174

Open msporny opened 2 months ago

msporny commented 2 months ago

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 commented 1 month ago

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

jandrieu commented 1 month ago

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 commented 1 month ago

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

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](https://github.com/w3c/vc-bitstring-status-list/issues/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](https://w3c.github.io/vc-bitstring-status-list/#bitstringstatuslistcredential). > *Brent Zundel:* See [https://w3c.github.io/vc-bitstring-status-list/#:~:text=credentialSubject.ttl](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 commented 1 day ago

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