Clarification on multiple items inside BitstringStatusListCredential.credentialSubject

[antonio-ivanovski]

The credentialSubject property of a document can contain a one or more items inside. The https://www.w3.org/TR/vc-bitstring-status-list/ document is taking the assumption that there will be only a single credential subject item, and that item can be used for further status check.

It is not possible to use the credentialSubject.id as it is in no way linked to the VC's credentialStatus that is being checked.

It is no possible to use credentialSubject.statusPurpose as there might be multiple credential subject with the same statusPurpose.

How to pick the correct credential subject for the given credential status check?

[msporny]

Hey @antonio-ivanovski thank you for your interest in the specification. You are correct that an issuer could list multiple entries in the credentialSubject and that the specification doesn't provide guidance on that item.

It is not possible to use the credentialSubject.id as it is in no way linked to the VC's credentialStatus that is being checked.

The BitstringStatusListEntry must contain the statusListCredential URL, but we don't require that URL to be used anywhere in the BitstringStatusList.

It is no possible to use credentialSubject.statusPurpose as there might be multiple credential subject with the same statusPurpose.

Yes, that is also true.

How to pick the correct credential subject for the given credential status check?

At present, the behavior is undefined and is therefore implementation dependent.

If we wanted to say something normative in the specification, we could say that only the first entry in the array that matches the statusPurpose wins. This has a downside that the array is supposed to be an unordered set and so the order isn't guaranteed (but maybe we don't care because issuers that create arrays with multiple entries for a statusPurpose are clearly doing it wrong and so we can't guarantee anything if they do that.

We could also require that verifiers scan the entire array to ensure that there are no duplicate statusPurposes in the array, but at the expense of having to do that check (implementation complexity where the upside of the check isn't really valuable -- you're dealing w/ an issuer that has a malformed array).

@antonio-ivanovski did you have any suggestions on what you'd like to see us do in the specification before we try to address your concern?

[antonio-ivanovski]

Thanks for the response @msporny.

From specification perspective for now could be useful for everyone to be aware of such scenario by:

1. Changing one of the example to include the credentialStatus as an array with multiple BitstringStatusList entries and another entry with type other than BitstringStatusList.
2. Have explicitly written the expected behaviour, example: "first entry in the array that matches the statusPurpose". This way, issuers and verifiers will be aware what to expect and aware what would happen if there are double entries.

As for a way to make this work better, I don't see another path forward as for adding additional binding identification parameter both to BitstringStatusList and BitstringStatusListEntry. Not sure how much desire there is for this, as the thing being handled here is incorrect usage of the feature.

[msporny]

@msporny wrote:

At present, the behavior is undefined and is therefore implementation dependent.

Hmm, I looked at your initial question and my answer again, and I think I misinterpreted what you were asking.

The credential status entries apply to ALL credentialSubject statements. If there are 30 credentialSubject entries in a VC, then a revocation statement associated with the credentialStatus entry applies to all 30 credentialSubject entries.

Another way to put it is that the credentialStatus applies to the entire VC, including any claims it makes.

Sorry for my confusion in my initial analysis of your question. Does what I say above make sense? If so, does that change the text you would like to see in the specification? Maybe we can just clearly state that credentialStatus (e.g., revocation, suspension, refresh) applies to ALL claims made by the VC.

[jandrieu]

I'll suggest some text to clarify that the revocation applies to the entire credential, not just one subject.

[iherman]

The issue was discussed in a meeting on 2024-12-11

• no resolutions were taken

View the transcript

2.2. Clarification on multiple items inside BitstringStatusListCredential.credentialSubject (issue vc-bitstring-status-list#184)

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

Brent Zundel: next is 184, clarification of multiple items inside credential subject.

Manu Sporny: this issue, the issue submitter was unclear which credential subject a BSSL applies to, this person said they don't know which subject the revocation bit applies to.
… the response was that the revocation bit applies to all credential subjects.
… what we might want to do is clearly state this in the spec.

Ivan Herman: +1 to manu, that sounds as the logical way to do it.

Joe Andrieu: +1, it's all the claims, we need to add that language.
… I can take this PR.

Brent Zundel: One more issue, is that worth looking at in our last minute.

Manu Sporny: this last issue is a test suite issue, we need to test a revoked vs non revoked credential.
… might want to move this issue to the BSSL test suite.

Ivan Herman: I have a general question before we end the call, is it correct that since the CR transition of BSSL, nothing substantial has happened, so we don't need CR2?

Brent Zundel: that is my understanding.

Manu Sporny: I don't know, I don't think so but not sure.

Ivan Herman: let's do it that way.

---

[brentzundel]

@jandrieu still looking forward to seeing your PR

[iherman]

The issue was discussed in a meeting on 2024-12-18

• no resolutions were taken

View the transcript

3.2. Clarification on multiple items inside BitstringStatusListCredential.credentialSubject (issue vc-bitstring-status-list#184)

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

Brent Zundel: clarification on multiple items inside BSSL credential subject. We talked about this last week. The suggestion was to say clearly that the revocation bit applies to all the credential subjects, we don't differentiate between multiple credential subjects in a status entry.
… I believe this should be a totally editorial change. Did Joe volunteer to raise a PR with some text? I think we are still awaiting that, I will ping Joe in the issue and we can move on unless folks have comments.

[msporny]

PR #196 was raised to address this issue. It has been merged, closing.