> For the complete documentation index, see [llms.txt](https://docs.blerify.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.blerify.com/trust-registry/did-method/did-method-did-lac1.md).

# DID Method did:lac1

The verifiability of digital credentials depends on the cryptographic signatures of **issuers** and **subjects**. Historically, **X.509 certificates** have been used for authentication, primarily in server and application security. However, these certificates lack the **scalability and flexibility** needed for digital credentials. A more scalable approach requires **decentralized identifiers (DIDs)**, which allow entities to manage multiple cryptographic key pairs while supporting **key rotation, revocation, and multiple endpoints**. This makes DIDs an ideal solution for modern digital credential ecosystems.

In compliance with the [W3C DID Core specifications](https://www.w3.org/TR/did-core/), we have proposed a new **DID method did:lac1, designed for scalability, security, and interoperability.** It builds upon the [ethr DID method ](https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md)and the [LAC DID method](https://github.com/lacchain/lacchain-did-registry/blob/master/DID_SPEC.md), introducing key enhancements for greater precision and transparency. Our method enables the **encoding of the exact resolution path within the DID itself**, ensuring seamless access to the underlying **DID registry**. Key improvements over **did:ethr, did:lac**, and other did methods include:

* **Backwards Revocation Time Support:** This feature allows a **DID controller** to revoke a key not only from the moment of revocation but also retroactively, specifying a time in the past (t₁) after which the key is considered revoked. This is particularly useful when revoking a key without invalidating all cryptographically verifiable statements signed with it—only those issued after t₁ are affected. Key benefits are:
  * **Transparency**: Since revocations are recorded on the blockchain, all key changes are fully **traceable and auditable**.
  * **Key Compromise Scenarios**: If a key associated with a DID is compromised, the controller has two options:
    1. **Full revocation**, which invalidates **all** statements signed with that key.
    2. **Selective revocation**, where the controller specifies a past date when the key became invalid (e.g., if a vulnerability was identified X days ago, only statements issued **after X days ago** are revoked, while earlier statements remain valid). To ensure a verifier can trust that a cryptographically verifiable statement was made **before X days ago**, the statement should include a **proof of time**, such as a timestamp anchored to a blockchain. This allows verifiers to confirm the document’s existence at a specific point in time.
* **Direct DID Registry Resolution:** Our method encodes the exact path to the **DID registry** within the DID itself, eliminating the need for additional lookups and ensuring seamless resolution.
* **Backward Compatibility & Upgradability**: Enhancements to the DID method are designed to be **fully backward compatible**, ensuring continued support for existing implementations while allowing for future improvements.
* **DID Migration Support**: Through the **also Known** as attribute, our method enables **smooth migration** to a different DID, ensuring identity continuity without disrupting existing verifiable interactions.

By integrating these innovations, our **DID method** enhances **trust, transparency, and flexibility**, making it a powerful solution for verifiable credentials and decentralized identity management

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.blerify.com/trust-registry/did-method/did-method-did-lac1.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.