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 <br...@qredo.com> 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 >
