Multiple Credential Status Lists

[bruno-zimmermann-bit]

Is it possible in similar fashion to credentialSubject to have credentialStatus be a set of JSON objects? To me this is not clear from the specification.

eg.

{
 ... ,
 "credentialStatus": [{
    "id": "https://university.example/credentials/status/3#94567",
    "type": "StatusList2021Entry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://university.example/credentials/status/3"
  },
  {
    "id": "https://university.example/credentials/status/4#94567",
    "type": "StatusList2021Entry",
    "statusPurpose": "suspension",
    "statusListIndex": "94567",
    "statusListCredential": "https://university.example/credentials/status/4"
  }
 ]
}

[msporny]

Is it possible in similar fashion to credentialSubject to have credentialStatus be a set of JSON objects?

Short answer, yes. :)

What would you like to see in the specification to make this more clear?

[bruno-zimmermann-bit]

Cool thanks 👍

For credentialStatus i could envision something along the line of:

credentialStatus If present, the value of credentialStatus is defined as a set of one or more objects or a single object. Each object MUST include the following: ...

Alternally, I think an additional example with multiple credentialStatus can also make it more clear.

[KDean-GS1]

This is a question that maps to several real-world use cases.

In GS1, we license ranges of identifiers to our user companies. The terms and conditions under which these ranges are licenses differ between GS1 Member Organizations (regional not-for-profit organizations that administer the identification system in their regions), but, in general, the licenses are renewable, typically annually. If the user company doesn't pay to renew the license, the GS1 Member Organization may suspend it pending payment and, after a grace period, revoke it entirely.

The business rules for the credential status include one that a trading partner shouldn't accept the presentation of a license that is suspended or revoked at the point in time at which the trading partner does the validation. If license is suspended and the user company then catches up on the terms and conditions of their license by making the payment, the local GS1 Member Organization will then remove the suspended status and the trading partner's validation process will succeed, without any change in the license itself.

