Decentralized Identifiers (DIDs)

A DID is “a new type of identifier” suitable for identifying a person, organization, thing, data model, abstract entity, etc. under a Self-Sovereign Identity Scheme. A DID is a URI that associates a DID subject with a DID document allowing trustable interactions associated with that subject, as it contains information about the authentication methods to prove ownership of that DID, endpoints, and other attributes. It is ideal to be used in Verifiable Credentials

DID: LAC Method

LACChain has developed and maintains the LACChain DID method, which is a fully on-chain DID method based on the ERC-1056 standard. The “lac” DID method allows to maintain a fully on-chain management of DIDs, using smart contracts to store the DIDs and the information associated to them. Some of the main features of the “lac” DID method are:

  • Compliant with latest DID model v1.0 specs by W3C (last update 31/01/2021)
  • Listed by DIF
  • Fully on-chain DID method
  • Based on the ERC-1056, originally implemented in “ethr” method by uPort
  • Support for multiple controllers
  • Automatic Key Rotation
  • On-chain Key Recovery
  • Based on the ERC-1056, originally implemented in “ethr” method by uPort
  • Public Keys -> Verification Methods
  • Introduce a new concept: Verification Relationships
  • Added blockchainAccountId as a special type of Public Key
  • Definition of controller for each Verification Method
  • Included new relationship: Invocation Capability

There is also an implementation the LACChain DID Method in NodeJS. It provides the necessary methods and functions to interact with a DID and resolve a DID Document without the need to directly call the smart contracts.


LACChain DID Registry

The LACChain DID Registry is an open and decentralized on-chain repository for LACChain DIDs, which is made up of a set of smart contracts that allow any owner of an Ethereum account to manage the attributes of their DID document. These contracts allows to perform key rotation and specify different keys and services that are used on its behalf for both: on-chain and off-chain.

Depending on the functionalities that you want to use, there are two smart contracts to create a DID Registry.

  1. DIDRegistry: It is the basic DID Registry that allows multiple controllers and automatic key rotation.
  2. DIDRegistryRecoverable: It is the advanced DID Registry that allows, in addition to the functions of a basic DID, key recovery.

There is no need to deploy a new set of Smart Contracts for a DID Registry, currently the official DID Registries are deployed in the following addresses:





Main Net
DIDRegistryRecoverableMain Net 

For technical documentation, please visit the LACChain Github repo

LACChain ID Resolver

The LACChain ID Resolver allows to resolve Decentralized Identifiers (DIDs) across many different DID methods. It uses a REST API to get DID Document from each DID method. This resolver also includes the LACChain DID method to resolve did:lac identifiers.

Currently, these are the following supported DID methods:


For more information, please visit the LACChain Github repo


LACChain ID Registry

Each type of Verifiable Credential (VC) follows the basic scheme proposed by the W3C that defines the fields and data types. In this way, it is possible to extend the proposed standard through schemes that define the new fields within a specific type of credential. LACChain has created a LACChain Credential Registry where any entity can register its type of credential along with the associated schema for later publication within the registry that is located here

For more information, please visit the LACChain Github repo

DID-Based Authentication

In order to access a digital service, the LACChain Alliance encourages using an authentication method based on OpenID Connect proposed by KayTrust called DIDConnect. This mechanism makes use of DIDs to perform the authentication. DID Connect introduces the usage of DID and Verifiable Credentials (VCs), which is a decentralized mechanism that allows the client to verify the identity of the user. The proposed authentication flows, together with the Diagrams, are described in the Authentication to Service Repository.


Copyright 2024 © All rights Reserved. Designed by LACNet