Two browser tools for the credential lifecycle: compose and sign a W3C Verifiable Credential 2.0, then optionally mint a Selective Disclosure JWT (RFC 9901) from the same claims and choose exactly what a verifier gets to see. Both sign with eddsa-jcs-2022 / EdDSA over an ephemeral did:key generated in your browser, or a key you paste yourself.
For engineers integrating verifiable-credential or SD-JWT issuance into a wallet, agent, or compliance pipeline; and for compliance teams who want to see, hands-on, what a selective-disclosure receipt does and does not prove.
Compose claims, sign a W3C Verifiable Credential 2.0 with an eddsa-jcs-2022 Data Integrity proof, verify it in-page, and export an OCG Standard §23 vc-2.0 input-attestation block ready to pointer into a chain's policy_parameters.
Issue a Selective Disclosure JWT (RFC 9901) with per-claim disclosure toggles, or paste any SD-JWT to build a redacted presentation with an optional KB-JWT holder binding. See exactly what the verifier resolves.
Open tool →A verified eddsa-jcs-2022 signature or SD-JWT JWS proves two things: the claims were not altered after signing, and whoever holds the private key behind the stated did:key produced that signature. It does not, on its own, prove who that key-holder is in the real world. These tools generate ephemeral keys in your browser by default: nothing anchors them to an external identity registry unless you separately bind the did:key to one (a business registration record, a national eID scheme, an X.509 certificate chain, or an OCG Standard §20 timestamp anchor). Treat a credential or SD-JWT from this workbench as a working example of the format and cryptography, not as issued identity assurance, until you have anchored the issuer key yourself.
Selective disclosure narrows what a verifier sees to exactly the claims the holder chooses to reveal, each backed by a salted hash so the verifier can confirm a disclosed value was part of the original issuance without seeing the undisclosed claims. It does not hide the always-disclosed claims (issuer, subject, timestamps, and any claim the issuer chose not to make selectively disclosable), and a verifier who colludes with the holder can still learn undisclosed values through other channels. Selective disclosure narrows what is shown; it does not make the presentation anonymous by itself.
did:key needs no network lookup and no registrar: the DID is derived directly from the public key, so a browser tool with zero network calls can mint and resolve one. It is appropriate for demonstrating the cryptography; production issuance typically anchors the issuer identity through a longer-lived method.
Yes. Both tools have an advanced toggle to paste an Ed25519 private key as a JWK instead of generating a fresh one, so you can issue under a key you already control and re-use across sessions (nothing is stored between page loads).
OpenChainGraph chains can cite an external credential as an input attestation: a pointer into the chain's policy_parameters, plus the credential and its proof. The VC 2.0 composer's export is pre-shaped to drop into that array, so a chain that consumes a subject's claims can verify they came from a signed credential rather than free-text input.