Clarify credentialStatus

[David-Chadwick]

There is some confusion about the semantics of the credentialStatus field, whether it refers to the status of the credential or the verifiable credential. The current text says it is a property of the VC and not the embedded credential. If this is so, it should be removed from the data model as it is not a property of the credential, or of the credential metadata. It is a property of the proof (either JWT or LD-proof) and should be defined along with the proof description.

However, both the underlying credential (e.g. degree certificate) and the digitally signed VC can have their own separate statuses. A person's degree can be revoked years after it has been issued, whilst a VC could be revoked if the issuer's private key is compromised. Therefore the proof specification should describe how the VC's proof can be revoked, whilst the VCDM should specify how the credential can be revoked. The following table shows the effects of combining these two revocation schemes.

Credential Status            Revoked Credential.          Not Revoked Credential
Revoked VC.                        unknown                         unknown
Not Revoked VC.             Credential Revoked                  Credential OK

If the VC has been revoked (e.g. because the issuer's private key was hacked) then we cannot tell what the status of the credential is, because the VC cannot be verified. In fact we cannot verify any of the credential's properties in this case.
Only if the VC has not been revoked, can we tell the status of the embedded credential. Thus it is logical that the credentialStatus field should apply to the credential and not to the verifiable credential as the current text states.
A PR is needed to change the definition of credentialStatus

[TallTed]

I do not think I understand your table. Is it meant to be a matrix? What are the periods (e.g., VC., Credential.) doing?

[David-Chadwick]

yes its a matrix indicating the status of the credential should either, neither or both of the credential or verifiable credential be revoked. You can ignore the periods.

[iherman]

The issue was discussed in a meeting on 2023-04-05

• no resolutions were taken

View the transcript

3.7. Clarify credentialStatus (issue vc-data-model#991)

See github issue vc-data-model#991.

Brent Zundel: Clarify credentialStatus.
… Not sure if this has been resolved because of our adoption of the StatusList work item.

David Chadwick: I think it's a valid comment. If you take the case of a degree certificate, revoke could happen if the private key is compromised or a student cheated. Need to differentiate between them.
… There was a problem with the CredentialStatusList. Did raise an issue.
… It would be nice if anyone involved in CredentialStatusList could say so.

Brent Zundel: Assigned davidc.

[iherman]

The issue was discussed in a meeting on 2023-06-07

• no resolutions were taken

View the transcript

2.8. Clarify credentialStatus (issue vc-data-model#991)

See github issue vc-data-model#991.

Brent Zundel: next issue 991, to discuss label. raised by and assigned to DavidC.

Orie Steele: We have a separate work item for credential status. This issue seems overtaken by events with open PRs. Close this PR and go over to that work item.

Orie Steele: I suggest closing this issue.

Brent Zundel: suggestion is to move this item to status list repo.

Orie Steele: and instead reviewing the open PRs on that work item.

Orie Steele: (you don't).

Joe Andrieu: that is not correct. Does seem to be about a specific status mechanism.

Orie Steele: there are not 2 objects, we spent over month on this.

Dave Longley: +1 just one object.

David Chadwick: There are 2 objects, credential and verifiable credential and now talking about the status is "mixed up" as well.
… one could be valid while the other is invalid and vice versa.

Brent Zundel: +1 just one object.

Joe Andrieu: +1 just one object, but this is the layering problem.

Orie Steele: It seems http range 14 is yet again, disrupting our ability to communicate.

Dave Longley: key revocation at the crypto layer is different than at the credential layer.
… key revocation and credential revocation are different things.

Joe Andrieu: We don't have separate items in our work. We have just one digital thing.

Orie Steele: joe is correct, and the digital thing, may or may not have any integrity protection.

David Chadwick: Driver's license is my credential (and I've been driving for a long time).

Joe Andrieu: There are three layers here. Different between having driven, the physical license and a digital thing.
… we don't have good language differentiating these three things.

David Chadwick: Yes it is difficult to talk about.

Dave Longley: there can a validity period on a proof (expressed via internal / external proof securing mechanism), a validity period on the VC, and a validity period expressed in a claim about a license that someone possesses ... all different things.
all works with 1 VC object.

---

[David-Chadwick]

Here is some proposed text for inclusion in the VCDM section 4.9 Status

Note. This property says nothing about the status of the underlying certificate/ticket/qualification/licence (collectively called certificate from hereon) from which the verifiableCredential was created. If the verifiableCredential has been revoked, then the certificate may or may not still be valid. It is out of scope of this specification how the status of the underlying certificate is determined

[iherman]

The issue was discussed in a meeting on 2023-06-28

• no resolutions were taken

View the transcript

2.12. Clarify credentialStatus (issue vc-data-model#991)

See github issue vc-data-model#991.

Brent Zundel: #991.
… how do we triage this one?

David Chadwick: depends is how much left in the core DM. Wants to change the terminology to "certificate verifiable credential". Certificate can be revoked or the VC can be revoked and status list should be able to distinguish between the two.

Orie Steele: It is relevant to the previous issue, and competitive positioning vs mDoc.

Brent Zundel: sounds like it's VC Status List work item.

David Chadwick: this is generic, not depending on the revocation status per se.

Joe Andrieu: issue is related to the core. Appreciates certificate suggestion. Status should just be about the VC. If about cert, should use ghe claim status of the cert.

David Chadwick: If we work remotely, then we have only VCs, Certs are only relevant f2f. Therefore if in the remote situation you only have the VC but the underlying cert can't be verified.

Brent Zundel: Proposes this issue be before CR and allow it to continue within the issue.

Joe Andrieu: fine with proposal - Re: David's ideas. Cert status? Either a mechanism to check it is there or not. If it exists you can put it in the claim.

Brent Zundel: encourages conversation to continue in the issue.
… to DavidC's question proposed text should be put in the issue.

[OR13]

This issue does not make sense to me.

[David-Chadwick]

@OR13 This is because it was written from the perspective of the credential and the verifiableCredential being different data objects, the credential being derived from the underlying certificate e.g. university degree, from which it was created, and then it being signed to create a VC. Now that it has been determined that credential and verifiableCredential are different terms for the same data object, nevertheless the original certificate from which the VC was created may or may not have been revoked, and may or may not have been the reason for the issuing of the revocation list. However, the status field says nothing about this. Hence the reason for adding the clarifying note.