ronakshah2895 / pride Goto Github PK

Hi PrIde,

The idea is great and I look forward to it.

I have worked on implementing a blockchain project before and some issues you will encounter are the following:

• Hyperledger doesn't maintain smaller projects very well. My team was implementing Hyperledger Iroha for a mobile app driven blockchain project in Spring 2019, and it was very painful for me. The main reason was that outside Hyperledger Fabric, the other hyperledger projects don't have a strong community around them. When my team and I tried asking for help on various forums, we received no help. Its because there was a blockchain boom and bubble with 'get rich quick' mentality in 2017/2018 and these projects had engineers actively working back at that time. Today, its a different scenario and many startups used up their Seed and Series A funding with no subsequent venture funding to push them forward. Please start early. My team faced a lot of issues and had to spend hours looking at simple issues around setup and getting a basic sample project running.
• Start early. My team and I tried to put 3 docker containers in AWS that ran Hyperledger Iroha, the frontend, and our backend node server. After lost of digging we found that Iroha had GRPC within the environment it was operating in. Connecting the 3 containers together and then making the routing work with the RPC within Hyperledger took a lot of time. I would highly suggest that you assign 1 person solely responsible to make sure the Hyperledger Indy example project setup works, the AWS setup works, the public and private routes within Hyperledger Indy are pointing to the endpoint (it wasn't obvious for my team), look into the APIs Indy gives you, and then how those APIs will connect to your project. That was my team's biggest problem in past.

I am not sure what planning on using but I suggest using crypto-js.

Other than those things, I don't see much issues. I am guessing the react, node, and DB parts won't be a big issue.

I am not trying to scare you, but seriously, Hyperledger was stressful enough that at one point I thought I won't graduate from undergrad because I was doing this as my senior project and the project won't work. In the end, we got it to kind of work.

Just start early. I don't know your team's background and you might have done this successfully in the past but I am just trying to help because no one warned my team of what we were getting ourselves into and the outcome wasn't very fulfilling for me.

Hi PrIde,

I am guessing via APIs you will transfer the credentials between the issuing authority, the user, and the verifier organization.

I didn't see a UI diagram uploaded to your github repo in an image or pdf format, so it's not clear how you intend to transfer the 'credential key' between these parties.

I am guessing its like this?
Issuer -> SHA256 -> user gets the hashed key. The same key is also put into the blockchain. Then when the user gives the key to the verifying authority, the verifying authority checks for the key in the blockchain and if it matches, it transfer's the user's details to the verifying's authority?

I am not sure how this will work from the web UI side. Will there be a login and then the user has a pin to unlock the process to transfer the key to a list of organizations that will then verify the data in the blockchain?

What stops someone in the verification authority to use that key to go to the issuer and 'pretend' to be the user and update the user's information to something wrong? Or does the user get 2 keys from the issuer authority and the public key is what the user gives the verification authority and the private key is used by the user to update/alter information in the Issuer's system? The private key is then mapped to the SHA256 hash internally inside the Issuer's system?

In my undergrad project, my team and I had to think about some of these issues and the handling of the keys. It became cumbersome for us during implementation. I didn't see a UI design document on your repo so I don't know how it works so I raised this issue.

· Hyperledger Indy:

Aligned with the requirement of decentralized identity. Try to explore Fabric, since it's flexible and has companies and a larger developer community.

Look at this:
https://hyperledger-fabric.readthedocs.io/en/release-1.4/tutorials.html and you will see that Fabric and CouchDB has integration.

· Docker containers to simulate nodes:

Docker tool is not specified. Will you be using container orchestration tool such as Kubernetes, Mesos, Flocker?

· Python/Node based framework as backend language:

Node.JS is the better choice. This is because of cryptic.js and its use case relevance to your project since its related to identity and security.

· React/Angular based frontend

No UI design is shared by the team which makes it difficult to visualize how the frontend is going to look like.

Also, the tech stack mentions React/Angular based frontend, but in architecture diagram ReactJS logo is provided which makes technology choice more uncertain. According to me, if you prefer TypeScript then opt for Angular, if you need to build a single-page application then choose Vue. Angular is more self-sufficient and follows straight forward coding strategy, while React is more flexible, has fast learning curve and more stable compared to Angular. React help and developer community is wider.

· PostgreSQL/MariaDB as relational database:

Aligned with the requirement, but final choice is expected to be updated. The html link I posted above shows various tutorials around Fabric and CouchDB. I suggest you check the viability of using those for your project and check to see if the tutorials are enough for you. If they are, its a smoother path.

Indeed a really nice idea of having a decentralized store of identifications for authentication but the problem statement could be articulated in a better way. I think using blockchain for authentication will increase user adoption and productivity rather than saying it will "provide granular control of identity information to any organization". self-sovereign identity would solve a lot of regulatory problems (like GDPR) for many organizations. Nicely explained in the following article Decentralized Identity: An alternative to password-based authentication.

Current authentication systems using SSO and AD are quite secure and provides organization control over what data to be shared with third-party service providers. So why would any organization adopt for decentralized authentication? Will this Implementation discard password-based authentication?