OAuth2 & OpenID Connect Debugger

DID Tools — resolve and verify a Decentralized Identifier

Resolve a DID to its document, read the keys it publishes, and check the two things a document cannot establish about itself: that a key it publishes really signed the credential this browser is holding, and that the DID and an origin are the same entity (DIF Well Known DID Configuration). Nothing here is specific to issuance or presentation — open it beside either workflow at any point.

did:jwk and did:key are their key: the identifier carries it, so they resolve with no network call at all. Only did:web has a document to retrieve. Note that SD-JWT VC defines no DID-based issuer signature mechanism — naming an issuer by DID with dc+sd-jwt is a profile extension — while ldp_vc is DID-native under VC Data Model 2.0.

Collapse all panes Tip: click a pane's title to collapse/expand it.

DID Document (W3C DID Core 1.0)

DID:The DID to resolve. did:jwk and did:key are decoded here with no network call; did:web is fetched from the document URL the method defines.
Resolve the DID above. did:jwk and did:key are decoded locally; did:web is fetched over HTTP(S) from the document URL the method defines. Load a DID Document from a file instead of resolving it. Use this when a did:web host sends no CORS headers, which stops a browser reading its document however correct the URL is: fetch it with curl, save it, and load it here.	Forget the resolved DID Document, its table, and the values it populated (on screen and in local storage).
Document URL:Where a did:web document is fetched from. Resolve fills this in from the DID: the host with its port percent-decoded, then /.well-known/did.json, or /<path>/did.json when the DID carries path segments. It stays empty for did:jwk and did:key, which have nothing to fetch. You can also type a URL here and press Retrieve, for a document that is not where the method's rules say it should be.	Fetch the DID Document from the URL above and use it here exactly as a resolved one. This is a retrieval, not a resolution: it is for a document that is not at the location the DID method derives — on a staging host, behind a tunnel, or at a path the issuer has not published yet. Because you chose the URL, a document whose id is a different DID is reported rather than refused.
Check that a key in this DID Document actually verifies the credential this browser is holding. Resolving a document proves nothing on its own — what matters is whether the key it publishes is the one that signed.
Credential in this browser:What the VC workflows last stored. Verify Signing Key checks the document against this credential, so it is worth knowing whether there is one and who it says issued it.

DID Document Members

The members of the document above, filled in when it resolves. Editable on purpose: this is where you try a document that has not been published yet, or break one deliberately to see what the verification does about it.

Domain Linkage (DIF Well Known DID Configuration)

A DID document says which keys a DID has. It cannot say why that DID should be believed to be the same party as some website — and for did:web the appearance of an answer is worse than none, because resolving did:web:example.com means fetching example.com. A Domain Linkage Credential breaks that circle: the DID signs, with its own key, a credential naming the origin, and a verifier checks the signature against the keys that DID authorises to assert.

Origin:The origin whose word is in question — scheme, host and port. Defaulted from the credential issuer this browser last discovered, but any origin can be asked about: a linkage is a claim between an origin and a DID and need have nothing to do with a credential.
Fetch /.well-known/did-configuration.json from the origin above and verify its Domain Linkage Credential. On success the origin's controller and the DID's controller are the same entity.

VC Tools

Tools that are useful at any point in these workflows, and belong to none of their steps.

DID Tools Resolve a DID to its document, read the keys it publishes, check that one of them really signed the credential this browser is holding, and check that the DID and an origin are the same entity.	Resolve a Decentralized Identifier (`did:jwk`, `did:key`, `did:web`) to its document, verify that a key it publishes signed the credential in this browser, and verify a domain linkage (DIF Well Known DID Configuration). Opens in this tab; the workflow's state is untouched.
Certificate Authority & X.509 Tools Build a Root, Intermediate and Issuing CA, issue certificates with any X.509v3 extension, and test a real TLS or mutual-TLS handshake with what you issued.	Build a certificate authority — Root, Intermediate and Issuing — and issue TLS server, TLS client, code-signing and S/MIME certificates with full X.509v3 extension control. Useful when the issuer or verifier is behind TLS you control. Opens in this tab; the workflow's state is untouched.