The IETF OAuth Working Group posted revision 26 of SD-JWT-based Verifiable Digital Credentials on November 6. The specification defines formats and validation rules for credentials using JSON payloads, with or without selective disclosure, and covers issuer metadata, credential-type metadata, key discovery, presentation, and verification.
The draft has been submitted to the IESG for publication, but it remains a work in progress and may change. Its operational lesson is already clear: a credential is not just a signed token. Its trust depends on issuer keys, holder binding, verifier policy, metadata, retrieval paths, caches, software, and infrastructure.
Three roles create multiple control planes
The issuer creates the credential, the holder controls its presentation, and the verifier decides whether to accept it. Each role may be operated by a different organization, service, device, or supplier. Selective disclosure adds choices about which claims are revealed and how undisclosed claims remain protected.
A useful inventory should connect:
- credential type, format version, media type, issuer, subject, status, validity, and policy basis;
- issuer signing algorithm, key identifier, key-discovery method, trust path, rotation, and revocation or status mechanism;
- holder-binding method, confirmation key, device or wallet, custody boundary, backup, recovery, and replacement process;
- verifier, relying application, accepted issuer and type policy, requested claims, disclosure rules, and decision result;
- credential-type metadata, issuer metadata, retrieval URL, registry, local cache, version, integrity, and freshness;
- JOSE header, digest algorithm, salt generation, disclosure structure, audience, nonce, and replay controls;
- library, parser, wallet, issuer service, verifier service, gateway, firmware, version, build, and configuration;
- device, host, service, environment, region, location, owner, supplier, and business process; and
- discovery source, observation time, scope, confidence, exception, and known coverage gaps.
This map lets teams trace an acceptance decision back to the exact cryptographic and operational dependencies that produced it.
Metadata is part of the security boundary
The draft defines ways to obtain issuer and credential-type metadata. Retrieval may occur from a URL, registry, or local cache. That makes metadata availability, integrity, freshness, and ownership operational security concerns.
An outdated cache can apply old display rules or validation expectations. A compromised retrieval path can misdirect a verifier. An unavailable endpoint can cause either denial of service or unsafe fallback, depending on implementation.
Inventory should record the authoritative source, cache lifetime, last successful retrieval, integrity mechanism, failure behavior, and deployed version. Testing should cover stale data, conflicting sources, redirects, outages, rollback, and recovery.
Key discovery is not key governance
Being able to fetch an issuer verification key does not establish that the key is approved, current, correctly bound to the issuer, or protected throughout its lifecycle. Teams still need generation, custody, activation, rotation, compromise, revocation, and retirement records.
Holder keys require equal attention. A credential bound to a wallet or device creates dependencies on device replacement, account recovery, backup, synchronization, and incident response. If recovery silently changes binding or weakens assurance, the verifier needs policy to recognize that difference.
Evidence should link exact key identifiers and software versions to issuance and presentation events without retaining unnecessary disclosed personal data. Cryptographic accountability and data minimization must be designed together.
Selective disclosure needs verification tests
A format can protect undisclosed claims cryptographically while the surrounding interaction reveals information through claim requests, timing, identifiers, logs, or repeated presentations. Teams should evaluate the complete protocol and application flow, not just token validation.
Test minimal and excessive disclosure, missing and malformed claims, wrong audience, stale nonce, replay, key mismatch, algorithm rejection, metadata changes, clock skew, and cross-verifier correlation. Confirm that logs and telemetry do not capture raw credentials or disclosures by default.
Record results at the issuer, wallet, verifier, library, and infrastructure versions tested. “Supports SD-JWT VC” is not a precise interoperability or privacy claim.
What organizations should do next
First, map issuer, holder, verifier, metadata, key, status, and recovery relationships to canonical services, devices, owners, suppliers, environments, and locations.
Second, define accepted algorithms, credential types, issuers, disclosures, holder-binding methods, and failure behavior as versioned policy.
Third, test complete lifecycle paths: issuance, storage, presentation, verification, rotation, revocation, device replacement, cache refresh, outage, and recovery.
Finally, track the draft through IESG review and reconcile changes before treating an implementation as conformant to a final standard.
How Vista Platform helps
Vista Platform is a proprietary, self-hosted infrastructure inventory and DCIM platform with cryptographic posture built in. It serves as a cryptographic system of record through discovery, canonical inventory, evaluation, action, and proof. Teams can connect cryptographic implementations and policy to applications, devices, hosts, locations, owners, suppliers, exceptions, and migration evidence.
Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted rather than indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Explore Vista’s cryptographic inventory, post-quantum migration, and CBOM and compliance resources.
Where uncertainty remains
Revision 26 is not yet an RFC and still has an unresolved IESG discussion recorded by the Datatracker. Implementations, profiles, privacy properties, interoperability, and policy expectations may change. Successful signature verification does not prove that disclosure was minimal, metadata was fresh, the device was uncompromised, or the credential should be accepted for a particular decision.
Source
- SD-JWT-based Verifiable Digital Credentials, draft-ietf-oauth-sd-jwt-vc-26, IETF OAuth Working Group, November 6, 2026.