The standards we support: W3C credentials, DIDs, OpenID4VC and SD-JWT
A credential only one company's software can read ties everyone to that company. The Essence credential layer is written to open standards from the W3C, the OpenID Foundation and the IETF.
A credential is only useful if it can be checked somewhere other than where it was issued. If only one company's software can read it, the person who holds it and the organisation that relies on it are both tied to that company. Open standards remove that tie: a credential in a published format can be checked by any software that follows the same specification.
The Essence credential layer is written to published specifications from the W3C, the OpenID Foundation and the IETF.
A few terms
- Verifiable credential. A set of claims about someone, such as a name or a date of birth, signed by an issuer so that anyone can check it has not been altered.
- Decentralised identifier (DID). An identifier that leads to a document holding public keys, without a central registry. Each DID method defines how that lookup works.
- Issuance and presentation. Issuance puts a credential in the holder's hands. Presentation shows it, or part of it, to a verifier.
- Status list. A published list a verifier checks to see whether a credential has been revoked.
The standards at a glance
| Standard | What it is for | On Essence |
|---|---|---|
| W3C Verifiable Credentials 1.x and 2.0 | A common format for signed claims about someone | The credential code accepts both the 1.x and the 2.0 contexts |
| Decentralised identifiers | Identifiers and public keys without a central registry | Handlers for five DID methods in the code |
| W3C StatusList2021 | Checking whether a W3C credential has been revoked | The revocation method in the W3C credential code |
| IETF Token Status List | Checking whether an SD-JWT credential has been revoked | The issuer code serves it as a signed list anyone can read |
| OpenID4VCI 1.0 | Issuing a credential to a holder | Issuer code, built in our August release |
| OpenID4VP 1.0 | Presenting a credential to a verifier | Verifier code that records each presentation check, built in our August release |
| HAIP 1.0 | A high-assurance profile of OpenID4VCI and OpenID4VP | The profile our OpenID4VC work is scoped to |
| SD-JWT VC | A credential that reveals some claims and withholds the rest | The first credential format in the issuer code |
W3C credentials and identifiers
The W3C layer is the older half of this work, built by our May release. Its credential code accepts both the 1.x and the 2.0 contexts of the Verifiable Credentials data model, so credentials written to either version are accepted.
Five DID methods have handlers in the code, each suited to a different case:
did:key, a self-contained identifier made from a public key;did:web, an identifier anchored to a web domain an organisation already controls;did:peer, for identifiers used between two parties;did:ethr, for identifiers recorded on an Ethereum-compatible ledger;did:essence, the platform's own method.
OpenID4VC and SD-JWT
OpenID4VCI and OpenID4VP are the OpenID Foundation's protocols for issuing a credential and for presenting it to a verifier. Our work on both is scoped to version 1.0, profiled by HAIP 1.0, a high-assurance profile that narrows the options for uses where the stakes are higher. The core issuer and verifier code was built in our August release.
The first credential format on this route is SD-JWT VC, and its value is selective disclosure. A holder can present the claims a verifier asked for and withhold the rest, and the verifier can still check that every claim it received was signed by the issuer.
A recorded test run shows the verifier behaving as intended. It accepted a presentation with one claim disclosed. It refused four altered versions, among them one with a tampered issuer signature, one with a wrong nonce and one from an unregistered issuer. And when a holder disclosed more than was asked, it set the extra claim aside, so the verifier saw only what it had requested.
Revocation a verifier can check
A credential can only be trusted if it can also be withdrawn. The platform uses two published ways of doing that.
For W3C credentials, revocation uses StatusList2021: a compact list of bits in which each credential has a position, so one published list covers many credentials.
For SD-JWT credentials, the issuer code serves a signed IETF Token Status List that anyone can read. A verifier fetches the list and checks the credential's entry.
For issuers and verifiers, these standards mean checks that rest on public specifications, from the signature to the revocation status, rather than on a private format. For the person in the middle, they mean a credential that does not depend on any one company. If you are planning to issue or accept credentials and want to talk through which standards fit your case, we would be glad to hear from you.
Last reviewed 8 October 2026