caching status lists as a mitigation for identifying when the holder visited a verifier about vc-bitstring-status-list HOT 4 OPEN

2.1. caching status lists as a mitigation for identifying when the holder visited a verifier (issue vc-bitstring-status-list#144)

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

Manu Sporny: PING wants normative guidance on caching behavior on status list.

Dmitri Zagidulin: (yeyyy normative guidance!).

Manu Sporny: if we put MUST we need to test it; Not sure how we would test it in this group.
… best we can say is SHOULD cache rather than MUST.

Dave Longley: +1 to SHOULD.

Dmitri Zagidulin: +1 to SHOULD.

Manu Sporny: would prefer SHOULD.

Brent Zundel: why don't we simply ask implementers whether they do cache. It is lame test, but may work.

Ivan Herman: agree with you. The goal of testing is to see if the recommendation is implementable...

Brent Zundel: other comments on this issue?

Manu Sporny: Fine, but concerned with precedent.
… Maybe the way we implement this is to add a field to each implementations implementation config file... "iCacheStatusListsISwear": true.

Brent Zundel: I hear the concerned. This group has had a commitment to developing solid test suites. I think we are okay.

Manu Sporny: I agree with Brent's analysis.

Paul Dietrich: arguing MUST may be too restrictive.

Manu Sporny: I also agree with Paul's concern.

Dave Longley: "yes, my implementation caches when validUntil is present".

Brent Zundel: editors of bitstring stat list, do you have what you need?

Manu Sporny: yes.

Dave Longley: +1 to pauld_gs1's concerns, i think we don't want to lock in caching rules either.

Dave Longley: (i.e., it would be good to allow better caching rules over time with experience).

Manu Sporny: I'll take a shot at caching rules, with a MUST and otherwise will backoff to a SHOULD.

Brent Zundel: could have a MUST with recommended caching rules.

Dave Longley: +1 to something like what Brent said around caching rules.