DID Documents for users & managers

5 min readMay 27, 2024

1) Introduction

Decentralized Identifiers (DIDs) are transforming digital identity verification by eliminating the need for a central authority. These unique identifiers ensure security through cryptographic methods and offer full control to the user. Each DID is linked to a publicly accessible DID Document containing crucial details like public keys and services. This innovative approach enhances transparency and trust in digital interactions, positioning DIDs at the forefront of identity management technology.

2) DIDs

Within the myDid project, a Decentralized Identifier (DID) is a unique identifier that adheres to key principles ensuring reliability and control:

  • Uniqueness: Each DID is distinctive, assigned once, and never reattributable.
  • Autonomy: Operates independently of any central authority.
  • Security: Linked to one or more cryptographic keys to ensure sole control by its owner.
  • Transparency: Enables retrieval of a public document, the “DID Document”, which references other elements like public keys and services.

In the myDid project, there are two types of DID Documents tailored to the varying needs : one for managers/organizations (on-chain) and another for individual users (off-chain). These two kinds of DID look the same but :
- “user DID Documents” are very simple and can be directly resolved offchain
- “manager DIDs Documents” are more complex and must be resolved by using blockchain and IPFS (see details below)


3) DID documents for individual end users

3a) Description & features

These DID Documents are simplified, designed for individual users who do not require a public profile maintenance. They contains a single signature key, encoded inside the DID itself, typically in Ethereum address format.

  • Simplicity: Contains a single public key used for signature, control and authentication.
  • Encoded self-contained key : The public key is directly inside available inside the user DID identifier, encoded in Ethereum address format.

This simple method is suitable for users requiring straightforward digital identity management without the complexities of a public profile. It allows easy and swift integration into systems utilizing public key standards for authentication.

Every user can freely create an infinite number of user DIDs: they are locally created inside the mobile application wallet, without online or on-chain traces by default.

3b) Resulting resolved user DID Document example:

"blockchainAccountId": "eip155:10200:0xAd6e394D8d3a1C1109AaD20ef6E8c4C97298BfE7"

4) DID Documents for Managers / Organizations

4a) Description & features

This type of DID Document caters to managers or organizations requiring a public profile and more complex management. These documents are managed directly through a smart contract on the blockchain, enabling dynamic management including updates and revocation.

  • Public Profile: Includes detailed information about the organization or manager, such as names, contacts, links to services, and potentially images or logos. It presents a reliable and verifiable digital identity to a community or customers.
  • Direct Management in Smart Contract: Facilitates the addition, updating, and revocation of attributes like authentication keys, assertion methods, and linked services. Modifications are recorded on the blockchain, ensuring complete traceability and transparency.

The public profile includes non-sensitive information such as name, sector, description, links to social media, a website, and a profile image. These details are structured in a JSON document and hosted in a decentralized manner on IPFS to ensure data security and persistence.

4b) Data Storage Process on IPFS

Two steps to ensure data decentralization and integrity:

  1. Image Upload: Profile image is uploaded on IPFS to obtain a Content IDentifier and a url like “https://myntfsid.mypinata.cloud/ipfs/Qmxxxxxx1”. The first part this url (“myntfsid.mypinata.cloud/ipfs”) is our default IPFS gateway (Pinata web services) but any other IPFS gateway or client can be used to retrieve the file through the IPFS Content IDentifier (e.g. “Qmxxxxxx1”).
  2. JSON Profile File Creation and upload : JSON file is created, containing the profile information and referencing the previously uploaded image. This JSON file is uploaded on IPFS, generating another IPFS url link (e.g. “https://myntfsid.mypinata.cloud/ipfs/Qmxxxxxx2”).

JSON Profile file content example:

"type": "Issuer Profile",
"name": "XYZ Company",
"sector": "Insurance",
"description": "Best-in-class solutions to take full care of travellers",
"website": "https://xyzinsurance.com/",
"twitter": "https://twitter.com/xyzinsurance",
"discord": "https://discord.com/invite/xyzinsurance",
"profileImage": "https://myntfsid.mypinata.cloud/ipfs/Qmxxxxxx1"

4c) Resulting resolved manager DID Document example:

"@context": [
"id": "did:mydid:zhabcdeYij8BNia179PZbMHvkvZreF7JdRjqRgdwSz3L",
"controller": "did:mydid:zhWGb57oYij8BNia179PZbMHvkvZreF7JdRjqRgdwSz3L",
"authentication": [
"id": "did:mydid:zhabcdeYij8BNia179PZbMHvkvZreF7JdRjqRgdwSz3L#AUTH_1",
"type": "EcdsaSecp256k1VerificationKey2019",
"controller": "did:mydid:zhabcdeYij8BNia179PZbMHvkvZreF7JdRjqRgdwSz3L",
"publicKeyMultibase": "zC9ByQ8aJs8vrNXyDhPHHNNMSHPcaSgNpjjsBYpMMjsTdS"
"assertionMethod": [
"id": "did:mydid:zhabcdeYij8BNia179PZbMHvkvZreF7JdRjqRgdwSz3L#ASSR_1",
"type": "EcdsaSecp256k1RecoveryMethod2020",
"controller": "did:mydid:zhabcdeYij8BNia179PZbMHvkvZreF7JdRjqRgdwSz3L",
"blockchainAccountId": "eip155:10200:0x6c99fEBf4dE77758F78C948F7166f07DbA4105a0"
"service": [
"id": "did:mydid:zhabcdeij8BNia179PZbMHvkvZreF7JdRjqRgdwSz3L#SERV_1",
"type": "Public Profile",
"serviceEndpoint": "https://myntfsid.mypinata.cloud/ipfs/Qmxxxxxx2"

See annexed diagram at the end of article for manager DID creation diagram

5) DID Resolver

A DID resolver is an essential tool in the myDid ecosystem that facilitates the retrieval and management of DID Documents. These documents contain crucial information such as public keys and service endpoints necessary for verifying digital signatures and interacting with the DID. The resolver translates a DID into a DID Document using a defined set of resolution rules and methods, providing a standardized way to access and verify decentralized identities.

For now, DIDs come in two types, each tailored to different use cases:

  • DID for Individual Users: Used for personal identity management, often involving a single public key for signature, control and authentication.
  • DID for Managers/Organizations: More complex, involving multiple keys and service endpoints managed via smart contract on the blockchain.

For manager/organization DIDs, the DID resolver plays a crucial role by retrieving information directly from the smart contract. This includes not only the current state but also the historical changes and modifications made to the DID Document, such as updates to public keys and changes in service endpoints. By accessing the smart contract, the resolver ensures that all updates are tracked and transparent, providing verifiers with a complete view of the document’s lifecycle.

Using the DID resolver, verifiers can easily obtain the necessary information to authenticate digital interactions, ensuring robust and reliable identity verification in the myDid ecosystem.

A public DID resolver for myDid method will be soon available on the DIF (Decentralized Identity Foundation) website.

Annex: Manager DID creation diagram

Manager DID creation diagram