The Cryptosuite Field in Your Credential's Proof Block

There is no cryptosuite field in the credentials we actually issue, and the proof block this page describes does not appear on our wire format at all. The term is spec, documented in our type definitions, absent from what ships.

What a cryptosuite is meant to name

In the W3C Data Integrity model, a credential carries a proof object, and inside it a cryptosuite property names the exact recipe used: the canonicalisation, the hash, the signature algorithm, as one identifier, so a verifier knows precisely what to do rather than inferring it.

Current-generation names look like eddsa-rdfc-2022: algorithm, canonicalisation, year.

Three naming systems, and we appear in the wrong two

This is the useful thing to take away, because it confuses people constantly. The same signing algorithm has a different name in each of three registries:

naming system	example	where it lives
Linked Data Proofs (pre-2022)	`Ed25519Signature2020`	suite names on a `proof.type`
W3C Data Integrity cryptosuites	`eddsa-rdfc-2022`	the `cryptosuite` property
JOSE algorithm identifiers	`EdDSA`	JWS/JWT headers, `alg`

They are not variants of one name. They are three different registries, and a value from one is meaningless in another.

Our published type uses the first. Our live issuer speaks the third. Nothing anywhere uses the second.

What our published type says

From the package you can install:

export interface CredentialProof {
  type: 'Ed25519Signature2020'
  created: string
  verificationMethod: string
  proofPurpose: 'assertionMethod'
  proofValue: string
}

Ed25519Signature2020 is a Linked Data Proofs suite name, the pre-2022 lineage. It is a real identifier, and it is not current Data Integrity naming. A grep for cryptosuite across the whole published package returns zero files; a control grep for issuer returns one, so the search works.

So the type is documented in an outdated form.

What actually ships, which is neither

$ curl -s https://capture-api.solidus.network/.well-known/openid-credential-issuer
  format                                  : vc+sd-jwt
  credential_signing_alg_values_supported : ["EdDSA"]

200, checked 2026-07-31. EdDSA is a JOSE algorithm identifier, from the third registry. The live response contains no proof block and no cryptosuite property at all, because the live format is JOSE/SD-JWT, a world where signature parameters live in a JWS header, not in a Data-Integrity proof object.

The proof block this page is about is a thing our types describe and our issuer has never emitted.

Why this matters to anyone integrating

Do not write a verifier against our published CredentialProof type and expect to receive one. You will receive an SD-JWT. The type describes a shape that is not on the wire.
Do not read Ed25519Signature2020 as a claim of Data Integrity conformance. It is an older suite name in a type definition, not an implementation.
Do not translate between the registries by pattern-matching. EdDSA, eddsa-rdfc-2022 and Ed25519Signature2020 are not interchangeable strings even when the underlying mathematics is the same.