The standards war is over. ORBIS.ID implemented the winners.

The protocol by which an issuer hands a credential to a wallet. The issuer publishes machine-readable metadata describing what it can issue; the wallet redeems an offer and collects the credential.

How ORBIS implements it. Issuer metadata is published at /.well-known/openid-credential-issuer and, per OID4VCI 1.0 §12.2.3, the token endpoint lives in the referenced authorization-server metadata at /.well-known/oauth-authorization-server — not in the issuer document. The pre-authorized code grant (urn:ietf:params:oauth:grant-type:pre-authorized_code) is advertised and supported, credential offers are delivered as QR codes, and every advertised configuration declares format dc+sd-jwt, an https credential type URI, JWK cryptographic binding, and ES256 signing and proof algorithms. The DIIP check VCI-1 asserts exactly this shape in CI.

The protocol by which a verifier asks a wallet for a proof, and the wallet responds — with the holder deciding what to disclose.

How ORBIS implements it. Presentation requests use response_type=vp_token with response_mode=direct_post, carry a fresh nonce and a client_id, and express what they want as a DCQL query over the dc+sd-jwt format. A relying party may bind its own nonce, audience and origin to a hosted request, so the resulting presentation is provably meant for it. The DIIP check VP-1 asserts the request shape in CI.

Selective Disclosure JWT: the credential format that lets a holder reveal individual claims and withhold the rest, while the issuer’s single signature still verifies. Share your age without your address. SD-JWT reached RFC status as RFC 9901 in 2025; SD-JWT VC is at the IESG for RFC publication.

How ORBIS implements it. Credentials are issued in the dc+sd-jwt format signed with ES256, with per-claim disclosure and a holder key binding proof, and the platform’s own validation chain checks the disclosure set the verifier actually required — not merely that the envelope parses.

The query language a verifier uses to state precisely which credential type and which claims it needs — the mechanism that turns “show me your ID” into “prove you are over 18”.

How ORBIS implements it. Every presentation request the platform builds carries a dcql_query naming the requested format and claim set; the public verifier only accepts claims that the requested credential type actually defines, and refuses a request with no valid claims.

A decentralized identifier that resolves over ordinary HTTPS: the issuer publishes a DID document containing its public keys, and anyone can fetch it. No blockchain, no registry fee, no gatekeeper.

How ORBIS implements it. The platform and every tenant have their own did:web identity; the DID document is served at /.well-known/did.json (per tenant, under its own path), binds to its own identifier, and publishes an EC P-256 assertion key. The DIIP check DID-1 asserts resolution, self-binding and curve in CI. Private keys are never in the document and never on disk — signing happens inside Azure Key Vault under managed identity.

Revocation without phoning home: the issuer publishes a compressed bitstring in which each credential owns one bit. A verifier fetches the list and reads the bit — learning nothing about which credential was checked.

How ORBIS implements it. Status lists are served as signed statuslist+jwt tokens (ES256) whose payload carries the bitstring, versioned per issuer and per tenant, and persisted so that a rolled-over issuer’s earlier lists keep serving. The DIIP check STATUS-1 asserts the media type, header type, algorithm and payload shape in CI.

Which issuers should a verifier believe? The platform maintains a signed issuer directory, and the drop-in verifier SDK lets a relying party trust exactly the identities it chooses — the trust decision stays with the relying party, not with ORBIS.

The W3C recommendation that defines what a verifiable credential is: issuer, subject, claims, proof, and the roles of issuer, holder and verifier. It is the conceptual ground the whole ecosystem shares, whatever wire format is used to carry it.

How ORBIS implements it. ORBIS credentials follow the issuer–holder–verifier model with cryptographic holder binding, and are carried in the SD-JWT VC format — the format the EU profile and the OpenID specifications select for selective disclosure.

A profile that pins down the options: which formats, which algorithms, which binding methods, so that two independently built implementations actually interoperate rather than merely claiming the same acronyms.

How ORBIS implements it. The platform’s wire surface is pinned to the high-assurance choices — dc+sd-jwt, ES256, JWK holder binding, direct_post — and those choices are asserted by the conformance suite so they cannot silently regress.

The interop profile the ecosystem tests against. ORBIS.ID passes five of five checks, and it passes them as a test — not as a certificate on a slide.

How ORBIS implements it. The conformance suite runs in CI against a live local instance on every deploy, so the wire surface a conforming wallet or verifier relies on can never silently regress; the same suite can be pointed at the live domain. The five checks are DID-1 (the did:web document resolves and binds to its own identifier, EC P-256), VCI-1 (issuance metadata advertises dc+sd-jwt, ES256 and JWK binding, with the token endpoint in the authorization-server metadata), STATUS-1 (the status list is a signed statuslist+jwt with a bitstring), VP-1 (the presentation request uses DCQL, a nonce, a client identifier and direct_post), and PRIV-1 (trust artifacts are CORS-open, so any relying party can fetch them from a browser).