SD-JWT VC `status` and `shortLived` claims for enhanced ETSI TS 119 472-1 compliance

[DavSanOl]

Summary

Align the status claim structure and add support for the shortLived claim within the SD-JWT VC implementation to improve ETSI TS 119 472-1 compliance.

Current behaviour

The SD-JWT VC payload includes an optional status claim if the revocationMethod is set in the credential schema. Said claim format is defined in sdjwtvc_formatter/model.rs but differs from TS 119 472-1 §5.2.10.

There is no support for the shortLived claim (§5.2.12), which indicates that the validity period of the EAA is too short to check its revocation status.

Expected behaviour

The following EAA status service model should be supported for SD-JWT VC format as defined in TS 119 472-1 §5.2.10:

{
    "status": {
        "type": "TokenStatusList",
        "purpose": "revocation",
        "index": 123,
        "uri": "https://some.status.list.com"
    }
}

Also, if the credential schema has no revocation method defined and the credential is meant to be issued under a short-lived policy, the EAA should include the shortLived claim as defined in TS 119 472-1 §5.2.12.

Motivation

Aligning SD-JWT VC status and shortLived claims with TS 119 472-1 is needed for QEAA interoperability, as they require either a normative status claim or the shortLived claim, according to TS 119 472-1 §5.2.10.2.

[EugeniuRusu]

Hi @DavSanOl, thank you for reporting!

We became aware of this issue recently as well, as part of some broader interop testing. The status entries we generate / support now are implemented according to draft-ietf-oauth-status-list-20 §4.2, which is referenced directly from the SD-JWT VC spec.

The ETSI TS 119 472-1 requirements in §5.2.10 define a different structure that matches the example you posted, this came up at the recent ETSI EAA plugtest as well, where several participants ran into the same discrepancy. In our current architecture this would require a new revocation method with corresponding configuration changes which is unwieldy.

We expect the ETSI definitions to eventually align with the IETF specs and re-use the existing status structure, in the meantime we will still aim to support both structures, as well as improve the handling of fields like shortLived, oneTime, category, etc.

[DavSanOl]

Hi @EugeniuRusu, thanks for the clarification!

It makes sense to wait for the ETSI definitions to align with IETF, and supporting both structures in the meantime sounds like a really good approach.