Revocation method implementation not clear

[muisit]

The spec indicates DIIPv4 supports IETF status token lists.

The IETF status token list indicates it is usable for JWT tokens. This creates an issue with CBOR encoded tokens and it is unclear if this would apply to SD-JWT credentials as well, or only to JOSE encoded credentials.

The IETF spec states the token status is encoded in a 'status' claim that contains a 'status_list' claim, presumably directly in the 'root' of the JWT.

DIIPv4 also states it supports VCDM 2.0. That spec has a 'credentialStatus' claim in the credential which would encode the status token list information. It is unclear whether support for IETF status tokens would allow encoding the status information in the credentialStatus claim of the credential, instead of in a separate 'claim' attribute.

Hence I suggest the next version offers more implementation details about how status lists should be encoded in the various supported encodings.

I also suggest to support BitstringStatusList. It is effectively the same technology as the IETF status token lists and the implementation fits nicely in the VCDM 2.0 credentialStatus claim. This would fit the ecosystem much better than supporting IETF status token lists, which are directed at JWT tokens specifically and not at credentials in general.

Cheers,

Michiel Uitdehaag
SURF

[nklomp]

Just a quick note as I do not have time. The encoding of the credential itself has little todo with the status list implementation. That implementation is a Verifiable Credential in itself separate from the credential referencing the statusList, encoded in some form, which the end solution obviously needs to support.

You can have JsonLD credentials protected by a Jwt or Cbor status list credential for instance

OAuth StatusList actually supports 2 encodings like VCDM with the Jose/Cose spec. That is JWTs and Cose

[muisit]

I think you are mostly correct but partially not.

The IETF Status Token list documentation is aimed at adding a 'status' claim to JWT tokens, not to other credentials that are encoded in a different way (COSE or plain json with or without embedded proof for example).

You could easily apply this implementation to any kind of credential, not only the ones encoded as a JWT. However, the IETF spec does not indicate anything about how to do this exactly, so the DIIP profile should step in here and be very exact in the expected claims.

Furthermore, the IETF Status Token list specification specifies the use of a 'status' claim in the JWT token, but the DIIP profile indicates it supports VCDM. The VCDM spec has a 'credentialStatus' attribute to encode status lists.

I suggest to specify explicitely that instead of (or in addition to) using the IETF 'status' claim, DIIP should support a 'credentialStatus' type of 'statuslist+jwt' with the relevant IETF Status List attributes (idx, uri). That would make implementing different status implementations much easier.

As alternative, I suggest that DIIP should explicitely state that the 'status' claim in plain JSON, JOSE, COSE and SD-JWT encoded credentials will contain the IETF Status Token list implementation, so that implementors are clear on exactly where to look for the status implementations (either in the status.status_list value, or in the VCDM credentialStatus value).

I can write up a PR for this if there is consensus.

[nklomp]

The token statuslist is just a regular credential in jwt or cbor encoding the statuslist itself. That in itself does not have to know anything about the actual end user credential and format it describes. It is just an indexed list providing a status and encoded as a credential. Is index X or Y valid, suspended, revoked etc. Then any credential format (vcdm1/2, sd-jwt, cwt/cbor/mdoc) supporting inclusion of statuslists can point to an index in the statuslist.

The process is simple. Encounter status list references in any of the credentials. Resolve them, decode and very the status list credentials (signatures), match isuers of statuslist and credential, lookup the value of the referenced index and be done.

Thus there is no relationship between statuslist format and end user credential format, except for the fact that typically the end user credential format describes the types/names of the statuslist formats it supports in the form of a registry or non normative info.

In reality in a lot of cases you see statuslist types using the same credential format/encoding as end user credentials, but we have on numerous occasions worked with jsonld and jwt credentials with different statuslist encodings for instance.

Since a statuslist cannot really describe all credentials it would be used in it would be wise to describe a normative section about known formats and non normative guidance for other formats.

Having said that the more specific we can be in DIIP, the better. So a PR is always welcome, as long as it follows VCDM2 approach of statuslists inclusion.

