Issue 60: clarification of status list usage

[muisit]

Added Bitstring Status List as supported status list implementations. Clarified the use of the status claim for IETF Status Token List implementations references. Added a VCDM credentialStatus type statuslist+jwt to allow IETF Status Token List references inside the VCDM credential structure.

[samuelmr]

Why should DIIP require support for both Token Status List and Bitstring Status List?

• Because both specifications exist?
• Because some implementations currently support one but not the other?
• Because in some situations (which?) you'd prefer one and in other situations (which?) the other?

I read the discussion on issue #60, but didn't see a reason for requiring support for both specs.

I'm not opposing the requirement to support both specs. I would just like to understand the reasons why.

[muisit]

There are several reasons to support BitstringStatusLists:

• an earlier version of DIIP supported StatusList2020, which is a direct predecessor of BitstringStatusList
• BitstringStatusList is much more closely related to VCDM and uses the credentialStatus attribute as defined for VCDM
• implementors wanting to add an embedded linked data proof can use the @context definitions of VCDM to encode the credentialStatus information. If you want to use IETF Status Token Lists with embedded proof, you need to supply a proper additional @context
• BitstringStatusList implements a message definition allowing verification implementors to explicitely check on message values instead of relying on business case specific implementations of the meaning of multi-bit status lists

But it has downsides as well, some of which are, IMHO:

• it may be less supported in a broader view
• the message implementation is, IMHO, incorrect: message definitions should be defined in the status list credential, not in the VC that references the status list

Issuer implementations may hence have a business case to support BitstringStatusList, or support IETF Status Token List.

In any case, there are bound to be more types of credential status implementations next to these two token-list specifications. VCDM allows an easy way of extending the status list references by using the credentialStatus attribute. For that reason, I suggest adding the IETF specification to the credentialStatus implementation under type 'statuslist+jwt'.

In the future there may be status implementations involving zero-knowledge proof or accumulators or simple credential IDs. Implementations of status verifications should be ready, architecture wise, to accept multiple different types of status implementations, so it is not an argument to say we only ever need 1. It is easy enough to implement if you allow for different status implementations from the start, even if your implementation only supports a single type in the end.

Supporting only IETF Status Token Lists forces us to adopt an implementation that is not linked closely to Virtual Credentials, but 'happens' to implement a way to document status information on random tokens, like JOSE/COSE and SD-JWT encoded Virtual Credentials. I think choosing IETF over BitstringStatusList in DIIPv4 was not a good choice, because of this inherent mismatch. It makes DIIPv4 a 'patch of solutions' instead of a profile deepening the available specifications with implementation details, IMHO.