Some explanation is in order for why Milagro was ignored shortly after incubation and what prevented the original contributors from driving this project. But that's the subject of another post.
What the Milagro committers need to do now is to re-invigorate the project to make sure it has every chance of success. This is great, breakthrough technology that has already found a home at IBM, NTT, various intelligence agencies (GCHQ, CCSD USAF, etc.) and defense contractors, JPM, Experian, UK Government, the list goes on. This project deserves our attention to make it successful.
Milagro needs a refresh to a) make it relevant and attract a developer ecosystem, b) to package the core technology (ZKP MFA, etc.) into a MODERN server architecture for easier deployment and use (we are delivering a PRODUCT, remember) and c) showcase its capabilities by addressing use cases that tackle billion dollar problems.
Refresh Code Repos, Website and Documentation
Milagro was conceived as a distributed cryptosystem with a unique emphasis on providing solutions for securing decentralized systems in 2016. Since then, the problems of securing these systems have only grown more pronounced and the need for cybersecurity solutions that fit to distributed/decentralized networks and architectures is even greater. Even the core cryptographic technology on which Milagro is based, zero-knowledge proof (ZKP) itself has become a mainstream topic within cryptocurrency development.
The Milagro Auth Servers are horribly out of date. They are built on Python 2.6, and are dependent on out of date core C libraries that, now updated, break the builds. The mechanism to connect relying party web applications to Milagro servers uses a non-standard, non OICD way of doing this which makes integration very hard to do.
I propose we focus our development energy in two places.
- Build a minimal Milagro Server for release within 60 days - The committers working at Qredo have been developing a decentralized security system for protecting cryptocurrency private keys, effectively digital asset custody. This is all based on code within Apache Milagro. Qredo has signed a CCLA and so have all developers working on the project. We propose putting this server code into the a new, modern, Milagro server for release within 60 days. This will also enable us to build a modern deployment architecture for the 'type' of Milagro server the customer wants to deploy and make a way for us to take the great work that Giorgio and others have done, particularly with the D-TA's issuing secrets via gRPC, and incorporate this work into the new, modern Milagro server. Qredo, which has recently signed a CCLA will make a software grant to Apache which covers the custody use case.
Website and Documentation
I propose that we refresh the website to give it more emphasis on securing these decentralized/distributed systems (like Bitcoin, etc.) in addition normal enterprise use cases like multi-factor authentication.
Now that Confluence is setup, we can proof the new website language here to get PPMC discussion and agreement on the updated website before going live. I propose we do this straight away and will have a draft this next week for everyone to review.
NOTE: The current website is hosted within SVN. I propose that we also move the location of the website to the milagro-crypto repository, putting the static site content in there for build into a 'content' folder within an 'asf-site' branch. This is all documented https://www.apache.org/dev/project-site.html and in the last section of Apache Guacamole's README.md file here https://github.com/apache/guacamole-website/tree/master (be sure to look at the asf-site branch). We need to make a request to asf infra to do this but it shouldn't be an issue.
Modern Milagro Server
Some of the contributors have been working on a modern implementation of a Milagro server using Golang which we propose to contribute to Milagro. This version of the Milagro Server can perform zero-knowledge proof authentication with an M-Pin protocol enabled client, but also performs a custodial operation (securing) cryptocurrency private keys, again, using code from the Milagro crypto libraries.
The point is that we can refresh the Milagro server with a build process that enables easy integration into other Apache infrastructure projects and provides utility value for these projects as well by way of supporting Docker and having a modern build system. As an example, the Milagro Server should integrate with Apache Web Server and in particular the mod_oidc to offer any implementer of OIDC relying party capability the option to integrate into a Milagro Server, when, in ZKP MFA mode, will have an on-board OIDC IP (Identity Provider) function.
Milagro Server Direction
I propose that Milagro Server addresses three main uses cases that are possible to implement given the core crypto library capabilities.
- Decentralized Zero Knowledge Proof Multi-Factor Authentication - this is been the historical core of capability and nothing changes here (except we deploy the authentication server, or D-TA's using a modern method).
- Decentralized Custody for Digital Assets - The Milagro Server should be able to communicate with other Milagro servers to arrange themselves in a distributed manner to offer a custodial operation for issuing cryptocurrency wallet addresses. This 'type' of Milagro Server will be covered in another page on this Confluence site shortly as a basis for discussion and planning. As stated above, Qredo, which has recently signed a CCLA will make a software grant to Apache which covers the custody use case.
- Decentralized Backup for Secrets and Digital Assets - Using code and architecture from #2, we will also be able to offer a secure backup for secrets and digital assets that is sorely needed for decentralized systems today. As in #2 above, this 'type' of Milagro Server will be covered in another page on this Confluence site shortly as a basis for discussion and planning.
I will alert the committers over the dev@ channel to put their comments through this email list to discuss, debate and agree on direction this weekend.
My idea for having and growing the community it to have something to present at the next Embedded Linux Conference in Lyon, the call for paper ends beginning of July. This will give us the right visibility for saying "We are back!". As always depends on us. Some thoughts: