Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The BitstringStatusList.statusMessages and statusSize properties are still being referenced #175

Open
timothee-haudebourg opened this issue Sep 5, 2024 · 6 comments
Assignees
Labels
CR1 This item was processed during the first Candidate Recommendation phase. normative The item is normative in nature.

Comments

@timothee-haudebourg
Copy link

timothee-haudebourg commented Sep 5, 2024

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 timothee-haudebourg changed the title The BitstringStatusListCredential.credentialSubject.statusMessages and statusSize properties are still beeing referenced The BitstringStatusList.statusMessages and statusSize properties are still beeing referenced Sep 5, 2024
@msporny msporny self-assigned this Sep 16, 2024
@msporny msporny added editorial CR1 This item was processed during the first Candidate Recommendation phase. labels Sep 16, 2024
@timothee-haudebourg
Copy link
Author

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

@msporny
Copy link
Member

msporny commented Sep 17, 2024

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 msporny added normative The item is normative in nature. and removed editorial labels Sep 17, 2024
@msporny
Copy link
Member

msporny commented Sep 17, 2024

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
Copy link
Contributor

For additional reasons why these pieces of information are in the status list entries in a VC and not the status list VC itself: #151

@msporny
Copy link
Member

msporny commented Sep 17, 2024

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.

@TallTed TallTed changed the title The BitstringStatusList.statusMessages and statusSize properties are still beeing referenced The BitstringStatusList.statusMessages and statusSize properties are still being referenced Sep 17, 2024
@iherman
Copy link
Member

iherman commented Sep 29, 2024

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.

Manu Sporny: There is maybe only one implementer for this feature at this point.

See github issue vc-bitstring-status-list#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CR1 This item was processed during the first Candidate Recommendation phase. normative The item is normative in nature.
Projects
None yet
Development

No branches or pull requests

4 participants