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

Remove `ttl` #120

Closed dlongley closed 8 months ago

dlongley commented 9 months ago

The ttl property seems to be ineffective, could lead to confusion (false expectations), and might be a layering violation. I suggest we remove it and note that other mechanisms could be used to achieve TTL-related use cases such as HTTP caching headers.

See: https://github.com/w3c/vc-bitstring-status-list/issues/73#issuecomment-1607874866 :

My understanding is that the goal of ttl is to enable issuers to avoid having to reissue status list VCs more frequently. If I understand the aim here, I don't think it actually works in practice.

If you sign a VC with a validUntil of sometime "next year" and a TTL of 5 minutes, you are indicating that some verifier somewhere may accept whatever was in that VC (with your signature on it) anytime between when that VC was first accessible and "next year". The TTL doesn't change that; it isn't helpful in this regard and there is no reason why the verifier couldn't just ignore it.

Additionally, consider one of the use cases for StatusList2021, where a holder fetches a status list VC and presents it along with whatever other VC is in the list it describes (in order to avoid having the verifier even contact the issuer at all). That holder can completely ignore the TTL and the verifier will be receiving it "within the TTL" when the holder presents it. There's no signature over when the holder requested it that could be checked, etc. Even if there were -- this would upend the goal of ttl by requiring more frequent signatures again.

In this scenario, an issuer might be thinking that if they always set a ttl of 5 minutes in their status list VCs then they will only have to wait 5 minutes after they publish a new status list VC to ensure it's the one all the verifiers use. They would be mistaken. This is based on an erroneous understanding of the meaning of the data and how the data and the various decentralized systems interacting with it are partitioned.

So, right now, I don't think ttl achieves its goal and therefore ends up adding both unnecessary complexity and a potential violation of expectations.

An issuer should instead decide on a validity period they are willing to commit to (maybe it's 5 minutes, maybe 15 -- maybe 24 hours -- maybe more, their call) and reissue the status list VC with an updated validUntil either on demand or on schedule. Then a verifier just checks validUntil per usual and can safely cache the status list VC as long as it's valid.

So, as an issuer, if you want to allow your status list VCs to expire every 5 minutes, issue a new one if any VC status changes (understanding that the status won't be consistent until after the old status list VC expires) and auto-reissue when a status list VC is requested if it has expired, bumping validUntil 5 minutes into the future each time.

msporny commented 8 months ago

I'll mark ttl as at risk for now given the logical inconsistency w/ ttl and validUntil described above.

dlongley commented 8 months ago

+1 to marking at risk -- and I'd say the at risk marker isn't about whether there are two or more implementations (which would be required of course), but because we might decide it's danger / problematic and remove it for that reason. In other words, this particular issue isn't just about implementation support, it could be a bad idea to specify it.

msporny commented 8 months ago

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

iherman commented 8 months ago

The issue was discussed in a meeting on 2024-01-16

View the transcript #### 2.4. Remove `ttl` (issue vc-bitstring-status-list#120) _See github issue [vc-bitstring-status-list#120](https://github.com/w3c/vc-bitstring-status-list/issues/120)._ **Brent Zundel:** PR 128 is associated with this. _See github pull request [vc-bitstring-status-list#128](https://github.com/w3c/vc-bitstring-status-list/pull/128)._ **Manu Sporny:** The PR marks the TTL property as at-risk. Allows us to go to CR. The assertion is that the "ttl" property and the "validUntil" property clash when they are both set. … Seems like the "ttl" property should not exists. … There is disagreement on that. **Dave Longley:** There are conflicting semantics and likely layering violations. When would software look at ttl vs validUntil? … Might be that the way TTL is done via HTTP headers instead of mixing it up with the credential data.
msporny commented 8 months ago

PR #128 has been merged, closing.