Define credentialStatus correctly in YAML

[OR13]

See: #211 (comment)

[OR13]

ping @nissimsan this is to track defining credentialStatus correctly in YAML.

[msporny]

The group discussed this on 2022-09-06. credentialStatus is defined correctly in https://github.com/w3c-ccg/vc-http-api/blob/main/components/IssueCredentialOptions.yml#L38. @dlongley noted that you need to create an issuing instance that's configured to work with a particular revocation mechanism, and when you use that endpoint, that revocation mechanism is used, you can't turn it on and off. If you want to use a different one, you need to configure a different instance. @PatStLouis asked why you don't specify credentialStatus and asked if there is a mechanism other than revocation that's supported. @dlongley we don't recommend someone having an issuing endpoint where you can ask the same endpoint multiple types of revocation status information, for example changing from revocation to suspension, or an entirely different mechanism to track status. It would be very challenging for implementations to switch status lists for same group of credentials, instead what we're saying is, when you want to issue credentials that use a different type of credential status, always use that instance (create groups of credentials linked to status revocation mechanism through that). Are there other types of status info? Yes, there are -- suspension exists in StatusList2021 spec. You can have multiple different types of statuses, the ones defined today is suspension and revocation. The comment about sending an option to an endpoint and not to do that was not about "don't use status lists", it was "preconfigure endpoints so you don't have to do that in order to make implementations simpler".

@PatStLouis asked if an instance should have one revocation/status mechanism implemented, what's the purpose of having a way to set status information. @dlongley noted that when API was originally designed, it was built around testing VCs, but that didn't work well with real world use cases. For example, if you digitally sign using Ed25519, you probably wouldn't issue the credential using Ed25519 and then set the revocation list to use P-256. What we moved to was having "issuing instances" that had "configurations" and that you'd configure key types, revocation mechanisms, and other things to that endpoint. So when you hit the API, you don't have the client to send all the options to the endpoint. You don't hard code this in in your client or your server, you'd just configure instances w/ appropriate combinations.

The group is suggesting that setting the credentialStatus option should be moved from the issuance endpoint to the issuance instance configuration endpoint. The group wanted to check with the Traceability API cohort before making this change to ensure that it wouldn't negatively impact the Traceability API. /cc @OR13 @mprorock @mkhraisha @nissimsan

[OR13]

https://github.com/w3c-ccg/traceability-interop/blob/a00d12c20075395764ae2d587f8c9c0ccd563060/docs/openapi/resources/credential-status.yml

Seems like there is a mismatch between "array" and "object".

Which is correct?

seems like "object" is correct... cc @mprorock

See also: w3c-ccg/traceability-interop#379

[msporny]

The group discussed this on the 2023-06-06 call and came to the realization that this does not have to do with the configuration/instance endpoint (except for the fact that one or more status list mechanisms might be configured for a particular endpoint). The main question is what does the object that is used to update one or more credential statuses look like? What it looks like is going to be dependent on the particular status list format. @jandrieu noted that if we want to specify the VC API to support multiple status mechanisms, that we need to specify an update object that is going to support multiple status mechanisms.

In order to generalize the solution the group proposed the following. A call to modify the status of a credential needs to take an object that:

1. Identifies the credential (the identifier does not have to appear in the VC itself).
2. Identifies the specific status list entry to update (allowing for multiple status list types in a single credential). There is a base assumption that you can always differentiate between different entries for the same type of status list (which will be status list type specific).
3. Specifies the new status (which is status list type specific and is expected to be specified in the specification).
4. A field that identifies a "status allocator" for services to use which indexes are being used/assigned to VCs. Status service needs to delegate index/status allocation to the issuing services that will attach status entries to the VCs they issue. This helps prevent mistakes where you don't want to claim a credential is mapped to something w/o clearly identifying what the allocator was.

A PR should be raised to update the credential status update call to use an object with the properties defined above as well as explanatory text in the main specification that guides implementers and specification writers to put the details of the 3rd item above into a status list specification.