information revealed by status updates

[npdoty]

Checking for revocation or status updates in general also reveal information about the holder to the verifier, potentially indefinitely afterwards. This is a significant risk, especially for open-ended status messages, or where status could reveal something sensitive (revocation of a privilege, criminal conviction, immigration status, etc.).

Can the holder know in advance what ongoing revocation status information will be provided?

Do open-ended status messages provide functionality proportional to the open-ended risk?

[msporny]

Checking for revocation or status updates in general also reveal information about the holder to the verifier, potentially indefinitely afterwards.

Yes, agreed. One mechanism to combat this that the group discussed was the shortening of timeframes for a particular VC, but then there is a counter-argument around ensuring that the holder has regular contact w/ the issuer, which is not the case in physical credential use cases today (such as driver's licenses).

Another mitigation discussed was providing the verifier with a "consent token" that only allows them to check the status if they are authorized (for a limited timeframe), but that creates a privacy harm that reduces the group privacy characteristics that you get with a large list (you'd have to make the list smaller for the "consent token" to be used appropriately).

Yet another approach was to require the verifier to phone home and ask about a specific subject, but then we're back to phoning home, which is also harmful to privacy.

At present, we think the right balance is what we have (due to the privacy drawbacks outlined above and the need to meet regulatory burden around revocation/suspension in a variety of use cases).

This is a significant risk, especially for open-ended status messages, or where status could reveal something sensitive (revocation of a privilege, criminal conviction, immigration status, etc.).

Yes, agreed, which is why we should warn against using the open-ended status messages for use cases where something sensitive could be revealed and used against the subject.

Can the holder know in advance what ongoing revocation status information will be provided?

For single-purpose status lists, yes, the holder knows in advance what status information is going to be published.

For open-ended status lists, no, the issuer could choose to re-publish a new open-ended message set at any time. We should add a section to the security considerations section around that.

Do open-ended status messages provide functionality proportional to the open-ended risk?

personal hat on -- No, I really dislike the status messages feature; it's unnecessary.

editor hat on -- There is a community that really wants this feature for non-person use cases (shipments).

I think the best we can do here is warn about the dangers of open-ended status lists. This might (and probably should) lead to warnings in digital wallets when they see open-ended status lists.

We can add two new sections to the privacy considerations section:

1. That having status lists at all enable after-the-fact monitoring of status information for a particular individual.
2. Open-ended status lists can update/change the types of status information published about the subject after the credential has been issued. Wallets might monitor these status lists and let the holder know when this information changes to keep them fully aware of the sorts of information others can track about them if open-ended status lists are used.

[jandrieu]

The right solution here is to enable "sidecar" status lists, which are provided by the user, NOT retrieved by the verifier.

[iherman]

The issue was discussed in a meeting on 2024-03-13

• no resolutions were taken

View the transcript

2.2. information revealed by status updates (issue vc-bitstring-status-list#146)

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

Manu Sporny: multi-status entries PING -- this could be more dangerous to privacy than "simple status list".
… "message" put arbitrary message allows issuer to add new types of status dynamically.
… explanation of the privacy concern and data leakage opportunity.

Dave Longley: e.g., issuer publishes, after the fact, that the credentialSubject likes Nickelback, without their consent.

Manu Sporny: other info can be exposed after the fact. PING wants this written up.
… feature is largely for traceability, but can be problematic in other cases.
… can even be sensitive in supply chain. This "messages" feature will have quite a write up in privacy section.

Joe Andrieu: surprised this is here. A bit too open ended.

Manu Sporny: half agreeing with you Joe...

Greg Bernstein: manu/JoeAndrieu: discussion...

Joe Andrieu: arbitrary messages stuff in the spec?

Dave Longley: +1 to Joe's concerns.

Manu Sporny: +1 to Joe's concerns (but not to the level that DB would object to it going in).

[msporny]

@jandrieu wrote:

The right solution here is to enable "sidecar" status lists, which are provided by the user, NOT retrieved by the verifier.

I don't quite understand this statement. The specification /does/ support the ability for the holder to deliver the status list to the verifier directly. The challenge is whether or not the verifier is going to 1) accept that flow, and 2) retrieve the status list anyway because they want to be extra-sure that they're working with the latest data (i.e., ignore holder-provided lists, ignore caching, always download).

What can we do to address the statement you raised above in the specification, @jandrieu?

[msporny]

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

[msporny]

PR #156 has been merged, closing.