Cryptographic Suite

A cryptographic suite, cryptosuite for short, is a named, versioned bundle of algorithm choices that two systems agree to speak together, so that "sign this data" doesn't require negotiating a hash function, a signature scheme, a data-canonicalization method, and an encoding format separately every time. Instead, both sides just agree on one name, eddsa-rdfc-2022, say, and that name alone fully specifies every choice underneath it.

This solves a real, recurring problem in cryptography: a signature scheme (like Ed25519) is only one ingredient. Actually producing an interoperable signed artifact also requires agreeing on what bytes get hashed, in what order, encoded how, and different specs need different answers depending on what they're signing (a flat JSON document, a canonicalized RDF graph, a binary CBOR structure). A cryptosuite name collapses all of that into one identifier so two independent implementations, written by two different teams, produce byte-identical, interoperable output.

The same underlying idea appears under different names across the specs Solidus's credential stack touches:

• W3C Data Integrity calls it, literally, a cryptosuite property, eddsa-rdfc-2022, ecdsa-rdfc-2019, bbs-2023 (see Data Integrity Proof).
• JOSE / JSON Web Signature calls it an alg value, drawn from an IANA-maintained registry (EdDSA, ES256, RS256, and others, see JSON Web Signature).
• COSE, the CBOR-native sibling of JOSE, has its own parallel IANA algorithm registry (see COSE).

Three registries, three naming conventions, the same underlying job: pick one name, get one fully-specified, interoperable construction.

Where it comes from

The Data Integrity cryptosuite property comes from the W3C VC Working Group's Data Integrity specification, with Manu Sporny and Dave Longley among its editors, the same lineage behind the rest of the Data Integrity family (see that entry). The JOSE alg registry traces to RFC 7518, edited by Michael B. Jones. The COSE algorithms registry is a separate, parallel IANA registry tied to RFC 9052. Solidus authored none of the three.

Solidus status

Documented, not live, the same gap the Data Integrity Proof entry already found in detail, restated here because this term names it directly. Solidus's own published type (CredentialProof in @solidus-network/types) hard-codes Ed25519Signature2020, a suite name from the pre-2022 Linked Data Proofs lineage (see Linked Data Signature), not the current Data-Integrity cryptosuite naming convention. And checked live, 2026-07-17: the actual running issuer doesn't emit a Data-Integrity proof block, or any cryptosuite field, at all, its published OID4VCI metadata instead names credential_signing_alg_values_supported: ["EdDSA"], a JOSE alg identifier from a completely different registry. Solidus's documented type material names one registry's convention; its live wire format speaks another's.

Proof you can run yourself: curl -s https://capture-api.solidus.network/.well-known/openid-credential-issuer, the live response names a JOSE alg, not a Data-Integrity cryptosuite, direct evidence of which registry the shipped issuer actually uses.