IDENTITY & CREDENTIALS

What is a Domain Linked Verifiable Credendital

A Domain Linked Verifiable Credential (DLVC) is a special Verifiable Credential that establishes a cryptographic link between a Decentralized Identifier (DID) and a web domain. This proves that a specific domain (like objectid.io) is legitimately…

A Domain Linked Verifiable Credential (DLVC) is a special Verifiable Credential that establishes a cryptographic link between a Decentralized Identifier (DID) and a web domain.

This proves that a specific domain (like objectid.io) is legitimately controlled by the holder of a DID. It’s an essential bridge between the decentralized world (DIDs) and the traditional web (DNS).


Why It Matters

Domain linkage enables users and systems to trust that a DID represents a legitimate entity, especially when interacting with websites, APIs, or services.

Without this link, anyone could claim a DID or domain independently—DLVCs allow verified binding between the two.


Format: JWT Verifiable Credential

In this case, the Verifiable Credential is encoded as a JWT (a signed token). It contains the same logical information as JSON-LD, but in a compact, URL-safe format.

Example (Decoded JWT Payload):

{
"iss": "did:web:objectid.io",
"sub": "",
"iat": 1712332800,
"exp": 1743868800,
"nbf": 1712332800,
"vc": {
"@context": [
"https://www.w3.org/2018/credentials/v1"
],
"type": [
"VerifiableCredential",
"DomainLinkageCredential"
],
"credentialSubject": {
"id": ""
}
}
}

This JWT is then signed with the private key corresponding to the DID’s verification method. The result is a token like:

php-templateCopyEditeyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJkaWQ6d2ViOm9iamVjdGlkLmlvIiwic3ViIjoiaHR0cHM6Ly9vYmplY3RpZC5pbyIsImlhdCI6MTcxMjMzMjgwMCwiZXhwIjoxNzQzODY4ODAwLCJuYmYiOjE3MTIzMzI4MDAsInZjIjp7IkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL3YxIl0sInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJEb21haW5MaW5rYWdlQ3JlZGVudGlhbCJdLCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6Imh0dHBzOi8vb2JqZWN0aWQuaW8ifX19.<signature>

Where Is the JWT Credential Published?

Just like with JSON-LD credentials, the JWT should be embedded in the .well-known/did-configuration.json file on the domain:

Example:

{
"linked_dids": [
"eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJkaWQ6d2ViOm9iamVjdGlkLmlvIiwic3ViIjoiaHR0cHM6Ly9vYmplY3RpZC5pbyIsImlhdCI6MTcxMjMzMjgwMCwiZXhwIjoxNzQzODY4ODAwLCJuYmYiOjE3MTIzMzI4MDAsInZjIjp7IkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL3YxIl0sInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJEb21haW5MaW5rYWdlQ3JlZGVudGlhbCJdLCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6Imh0dHBzOi8vb2JqZWN0aWQuaW8ifX19.<signature>"
]
}

This file must be accessible at:

/.well-known/did-configuration.json

Verification Process

A verifier that wants to validate the domain linkage will:

  1. Resolve the DID (did:web:objectid.io)
  2. Fetch the .well-known/did-configuration.json file
  3. Decode and verify the JWT:
    • Check signature against the DID’s public key
    • Check sub (subject) matches the domain
    • Confirm credential type is DomainLinkageCredential
    • Check time validity (iat, nbf, exp)

Advantages of JWT Format

  • Compact and URL-safe
  • Easier to use in environments where JSON-LD parsers are not available
  • Integrates well with OAuth2 / OpenID Connect stacks
  • Suitable for embedded systems and mobile apps
NEED MORE CONTEXT?

Explore the complete ObjectID architecture.

Back to knowledge base ↗