ZKP MFA

[Kealan McCusker <ke...@gmail.com>]

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

Re: ZKP MFA

[Giorgio Zoppi <gi...@gmail.com>]

Dear all,
the main point here is interop with other apache products, i.e. Fineract,
OfBiz, Tomcat, httpd.
If  we want users, those might be the our first class citizen.
Provide them a way to use our product and OIDC is a way.
best regards,
giorgio.


El lun., 10 jun. 2019 a las 8:05, Brian Spector (<br...@qredo.com>)
escribió:

> Hi Kealan,
>
> Tacitly I’m in agreement, as long as the ‘OIDC’ integration does
> not preclude someone from using a ‘direct’ integration later. I
> believe the reason we have the issues with the server at the moment is
> that the original development team on it went for some hybrid federation
> model that was completely alien to the rest of the market and hence it
> worked for no one.
>
> I don’t think the current MFA server is fit for purpose either. The
> code hasn’t been maintained in some while, it needs an upgrade to work
> on Python 3.x, doesn’t fit in OIDC, does not work with Apache Web
> Server, etc.
>
> I know there is an OIDC module on web server (mod_oidc) and wonder if we
> can use this for our purpose?
>
> I think Jean-Frederic was working on it at one point.
>
> 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
>


-- 
Life is a chess game - Anonymous.

Re: ZKP MFA

[Brian Spector <br...@qredo.com>]

Hi Kealan,

Tacitly I’m in agreement, as long as the ‘OIDC’ integration does 
not preclude someone from using a ‘direct’ integration later. I 
believe the reason we have the issues with the server at the moment is 
that the original development team on it went for some hybrid federation 
model that was completely alien to the rest of the market and hence it 
worked for no one.

I don’t think the current MFA server is fit for purpose either. The 
code hasn’t been maintained in some while, it needs an upgrade to work 
on Python 3.x, doesn’t fit in OIDC, does not work with Apache Web 
Server, etc.

I know there is an OIDC module on web server (mod_oidc) and wonder if we 
can use this for our purpose?

I think Jean-Frederic was working on it at one point.

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

Re: ZKP MFA

[Brian Spector <br...@qredo.com>]

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 <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
>>

Re: ZKP MFA

[Kealan McCusker <ke...@gmail.com>]

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
>

Re: ZKP MFA

[Brian Spector <br...@qredo.com>]

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