We got a plan! On 12 Jun 2019, at 9:26, Kealan McCusker wrote:
> Hi Brian > > Yes, I think that we should focus our development effort on the D-TA as > all the other functionality is totally dependent on it. > > Regards > > Kealan > > On Wed, 12 Jun 2019 at 00:23, Brian Spector <[email protected]> wrote: > >> 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 >>
