Standards & Specifications

This is the section that carries the argument. Solidus's claim is composition, not invention, and a claim like that is either backed by a countable list of other people's specifications or it is marketing. This is the list.

Measured 2026-08-07: 49 compose a standard written and maintained elsewhere, 4 implement someone else's specification with our own code, and none are inventions. It is also the section where Solidus ships the most, because a protocol assembled from finished specifications gets to inherit finished work. The live counts are the badges at the top of this page; they are computed from the entries themselves rather than typed here, so they cannot drift.

The shape of the stack

Read it in layers, from the identifier upward:

• Identifiers. A DID is a URL that resolves to a DID document containing public keys, with no registry operator in the middle. DID resolution is the lookup. A DID method is the rules for one family of DIDs, and did:solidus is ours, registered in the W3C DID Method Registry on 2026-07-04. That is a registry listing: it means the method name is reserved and the spec is published, and it is not a W3C standard, a W3C endorsement, or a certification of anything.
• Credentials. A Verifiable Credential is a signed set of claims about a subject. VC Data Model 2.0 is the W3C Recommendation that defines its shape (Solidus uses validFrom/validUntil, the 2.0 fields, not 1.1's issuanceDate). A Verifiable Presentation is what a holder sends a verifier. The issuer–holder–verifier triangle is the three-party model everything else assumes.
• Proof formats. Data Integrity proofs and linked-data signatures attach signatures to JSON-LD; JSON-LD itself gives the claims machine-readable meaning; cryptographic suites name the algorithm choices. Status lists and credential status answer "is this still valid?" without phoning the issuer on every check.
• Session and API auth. The whole OAuth 2.0 / OIDC / JWT / JWS / JWK / PKCE / DPoP / token introspection family: the IETF and OpenID Foundation work that Solidus Auth is built on. None of it is ours; all of it is battle-tested elsewhere first.
• Interop protocols. DIDComm v2, Presentation Exchange, Sidetree and the Universal Resolver come from the Decentralized Identity Foundation, where Solidus is an Associate Member, participation, not endorsement.

What is honest to say about conformance

Ranking a specification in this list does not mean Solidus passes its full test suite. Seven entries here say not-built (CBOR, COSE, mDoc, SIWE, Sidetree, credential schema, and more), five are spec, published design with no running code, and two are roadmap. Where a spec's clause-by-clause conformance matters, it gets its own page under /lexicon/specs, which carries a conformance verdict and, more importantly, a gaps field. A large specification with an empty gaps field means nobody checked, not that nothing is missing.

Everything shipped runs on a public testnet: no mainnet, no token, no audit, no paying customer.

Where this category ends

The mathematics of BBS+, BLS, VRF and zero-knowledge proofs is the cryptography section, this one covers the wire formats they get packaged into. Solid protocol standards are broken out separately, because Solidus's relationship to Solid needs its own honest framing. Regulations are not specifications and are filed under the EU and Türkiye sections.