Decentralized identifiers (DID)
Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity.
Last updated
Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity.
Last updated
DIDs are unique universally resolvable identifiers. A DID represents a subject, which can be a person, but also an organization, object, document, etc. There is no central register that registers all DIDs. Instead, there a DID has a method that indicates how it can be resolved.
are a W3C standard. LTO Network implements v1.0.
Resolving a DID results in a DID document. This document contains cryptographic material that allows the DID controller to prove control of the DID.
DID documents do not contain other (identifying) information, like a name, address, etc.
A decentralized identifier (DID) isn't the same as an account. Both correspond with a blockchain address. However, an account is based on a single public/private key pair. A DID can have multiple verification methods, managed through associations.
DID with the method "lto" can be resolved by the LTO Network identity node.
The method-specific string is an address on the public chain. In the case of derived DIDs, it's followed by a path.
The address is case-sensitive.
Any address on the LTO public chain can be represented by a DID. The DID document always contains a single verification method containing the public key of the account. This method is applicable for both authentication and assertion.
The subject field of the association transaction should not be set.
LTO Network supports 3 cryptographic algorithms: ed25519, secp256k1, and secp256r1.
ed25519
secp256k1
secp256r1
Association transactions support expiration. Set the expires field to add a verification method that's automatically revoked at a specific date.
The expiration date can be changed by issuing a new association with an updated expires field.
Different verification relationships enable the associated verification methods to be used for different purposes. It is up to a verifier to ascertain the validity of a verification attempt by checking that the verification method used is contained in the appropriate verification relationship.
By default, a verification method does not have any relationships. These can be specified in the data property of the association transaction, using the relationship as key and true as value.
Authentication like logging into a website
Issue Verifiable Credential
Encryption and secure communication
Update the DID document
Delegate authority to a subordinate
The key pair of the main account of the DID is known as the management key. This is the only key that can sign for any on-chain transaction. That means it's the only key that can be used to modify the DID document.
You should not add verification methods with capability relationships without using a smart account.
By default, the management key has all verification relationships. To change the relationships, issue an association with type 0x100, setting the data to include specific relationships.
It's recommended to use the management key only for on-chain transactions and remove the authentication, assertion and key agreement relationships.
In addition, it will revoke all verification methods, including the management key. This ensures that the DID document can't be used, including implementations that don't check the metadata.
It's not possible to only revoke the management key, without also revoking all other verification methods.
The recipient of the statement transaction should be omitted. Optionally, a reason can be specified as data entry.
Deactivating the DID account does not prevent the associated account to do transactions on the public chain or private layer.
Creating an association with type 0x108 will add a key that can be used to deactivate the DID. This key will be listed in the capabilityInvocation relationship (and not as a generic verification method).
The main reason to use this is to allow a trusted authorized party to deactivate a DID document in case the management key is lost.
An authorized party can deactivate a DID using a statement transaction with type 0x121. The recipient of that statement should be the address of the management key of the DID. Optionally a reason can be specified as data entry.
Adding a verification method through an association with type 0x100 and with the capability invocation relationship, will not allow that key to deactivate the account. You must use association type 0x108.
The first thing the malicious holder of a compromised management key would do is revoke all deactivation capabilities. This would be a serious issue if the management key is both compromised and lost. To counter this, the holder can set a revocation delay by adding a revokeDelay data entry to the association tx. The value should be in microseconds. E.g. 86400000 is a delay of 24 hours.
In this example, the verification relationships of the management key have been set to only capability invocation and capability delegation. A new verification method is added for authentication, assert method and key agreement. And deactivation capability is granted to one key.
Services must be JSON encoded. Any data entry with a key starting with did:service: will be decoded and added as data entry. If the service id is omitted, it will be generated based on the service key.
A data instruction with the following data entries
results in the following service property of the DID document
Using versionTime will return the DID document at the moment of the given time. If the DID document has changed since that time, the metadata will contain an updated and a nextUpdate property.
The DID will be marked as created at the moment when the public key is known on-chain. Requesting a DID with versionTime before the creation date will result in a not-found.
It's possible to explicitly specify verification methods for a DID document using . An association with the type 0x0100 specifies that the public key of the association recipient is a valid verification method for the association sender.
The public key of the recipient must be known. The allows the management account to register the public keys of all verification methods.
The verification method can be revoked using a transaction with association type 0x100 and an empty subject.
To change the relationships of an existing verification method, issue a new transaction with updated data.
For , the key relationship verification method must have type X25519KeyAgreementKey2019. The X25519 public key is generated from the ED25519 public key used to sign a transaction.
For secp256k1 and secp256r1 accounts, you can use EcdsaSecp256k1VerificationKey2019 for encryption. We support . However, this may not be understood by verifiers.
Giving a verification method capability relationships does not allow it to do on-chain transactions. In case you want to allow other keys to modify the DID document and make changes in a , you must use a .
If the management key is compromised, the DID should no longer be used. Issuing a statement with type 0x120, will mark the DID as .
Services are used in DID documents to express ways of communicating with the DID subject or associated entities. A can be any type of service the DID subject wants to advertise, including decentralized identity management services for further discovery, authentication, authorization, or interaction.
Defining services is done through . These transactions allow setting metadata of an account. This data is used by the indexer service when resolving a DID.
LTO Did as versioned and support the .
