JSON Web Signature (JWS)

A JSON Web Signature is a compact, URL-safe way to attach a cryptographic signature to a JSON payload, so the result can travel as a single string, through a URL, an HTTP header, a QR code, rather than as a structured document that needs its own parser. It's the format quietly underneath most JWTs: when people say "JWT," they usually mean, specifically, a JWS whose payload happens to be a set of registered claims.

The construction is simple and worth seeing directly, because it explains why JWTs look the way they do:

base64url(header) . base64url(payload) . base64url(signature)

Three dot-separated segments. The header names the algorithm ({"alg":"EdDSA","typ":"JWT"}) and any key-identification metadata. The payload is whatever JSON the signer wants to sign, arbitrary claims, in JWT's case. The signature is computed over the literal ASCII bytes of base64url(header) + "." + base64url(payload), using whichever algorithm the header named. Verification just reverses this: recompute the signature over the same two segments, using the key the header (or context) points to, and check it matches the third segment exactly.

This is also exactly the shape a Key-Binding JWT takes (see that entry), and the leading segment of an SD-JWT VC's compact form, before any ~-separated disclosures, is a JWS in this same sense.

Where it comes from

RFC 7515, from the IETF JOSE working group, with Michael B. Jones as its primary editor alongside John Bradley and Nat Sakimura across the surrounding family of related RFCs (7515 through 7519, covering JWS, JWE, JWK, JWA, and JWT together). Solidus did not design the format.

Solidus status

Shipped, and this is the one entry in this batch where "implements" rather than "composes" is the honest call, worth explaining rather than just asserting. Solidus deliberately avoids a general-purpose JOSE library: its internal @solidus/jwt package hand-rolls the compact header.payload.signature construction directly over @noble/ed25519 (project convention: use the primitive directly, not a jose dependency), and the published @solidus-network/sdk's Key-Binding JWT code does the same, parsing and building the three-segment structure itself, in sdjwt/signer.ts and sdjwt/verify.ts. That's Solidus writing its own conformant reader and writer for RFC 7515's compact serialization, not wrapping someone else's.

Named honestly, though: the SD-JWT credential's own leading JWS segment, the part before any disclosures, is assembled by the wrapped, third-party @sd-jwt/core library, not by Solidus's own code. So the picture is mixed: Solidus wrote its own JWS handling for the Key-Binding JWT specifically, and depends on a third-party library's JWS assembly for the credential's primary signature. Both produce genuine, spec-conformant JWS structures either way.

One more precision worth stating: @solidus/jwt, the package with the fullest hand-rolled implementation, is marked private in its own package.json and has never been published to npm: a stranger can't npm install and inspect that exact code directly. What is independently installable and inspectable is the KB-JWT handling inside the published @solidus-network/sdk.

Testnet only; no mainnet exists.

Proof you can run yourself: npm i @solidus-network/sdk, call presentSdJwtVc, split the result on ~, and decode the final segment with any standard JWS/JWT tool, three base64url segments, exactly as described above. The parsing code that verifies it, with no jose dependency anywhere in the path, is right in the published source at sdjwt/verify.ts.