This specification describes a new DID method for hosting DIDs on the Celo blockchain, also referred to as Celo 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.
Celo DID is a URI conforming to IETF RFC 3986 and SHOULD be generated by each entity itself.
Celo DID is generated in conformity with W3C DIDs specification.
The ABNF grammar used to generate the Celo DID identifier is as follows:
celo-did = "did:celo:" celo-specific-idstring
celo-specific-idstring = 40*40HEXDIG
did:celo: denotes that Celo DIDs are decentralized identifiers conforming to W3C DIDs specification, and are registered on the Celo blockchain.
Below is an example of a Celo DID:
did:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121
Celo DID can be automatically generated without registration for each Celo address.
When a Celo DID is deactivated, all the related data including public keys, controllers, and other properties will be deleted and only a record of the Celo DID identifier will remain on the Celo blockchain.
A deactivated Celo DID can no longer be used and cannot be reactivated for use.
Each Celo DID will have a corresponding Celo DID Document, which is a set of data describing this Celo DID.
Below is the basic structure of the Celo DID Document:
{
"@context": ["https://www.w3.org/ns/did/v1"],
"id": "did:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
"publicKey": [...],
"authentication": [...],
"controller": [...],
"service": [...],
"updated": "..."
}Celo 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"]
}Celo DID Documents MUST include an id property.
The value of the id property denotes the Celo DID subject that the Celo DID Document is about.
The value of id MUST be a valid Celo DID. A Celo DID MUST have exactly one DID subject.
{
"id": "did:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121"
}A Celo DID Document MAY include a publicKey property to specify a set of public keys linked to that Celo DID.
Public and private key pairs can be used for the identity management, authorization, and verification of Celo DIDs. A Celo 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 Celo 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. Celo 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 Celo DID, implying that the public key is controlled by this Celo DID.
The encoding formats that Celo 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:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-1",
"type": "EcdsaSecp256k1VerificationKey2019",
"controller": "did:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
"publicKeyHex": "0xfbf38de9fb40edcdab412094d24fa39a314f3d3f52f5860e2509c32522eda30161fe70dfc9f90434d64bd976ede4f112d4f2d8e34d28fe48281663219d2ddac6"
},
{
"id": "did:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-1",
"type": "EcdsaSecp256k1RecoveryMethod2020",
"controller": "did:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
"ethAddress": "0xf269E60fF7280e3E11b7EEd7B76b5C005105D121"
}
]
}Celo DID Documents SHOULD include an authentication property to specify a set of verification methods.
A Celo DID subject could add the authentication property in its corresponding Celo 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:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-1",
{
"id": "did:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-2",
"type": "EcdsaSecp256k1VerificationKey2019",
"controller": "did:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
"publicKeyHex": "03a835599850544b4c0a222d594be5d59cf298f5a3fd90bff1c8caa064523745f3"
}
],
}In a Celo DID Document, an OPTIONAL controller property is included to assign one or more delegates.
A Celo DID can be delegated to and controlled by one or more distinct Celo DIDs.
A Celo DID delegate has the necessary authorization to insert a new verification method into the authentication property of the delegated Celo DID.
It is worth noting that a Celo DID Document can assign controller without defining the value of authentication.
The Celo DID Document of the delegate SHOULD have a authentication property.
Below is a specific example representing that either did:celo:5Ee76017be7F983a520a778B413758A9DB49cBe9 or did:celo:9861eE37Ede3dCab070DF227155D86A7438d8Ed2 can act as a delegate of did:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121:
{
...
"id": "did:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
"controller": [
"did:celo:5Ee76017be7F983a520a778B413758A9DB49cBe9",
"did:celo:9861eE37Ede3dCab070DF227155D86A7438d8Ed2"
],
}Celo DID Documents use an OPTIONAL service property to specify the service property.
Celo DID allows entities to add services and specify the relevant information of a service that is related to the particular Celo 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:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121#some-service",
"type": "SomeServiceType",
"serviceEndpoint": "Some URL"
}
]
}Celo DID Documents do not include a created property as Celo DID can be automatically generated for each Celo address.
Celo 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 Celo DID Document is as follows:
{
"@context": ["https://www.w3.org/ns/did/v1", "https://www.eth.org/did/v1"],
"id": "did:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
"publicKey": [
{
"id": "did:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-1",
"type": "EcdsaSecp256k1VerificationKey2019",
"controller": "did:celo:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
"publicKeyHex": "0xfbf38de9fb40edcdab412094d24fa39a314f3d3f52f5860e2509c32522eda30161fe70dfc9f90434d64bd976ede4f112d4f2d8e34d28fe48281663219d2ddac6"
}
],
"authentication": [
"did:celo: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