Skip to main content

Understanding DIDs (Decentralized Identifiers)

DIDs are a fundamental component of digital identity and verifiable credentials. Understanding DIDs helps you better manage your credentials and identity infrastructure.

What is a DID?​

A DID (Decentralized Identifier) is a unique identifier that:

  • Is controlled by you (not a central authority)
  • Can be verified cryptographically
  • Doesn't require a centralized registry
  • Works across different systems and platforms

Think of a DID as a digital identity that you own and control, similar to how you own your email address, but without relying on a single company or service.

How DIDs Work​

DID Structure​

A DID consists of three parts:

  1. Scheme: Always starts with did:
  2. Method: The DID method (e.g., key, web, jwk)
  3. Identifier: A unique string specific to that method

Example: did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

Supported DID Methods​

Skippy supports several DID methods, each best suited for different use cases.

did:key​

The did:key method is a DID method where the DID is derived directly from a cryptographic public key. It is a self-certifying identifier that does not require a blockchain or any other external registry to resolve.

Structure:

did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

Pros:

  • Self-contained: The DID string itself contains the public key.
  • No Registry: No need to register on a blockchain or database.
  • Cost: Free to create and use.

Cons:

  • No Key Rotation: Changing the key changes the DID.

When to Use:

  • Testing and Development
  • Ephemeral Relationships
  • Direct Peer-to-Peer interactions

Example DID Document:

{
  "@context": "https://w3id.org/did-resolution/v1",
  "didDocument": {
    "id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
    "verificationMethod": [
      {
        "id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
        "type": "Ed25519VerificationKey2018",
        "controller": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
        "publicKeyBase58": "..."
      }
    ],
    "authentication": [
      "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
    ],
    "assertionMethod": [
      "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
    ]
  }
}

did:web​

The did:web method allows you to use your existing web domain as your decentralized identity. It links your DID to a web domain's reputation and security.

Structure:

did:web:example.com

Pros:

  • Domain-based: Leverages DNS and HTTPS for trust.
  • Organization-friendly: Ideal for businesses with existing web presence.
  • Resolvable: Resolves via standard HTTP requests.

Cons:

  • Requires maintaining a secure web server and domain.

When to Use:

  • Organizations and businesses
  • High assurance use cases

How it works: Resolves to https://example.com/.well-known/did.json.

did:jwk​

The did:jwk method enables a JSON Web Key (JWK) to be transformed into a DID.

Structure:

did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6Im...

Pros:

  • Self-contained: Encodes the JWK directly in the DID.
  • Interoperable: Works well with OIDC/OAuth2 systems.

Cons:

  • Large Identifiers: The DID string can be very long.
  • No key rotation.

did:cheqd​

The did:cheqd method operates on the Cheqd network, a blockchain for self-sovereign identity.

Structure:

did:cheqd:mainnet:zF7rhDBfUt9d1...

Pros:

  • Persistent: Identity anchored on a blockchain.
  • Key Rotation: Supports updating keys without changing the DID.
  • Resource Linking: Can link schemas and other resources.

When to Use:

  • Permanent identities
  • Commercial and trust registry use cases

DIDs in Skippy ID​

Organization DIDs​

When you create an organization:

  • Skippy ID automatically generates a DID for your organization
  • This DID represents your organization's identity
  • It's used for signing credentials and establishing trust

Project DIDs​

Each project gets its own DID:

  • Generated automatically when you create a project
  • Used as the issuer DID for credentials in that project
  • Can be used for verification workflows

Issuer DIDs​

When issuing credentials:

  • You select which DID will sign the credential
  • This is typically your project's DID
  • The DID proves that you issued the credential

Verifier DIDs​

For verification:

  • Your project has a verifier DID
  • This DID represents your verification authority
  • It's used when creating verification requests

Why DIDs Matter​

Decentralization​

  • No Single Point of Failure: DIDs don't rely on a central authority
  • Interoperability: DIDs work across different platforms and systems
  • Ownership: You control your DID and the keys associated with it

Security​

  • Cryptographic Proof: DIDs use cryptographic signatures for verification
  • Tamper-Proof: Credentials signed with DIDs can't be forged
  • Privacy: DIDs don't reveal personal information unless you choose to

Trust​

  • Verifiable: Anyone can verify who issued a credential by checking the DID
  • Transparent: DID documents are publicly accessible
  • Reputation: Your DID builds reputation over time as you issue credentials

Managing DIDs​

Viewing Your DIDs​

In Skippy ID, you can:

  • View organization DIDs in organization settings
  • View project DIDs in project settings
  • See which DIDs are used for issuing and verification

DID Documents​

Each DID has a DID document that contains:

  • Verification Methods: Public keys used for signing
  • Service Endpoints: URLs for credential issuance and verification
  • Metadata: Additional information about the DID

Next Steps​

Learn about other important concepts: