Hyperledger-Prism Interoperability

INTRODUCTION

One of the most used SSI frameworks is Hyperledger Indy from The Linux Foundation. It was adopted by many governments around the world, being Sovrin the most popular permissioned SSI deployment of Hyperledger Indy. That lead to that most of the Verified Credentials were issued and reside in Indy platform, making Indy the ideal target where Atala Prism should prioritize interoperability.

This project is about providing open-source code to give Atala Prism two layers of interoperability with that framework:

1. A communication layer based on DIDComm v1 protocol
2. A mapping mechanism to convert Verifiable Credentials both ways

This kind of interoperability will open a great opportunity for new projects to interact with already established solutions. For example, the following project implementations were deployed on Sovrin:

• IATA Travel Pass
• NHS Staff Passport
• GLEIF, Global Legal Entity Identifier Foundation
• SSI4DE, co-funded by the German Federal Ministry of Economic Affairs
• CULedger MemberPass for Credit Union customer identity verification
• Farmer Connect

If we  can open a door to some of those solutions, we will put Cardano in a favorable position to be the leader as permission-less technology in the Self-Sovereign Identity space.

DETAILED PLAN

LAYER 1- DIDComm v1 communication layer

Hyperledger Indy is a complete SSI framework that provides tools, libraries, and components for providing digital identities. After it's initial release, the framework was being reshaped to separate components to be reusable and agnostic from each other, based on The Linux Foundation primitives. As a result, Hyperledger Aries became the AGENT part of the solution providing a reusable toolkit focused on creating, transmitting and storing verifiable digital credentials.

Hyperledger Aries communication layer is based on DIDComm v1  so since Aries is open source the plan is to port that layer into an Atala Prism Agent. Doing so we will enable agents to "talk" to each other in a secured and more standardized way.

That communication layer will allow the full range of credential use cases such as requesting, offering, sending and receiving, and requesting and answering proofs.

LAYER 2- Mapping mechanism to convert Verifiable Credentials both ways

Having a channel of communication between agents is not enough. At this time, Atala PRISM credentials do not fully conform with the W3C data model so in order to share credentials with Aries some conversions will be required.

The goal in this second part of the project is to provide open source code with a basic framework that enables the mapping of Hyperledger Aries credentials into Atala Prism Credentials both ways. The code will be flexible enough so each implementer could easily create its own mappings.

BUDGET, DELIVERABLES AND DURATION

LAYER 1- DIDComm v1 communication layer:

• Deliverable: github repository with open source code
• Estimated development cost: USD 20.000
• Estimated duration: 2 months

LAYER 2- Mapping mechanism to convert Verifiable Credentials both ways

• Deliverable: github repository with open source code
• Estimated development cost: USD 10.000
• Estimated duration: 1 month

SUMMARY:

• TOTAL BUDGET: USD 30.000
• TOTAL DURATION: 3 months

PROJECT ORGANIZATION AND TRACKING

The project implementation will follow Agile management based on Jira Cloud tools. Jira users can be created for follow up and auditability. Additionally, a bi-weekly report will be published with project progress, major milestones and risk assessment.

There are two deliverables that constitute the main metric of progress and success:

• Layer 1 DIDComm v1
• Layer 2 Mapping mechanism to convert Verifiable Credentials

As a commitment to the transparency of the allocated funds, we expect payments based on above deliverables without the need of advance payments.

Intermediate progress will be reported as Sprint Burndown, a KPI metric that shows the progres of each development sprint. Additionally, the development will be managed in a public github repository where periodic commits will be pushed and that allow the community to audit and validate the work.

RISK ASSESSMENT

During developing of this proposal, two concerns/risks were identified and came up with mitigation plan in case it is needed:

• can enough time be allocated to the development?: if an unplanned time constrain appear, an additional developer will be hire that will be paid with the budget (note that budget is base on hourly development rates)
• can cope with the technological challenge?: although Hyperledger Aries have implementation in many coding languages that help a lot, difficulties can arise. As being part of the Atala Prism Pioneer Program we made strong contacts with Atala Prism Team that are willing to provide help, guidance, or point to external resources.

THE TEAM

This proposal was elaborated by Rodolfo Miranda. His Linkedin profile can be find at https://www.linkedin.com/in/rodolfomiranda/

His background includes a MS EE degree at Stanford University and more than 25 years of successful work experience in both large multinational companies and owned startup projects. His main activities involve architecting, developing, and implementing large scale software solutions for the Telecommunication Industry. He leads multi-disciplinary and multinational teams in the Caribbean and Latin America.

More than 40 years of self-taught programming with advanced knowledge on many coding languages. Lately, he was engaged in blockchain technologies and joined Cardano community where he:

• Submitted and received funding for his proposal in Fund 6: https://cardano.ideascale.com/a/dtd/Interoperability-as-growth-driver/368705-48088
• Delivered a DIF side-tree implementation on top of Cardano: https://github.com/rodolfomiranda/sidetree-cardano
• Participated as Community Advisor in Fund 6
• Is one of the members of the Challenge Team for Fund 7 challenge "Grow Latinamerica, Grow Cardano"
• Is part of the first cohort of the Atala Prism Pioneer Program

For this personal project he will allocate sufficient time resources to cope with the project. An additional developer will be included if needed. The final selection of the developer will be made among already known developers from Latin America that were part of other projects. Note that the developer does not require a full understanding of Cardano blockchain, but a great knowledge of Javascript and Python languages and ability to understand specifications and protocols.