Drey Actuaries will act as Distributed Trust Authorities, acting on requests from the Drey Proof of Life app to issue shares of a Type-3 identity based private key to randomised identities enrolling in the fund.
Drey Actuaries respond to a cryptographically secured request from the Drey Proof of Life App to generate a share of this identity based private key and encrypt it with a public key generated in the Drey Proof of Life App operated by the Drey Investor.
The public key encryption is necessary to secure the client secret share so that no party, including any intermediary relay, can obtain access to the share.
Drey Actuaries will also provide shares of a server secret to each other Drey Actuary so individually, each Drey Actuary will be enabled to run the M-Pin zero-knowledge proof multi-factor identity verification protocol with the Drey Investors on their app during the Proof of Life operation every month.
Note the Drey Actuaries do not need to co-ordinate with each other to issue client or server secret shares, a DTA simply responds to the request from the Drey Proof of Life App or other Drey Actuaries for a share.
Initiative / goal
This is a critical objective that is central to user authentication so that they can obtain account information/balances over Nostr from DAC instances and proof liveliness to DAC instances in order to receive monthly annuity payments.
Hypothesis
An end to end workflow where the Drey POL app is able to enrol for a client secret, obtain shares from each enrolled DAC instance, initialise the secret with FaceID/PIN combo locally in the app, store the token, then performa authenticate flow: reassemble the secret, generate zero knowledge proof, send the zkp to any enrolled DAC instance, and have the DAC instance verify the zkp.
When the DAC instances initialise and join the group, they must generate a DTA master secret. From this master secret is generated a server secret share, and client secret shares. It must distributed its server secret share to all other DAC instances, whereby all other instances upon receiving all issued server secret shares generate the complete server secret.
Acceptance criteria and must have scope
As described above, both initialization and authentication flows must be successfully enabled from within both iOS and Android apps connecting to DAC relays. DAC relays must successfully issue client secret shares to each iOS and Android app initialised post install and post verified identity (to use hashed ID information) and server secrets to each other.
Working code will be open sourced, and a new NIP proposal submitted.
Stakeholders
This is core functionality affecting all systems, and needs to be at the top of priorities.
Description
Drey Actuaries will act as Distributed Trust Authorities, acting on requests from the Drey Proof of Life app to issue shares of a Type-3 identity based private key to randomised identities enrolling in the fund.
Drey Actuaries respond to a cryptographically secured request from the Drey Proof of Life App to generate a share of this identity based private key and encrypt it with a public key generated in the Drey Proof of Life App operated by the Drey Investor.
The public key encryption is necessary to secure the client secret share so that no party, including any intermediary relay, can obtain access to the share.
Drey Actuaries will also provide shares of a server secret to each other Drey Actuary so individually, each Drey Actuary will be enabled to run the M-Pin zero-knowledge proof multi-factor identity verification protocol with the Drey Investors on their app during the Proof of Life operation every month.
Note the Drey Actuaries do not need to co-ordinate with each other to issue client or server secret shares, a DTA simply responds to the request from the Drey Proof of Life App or other Drey Actuaries for a share.
Initiative / goal
This is a critical objective that is central to user authentication so that they can obtain account information/balances over Nostr from DAC instances and proof liveliness to DAC instances in order to receive monthly annuity payments.
Hypothesis
An end to end workflow where the Drey POL app is able to enrol for a client secret, obtain shares from each enrolled DAC instance, initialise the secret with FaceID/PIN combo locally in the app, store the token, then performa authenticate flow: reassemble the secret, generate zero knowledge proof, send the zkp to any enrolled DAC instance, and have the DAC instance verify the zkp.
When the DAC instances initialise and join the group, they must generate a DTA master secret. From this master secret is generated a server secret share, and client secret shares. It must distributed its server secret share to all other DAC instances, whereby all other instances upon receiving all issued server secret shares generate the complete server secret.
Acceptance criteria and must have scope
As described above, both initialization and authentication flows must be successfully enabled from within both iOS and Android apps connecting to DAC relays. DAC relays must successfully issue client secret shares to each iOS and Android app initialised post install and post verified identity (to use hashed ID information) and server secrets to each other.
Working code will be open sourced, and a new NIP proposal submitted.
Stakeholders
This is core functionality affecting all systems, and needs to be at the top of priorities.
Timeline
First before others.