What Fields Are Actually Inside Your Credential

Solidus does not implement credentialSchema. Our published credential type has no such field, and nothing in our issuance path validates a credential's shape against a published, independently fetchable schema document. The term is not-built.

The rest of this page explains what the missing thing is, why it matters, and what we do instead.

What credentialSchema is meant to be

In the W3C data model, credentialSchema is a property on a credential that points at a schema document, a machine-readable description of what fields this kind of credential must contain and what shape they take.

Its purpose is to let a verifier that has never seen your credential type before fetch the contract and check the credential against it, rather than relying on prior agreement about field names.

Without it, the contract still exists: it is just not written down anywhere a machine can find.

What is actually in ours, checked from the outside

You do not have to take our word for the field list. It ships in a public package:

$ npm view @solidus-network/types version        # 0.6.3, checked 2026-07-31
# then read dist/vc.d.ts — the VerifiableCredential interface:
  '@context'          string[]
  id                  string
  type                string[]
  issuer              string
  validFrom           string
  validUntil?         string
  credentialSubject   { id: string, [key: string]: unknown }
  proof               CredentialProof

Eight members. No credentialSchema. That is a negative result, and we are stating it plainly because that is what the evidence shows.

Note credentialSubject's index signature: [key: string]: unknown. The claims inside a credential are, at the type level, arbitrary. The shape is enforced only implicitly, by whatever the issuing code happens to construct, not by anything a verifier could independently check.

A coincidence that will mislead you if you grep for it

There is a credentialSchema in the Solidus codebase, and it is not this.

pod/apps/backend/src/routes/credentials.ts defines a variable by that name. It is an internal request-body validator for the Pod's own credential-storage API: it checks that an incoming HTTP request has the right shape before the Pod stores something. It has nothing to do with the W3C credential property, does not appear in any issued credential, and is not fetchable by a verifier.

We are naming it because someone auditing this repository will find it, and a same-named variable is exactly the kind of thing that gets mistaken for the real feature. It is not evidence that we implement credentialSchema. We do not.

A second precision, so the same grep does not mislead you twice

credentialStatus is also absent from that interface, and that does not mean credential status is unimplemented.

The two live on different paths. Revocation status on our SD-JWT credentials travels as a status claim inside the token, not as a credentialStatus property on the JSON-LD type, and that mechanism, including a signed and live status-list endpoint, is documented on why your credential shows active, suspended or revoked.

One absent field in one type is not a verdict on a whole capability. Check both paths before concluding.

What we do instead, and why it is weaker

The shape of a Solidus credential is fixed by two things: the issuing code, and the single credential configuration our issuer advertises in its published metadata.

That is a de facto contract. It is real, a verifier reading the issuer metadata learns what to expect, but it is not the thing credentialSchema provides:

• It is not attached to the credential. A credential encountered on its own does not carry a pointer to its own definition.
• It is not versioned as a fetchable document. If the shape changes, nothing tells a verifier which version it is holding.
• It does not generalise past us. With one issuer and one credential type, "everyone agrees on the shape" is easy. That property does not survive a second issuer, and a second issuer is the entire premise of a portable credential.

So this is a gap that gets worse exactly as the thing we are building starts working. We would rather name it that way than describe it as a minor omission.

What would have to change

1. A credentialSchema property carried on issued credentials.
2. A published, versioned, fetchable schema document per credential type.
3. Validation against it at issuance, otherwise the pointer is decorative.
4. More than one credential type, and more than one issuer, for any of it to earn its cost.

None of those exists today, and none is on a roadmap we would ask you to rely on.