Decentralized Identifier — DID
A W3C recommendation finalized in 2022. Identifiers carry their own public keys and verification methods, so no central issuer is required. Paired with Verifiable Credentials, DIDs name the subject of attribute attestation in a verifiable way.
Definition
A DID is expressed as a URI of the form did:method:identifier. Each method defines its own resolution mechanism; the resolution result is a DID Document carrying public keys, service endpoints, and authentication methods. Issuance and verification are separated at the spec level.
W3C DID Core 1.0 reached Recommendation status in 2022. Common methods include did:web (HTTPS-hosted), did:key (the public key as the identifier itself), did:jwk, and did:pkh. For enterprise use cases like Lemma, did:web — anchored at an organization's own endpoint — is the most natural choice.
A DID does not prove anything by itself. It uniquely identifies a subject; Verifiable Credentials are responsible for the actual attribute claims. The two together let the system express, in a third-party-verifiable form, "who claimed what."
Lemma Oracle implementation
Lemma's attribute attestations and provenance chains identify both Issuer and Subject by DID. When an organization runs did:web, its own domain — via /.well-known/did.json — becomes the trust anchor directly.
Combined with selective disclosure, the attributes of a DID-identified subject (e.g., "this operator is EU-based," "this AI model was trained by a specific organization") can be proven without revealing the values themselves.
DIDs get most of their visibility in web3 projects, but as a W3C standard they are chain-agnostic. Lemma positions did:web as its primary method so the system rides on the existing DNS + HTTPS trust infrastructure.