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.
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.
The M-Pin zero-knowledge proof multi-factor authentication crypto protocols are alive and well in the core lib, and C and JavaScript implementations. I recommend that we decommission the current class of Milagro server, standardize on OIDC and build a modern Milagro server using go-kit or some other type of automated system that will automatically build the right kind of server the customer wants/needs (D-TA, ZKP MFA, Crypto Custody) from the Milagro crypto components and libraries. This is covered further in a further section.
I propose we focus our development energy in two places.
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.
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.
I propose that Milagro Server addresses three main uses cases that are possible to implement given the core crypto library capabilities.
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.