Managing DIDs
DIDs, or Decentralized Identifiers, are a type of identifier used to represent individuals, organizations, and things in a decentralized manner. In other words, a DID is a unique digital identity that is not tied to any central authority or entity. Instead, it is managed and controlled by the owner of the identity.
DIDs are built on top of blockchain technology, which provides a decentralized and tamper-resistant platform for identity management. This means that DIDs can be used to establish trust and verify identities in a secure and transparent way.
The best standard for DIDs is the W3C DID specification, which provides a standardized way to create, manage, and verify DIDs. The specification defines the structure and format of DIDs, as well as the methods for resolving and verifying them.
The syntax for a DID is "did:METHOD:SPECIFIC-ID". The METHOD specifies the decentralized method used to generate the DID, and the SPECIFIC-ID is the unique identifier generated using the chosen method. For example, the following is an example of a DID using the "example" method:
did:example:123456789abcdefThere are various methods for generating DIDs, each with their own unique way of generating and managing DIDs. Some popular methods include:
- "ethr" for Ethereum-based DIDs
- "web" for URLs
- "key" for cryptographic keys
- "sov" for Hyperledger-based DIDs
In the context of the Coreto DRS, DIDs are used as the unique identifiers that all historical reputation data is linked to. As opposed to wallet addresses, which can differ based on the blockchain that the wallet is based on, the DID standard provides a way to offer consistency and flexibility in tracking reputation regardless of what blockchain the user or platform is based on.
This is why the Coreto DRT requires an
account_did for every data record, that is used to reliably identify users and track reputation data regardless of the blockchain (or no-chain) that the platform from which the data originates is built on.Using this approach allows each platform to integrate with their prefered DID provider, or even build their own DID service. It does however allow for possible fragmentation of the reputation data, creating ecosystem silos around identity providers.
Even if this may not be a problem in itself, the aim of the Coreto DRS is to allow users to track their reputation across multiple platforms and industries in a consistent way, and to have an aggregated overview of their reputation from all such places on the internet.
This is why we have started working on our own DID solution, with the scope of having a cross chain, flexible and consisten way of gathering online identities from all over the internet in one place - privately, securely and with full ownership and control of their identity.
At this stage, the Coreto DID is still a long way from being completed. But in order to get things started, we have built a very simple DID registry in the form of a smart contract on the NEAR Protocol blockchain.
The only goal for now is to have a quick and easy way for platforms to start using the Coreto DRS without having to think about identity solutions - for now.
As mentioned, the Coreto DID is in the VERY EARLY stages of development. It only acts as a mapping between NEAR wallet accounts and W3C DID identifiers for now.
It does not store any profile information, and doesn't provide authentication methods or other more advanced features, but we are planning to develop it into a full fledged cross-chain Decentralized Identity solution in the future.
Another limitation for now is that it only works with NEAR wallet accounts, but this will also change in future iterations.
As is the case with the Coreto DRT for managing historical reputation data, the Coreto DID lives as a smart contract on the NEAR Protocol mainnet, and is complemented by a REST API.
The Coreto DRT smart contract is available on the NEAR mainnet and is used to record, store and access historical reputation data.
Coreto DRT smart contract address: did1-service.coretois.near
The Coreto DID API is accessible using standard HTTP calls and acts as a web2 compatibility layer on top of the Coreto DRT smart contract.
The API is built using the HAPI Framework. The API code is available as Open Source, and can also be self-hosted.
In order to store new DID mappings on the Coreto DID smart contract, you will need a dedicated NEAR wallet.
The platform's NEAR wallet acts as an access key for writing new data to the system. Access is granted by having the wallet approved as a data source, and will consume NEAR tokens as GAS (required by the NEAR Protocol) in order to record or update data inside the smart contract's database.
Both the API and the direct smart contract options provide the same end results, and require the use of a dedicated NEAR wallet in order to write new data to the system.
New data records are sent as blockchain transactions to the smart contract, calling the respective functions with the data payload sent as arguments.
The smart contract provides four methods for managing DIDs for the moment:
put_did- Add a new DID/NEAR account mapping into the DID registryhas_did- Check if a NEAR account has an associated DIDget_did- Get the associated DID for a NEAR wallet accounttransfer_did- Transfer the DID to another wallet account
The Coreto DID API has the same available funtions, also providing an extra
create_did method for generating W3C compatible DID identifiers (DIDs) using the cryptographic key method (ex: did:key:123456789abcdef).The proces of managing Coreto DIDs is very simple and straight forward, and you can consult the API Documentation for further reference.
Last modified 2mo ago