The `BitstringStatusList.statusMessages` and `statusSize` properties are still being referenced

[timothee-haudebourg]

In Section 2.2 BitstringStatusListCredential about message value of the credentialSubject.statusPurpose property it is said:

Used to indicate a status message associated with a verifiable credential. The status message descriptions MUST be defined in credentialSubject.statusMessages. credentialSubject.statusSize MUST be specified when this statusPurpose value is used.

I believe that since the Draft 16 April 2024, the statusMessages and statusSize have been moved from BitstringStatusList to BitstringStatusListEntry, right? Is this a mistake or should the BitstringStatusListCredential still contain those properties?

[timothee-haudebourg]

Hi @msporny, I see the editorial label was added, does that mean the BitstringStatusList.statusSize property has indeed been removed?

[msporny]

Hey @timothee-haudebourg, the group is currently focused on the other specifications and I was just trying to triage this issue. I've taken another look and agree with you, the current framing is problematic.

The issue with statusSize and statusMessage is that many of the current implementers have not implemented the feature yet or are not planning on implementing the feature. I think you've found an issue in the spec and agree with you that the placement of statusSize and statusMessage are problematic... we're going to keep repeating the same information when it probably belongs on the StatusListCredential -- I'm going to have to check w/ the people that created this feature and see why they wanted those properties on the status list entry instead of the status list credential. As a result, I'll re-label this as normative, as if we change this, it will be a normative change.

[msporny]

I was just reminded that the reason we moved the statusSize and statusMessage to the credentialStatus field was due to privacy concerns around exposing the values to the general public. Not exposing them means that people watching the status list can't really tell what messages are associated with which bits (though, it's true that a determined attacker might figure that stuff out anyway by just getting their hands on a credentialStatus field from a VC.

So, given that, it's unlikely to change unless we get more implementers arguing one way or the other.

Maybe @mprorock or @brentzundel have some stronger opinions on where statusSize or statusMessage appear?

[dlongley]

For additional reasons why these pieces of information are in the status list entries in a VC and not the status list VC itself: https://github.com/w3c/vc-bitstring-status-list/issues/151

[msporny]

Right, one of which was that we didn't want issuers to be able to change the meaning of the status fields post issuance as a security guarantee to the holders. That is, the status messages would not change after issuance to the holder so that they can be assured of the information that they're handing over to the verifier.

[iherman]

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

• no resolutions were taken

View the transcript

#### 4.5. The `BitstringStatusList.statusMessages` and `statusSize` properties are still being referenced (issue vc-bitstring-status-list#175) _See github issue [vc-bitstring-status-list#175](https://github.com/w3c/vc-bitstring-status-list/issues/175)._ **Manu Sporny:** There is maybe only one implementer for this feature at this point. _See github issue [vc-bitstring-status-list#176](https://github.com/w3c/vc-bitstring-status-list/issues/176)._ **Manu Sporny:** Dont think it is currently marked as at risk. … Actually it is already marked at risk. … So we are waiting for implementations. **Brent Zundel:** My understanding is mesur implements these features. **Manu Sporny:** Great. I think Spruce may also be using it, so leaving it in awaiting implementations.

[timothee-haudebourg]

I just want to point out that this change is affecting the vc-barcodes CCG where status list entries should be described in a compact way. Adding the statusMessages and statusSize properties would go against that. See https://github.com/w3c-ccg/vc-barcodes/issues/19