SVX Documentation
HomepageAPISDK
Current
Current
  • Docs
  • Concepts
    • Digital Identity and Why It's Important
    • Digital Wallets
    • Ecosystems
    • Information Security
    • Personal Data & Attributes
    • Privacy- and Security-by-design
    • Secure Data Storage
    • Selective Disclosure / ZKP
    • Tokens and Tokenisation
    • Verifiable Credentials
    • Terminology
  • Platform
    • Secure Value Exchange
    • Authorisation, Tenant & Organisation Manager (ATOM)
    • Credential Service
    • Decentralised Identifiers (DIDs)
    • Keys
    • Tenants, Organisations, and End-Users
    • Vault
      • Enterprise Vault
    • Portal
    • Supported Standards
  • Guides
    • Onboarding to SVX
    • API Guides
      • Credentials
        • Credential Schemas
        • Credential Types
        • Issue Credentials
        • Presentation Definitions
        • Presentations
      • DIDs
        • DID Resolver
        • DID Registrar
        • DID Methods
          • did:key
          • did:web
          • did:ebsi
          • did:indy
        • DID Controller Keypair
      • OpenID Connect
        • For Verifiable Presentation
      • Users
        • Inviting End-Users
        • Authenticating End-Users
      • Vault
        • Items and Slots
        • Connections and Sharing
        • Classification Hierarchies
        • Attachments
        • On-sharing & Client Tasks
        • Account Delegation
      • Machine-2-Machine Communication
    • Portal Tutorials
      • Tenant Administrators
        • Onboard to a Tenancy
        • Dashboard and Navigation
        • Manage Tenancy
        • Manage Tenant Administrators
        • Manage Organisations
        • Manage Organisation Administrators
        • Credential Schemas
        • Applications
        • End Users
      • Organisation Administrators
        • Manage Organisation
        • Onboarding and Organisation Setup
        • Dashboard and Navigation
        • Manage Organisation Administrators
        • Credential Templates
        • View Credentials
        • Verification Templates
        • Verification Requests
        • Connections
        • Applications
    • Wallet Tutorials
      • Wallet Set Up
      • Provider Registration
      • Organisation Configuration
      • Credentials
      • Requests
      • Security
      • Wallet Recovery
  • Tools
    • Meeco SDK & CLI
    • Cryppo SDK & CLI
  • Releases
    • 2.1.1
    • 2.1.0
    • 2.0.0
    • 1.4.3
    • 1.4.2
    • 1.4.1
    • 1.4.0
    • 1.3.8
    • 1.3.7
    • 1.3.6
    • 1.3.5
    • 1.3.4
    • 1.3.3
    • 1.3.2
    • 1.3.0
    • 1.2.5
    • 1.2.4
    • 1.2.3
    • 1.2.2
    • 1.2.1
    • 1.2.0
    • 1.1.0
    • 1.0.0
    • Legacy API-of-Me
  • Policies
    • Privacy
    • Developer Policy
Powered by GitBook
On this page
  • DID Methods
  • Universal Resolver
  • How are DIDs used?

Was this helpful?

Edit on GitHub
  1. Platform

Decentralised Identifiers (DIDs)

Last updated 5 months ago

Was this helpful?

Decentralised identifiers (DIDs) are a type of digital identifier that can be associated with any subject. The subject can be a: person, device, organisation or thing. Whatever type of subject the DID is linked to, they are controlled by the creator who can choose where and when to use them. The difference between other commonly used identifiers (e.g. email, twitter handle) and DIDs is that the former are controlled by someone else (email provider, Twitter) and can be taken away. DIDs solve that issue, which makes them a very important cornerstone for digital identity.

A DID may have one or more DID controllers who contribute to changes made to a DID document. Meeco's framework does not prohibit the usage of any property in the DID document by the DID controller, this is to aid future extensibility and versatility.

Key characteristics of a DID include:

  • Decentralised: they are not managed or issued by a central authority.

  • Persistent: once created, they are permanent and do not rely on an organisation to manage them (as opposed to DNS, email, etc).

  • Cryptographically verifiable: designed to be associated with cryptographic keys and as such allow someone to prove control over the DID.

  • Resolvable: allow any party to discover information about it to give it meaning.

See for more information.

DID Methods

There are many DID methods in use today (+200 at the time writing). Determining which DID method to use at any one time generally depends on its intended use case. An important consideration is whether the DID is going to identify a natural person (NP) or legal entity (LE). When identifying NPs, privacy regulations come into effect and, generally speaking, it is always safer to use a DID method that does not rely on a verifiable data registry (VDR). On the other hand, for LEs, it is rather useful to use a publicly accessible VDR that allows secure resolution of a DID.

DID method specifications are developed to define DID methods, including specific operations. These operations include how the DIDs and DID documents are created, resolved, updated, and deactivated.

Universal Resolver

Meeco supports DID resolving for various DID methods via a system based on the Universal Resolver (UR). The UR has been designed and is managed by the and can be contributed to by individuals working in the discipline. The UR enables systems to resolve DIDs across many different DID methods. This allows system implementers to be DID-agnostic and provide seamless workflows between ecosystems.

How are DIDs used?

While DIDs are used to identify a particular subject, personally identifiable information (PII) is not generally associated with the DID or associated DID document. Keeping in mind that a DID is a URI and as such a formatted combination of letters, numbers and specific symbols, a subject’s DID does not include the subject’s name, location or other identifying attributes. It is advised by W3C that, when PII associated with a subject needs to be managed or shared, it should be done so via a Verifiable Credential (VC) or service endpoints controlled by the DID subject. This process ensures that the privacy of the subject is maintained and the control over data sharing and exposure remains with the subject itself. Items such as VCs can be associated with DIDs to ensure the subject can maintain and manage their PII, however only the subject can read the data inside the VC. The subject can always share the VC with another party, and in that transaction the subject will grant access to the party to read their associated DID document.

For detailed information on Meeco’s DID implementations see our .

Use Cases and Requirements for Decentralized Identifiers, W3C
DIF Identifiers & Discovery Working Group
DID API documentation