[muisit]

I think you are missing my point.

I am not talking about the actual implementation of status lists.
I am talking about the reference inside the credential or JWT to that status list.

The IETF Status Token List specification says it applies to JWTs. That means it does not apply to COSE encoded credentials, nor to plain JSON credentials with embedded proof. It may apply to SD-JWTs in the same way as it applies to VCDM 1.1 and VCDM 2,0 encoded JOSE credentials. This is a cause for confusion.

The IETF Status Token List specification explicitely mentions the use of a 'status' claim in the status protected JWT instead of using the VCDM 'credentialStatus' attribute. This again is cause for confusion.

I will draft up a PR to make it clear what I suggest.

[muisit]

I must correct myself: IETF does specify something for COSE and mDOC encoded credentials, just not for plain JSON credentials with or without embedded proof.

[nklomp]

It mentions the status object as that is how you include a statuslist in the sd-jwt, just like there is a defined way in the Vcdm1/2 specs to reference/include a statuslist in your credential.

Hence why i mentioned that a statuslist spec itself should only make normative references of credential specs referencing them (statuslist) it knows about and a non normative text about others credential specs potentially referencing the statuslist.

For vcdm credentials there is a statuslist type value in every statuslist being referenced from the credential, not sure if there already is a value or registry inclusion for oauth statuslist though.

[nklomp]

It mentions the status object as that is how you include a statuslist in the sd-jwt, just like there is a defined way in the Vcdm1/2 specs to reference/include a statuslist in your credential.

Hence why i mentioned that a statuslist spec itself should only make normative references of credential specs referencing them (statuslist) and a non normative text about others credential specs potentially referencing the statuslist.

For vcdm credentials there is a statuslist type value in every statuslist being referenced from the credential, not sure if there already is a value or registry inclusion for oauth statuslist though.

Basically we are talking about describing https://www.w3.org/TR/vc-data-model-2.0/#example-use-of-multiple-entries-for-the-status-property

[nklomp]

And the nicest approach would be to get it into the registry/extension document at https://w3c.github.io/vc-extensions/#credential-status

[muisit]

That would be a good thing, I agree.

#61

[Oran-Dan]

To continue the discussion also held during the meeting yesterday I will post my thoughts/suggestions below:

• For simplicity, leave BitstringStatusList out, focus on Token Status List (TSL)
• To be compliant with OpenBadges and VC 1.1 I suggest to include the in VC 2 optional field id and it MUST be the same as the uri. Of course this would be duplicate information but I don't see a cleaner, simpler way to satisfy both specs: OpenBadges & VC1.1 want the id field to be the URL and IETF wants that URL to be in the uri field.
• Since Openbadges/VC1.1 only accept one CredentialStatus object, not an array, and in VC 2 it can be both I'd suggest sticking to one object, no array. This point of having multiple "statuses" has also been discussed in the IETF TSL spec github itself. Also there they opt for only a single status, if more information needs to be conveyed this can be done via the extensible StatusTypes which doesn't have to be only 1 bit with 2 options in the TSL spec.
• As discussed before it would be a good idea to try and get this into the VC extensions registry document.
• I also agree flattening the Referenced Token info into the VC Json object, as Michiel suggested. This best mimics the spec definitions for SD-JWT.
• When retrieving the Status List Token JWT from a uri I suggest using the same key mechanisms as used already in the DIIP Profile in the OID4VCI chapter 4.5:
  Requirement: DIIP-compliant implementations MUST support the jwt proof type with a did:jwk or did:web as the iss value and use a kid from the assertionMethod Verification Method relationship of the respective Issuer's DID document.
  Since this paragraph is listed specifically for OID4VCI it should be repeated in the Revocation method chapter.

P.S. perhaps premature but in the future if we encounter need for more StatusTypes then the 3 defined already in the spec (Valid, Unvalid, Suspended) we can also extend the StatusTypes here in the profile to ensure interop.