This specification describes a new DID method for hosting DIDs on the Ethereum blockchain, also referred to as ETHO DID. This specification conforms to the requirements specified in the DIDs specification currently published by the W3C Credentials Community Group.
This specification assumes a fair degree of understanding of W3C DIDs specification.
The key words "MUST", "MUST NOT", "SHOULD", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119.
ETHO DID is a URI conforming to IETF RFC 3986 and SHOULD be generated by each entity itself.
ETHO DID is generated in conformity with W3C DIDs specification.
The ABNF grammar used to generate the ETHO DID identifier is as follows:
etho-did = "did:etho:" etho-specific-idstring
etho-specific-idstring = 40*40HEXDIG
did:etho: denotes that ETHO DIDs are decentralized identifiers conforming to W3C DIDs specification, and are registered on the Ethereum blockchain.
Below is an example of a ETHO DID:
did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121
ETHO DID can be automatically generated without registration for each Ethereum address.
When a ETHO DID is deactivated, all the related data including public keys, controllers, and other properties will be deleted and only a record of the ETHO DID identifier will remain on the Ethereum blockchain.
A deactivated ETHO DID can no longer be used and cannot be reactivated for use.
Each ETHO DID will have a corresponding ETHO DID Document, which is a set of data describing this ETHO DID.
Below is the basic structure of the ETHO DID Document:
{
"@context": ["https://www.w3.org/ns/did/v1"],
"id": "did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
"publicKey": [...],
"authentication": [...],
"controller": [...],
"service": [...],
"updated": "..."
}ETHO DID Documents MUST include a @context property.
The value of the @context property MUST be one or more URIs, where the value of the first URI MUST be https://www.w3.org/ns/did/v1. For more information, see W3C DIDs specification.
Below is an example in which the @context property has two values:
{
"@context": ["https://www.w3.org/ns/did/v1"]
}ETHO DID Documents MUST include an id property.
The value of the id property denotes the ETHO DID subject that the ETHO DID Document is about.
The value of id MUST be a valid ETHO DID. A ETHO DID MUST have exactly one DID subject.
{
"id": "did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121"
}A ETHO DID Document MAY include a publicKey property to specify a set of public keys linked to that ETHO DID.
Public and private key pairs can be used for the identity management, authorization, and verification of ETHO DIDs. A ETHO DID can be linked to multiple public and private key pairs and one pair of public and private keys can also be used to manage multiple ETHO DIDs.
Every public key object linked to the publicKey property MUST include the fields id, type, controller and specific public key properties, and MAY include other additional properties.
Each linked public key has its own identifier specified using the field id. The value of publicKey MUST NOT contain multiple entries with the same id.
Bound public keys can be revoked. Revoked public keys MUST NOT be reactivated, but can still possess the original id.
The value of the type field represents the corresponding public key type. ETHO DID Documents support EcdsaSecp256k1RecoveryMethod2020 and EcdsaSecp256k1VerificationKey2019.
The value of the controller field which identifies the controller of the corresponding private key MUST be a valid ETHO DID, implying that the public key is controlled by this ETHO DID.
The encoding formats that ETHO DID Documents support include publicKeyHex and ethAddress. Public keys of all types MUST be expressed in these two formats.
Below is a specific example of the publicKey property:
{
"publicKey": [
{
"id": "did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-1",
"type": "EcdsaSecp256k1VerificationKey2019",
"controller": "did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
"publicKeyHex": "0xfbf38de9fb40edcdab412094d24fa39a314f3d3f52f5860e2509c32522eda30161fe70dfc9f90434d64bd976ede4f112d4f2d8e34d28fe48281663219d2ddac6"
},
{
"id": "did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-1",
"type": "EcdsaSecp256k1RecoveryMethod2020",
"controller": "did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
"ethAddress": "0xf269E60fF7280e3E11b7EEd7B76b5C005105D121"
}
]
}ETHO DID Documents SHOULD include an authentication property to specify a set of verification methods.
A ETHO DID subject could add the authentication property in its corresponding ETHO DID Document to denote that the subject has authorized a set of verification methods for the purpose of authentication.
The associated value MUST be an ordered set of one or more verification methods. Each verification method in the authentication property MAY be embedded or referenced.
Below is an example which refers to authentication keys in the two way specified above:
{
...
"authentication": [
"did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-1",
{
"id": "did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-2",
"type": "EcdsaSecp256k1VerificationKey2019",
"controller": "did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
"publicKeyHex": "03a835599850544b4c0a222d594be5d59cf298f5a3fd90bff1c8caa064523745f3"
}
],
}In a ETHO DID Document, an OPTIONAL controller property is included to assign one or more delegates.
A ETHO DID can be delegated to and controlled by one or more distinct ETHO DIDs.
A ETHO DID delegate has the necessary authorization to insert a new verification method into the authentication property of the delegated ETHO DID.
It is worth noting that a ETHO DID Document can assign controller without defining the value of authentication.
The ETHO DID Document of the delegate SHOULD have a authentication property.
Below is a specific example representing that either did:etho:5Ee76017be7F983a520a778B413758A9DB49cBe9 or did:etho:9861eE37Ede3dCab070DF227155D86A7438d8Ed2 can act as a delegate of did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121:
{
...
"id": "did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
"controller": [
"did:etho:5Ee76017be7F983a520a778B413758A9DB49cBe9",
"did:etho:9861eE37Ede3dCab070DF227155D86A7438d8Ed2"
],
}ETHO DID Documents use an OPTIONAL service property to specify the service property.
ETHO DID allows entities to add services and specify the relevant information of a service that is related to the particular ETHO DID, including fields such as the type of service and service endpoint.
This part is derived directly from W3C DIDs specification.
Below is a specific example:
{
...
"service": [
{
"id": "did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121#some-service",
"type": "SomeServiceType",
"serviceEndpoint": "Some URL"
}
]
}ETHO DID support white list for authorizations in reading information.
{
...
"allowers": [ "did:etho:1726ad7021f98c715747d57d165a6831a522d87f" ],
}ETHO DID support proof signature based on https://www.w3.org/TR/vc-data-model/. At least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential or presentation to be a verifiable credential or verifiable presentation; that is, to be verifiable.
This specification identifies two classes of proof mechanisms: external proofs and embedded proofs. An external proof is one that wraps an expression of this data model, such as a JSON Web Token, which is elaborated on in Section 6.3.1 JSON Web Token. An embedded proof is a mechanism where the proof is included in the data, such as a Linked Data Signature, which is elaborated upon in Section 6.3.2 Data Integrity Proofs.
When embedding a proof, the proof property MUST be used.
proof One or more cryptographic proofs that can be used to detect tampering and verify the authorship of a credential or presentation. The specific method used for an embedded proof MUST be included using the type property.
Because the method used for a mathematical proof varies by representation language and the technology used, the set of name-value pairs that is expected as the value of the proof property will vary accordingly. For example, if digital signatures are used for the proof mechanism, the proof property is expected to have name-value pairs that include a signature, a reference to the signing entity, and a representation of the signing date. The example below uses RSA digital signatures.
{
...
"proof": [
[
"id": "did:nebuia",
"typeSignature": "did:nebuia",
"proofPurpose": "RsaSignature2018",
"verificationMethod": "assertionMethod",
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5XsITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUcX16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtjPAYuNzVBAh4vGHSrQyHUdBBPM"
]
]
}ETHO DID Documents do not include a created property as ETHO DID can be automatically generated for each Ethereum address.
ETHO DID Documents SHOULD include an updated property to specify a timestamp of the most recent change.
This part is derived directly from W3C DIDs specification.
Below is a specific example:
{
"updated": "2019-06-30T12:00:00Z"
}A simple example of a ETHO DID Document is as follows:
{
"@context": ["https://www.w3.org/ns/did/v1", "https://www.eth.org/did/v1"],
"id": "did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
"publicKey": [
{
"id": "did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-1",
"type": "EcdsaSecp256k1VerificationKey2019",
"controller": "did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
"publicKeyHex": "0xfbf38de9fb40edcdab412094d24fa39a314f3d3f52f5860e2509c32522eda30161fe70dfc9f90434d64bd976ede4f112d4f2d8e34d28fe48281663219d2ddac6"
}
],
"authentication": [
"did:etho:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-1"
]
}[W3C-DID]
Decentralized Identifiers (DIDs) v1.0. W3C. Jul 2020. Working Draft. URL: https://www.w3.org/TR/did-core/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. JANUARY 2005. Standards Track. URL: https://tools.ietf.org/html/rfc3986