Another wrinkle to this is that, within the GS1 ecosystem, user companies can issue credentials of their own that reference their license credentials. Any credentials that are issued during the suspension period are subject to the same validation rules as those issued prior to the suspension; once the suspension is lifted, both sets of credentials are equally valid, because the suspension status is concerned only with the point in time at which the validation takes place. Revocation is different; credentials linked to the license that are issued before the revocation will be valid for many use cases (e.g., historical information for products from a manufacturer that is out of business) but none are valid under any circumstances if issued after the revocation (you can't issue a credential to identify a product if you are no longer licensed to use that identification range).

So, within the GS1 ecosystem, we can have one and only one status with multiple possible values: active (no other status applied), suspended (transient by definition), revoked (permanent), and replaced (permanent but a completely separate discussion).

Other ecosystems, though, may require more detail. A medical doctor is licensed to practice in a given jurisdiction. Let's say that the ecosystem for licensure allows a doctor to issue credentials (e.g., to certify a patient having received certain vaccines before travelling to a foreign country). If the doctor is under investigation for something serious enough, their license may be suspended, during which time they are not permitted to practice. If the investigation clears the doctor of wrongdoing, the suspension will be lifted, but the record of the suspension and the time period in which it applied must remain. A vaccination credential issued by the doctor prior to the suspension should be considered valid, regardless of the suspension, by checking the date issued against the start date of the suspension. A vaccination credential issued by the doctor during the suspension should be considered invalid, because the doctor was not licensed to practice during that period. In this use case, the business rule requires comparison of the timestamps of the license status and dependent credential, which differs from the GS1 use case which requires checking the license status only at the time of validation.

[iherman]

The issue was discussed in a meeting on 2024-01-31

• no resolutions were taken

View the transcript

#### 2.8. Multiple Credential Status Lists (issue vc-data-model#1291) _See github issue [vc-data-model#1291](https://github.com/w3c/vc-data-model/issues/1291)._ **Brent Zundel:** Multiple credential status lists -- is it possible to have multiple credential statuses, i.e., have `credentialStatus` be a set? … The short answer is "yes". Do we want to have an example? **Manu Sporny:** We have an example in the bitstring status list spec on having multiple statuses. > *Manu Sporny:* Multiple Status Lists in One Verifiable Credential: [https://w3c.github.io/vc-bitstring-status-list/#multiple-status-lists-in-one-verifiable-credential](https://w3c.github.io/vc-bitstring-status-list/#multiple-status-lists-in-one-verifiable-credential). **Manu Sporny:** But that's just for the bitstring status list type... let me get a link in here. … Maybe they are wanting something slightly different which is wanting different types of credential statuses. … We could just reuse the example from bitstring status list. Or we could point to those examples? **Brent Zundel:** We could create an example or modify example 17 in the spec so that credential status an array of objects, but hesitation to propose that as a path forward is that then we have to say how those statuses interact. Maybe we just have to say -- if you have multiple statuses and they are conflicting, good luck figuring that out. **Manu Sporny:** Yes, +1 to the same concerns. … He does provide an example -- about revocation and suspension. We could just use the example and add the warning that you just mentioned, Brent. It feels like it would address this issue. **Brent Zundel:** Ok. There's a proposal on the table, we take the suggestion from the issue, work it into the example we already have in the spec and then add a sentence to the spec that says, should multiple statuses be included and they be in conflict, the verifier's business logic needs to take that into account. **Joe Andrieu:** I like that general approach, +1, I don't think it's as much about them being in conflict as they represent different things semantically, we just need the validation phase to be able to pull in all the factors and be able to understand the semantics to make a decision. **David Lehn:** Is the processing of things like this similar to how you'd process proofs, where you have ANDs and ORs -- and it's a bit more work, but should we do that sort of thing? **Manu Sporny:** I'm concerned about saying that much in the spec this late in the process. … Most of the usage of credential status that I know of right now is whether it's revoked/suspended/or does it have 1-30 different values (multi-status stuff). I don't think we have enough implementation experience to make broad statements about composition. … And we should stay silent now until there's more implementation experience. **Joe Andrieu:** General +1 to Manu. … We do want to say that this is possible, and however many there are, they are inputs to validation and how composition happens and so on is the verifier's business. … They need to figure it out. There's also a use case contribution by Kevin from GS1 -- as GTINs get brought in during acquisitions there's a need to track status things. **Brent Zundel:** If anyone here says "that's a good idea, let's clean this up" -- assign yourself! If no one volunteers it won't get done. … Thank you all for being here, still a lot of work to do, hoping we can continue the momentum, thank you Dave for scribing, thank you all for being here, see you next week! ---

[iherman]

The issue was discussed in a meeting on 2024-02-28

• no resolutions were taken

View the transcript

#### 3.5. Multiple Credential Status Lists (issue vc-data-model#1291) _See github issue [vc-data-model#1291](https://github.com/w3c/vc-data-model/issues/1291)._ **Brent Zundel:** Do you need feedback on this one, Manu? **Manu Sporny:** I think this example should be in the status list spec, so let's transfer that over there. … So I think we already have a multi-purpose list over there so we might be able to close this. … The only problem is that it's not clear what implementers prefer to do over there. … Short answer is to transfer for status list. **Brent Zundel:** So the suggestion for 1291 is to move the issue to bitstring status list and address it there. … The question that comes to my mind is -- is that sufficient? … Theoretically, bitstring status list will be one of many that might go into the `credentialStatus` property all at the same time. … Is there sufficient language around the core data model for this -- or does the core DM need some language? **Manu Sporny:** That's an excellent point, I take back my proposal. Maybe what we should do here instead is provide an example of multiple status lists and just use BSL as the two entries. … Proposal is to add an example under `credentialStatus` with one that has revocation and another that has suspension. **Brent Zundel:** And a line that says check the status list specs to see how to handle things. It's possible for multiple statuses to exist and be contradictory and what you do with them is up to you. **Manu Sporny:** Sounds good.

[msporny]

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

[iherman]

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

• no resolutions were taken

View the transcript

#### 2.11. Multiple Credential Status Lists (issue vc-data-model#1291) _See github issue [vc-data-model#1291](https://github.com/w3c/vc-data-model/issues/1291)._ **Brent Zundel:** 1291. _See github pull request [vc-data-model#1450](https://github.com/w3c/vc-data-model/pull/1450)._ **Brent Zundel:** PR1450 covers this one. several approvals. … can be merged this week. … please take a look at it.

[msporny]

PR #1450 has been merged, closing.