Clearly define "revocation" and "suspension".

[OR13]

Requirements:

• use status list 2021
• use a "status changed" credential type which does not yet exist, and which exposes the duration of the changed status.

[OR13]

A Credential with a Status

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/vc/status-list/2021/v1"
  ],
  "id": "https://example.com/credentials/23894672394",
  "type": ["VerifiableCredential"],
  "issuer": "did:example:12345",
  "issuanceDate": "2021-04-05T14:27:42Z",
  "credentialStatus": {
    "id": "https://example.com/credentials/status/3#94567"
    "type": "StatusList2021Entry",
    "statusPurpose": "suspension", // status to check
    "statusListIndex": "94567",
    "statusListCredential": "https://example.com/credentials/status/3"
  },
  "credentialSubject": {
    "id": "did:example:6789", // subject is the organization
    "type": "Organization"
  },
  "proof": { ... }
}

A Credential tracking WHEN the status has changed

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
  ],
  "id": "https://example.com/credentials/111111",
  "type": ["VerifiableCredential", "StatusChanged"],
  "issuer": "did:example:12345",
  "issuanceDate": "2021-04-05T14:27:42Z", // date the status changed
  "credentialSubject": {
    "id": "https://example.com/credentials/23894672394", // subject is the credential
    "type": "VerifiableCredential"
  },
  "proof": { ... }
}

[mkhraisha]

Requirements:

1. Verifier needs to be able to check the status of the credential.
2. Verifier needs to receive a notification that the status of the credential has changed
3. Verifier needs to be able to suspend benefits until X Activity occurs
4. Verifier needs to be able to confirm Time of Suspension
5. Verifier of a valid (non-revoked/suspended) credential may or may not confer benefits due to their own business rules

[mkhraisha]

Current Capabilities using StatusList2021:

1. This is doable with no changes
2. This can be modelled as a SuspensionEventCredential OR a StatusChangedCredential ( i.e. event vs a non-event credential)
3. Verifier can always do this, because they are in charge of their own business rules
4. The SuspensionEventCredential/StatusChangedCredential needs to have times associated with start/end of suspension
5. Verifier can always do this, they are in charge of their own business rules

[BenjaminMoe]

1. We need more people to answer "are these requirements able to be met with StatusList2021"?
2. If not, are the other methods of addressing these requirements?

[mkhraisha]

@OR13 @mprorock @msporny @dlongley are you able to weigh in on the current StatusList2021 capabilities and if they satisfy those requirements /alternatives

[msporny]

Unless I'm missing something obvious, it feels like @mkhraisha's comments here are valid: #607 (comment)

Note: StatusList2021 is being renamed, so I'll refer to it using the old name for now. More thoughts below:

Verifier needs to be able to check the status of the credential.

Yes, this is supported w/ StatusList2021.

Verifier needs to receive a notification that the status of the credential has changed

This is not supported w/ StatusList2021 as StatusList2021 doesn't deal w/ communicating events to roles interested in status updates.

That said, there is nothing to say that one couldn't extend the status list endpoint to allow registering for future events when the list changes (though, that could be a DoS vector for the entity that is hosting the status list -- so, security mitigations would have to be considered there).

Verifier needs to be able to suspend benefits until X Activity occurs

Verifier can do this since they are in charge of their own business rules.

Verifier needs to be able to confirm Time of Suspension

StatusList2021 does not support this as it would make the list REALLY BIG if you wanted to store revocation time... and could create correlation issues if not done carefully. It changes the security characteristics of the list to publish this information.

One could extend the status list endpoint to allow querying this sort of information, but that would certainly destroy some of the privacy characteristics of the solution. An issuer would find out 1) who is interested in the information, unless the request for the information goes through a mixnet, 2) when they were interested in the information, and 3) that a relationship exists between the entity retrieving the status list and an entry in the status list. All of those things are correlation risks (that might be ok or not ok, based on the use case).

Verifier of a valid (non-revoked/suspended) credential may or may not confer benefits due to their own business rules

Verifier can do this since they are in charge of their own business rules.

[mkhraisha]

Verifier needs to be able to confirm Time of Suspension

StatusList2021 does not support this as it would make the list REALLY BIG if you wanted to store revocation time... and could create correlation issues if not done carefully. It changes the security characteristics of the list to publish this information.

One could extend the status list endpoint to allow querying this sort of information, but that would certainly destroy some of the privacy characteristics of the solution. An issuer would find out 1) who is interested in the information, unless the request for the information goes through a mixnet, 2) when they were interested in the information, and 3) that a relationship exists between the entity retrieving the status list and an entry in the status list. All of those things are correlation risks (that might be ok or not ok, based on the use case).

@mprorock I believe it was you who raised the business need for a timestamp of suspension time, tagging you to bring you in.

would a "generic" timestamp work, i.e. something that says it is suspended as of X date rather than a millisecond based one help alleviate some correlation risk, and still fulfill the business need?

are there any other ideas for this?