Set up a Baseline Workgroup using the Decentralized Identifiers(DID)-based Baseline Phone Book

[italobb]

Baseline Protocol Workgroups using DIDs

Bounty

$2,000 in Eth

Background

The Baseline Protocol is an open source protocol which enables confidential collaboration between enterprises using blockchain technology, without putting sensitive data on-chain.

In order to run a “baselined” workflow between companies, you first need to set a Workgroup. In the Baseline Reference Implementation 1 (BRI-1), it consists of deploying a smart contract known as OrgRegistry, containing all the attributes required by the communication between the parties and inviting them using a NATS JWT bearer token. So far, such attributes have been raised between the parties manually, without a tool, a defined process or a trustable source of data to support the setup process.

The Baseline community raised this problem in the issue #133, suggesting the creation of a global phonebook. The problem and possible solutions were discussed during the Baseline Summit (youtube link here). The main problem is to turn enterprises publicly discoverable in an easy and secure way, guaranteeing the governance and trustworthiness of the data.

An usual solution for such problems is the election of a centralized entity which assumes the responsibility of managing the governance of the catalog, and even the accountability over any damages caused by tampered data.

In order to reduce the responsibility that relies on an entity hosting the phonebook, it’s appropriate to use a decentralized solution to anchor the trust of each entry. Nowadays it can be easily implemented using decentralized identifiers technologies, like the Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) standards from W3C.

A first implementation of the Baseline Phonebook is being developed by the Consensys Identity team using a combination of DIDs, VCs and DIF Well-Known DID Configuration (respectively RFC-8615). The solution guarantees a trustable linkage between DIDs, which contains public keys from an entity, and a web domain, which can be used to identify that entity. This trust anchor, that dismisses the need of an intermediary, enables any party to retrieve additional information about counterparties, like communication endpoints, simply by resolving DID addresses.

This solution can still be extended to implement solutions which require a centralized entity to increment the entries trust and details by associating attestations to them, using VCs; assuming accountability over the catalog; or adding business rules and other levels of governance on top of it.

The Baseline Phonebook

The Baseline Phonebook is still under development, but some of the main components are already available to be used by the community. The solution uses the Well-Known DID Configuration specification, from DIF, which enables a self-registration process for any organization using their domain and their DIDs.

To onboard a company to the Baseline Phonebook their IT responsible should follow this simple procedure:

1. Create a DID for the company, which will be used to communicate with other parties;
2. Generate a Well-Known DID Configuration file with the selected DID and the company domain;
3. Store the Well-Known DID Configuration in the company domain.
4. Register their domain in the phonebook.

The registration form for step 4 is under development, but it’s optional. The solution itself doesn’t require anything more than the counterparty domain, so the Well-Known DID configuration can be retrieved from the well-known URI and can be verified.

These steps can be executed using the Well-Known DID configuration DAF plugin:

1. Clone the plugin repo.

2. Configure the agent instance by editing the agent.yml file (or, if you’re simply trying it or joining a hackathon, keep the configuration as it is).

3. Run the following command to execute your agent:

yarn && yarn build && yarn start

4. Execute the following command to generate a DID:

yarn daf execute -m identityManagerCreateIdentity -a "{}"

5. Execute the following command to generate your Well-Known DID configuration file, using the DID created in the previous step and the domain from your company:

yarn daf execute -m generateDidConfiguration -a "{\"dids\":[\"<did>\"],\"domain\":\"<domain>\"}"

6. Upload the Well-Known DID Configuration file to the company website and host it under the well-known URI:

https://<domain>/.well-known/did-configuration.json

7. Verify your Well-Known DID Configuration running:

yarn daf execute -m verifyWellKnownDidConfiguration -a "{\"domain\": \"<domain>\"}"

The Challenge

The Baseline Phonebook has a defined solution and a simple MVP, so there’s still a lot yet to be evolved. In this challenge, we’d like to see someone building a tool that uses the DID-based phonebook solution to create a new Baseline Workgroup from it.

Remember, the phonebook is still under construction, but you won't need it now. You can simply create a Baseline Workgroup by retrieving the Well-Known DID configuration directly from the participants domains (from the well-known path). So, you won't need a central phonebook to implement your solution.

Basic flow to be covered

Basically your tool will need to implement the following flow:

1. Download the Well-Known DID configuration from the domain of each party that will join the Workgroup, using the Well-Known DID configuration DAF plugin .

2. Define how the Baseline communication endpoint and public keys from each party will be stored in their DID Documents, obtained in the previous step. It can potentially become a standard proposal for the Baseline community.

3. Build a new Baseline Workgroup by inviting participants using the attributes retrieved from the DID Documents of each party in the previous step (the OrgRegistry can become optional here).

4. Run a baselined workflow using the workgroup just defined.

Technical Requirements

• The solution should be demonstrated using the current Baseline Reference Implementation (BRI-1). So, a forked version of this repo should be part of the deliverables.

