Until now, Decentralized Identifiers (DIDs) on Dock could only have one key at any moment. Though they could be rotated over time, having only one valid key at any moment meant that the DID owner had to use the same key for all purposes.
As an example, consider the life of an issuer utilising a DID. The issuer could perform several functions like the issuance of credentials, authenticating with some other application, engaging in secure communication using a methodology like DIDComm, or revoking its issued credential on the blockchain, which again requires authenticating itself to the chain. Following the principle of separation of concerns, the issuer would ideally like to have separate keys for each of these functions so that when one key is compromised or lost, its other functions are not impacted. Also, the issuer would like to have separate more sensitive keys that can be used to add new or remove existing keys of its DID.
With the latest release of our platform (blockchain node and SDK), we enable a DID owner to have a setup like the above. This new release will allow a DID to add multiple keys for its DID and give them different capabilities. These are called Verification relationships in the W3C DID spec. A key can have one or more Verification relationships to the DID depending on the kind of functions it's supposed to perform on the DID's behalf.
We support 4 Verification Relationships:
1. Authentication - Keys with this relationship are only allowed to be used for authentication, i.e. convincing the other party that it's a key of the DID. Such a key can revoke a credential on the blockchain, add a schema, or act as a holder when sharing a presentation of credential(s).
2. Assertion - Keys with this relationship are used for signing credentials during issuance.
3. Key Agreement - These keys are used during secure communication to encrypt some data for the DID.
4. Capability Invocation - These keys are able to modify the DID Document, i.e. add new or remove existing keys, add/remove service endpoints, controllers (more on this below), etc. If a DID has one or more such keys, we say that the DID "controls" itself, meaning that it can modify its DID Document. We have intentionally decided to allow keys with this relationship to also add schemas, revoke credentials, etc., on the chain.
While adding a key, it can be specified what verification relationships the key would have with the DID. Each new key gets a unique id (in that DID's context), and using this id, the key can be removed as well.
As mentioned above, only keys with "Capability Invocation" are able to modify the DID Document. A DID with such a key is said to be self-controlled, or it's a controller of itself. But a DID might have other controllers as well, or a DID might not control itself but is only controlled by other DIDs. This capability is essential for guardianship use cases where a DID (the controller) is the custodian of another DID (controlled).
As an example, consider an organization that wants to onboard its members to our chain and give each member a DID. At the time of onboarding, members might not be capable of managing keys, so the organization will create a DID for each of its members. That member DID won't have a key, and the organization DID will be the controller of the member DID. Now the organization is the guardian of the member.
When the member becomes capable of managing keys, the member will provide its public key to the organization, which will update the member DID with that public key, make the member the controller of its DID and remove itself from the controller role, thus ending the guardianship.
In another example, consider an IOT application where each sensor has its own DID. The sensors have keys that they use to sign (Authentication) messages before sending or decrypting (Key Agreement) received messages, but only the owner of the sensors can update their keys. Also, the owner could add new owner(s) to those sensors by adding more controllers to their DID or remove itself as the controller, thus transferring the ownership.
Similar to sensors, DIDs can be assigned to other objects like batteries where batteries have DIDs, but they don't have any keys, only controllers (the owner of the battery). This helps us in building Digital Product Passports which are digital twins of physical products to enable a sustainable and circular economy, etc. DIDs can also be assigned to an NFT where the NFT itself has no keys, but the owner of the NFT is the controller of its DID. When the ownership is transferred, the controller of the NFT DID also changes (this will be triggered through a smart contract).
DIDs often need a way to communicate, like a subject DID needs to request a credential from the issuer DID. The issuer thus needs a way to publish its contact information like an HTTPS endpoint it should be reached on or its website. This is achieved by the issuer adding a "service" to its DID Document, which specifies this information. As alluded to before, only controllers of a DID can update the DID Document, thus adding the service endpoint.
Another feature we have added is off-chain DID Documents. Until now, all things part of the DID document, like keys, controllers, and services, are stored on the chain. The logic to add/remove these is not clearly defined in the DID spec but is what looked like the most reasonable to us. But for users who would like a different set of rules for updating DIDs or adding more functionalities without waiting for us to build them can host their DID documents on another storage like IPFS or anything and only store the reference to the document like IPFS CID or URL for the DID.
Lastly, the release contains several refactorings and improvements, which led us to introduce breaking changes, so please upgrade your applications at your earliest convenience.
For a more technical walkthrough of these features check out the conceptual explanation and the hands-on example. Also, there are breaking changes for our SDK so please use SDK version 2.3.0 or above.
到目前为止，Dock上的分散式身份（DIDs）只能同时拥有一个密钥。虽然它们可以随着时间的推移轮换，但任何时候只有一个有效密钥意味着DID所有者必须为所有用途使用相同的密钥。
例如，考虑一个利用DID的发行者的生活。发行者可以执行多个功能，例如发行凭证、在某个其他应用程序中进行身份验证、使用像DIDComm这样的方法进行安全通信，或在区块链上撤销其发行的凭证，这又需要向链进行身份验证。遵循关注点分离的原则，发行者理想情况下希望为每个功能分别设置密钥，以便在一个密钥被危及或丢失时，其其他功能不会受到影响。此外，发行者希望拥有单独的更敏感密钥，可用于添加新密钥或删除其DID上现有密钥。
我们平台（区块链节点和SDK）的最新版本使DID所有者能够像上述那样设置。这个新版本将允许DID为其DID添加多个密钥，同时赋予它们不同的能力。这在W3C DID规范中称为验证关系。密钥可以根据它们代表DID执行的功能类型与DID具有一个或多个验证关系。
我们支持4个验证关系：
在添加密钥时，可以指定密钥将具有哪些验证关系。每个新密钥都获得一个唯一的ID（在该DID的上下文中），使用此ID可以删除密钥。
如上所述，只有具有“能力调用”功能的密钥才能修改DID文档。具有这样的密钥的DID被称为自我控制，或者它是自己的控制器。但是，DID可能还有其他控制器，或者DID可能不控制自己，而只受其他DID的控制。这种能力对于监护用例至关重要，其中DID（控制器）是另一个DID（受控制）的保管人。
例如，考虑一个希望将其成员上载到我们的链并为每个成员提供DID的组织。在入职时，成员可能无法管理密钥，因此该组织将为其每个成员创建一个DID。该成员DID将不拥有密钥，组织DID将成为成员DID的控制器。现在，该组织是该成员的监护人。
当成员能够管理密钥时，该成员将向组织提供其公钥，组织将使用该公钥更新成员DID，使成员成为其DID的控制器，并从控制器角色中删除自己，从而结束监护关系。
在另一个例子中，考虑一个IOT应用程序，其中每个传感器都有自己的DID。传感器具有用于在发送消息之前对其进行签名（身份验证）或在接收到的消息之前解密（密钥协商）的密钥，但只有传感器的所有者才能更新其密钥。此外，所有者可以通过将更多控制器添加到其DID或将自己从控制器角色中删除来向这些传感器添加新所有者或删除自己作为控制器，从而转移所有权。
与传感器类似，可以将DIDs分配给其他对象，例如电池，其中电池具有DID，但没有任何密钥，仅有控制器（电池所有者）。这有助于我们构建数字产品护照，这些护照是物理产品的数字副本，以实现可持续和循环经济等。DIDs也可以分配给NFT，其中NFT本身没有密钥，但NFT的所有者是其DID的控制器。当所有权转移时，NFT DID的控制器也会更改（这将通过智能合约触发）。
DIDs通常需要一种通信方式，例如主题DID需要从发行者DID请求凭证。因此，发行者需要一种方式来发布其联系信息，例如它应在何处达到的HTTPS端点或其网站。这是通过将“服务”添加到其DID文档中来实现的，该服务指定了此信息。如上所述，只有DID的控制器才能更新DID文档，因此添加服务端点。
我们添加的另一个功能是离链DID文档。到目前为止，DID文档的所有部分，例如密钥、控制器和服务，都存储在链上。添加/删除这些的逻辑在DID规范中没有明确定义，但这是我们看来最合理的。但是，对于希望使用不同的规则更新DIDs或添加更多功能而不必等待我们构建它们的用户可以将其DID文档托管在另一个存储中，例如IPFS或任何其他存储，并仅存储对文档的引用，例如IPFS CID或DID的URL。
最后，该版本包含几个重构和改进，这导致我们引入了破坏性更改，因此请尽快升级您的应用程序。
有关这些功能的更多技术说明，请查看概念说明和实践例子。此外，我们的SDK存在破坏性更改，请使用SDK版本2.3.0或更高版本。