Creating an Enterprise DID to Provide Power of Attorney for Employees

Written by Denys Popov

SSI adoption has many layers of challenges and complexities. One of the problems that I want to address in this article is,

“How to have an enterprise Decentralized Identifier (DID) when an employee 👨‍💼👩‍💼 can act on behalf of this company 🏢 with flexible permissions layer in a decentralized or peer-to-peer way?”

There are several hack solutions for this, but all of them have at least one major problem, which limits the usage and implementation of existing solutions.

Before we go into my proposed solution, let’s look at the problem first.

Problem Statement

Let’s say an organization wants to issue power of attorney as a Verifiable Credential (VC) for an employee DID.

Such an issuance requires a custom method for VC verification, so there should be a custom flow. Here, the employee should pass any meaningful info/VC to prove his organization’s power of attorney VC, and the verifier must perform that extra check of authority VC.

This verification may not be as easy as it sounds because the verifier must know how to handle that.

Workflow

Here’s the workflow of the above problem.

• The founder/CEO/creator of the organization DID can add to the DID document public keys (with proper authority/access/entry points) of employees.
• Next, an employee can use his personal DID to issue a document/VC on behalf of the organization and set it to an issuer field organization DID before sharing it with the verifier.
• The verifier will resolve the Issuer DID (in this case, it’s the organization’s DID). To do this, the verifier will get the issuing organization’s DID Document, find the proper employee public key, and verify the signature.

Looks good so far.

However, we have a problem here. The founder, who created the organization DID, will have full control and access to the anchor/recovery key. Therefore, they can always update the organization’s DID document, and no CEO/Founder rotation is possible here.

Though some existing solutions include modifications to the DID document to have several controllers, they won’t solve the issue altogether.

Proposed solution

Here’s my solution to support the majority of DID methods without modifications/custom flows and simultaneously have the flexibility you need.

• Create a DAO smart contract. In the initialize phase, define a set of stakeholders (their crypto addresses/DIDs) and define a threshold number required to get the consensus/perform action (should be equal to or smaller than the number of stakeholders), and initially perform the anchoring of DID by this smart contract on initialization.
• Next, the smart contract (kind of DAO) interface should allow for the threshold number from that group of stakeholders to make a decision (change the smart contract state):

- Update the related DID Document (by adding/removing public keys of employees or some permissions of it)

- Change the threshold number for making future decisions

- Add/remove stakeholders

With this solution, an organization’s authorized employee can sign documents using their personal keys, but can mark the Issuer as organization DID. Then, the verifier will perform just the standard verification, and it will work.

At any point, the stakeholders can remove an employee’s public key from an organization or change those permissions. Also, stakeholders can be changed when the required consensus is met. All this interaction is done and available in a decentralized way.

What do you think of this solution?

Join our community today

• Get conversations going with #teamaffinidi and the community on Discord
• Follow us on LinkedIn, Twitter, and Facebook
• Get the latest updates on what’s new at Affinidi; join our mailing list
• Interested in joining our team?
• Start building with the Affinidi tech stack now
• For media inquiries, please get in touch with Affinidi’s PR team via pr@affinidi.com