On the same topic of conversation, I believe the most crucial thing is to get a functioning D-TA out first. It is from a D-TA that all other applications can be built upon.
The vision for this D-TA was outlined in a blog post earlier in the week, but I will restate it: The Decentralized Trust Authority has two jobs: 1) Issue shares of secrets to clients or servers or peers, or 2) safeguard secrets in a decentralized manner, acting as a “Fiduciary” for its Beneficiary. Use case 1) describes a D-TA issuing secrets to an MFA server or clients, as an example, or issuing ECDSA or Edwards curve keys to Beneficiaries to recreate a whole bitcoin key, as another example. Use case 2), as an example, would have a D-TA receive shares of a BLS key, use these keys as signature keys, to enable signature to be collected by a signature aggregator, who then turns the complete signature into a seed value for an HD Wallet. Both cases need a functioning D-TA that operates in roughly the same manner. We are working on D-TA code and a D-TA REST API that supports use case 2). This is what we will be committing to the Milagro project imminently. I suggest that, as a group, we start here as our focal point of collaboration to make sure that what we are building can support both scenarios. To that end, I have started updating the milagro website to support the inclusion of Swagger style rest API documentation. The old website was horribly out of date. While there is still some more porting to do, I should have this done by Thursday. On the subject of the code contribution, I believe it will have the ability to digest signed JWT tokens in bearer form to validated the calls from applications to 1) issue secrets or 2) safeguard secrets on its behalf. Focusing on the D-TA, and the D-TA’s API first just seems like a sensible approach. If we get the API right on the D-TA, I think everything else will go fast. Does everyone agree that we start with the D-TA, and then move on to the MFA server? Thanks Brian On 9 Jun 2019, at 16:08, Kealan McCusker wrote: > Hi All > > I would like to start a discussion about what should be in the first > release of the ZKP MFA component of the Milagro server. > > ZKP MFA, at it's simplest, is a drop in replacement for username / > password > that enables multi-factor authentication, no server side hashed > password db > and, best of all, it works in software! > > Here are two ways to integrate ZKP MFA into your system; > > 1. Directly > 2. OpenId Connect (ODIC) > > Obviously, only the second option allows federation of identity. I > propose, > at least initially, that we directly integrate the authentication > server > into a system requiring this service. > > There is also in the current Milagor repo's an old method of > integrating > ZKP MFA. In my view, it is not fit for purpose and should not be > followed. > > Regards > > Kealan