• The solution needs to be easy to use. The user should be able to inform as input only the domain name of the Workgroup participants and have the OrgRegistry deployed using the attributes retrieved from the DID Documents.

• The Well-Known DID configuration DAF plugin must be used in the solution.

• No secret keys and no personal information must be associated with the DID as every attribute that is added to the DID Documents of that DID could be potentially stored on a public Blockchain.

• Define a DID service endpoint for Baseline.

Important Tips

• The BRI-1 uses NATS servers to implement the communication layer and it uses Decentralized JWT Authentication/Authorization to invite each Workgroup participant.

• DIDs through their resolution process (DID Documents) could be a great tool for public key and endpoint discovery of counterparties.

• The Well-Known DID configuration DAF plugin already implements some of the steps your tool needs to implement like downloading and validating a Well-Known DID configuration file from a domain. So, take a good look on its API before starting.

• The current BRI-1 stack rely on the IRegistry interface to build workgroups. After this challenge, it'll simply rely on the DID Document attributes. So, your changes in the BRI-1 won't be large but you'll need to set up the environment to run it by creating DIDs for participants, creating their DID configuration files (using DAF), storing their DID configuration in their websites (in the dockers from BRI-1), store and retrieve the communication endpoints in the DID document of the participants.

Evaluation Criteria

The solution must have at least worked by obtaining communication attributes using Well-Known DID Configuration, otherwise it won't be accepted and evaluate.

The competitor with the highest score based in the table bellow wins:

Deliverable	Points
Github commit hash and Github URL	10
Detailed README instructions so anyone can run it	20
Technical requirements covered	40
A single demonstration video showing:
(video) How to use the tool (how to access and use the repo where the solution was implemented)	10
(video) The setup for the demonstration (like storing the Well-Known DID Configuration files in the participants domains)	10
(video) The tool receiving the domain names and retrieving the attributes (explanation on how the attributes were retrieved from the DID Documents; Execution and evidences, using the data from the previous step)	30
(video) The workgroup stablished (some log or debug showing the date used to create the workgroup, using the data from the previous step)	30
(video) The Baseline workflow running (workflow steps using the communication attributes retrieved from the phonebook solution)	40
(video) Explain how the OrgRegistry is used in the solution	30
(video) Explain how the solution can be evolved	20
Extra points: describe and exemplify how the same solution can be applied in other cases not BRI-1	30
Extra points: demonstrate interoperability between DIDs using distinct methods	30

Winner Announcement Date

January 27, 2021

[moisesja]

The link to the DAF plug in seems to be incorrect. Looking at the uPort's github repos it seems it could be this one? https://github.com/uport-project/daf-plugin

Is that correct?

[italobb]

The link to the DAF plug in seems to be incorrect. Looking at the uPort's github repos it seems it could be this one? https://github.com/uport-project/daf-plugin

Is that correct?

The "Well-Know DID Configuration DAF Plugin" is available at: https://github.com/uport-project/daf-plugin-did-config

The link you've mentioned is the DAF Plugin Template. You can use it, but the "Well-Know DID Configuration DAF Plugin" already contains the methods to generate a DID configuration file and to verify a DID configuration from a domain.

[moisesja]

The link to the DAF plug in seems to be incorrect. Looking at the uPort's github repos it seems it could be this one? https://github.com/uport-project/daf-plugin Is that correct?

The "Well-Know DID Configuration DAF Plugin" is available at: https://github.com/uport-project/daf-plugin-did-config

The link you've mentioned is the DAF Plugin Template. You can use it, but the "Well-Know DID Configuration DAF Plugin" already contains the methods to generate a DID configuration file and to verify a DID configuration from a domain.

Hi Italo, the link you provided returns a 404. Thanks!

[italobb]

@moisesja Fixed. The repo was private. Just fixed that. Thanks.

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

This issue now has a funding of 3.4023 ETH (2000.01 USD @ $587.84/ETH) attached to it.

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
  • Want to chip in? Add your own contribution here.
  • Questions? Checkout Gitcoin Help or the Gitcoin Chat
  • $1,207,512.91 more funded OSS Work available on the Gitcoin Issue Explorer

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

Work for 3.4023 ETH (1865.46 USD @ $566.42/ETH) has been submitted by:

---

• Learn more on the Gitcoin Issue Details page
• Want to chip in? Add your own contribution here.
• Questions? Checkout Gitcoin Help or the Gitcoin Chat
• $1,202,779.89 more funded OSS Work available on the Gitcoin Issue Explorer

[italobb]

We just launched a new version of the DAF plugin, where the verification function returns an object containing, in addition to the DID configuration, the list of DIDs associated with the domain. We also published the NPM package: https://www.npmjs.com/package/daf-plugin-did-config

[aldigjo]

We've updated the readme to include a programmatic usage example here