6
6
7
7
## Preface
8
8
9
- The ethr DID method specification conforms to the requirements specified in
10
- the [ DID specification] ( https://w3c-ccg.github.io/did-core/ ) , currently published by the
11
- W3C Credentials Community Group. For more information about DIDs and DID method specifications,
9
+ The ethr DID method specification conforms to the requirements specified in
10
+ the [ DID specification] ( https://w3c-ccg.github.io/did-core/ ) , currently published by the
11
+ W3C Credentials Community Group. For more information about DIDs and DID method specifications,
12
12
please see the [ DID Primer] ( https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/did-primer.md )
13
13
14
14
## Abstract
@@ -37,18 +37,18 @@ ARTIS sigma1 | `artis_s1` | 0x03c301 | `0xdca7ef03e98e0dc2b855be647c39abe
37
37
Since each Ethereum transaction must be funded, there is a growing trend of on-chain transactions that are
38
38
authenticated via an externally created signature and not by the actual transaction originator. This allows for
39
39
3rd party funding services, or for receivers to pay without any fundamental changes to the underlying
40
- Ethereum architecture. These kinds of transactions have to be signed by an actual key pair and thus cannot be used
41
- to represent smart contract based Ethereum accounts. ERC1056 proposes a way of a smart contract or regular key pair
40
+ Ethereum architecture. These kinds of transactions have to be signed by an actual key pair and thus cannot be used
41
+ to represent smart contract based Ethereum accounts. ERC1056 proposes a way of a smart contract or regular key pair
42
42
delegating signing for various purposes to externally managed key pairs. This allows a smart contract to be
43
43
represented, both on-chain as well as off-chain or in payment channels through temporary or permanent delegates.
44
44
45
45
For a reference implementation of this DID method specification see [ 3] .
46
46
47
- ### Identity Ownership
48
- By default, each identity is controlled by itself. Each identity can only be controlled by a single
49
- address at any given time. By default, this is the address of the identity itself. The owner can
47
+ ### Identity Controller
48
+ By default, each identity is controlled by itself. Each identity can only be controlled by a single
49
+ address at any given time. By default, this is the address of the identity itself. The controller can
50
50
replace themselves with any other Ethereum address, including contracts to allow more advanced
51
- models such as multi-signature ownership .
51
+ models such as multi-signature controllership .
52
52
53
53
## Target System
54
54
@@ -64,15 +64,15 @@ The target system is the Ethereum network where the ERC1056 is deployed. This co
64
64
65
65
- No transaction fee on identity creation
66
66
- Uses Ethereum's built-in account abstraction
67
- - Multi-sig wallet for identity owner
67
+ - Multi-sig wallet for identity controller
68
68
- Decoupling claims data from the underlying identity
69
69
- Decoupling Ethereum interaction from the underlying identity
70
70
- Flexibility to use key management
71
71
- Flexibility to allow third-party funding service to pay the gas fee if needed
72
- - Supports any EVM-compliant blockchain
72
+ - Supports any EVM-compliant blockchain
73
73
74
74
## JSON-LD Context Definition
75
- Note, this DID method specification uses the ` Secp256k1VerificationKey2018 ` ,
75
+ Note, this DID method specification uses the ` Secp256k1VerificationKey2018 ` ,
76
76
` Secp256k1SignatureAuthentication2018 ` types and an ` ethereumAddress ` instead of
77
77
a ` publicKeyHex ` .
78
78
@@ -91,7 +91,7 @@ The definition of the ethr DID JSON-LD context is:
91
91
92
92
The namestring that shall identify this DID method is: ` ethr `
93
93
94
- A DID that uses this method MUST begin with the following prefix: ` did:ethr ` . Per the DID specification, this string
94
+ A DID that uses this method MUST begin with the following prefix: ` did:ethr ` . Per the DID specification, this string
95
95
MUST be in lowercase. The remainder of the DID, after the prefix, is specified below.
96
96
97
97
## Method Specific Identifier
@@ -137,36 +137,36 @@ transactions to the ERC1056 registry looks like this:
137
137
'@context ': 'https://w3id.org/did/v1 ',
138
138
id: 'did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a',
139
139
publicKey: [ {
140
- id: 'did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a#owner ',
140
+ id: 'did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a#controller ',
141
141
type: 'Secp256k1VerificationKey2018',
142
- owner : 'did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a',
142
+ controller : 'did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a',
143
143
ethereumAddress: '0xb9c5714089478a327f09197987f16f9e5d936e8a'}] ,
144
144
authentication: [ {
145
145
type: 'Secp256k1SignatureAuthentication2018',
146
- publicKey: 'did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a#owner '}]
146
+ publicKey: 'did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a#controller '}]
147
147
}
148
148
149
149
### Read (Resolve)
150
150
151
151
The DID document is built by using read only functions and contract events on the ERC1056 registry.
152
152
153
- Any value from the registry that returns an Ethereum address will be added to the ` publicKey ` array of the DID
153
+ Any value from the registry that returns an Ethereum address will be added to the ` publicKey ` array of the DID
154
154
document with type ` Secp256k1VerificationKey2018 ` and an ` ethereumAddress ` attribute containing the address.
155
155
156
- #### Owner Address
156
+ #### Controller Address
157
157
158
- Each identity always has an owner address. By default it is the same as the identity address, but check the
158
+ Each identity always has a controller address. By default it is the same as the identity address, but check the
159
159
read only contract function ` identityOwner(address identity) ` on the deployed version of the ERC1056 contract.
160
160
161
- The identity owner will always have a ` publicKey ` with the id set as the DID with the fragment ` #owner ` appended.
161
+ The identity controller will always have a ` publicKey ` with the id set as the DID with the fragment ` #controller ` appended.
162
162
163
163
An entry is also added to the ` authentication ` array of the DID document with type ` Secp256k1SignatureAuthentication2018 ` .
164
164
165
165
#### Enumerating Contract Events to build the DID Document
166
166
167
167
The ERC1056 contract publishes three types of events for each identity.
168
168
169
- - ` DIDOwnerChanged `
169
+ - ` DIDOwnerChanged ` (indicating a change of controller)
170
170
- ` DIDDelegateChanged `
171
171
- ` DIDAttributeChanged `
172
172
@@ -199,22 +199,22 @@ A `DIDDelegateChanged` event is published that is used to build a DID document.
199
199
uint validTo,
200
200
uint previousChange
201
201
);
202
-
202
+
203
203
204
204
The only 2 ` delegateTypes ` that are currently published in the DID document are:
205
205
206
206
- ` veriKey ` which adds a ` Secp256k1VerificationKey2018 ` to the ` publicKey ` section of the DID document.
207
207
- ` sigAuth ` which adds a ` Secp256k1SignatureAuthentication2018 ` to the ` publicKey ` section of document. An entry
208
208
is also added to the ` authentication ` section of the DID document.
209
209
210
- Note, the ` delegateType ` is a ` bytes32 ` type for Ethereum gas efficiency reasons and not a ` string ` . This
210
+ Note, the ` delegateType ` is a ` bytes32 ` type for Ethereum gas efficiency reasons and not a ` string ` . This
211
211
restricts us to 32 bytes, which is why we use the short hand versions above.
212
212
213
213
Only events with a ` validTo ` in seconds greater or equal to the current time should be included in the DID document.
214
214
215
215
#### Non-Ethereum Attributes
216
216
217
- Non-Ethereum keys, service endpoints etc. can be added using attributes. Attributes only exist on the
217
+ Non-Ethereum keys, service endpoints etc. can be added using attributes. Attributes only exist on the
218
218
blockchain as contract events of type ` DIDAttributeChanged ` and can thus not be queried from within solidity code.
219
219
220
220
event DIDAttributeChanged(
@@ -225,10 +225,10 @@ blockchain as contract events of type `DIDAttributeChanged` and can thus not be
225
225
uint previousChange
226
226
);
227
227
228
- Note, the name is a ` bytes32 ` type for Ethereum gas efficiency reasons and not a ` string ` . This restricts us to
228
+ Note, the name is a ` bytes32 ` type for Ethereum gas efficiency reasons and not a ` string ` . This restricts us to
229
229
32 bytes, which is why we use the short hand attribute versions below.
230
230
231
- While any attribute can be stored, for the DID document we currently support adding to each of these sections of
231
+ While any attribute can be stored, for the DID document we currently support adding to each of these sections of
232
232
the DID document:
233
233
234
234
- Public Keys
@@ -255,7 +255,7 @@ generates a public key entry like the following:
255
255
256
256
##### Base64 encoded Ed25519 Verification Key
257
257
258
- A ` DIDAttributeChanged ` event for the identity ` 0xf3beac30c498d9e26865f34fcaa57dbb935b0d74 ` with the name
258
+ A ` DIDAttributeChanged ` event for the identity ` 0xf3beac30c498d9e26865f34fcaa57dbb935b0d74 ` with the name
259
259
` did/pub/Ed25519/veriKey/base64 ` and the value of ` 0xb97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71 `
260
260
generates a public key entry like this:
261
261
@@ -272,8 +272,8 @@ The name of the attribute should follow this format:
272
272
273
273
` did/svc/[ServiceName] `
274
274
275
- A ` DIDAttributeChanged ` event for the identity ` 0xf3beac30c498d9e26865f34fcaa57dbb935b0d74 ` with the name
276
- ` did/svc/HubService ` and value of the URL ` https://hubs.uport.me ` hex encoded as
275
+ A ` DIDAttributeChanged ` event for the identity ` 0xf3beac30c498d9e26865f34fcaa57dbb935b0d74 ` with the name
276
+ ` did/svc/HubService ` and value of the URL ` https://hubs.uport.me ` hex encoded as
277
277
` 0x68747470733a2f2f687562732e75706f72742e6d65 ` generates a service endpoint entry like the following:
278
278
279
279
{
@@ -297,22 +297,22 @@ Two cases need to be distinguished:
297
297
- In case no changes were written to ERC1056, nothing needs to be done, and the private key which belongs to the
298
298
Ethereum address needs to be deleted from the storage medium used to protect the keys, e.g., mobile device.
299
299
- In case ERC1056 was utilized, the owner of the smart contract needs to be set to ` 0x0 ` . Although, ` 0x0 ` is a valid
300
- Ethereum address, this will indicate the identity has no owner which is a common approach for invalidation,
300
+ Ethereum address, this will indicate the identity has no owner which is a common approach for invalidation,
301
301
e.g., tokens. Other elements of the DID Document may be revoked explicitly by invoking the relevant smart contract
302
302
functions as defined by the ERC1056 standard. This includes the delegates and additional attributes. Please find a
303
303
detailed description in the [ ERC1056 documentation] ( https://github.com/ethereum/EIPs/issues/1056 ) . All these functions
304
304
will trigger the respective Ethereum events which are used to build the DID Document for a given identity as
305
- described in [ Enumerating Contract Events to build the DID Document] ( #Enumerating-Contract-Events-to-build-the-DID-Document ) .
305
+ described in [ Enumerating Contract Events to build the DID Document] ( #Enumerating-Contract-Events-to-build-the-DID-Document ) .
306
306
307
307
## Reference Implementations
308
308
309
309
The code at [ https://github.com/decentralized-identity/ethr-did-resolver ] ( < > ) is intended to present a reference implementation
310
- of this DID method.
310
+ of this DID method.
311
311
312
312
## References
313
313
314
314
** [ 1] ** < https://w3c-ccg.github.io/did-core/ >
315
315
316
- ** [ 2] ** < https://github.com/ethereum/EIPs/issues/1056 >
316
+ ** [ 2] ** < https://github.com/ethereum/EIPs/issues/1056 >
317
317
318
318
** [ 3] ** < https://github.com/decentralized-identity/ethr-did-resolver >
0 commit comments