Skip to content

Commit 60dd7db

Browse files
ghoshbishakhghoshbishakh
committed
Update Network DID update policy in identity rfc
Signed-off-by: Bishakh Ghosh <[email protected]>
1 parent e673610 commit 60dd7db

File tree

1 file changed

+58
-10
lines changed

1 file changed

+58
-10
lines changed

‎rfcs/models/identity/identity-update-policy.md‎

Lines changed: 58 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@
1313

1414
The memberships in a blockchain network are not guaranteed to be static. Often existing participant members of a network leave while new participants join. As a result, the `verificationMethod` and `networkParticipants` of the *Network DID* must also be updated to capture the updated network structure.
1515

16-
Based on the different governance policies of different networks, they might want to enforce different policies that dictate which combination of exisiting parcitipants of the network are allowed to introduce a new member or expel existing members. These policicies can be encoded into the `updatePolicy` property of the *BlockchainNetworkMultiSig* `verificationMethod` in the *Network DID*.
16+
Based on the different governance policies of different networks, they might want to enforce different policies that dictate which combination of existing participants of the network are allowed to introduce a new member or expel existing members (or acknowledge members who left the network). These policies can be encoded into the `updatePolicy` property of the *BlockchainNetworkMultiSig* `verificationMethod` in the *Network DID*.
1717

