Remove open ended status messages because it is a layer violation

[jandrieu]

In discussing issue #146, @msporny clarified that the current bitstring status list supports arbitrary messages in status lists.

Unfortunately, this turns status lists into yet another attestation architecture, which is a layering violation. Status lists don't have the privacy and security features we have for VCs, which is where, in the VC architecture, issuers make formal attestations about subjects.

Bitstring status lists should be used to enable decentralized verification of pre-arranged possible statuses, not of arbitrary, potentially changing attributes of the subject.

[msporny]

/cc @mkhraisha @OR13 @mprorock @npdoty @kdenhartog (please CC other implementers)

[msporny]

@jandrieu Given that the specification has already marked the status messages feature as "at risk", and is seeking implementer feedback during CR, do you see this issue as potentially blocking our transition to CR next month?

[brentzundel]

Isn't status returned as a VC? That would mean Status lists are using the VC attestation architecture which has precisely the privacy and security features we have for VCs.

The trouble with our WG trying to pre-arrange every possible status is that we can't possibly get them all. Why shouldn't a status VC have extension points just like a regular VC?

Perhaps it needs to be clarified that the subject of a status VC is always another credential, therefore any messages in a status VC are only ever messages about the status of the VC, not about the subject of the original VC.

[iherman]

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

• no resolutions were taken

View the transcript

2.1. Remove open ended status messages because it is a layer violation (issue vc-bitstring-status-list#151)

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

Manu Sporny: PING have raised several privacy issues that we should address.
… several issues around I18N that need to be reviewed.
… strings may be human readable.

Manu Sporny: https://github.com/w3c/vc-data-model/pulls.

Manu Sporny: will be a massive PR to address Yaskin's comments.
… mostly editorial apart from a few normative statements (but no new implementation requirements).

[jandrieu]

Isn't status returned as a VC? That would mean Status lists are using the VC attestation architecture which has precisely the privacy and security features we have for VCs.

Unfortunately the status list architecture does not have the same privacy and security features as VCs, because the holder is not involved in the status check. That check bypasses holder control, which is a key component of the VC privacy architecture.

The trouble with our WG trying to pre-arrange every possible status is that we can't possibly get them all. Why shouldn't a status VC have extension points just like a regular VC?

Agreed. We don't need to come up with all possible statuses, but the possible statuses of a given credential, IMO, should be set at the time of issuance and not changing over time.

The idea that we might restrict status results to a particular subject, e.g., that of the credential, is a good idea, but I think only half-way there.

The problem is that there is no way to enforce that.

If issuers have a set of known states they want to dynamically update, they can do that with a static set of states. That addresses a wide range of legitimate use cases without needing to enable open-ended assertions through the status list.

What we don't want issuers to do is to use the status list as a mechanism to publish arbitrary content about the subject of a VC without that subject being involved in the distribution of that content.

[jandrieu]

@jandrieu Given that the specification has already marked the status messages feature as "at risk", and is seeking implementer feedback during CR, do you see this issue as potentially blocking our transition to CR next month?

Good question. If its in the spec, it would probably lead to a formal objection, if that's what you're asking.

Whether or not we should attempt CR with language known to be objectionable is a discussion for the group.

[iherman]

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

• no resolutions were taken

View the transcript

3.4. Remove open ended status messages because it is a layer violation (issue vc-bitstring-status-list#151)

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

Manu Sporny: In the bistring status list, we have a feature that allows open-ended status messages, used for supply chain stuff.
… so you can have multiple states for a given VC.
… When PING was doing their review, they said "it looks like the issuer can change the amount of information that is published without notifying the subject".
… This will lead to a privacy violation where on Day 1 the messages are "pending" and "cancelled" but on Day 2 it becomes "cancelled due to criminal activity".
… Discussion: is it ok to keep this feature in there. It is marked as "at risk".
… or would people would object to CR because the feature isn't useful.

Gabe Cohen: I noticed Brent is assigned.

Manu Sporny: brent added some comments. He's representing mesur.io. They were an advocate of that feature.

Joe Andrieu: Manu summed up my concerns well. It becomes an avenue for arbitrary content being published w/o the subject being involved. Brent's argument was that we have same privacy as VCs. I disagree because holder is not in the loop (where they are with wrt. VCs).

Dave Longley: +1 to Joe.

Joe Andrieu: If we had a shared expectation where the user could know w/ shared states, if future version needs new state, individual could use new VC with that knowledge. What we have is a publication architecture that undermines privacy considerations put into VCs.

David Chadwick: +1 to JoeAndrieu.

Gabe Cohen: with chair hat off, can we avoid this problem by noting the status message in the credential itself.

Manu Sporny: Yes, +1 to what decentralgabe that's what I was on the queue to suggest as well.

Joe Andrieu: Instead of having a multi-bit status list you have multiple entries... status list should be of a constrained set if it's going to be of a set.

Dave Longley: +1 to Joe again :).

Paul Dietrich: within these status lists, there is nothing from preventing an issuer from adding additional information.

Manu Sporny: two things. If this is the concern, that privacy characteristics change after the fact. Then locking the states into the credential itself, then the holder knows the deal.
… this does make things more complicated.
… if we don't make that change, then it is true that multi-status allows leakage after the fact.
… which is likely going to lead to objections.
… To Paul's point, what we write in the spec with affect how people deploy, so while it is true that issuers can add anything they want, but that is very different from the WG saying this is how you can do.

Dave Longley: +1 to Manu, i think Joe's point is that we don't need to bless or approve of a particular approach in the standard, we can even speak against it (but we don't control behavior).

Manu Sporny: instead we can highlight that there is a better way. we can have implementation guidance that explains this privacy risk so that issuers can apply best practices.
… we would be establishing clear guidance.

Dave Longley: a major point of VCs is not to repeat the status quo where a user communicates to a verifier some way for them to then ask an issuer for whatever they want.

Mahmoud Alkhraishi: I don't think it would be seen negatively to commit to a static list of states.
… Let me talk with the rest of the traceability folks, but I think it can work.

Ivan Herman: q=.

Gabe Cohen: That's it for the agenda.

[decentralgabe]

I am supportive of the approach that stamps the acceptable status(es) in the credential at time of issuance.

[msporny]

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

[msporny]

PR #164 has been merged, closing.