Autonomous DIDs Identifiers for Organisations
Organizations identifiers
Organizational identifiers have different sets of requirements and functions. It is not enough to have per-to-peer private communications. Organizations are more public, so we need publicly resolvable identifiers. DID:key satisfy this condition entirely but fails to fulfill the organization's needs.
- Organizations quite often act as issuers of credentials or attestations. For issuance, it is critical to have the possibility to rotate signing keys or even deactivate or delete identifiers if keys or issuer get compromised or to comply with security company policies.
- Organizations often require a split between the Controller of the identifier and the Identifier subject or even a transfer of the identifier subject.
- Organizations must have complete control of infrastructure and effectively manage resources and costs. The price of a single identifier should be fixed, and the method of creating new identifiers should be scalable.
- One of the essential requirements is trust and governance and transparent mechanics of proving and binding an identifier to an organizational entity and creating trust relations.
- Access to Identifier management is quite often controlled by a group of users
Nonfunctional requirements
- portability
- interoperability
- scalability
- Autonomous and control
- security
Autonomous Identifiers
In my previous articles, we talk about Autonomous identifiers and how they differ from regular DIDs.
To recap
Autonomous identifiers (AIDs) are DIDs generated algorithmically from a crypto- graphic key pair in such a way that they are self-certifying, i.e. the binding with the public key can be verified without the need to consult any external blockchain or third party. KERI is an example of a decentralized identity technology based entirely on AIDs. © https://trustoverip.org/blog/2023/01/05/the-toip-trust-spanning-protocol/
In a previous article, I show how to create and use a did:key as an Autonomous identifier that feet well to private person-to-person secure communication.
Architectures and protocols that build on top of AIDs have few critical properties
- self-hosting and self-contained
- self-certified and Autonomous
- portable
- interoperable
- full control of infrastructure
- cost management
Nowadays, I discovered a few AIDs methods
- did:key — self-contained and public
- did:peer — self-certified, upgradable but private
- KERI based did — we waiting for did:keri method to be announced soon, but KERI infrastructure could be used to build internals of did:peer or similar methods.
- did:web — public, self-certified, and self-hosted method, but still, we have active community discussion and critics as far as it fully relays to ownership of domain name that could be stolen or re-assigned.
So we have to choose from did:key did:web and I hope in a future from did:keri.
To move forward, we need to understand the DID architecture better and how all parts are connected.
Subject, Controller, Key Pair, Identifier, and its Relations
In many cases of personal or sovereign entities Subject and the Controller are the same, but for Organisations, it could have a crucial difference.
DID Subject
The DID subject is the entity that the DID represents. It can be a person, organization, device, or other identifiable entity. The DID subject is associated with a unique DID that serves as a persistent, resolvable, and cryptographically verifiable identifier. The subject is the primary focus of the identity management process and typically has one or more DIDs associated with it.
DID Controller
The DID controller is the entity (person, organization, or device) that has the authority to manage the DID Document associated with a particular DID. The DID controller can update, revoke, or delegate control of the DID Document, which contains the public keys, service endpoints, and other information required for interacting with the DID subject.
In many cases, the DID subject and DID controller can be the same entity, especially for individual users who create and manage their DIDs. However, in some situations, the DID controller may differ from the DID subject, such as when an organization manages the DIDs on behalf of its employees or when an administrator manages a device.
In summary, the DID subject is the entity the DID represents, while the DID controller is the entity with authority to manage the associated DID Document. Depending on the specific use case and requirements, these roles can be held by the same or different entities.
Key Pair
It is simple from the first point of view. Key-Pair is an asymmetric public and private key. One of the main DID functions is the distribution of public keys. DIDDoccument could contain multiple public keys with authorization rules and key roles.
Identifier
Representation of did itself. is a part of DID URI.
DID:Key
DID web
Relations
Relations between all parts of DID identifier can be illustrated in the following diagram. DID method dictate how DID identifier gets created, updated, deactivated, and resolved.
Focusing on the relations of the controller, key pairs, and the identifier is more interesting for us.
The most significant power and benefit of DID are decoupling a key pair from a controller and identifier. It allows the rotation of keys and changes the ownership of the identifier and its subject and controller. It is the main competitive advantage of DID and SSI over web3 wallets and raw keys.
The ideal case is KERI infrastructure that decouples all parties via cryptographic binding and protocols.
To discover more, read the paper.
We used did: keys as AID in the previous article. DID:key is a cryptographically bound identifier to the public key but cannot change the binding. As a result, keys couldn't be rotated in the future. The controller has no binding except to prove private key ownership via the signature-based protocol.
On the other side, DID:web does not have a cryptographic binding of an identifier to a key pair from one side. It gives an easy possibility to rotate keys but loses the verifiability of the identifier.
The most interesting part is the Controller to identifier binding in a did: web. It is based on proof of domain name ownership and website resource. As I mention, it has some security considerations and critics in a community. Still, at the same time, we get a critical mechanism that settles trust and connects identifiers to the organization entity.
The mechanism of web domain ownership is well-defined and easy to explain to other users, even outside of SSI and web5 domain. It is getting wider adoption and creating a lot of use cases for organizations. So it helps to create a trust relationship between an identifier and organizational entity in a very transparent, human-readable, and self-explained way — the identifier hosted on the corporate domain belongs to the organization. On another side, it makes the transfer of the controller almost impossible. That's why it is critical to differentiate between a subject and a controller.
I believe that did:web still covers a lot of organizational cases and is suitable for issuing Verifiable Credentials and attestations on behalf of organizations.
How to DID:WEB
Step-by-step guide on how to create and manage did:web you could find in my article
More detailed step-by-step coding guide with the live example you could find in my SSI notebooks book