1818
`updatePolicy` defines a combination of participant units that can sign and authorize a Network DID updation request. This `updatePolicy` has the condition format as specified in [`verifiablecondition2021`](https://w3c.github.io/did-spec-registries/#verifiablecondition2021) verification method. It can be used to combine different verification methods together to create complex conditional expressions such as logical operations, thresholds, weighted thresholds, relationships and a delegation to external verification methods.
1919

@@ -47,23 +47,71 @@ There can be two scenarios when an existing participant unit of a network leaves
4747

4848
A. The *Network DID* update request is attested by the participant who is leaving the network, that is the participant whose DID is being excluded from the `networkParticipants` property. This indicates voluntary exit from the network.
4949

50-
B. If condition A is not satisfied, and there exists an `updatePolicy` property of the *BlockchainNetworkMultiSig* `verificationMethod` in the *Network DID*, then the DID update request must be attested satisfying the `updatePolicy`.
50+
B. If condition A is not satisfied, then the DID update request must be attested satisfying the `updatePolicy` property of the *BlockchainNetworkMultiSig* `verificationMethod` in the *Network DID*. The update request may also contain a new `updatePolicy` which does not depend on the member that is being removed from the `networkParticipants`.
5151

52-
C. If condition A is not satisfied and there is no `updatePolicy` property of the *BlockchainNetworkMultiSig* `verificationMethod` in the *Network DID*, then the DID update request must be attested by strictly greater than half (`> N/3`) of the existing participants in the network indicated by `networkParticipants` property of the existing *Network DID* document.
52+
<!--
53+
C. If condition A is not satisfied and there is no `updatePolicy` property of the *BlockchainNetworkMultiSig* `verificationMethod` in the *Network DID*, then the DID update request must be attested by strictly greater than half (`> N/2`) of the existing participants in the network indicated by `networkParticipants` property of the existing *Network DID* document.
54+
-->
5355

54-
### Participants joining the network
55-
56-
For new network participants joining the network, the DID update request must be authenticated based on the following conditions:
5756

58-
A. If there is an `updatePolicy` property of the *BlockchainNetworkMultiSig* `verificationMethod` in the *Network DID*, then the DID update request must be attested satisfying the `updatePolicy`, and it must also be attested by the participant which is being added to the `networkParticipants`.
57+
### Participants joining the network
5958

60-
B. If there is no `updatePolicy` property of the *BlockchainNetworkMultiSig* `verificationMethod` in the *Network DID*, then the DID update request must be attested by strictly greater than half (`> N/3`) of the existing participants in the network indicated by `networkParticipants` property of the existing *Network DID* document. The request must also be attested by the participant which is being added to the `networkParticipants` property.
59+
For new network participants joining the network, the DID update request must be authenticated based on `updatePolicy` property of the *BlockchainNetworkMultiSig* `verificationMethod` in the *Network DID*. The DID update request must also be attested by the participant which is being added to the `networkParticipants`.
60+
<!--
61+
B. If there is no `updatePolicy` property of the *BlockchainNetworkMultiSig* `verificationMethod` in the *Network DID*, then the DID update request must be attested by strictly greater than half (`> N/2`) of the existing participants in the network indicated by `networkParticipants` property of the existing *Network DID* document. The request must also be attested by the participant which is being added to the `networkParticipants` property.
62+
-->
6163

6264
### Other updates to the Network DID
6365

64-
For *Network DID* update requests, where the `networkParticipants` property is not altered, indicating that the participant list is unchanged, the requests are authenticated based on attestations satisfying `updatePolicy` property of the *BlockchainNetworkMultiSig* `verificationMethod`. If no `updatePolicy` is specified in the *Network DID*, then the update request has to be attested by strictly greater than half (`> N/3`) of the existing participants in the network indicated by `networkParticipants` property of the existing *Network DID* document.
66+
For *Network DID* update requests, where the `networkParticipants` property is not altered, indicating that the participant list is unchanged, the requests are authenticated based on attestations satisfying `updatePolicy` property of the *BlockchainNetworkMultiSig* `verificationMethod`.
67+
68+
<!-- If no `updatePolicy` is specified in the *Network DID*, then the update request has to be attested by strictly greater than half (`> N/2`) of the existing participants in the network indicated by `networkParticipants` property of the existing *Network DID* document. -->
6569

6670

6771
# Choice of `updatePolicy`
6872

69-
The `updatePolicy` of a network is constructed by the network itself as a combination of different participants that need to attest any request to change the *Network DID* in future. Situations might arrive due to a poor choice of `updatePolicy` which cannot be satisfied by network the participants, where the *Network DID* can no longer be controlled by the network. In those cases the members of the network have to form a separate *Network DID* (a new network in the identity plane), and advertise the new DID as the new network address for the same network.
73+
The `updatePolicy` of a network is constructed through a consensus of different participants that need to attest any request to change the *Network DID* in future. The initial policy created for a Network DID creation requires unanimity, while subsequent policy updates are governed by existing policy. Situations might arrive due to a poor choice of `updatePolicy` which cannot be satisfied by network the participants, where the *Network DID* can no longer be controlled by the network. In those cases the members of the network have to form a separate *Network DID* (a new network in the identity plane), and advertise the new DID as the new network address for the same network.
74+
75+
During the creation of a *Network DID*, if no `updatePolicy` is set in the Network DID Document, then a default `updatePolicy` may be set by the IIN as a threshold condition requiring the attestation of `> N/2` network participants.
76+
77+
Example:
78+
79+
```json
80+
{
81+
"id": "did:<iin_name>:<network_name>#updatepolicy",
82+
"controller": "did:<iin_name>:<network_name>",
83+
"type": "VerifiableCondition2021",
84+
"threshold": 4,
85+
"conditionThreshold": [
86+
"did:<iin_name>:<network_participant_1>#key1",
87+
"did:<iin_name>:<network_participant_2>#key3",
88+
"did:<iin_name>:<network_participant_3>#key2",
89+
"did:<iin_name>:<network_participant_4>#key1",
90+
"did:<iin_name>:<network_participant_5>#key1",
91+
"did:<iin_name>:<network_participant_6>#key1",
92+
"did:<iin_name>:<network_participant_7>#key1"
93+
]
94+
}
95+
```
96+
97+
If the network members explicitly want to create a "static" network where the network members are not supposed to be changed, then the threshold is set to a value more than the number of participants in the network.
98+
99+
Example:
100+
101+
```json
102+
{
103+
"id": "did:<iin_name>:<network_name>#updatepolicy",
104+
"controller": "did:<iin_name>:<network_name>",
105+
"type": "VerifiableCondition2021",
106+
"threshold": 8,
107+
"conditionThreshold": [
108+
"did:<iin_name>:<network_participant_1>#key1",
109+
"did:<iin_name>:<network_participant_2>#key3",
110+
"did:<iin_name>:<network_participant_3>#key2",
111+
"did:<iin_name>:<network_participant_4>#key1",
112+
"did:<iin_name>:<network_participant_5>#key1",
113+
"did:<iin_name>:<network_participant_6>#key1",
114+
"did:<iin_name>:<network_participant_7>#key1"
115+
]
116+
}
117+
```

0 commit comments

Comments
 (0)