SD-JWT VC revocation via IETF Token Status List (gated: RFC + openvc-core + demand)

[luisgf]

Horizon: mid-long (gated) · Effort: L · 2026-07-17 roadmap analysis (round 3)

SD-JWT VC badges are deliberately irrevocable today: issuance rejects a credentialStatus (#226) because no interoperable revocation mechanism existed for the JOSE track. The mechanism now has a name — IETF OAuth Token Status List, at draft-21 (2026-06-21, expires 2026-12-23) — but it is not finished, and our delegate does not speak it.

Explicit gates — build only when all hold:

• Token Status List is published as a Standards-Track RFC
• openvc-core implements it (as of 1.20.2 / 2026-07-16 it does not — its status-list support is W3C Bitstring, which our LDP/JWT-VC tracks already use; delegation is the established pattern for this track, no native build)
• named demand, or HAIP/EUDI requiring status for the credential types we issue

Until then the #226 policy (reject at issuance + document the boundary) remains correct. Re-evaluation point: the December EUDI checkpoint (cross-referenced from that issue); if the gates are still open there, this moves to the quarterly radar (#173).

[luisgf]

openvc sub-gate re-checked against openvc-core 1.21.0 (2026-07-20). One of the three gates has effectively already moved, which sharpens this issue's framing.

Gate (b) "openvc-core implements it" — satisfied for verify. openvc-core exposes openvc.status.verify_status_list_token plus check_token_status / parse_token_status_ref (source-confirmed, not just changelog): it verifies the status-list token's signature, enforces typ: statuslist+jwt, checks exp fail-closed, does the anti-swap sub == expected_uri check, and reads the referenced token's status.status_list, with the codec conformance-pinned to the draft. This has shipped since openvc-core 0.4.0 (2026-07-06), so it is not new to 1.21 — the round-3 analysis simply confirmed it against source. So delegation would be available the same way the ecdsa-sd and SD-JWT paths already delegate.

Gate (a) "TSL is an RFC" — still closed. openvc's own source documents draft-ietf-oauth-status-list-21 as "IESG-approved and in the RFC Editor queue… no RFC number yet." Until it publishes, building against a draft is the same bet this issue already flags.

Gate (c) "demand / HAIP requirement" — unchanged.

Net: the implementation gate is no longer the blocker; the RFC gate is. Re-evaluation still belongs at the December EUDI checkpoint (#248), which is also when the RFC is expected. Today's #226 posture (reject credentialStatus at SD-JWT VC issuance) stays correct. No action now.

(Context: this came out of bumping the openvc-core floors to >=1.21 in 677f4ed. openvc-core still has no OpenID4VCI issuance, BBS, or X.509 CRL/OCSP — so #236's revocation gap and the OpenID4VCI side stay as recorded.)