We all know and love DIDs in an SSI space. We have one day-to-day operation we are constantly doing with DIDs that somehow stay in a shadow but open many possibilities for secure identity and Identity protocols.
We have four possible operations defined by DID method.
- resolve — exchange DID to a DID Document metadata
- create — create a DID and bind it to a DID Document metadata
- update — update a DID Document metadata
- deactivate — invalidate a DID and DID Document binding and make it unresolvable.
I would say that we have a fifth operation — Prove of Ownership. It is not covered by spec but has a significant practical meaning.
What is DID (just to remind)
A Decentralized Identifier (DID) is a type of digital identifier designed to be self-owned and globally unique, allowing individuals and organizations to create and manage their digital identities without relying on a centralized authority or intermediary.
DIDs are designed to work on decentralized networks, such as blockchain, and are based on open standards developed by the W3C (World Wide Web Consortium) and other industry groups. They provide a way to represent and verify digital identities, attributes, and credentials in a decentralized and interoperable way.
The key feature of DIDs is that they are self-owned, meaning that the individual or organization has complete control over the DID and the associated data. This is achieved through public key cryptography, where the DID is derived from a public key, and the owner of the DID holds the corresponding private key.
DIDs can be used in various contexts, such as online identity verification, access control, and decentralized authentication. They provide a way to establish trust between different parties in a decentralized environment and enable secure interactions without relying on a central authority or intermediary.
How to Prove Ownership?
It is one of the cornerstone operations not part of four well-defined DID operations(resolve , create , update , deactivate ), but the most common DID interaction after DID resolution. So how Controller or Subject could prove that he owns or control a DID?
In the real world, challenge-based tokens from a verifier are preferable. In this case, the verifier issues a challenge that should be signed by the private key and shared with a DID. We can build authorization protocols that verify the verifier and the consumer. It is a core of the didAuth protocol.
Let's simplify a task and focus on self-issued tokens that prove DID ownership. It is based on signatures. The most straightforward way to share a signature with a payload is JWT tokens. The most straightforward flow could be described in the following flow diagram.
In addition, we could visualize actors and involved entities. Self-certifier JWT contains DIDUrl in an iis field. So Verifier could use any Resolver mechanism for a did method to obtain a DID document via the resolution process. Now it is a trivial task to extract a public key and validate the signature of the JWT token.
Top comments (0)