mosip / documentation Goto Github PK

Have a look at this PR: mosip/id-authentication#2

There is a bug identifier MOS-30337 and no description of the issue whatsoever. It seems to refer to a separate issue tracker that I can't find a reference to on the site.

Similar instances here:
mosip/commons#7
mosip/commons#6

Some of these PRs are being merged as well: mosip/commons#2

Can you please enumerate all the forums where issues are tracked, discussed and debated? This should include forums, chat groups, mailing lists etc. This will be essential for the community to feel welcome and engaged via transparency and inclusiveness.

Taking off from the engagement proposed by MOSIP at IndiaOS Conference last week. Please note that my views are personal and not reflective of IndiaOS which was just a volunteer run conference.

So it is great that the repository is opened and this is just the first step to build a community project and shows great intent. The next step is to align interest in the community to contribute. This will be a gradual process, here are a few suggestions:

1. Publish a list of things you need help for (could be bugs, features, documentation).

2. Announce small bounties to attract developers, amounts that would attract students or freelancers, like Rs Rs 5,000, Rs 10,000 etc based on the size of the activity. For example checkout this issue on our project frappe/frappe#6989

3. But beware money may not be enough motivation (for example, there is $2500 sitting for our team to take, but we have not done it yet). Ultimately true hackers want to contribute if there is something they themselves are impacted by. Scratch your own itch is the number 1 motivator for true hackers. For this I have 2 suggestions:

   1. This project is too big for anyone to meaningfully understand its impact. Break this up into smaller units so people can use this ID system in organizations, like IIITB.

   2. Use your good connections with UIDAI so that they are committed to use one non-critical module of MOSIP in the Aadhaar infra. There will be 100 objections to this, but I am proposing this is a very small move to build trust. This has to be a non critical module and can come with its riders. But this will show a lot of intent. Once this is done, you will see a lot of interest.

Open Source is not about getting free labour of hackers, it is about building communities and we can only build communities if we aim for the middle ground.

If you really wish for MOSIP to be a community tool and not an establishment tool, then I hope you will give these suggestions some deep thought. These are not radical ideas, just baby steps.

We (and I hope I can speak for the community here) are not asking for making the full UIDAI codebase open yet, but you should know that is where we want to eventually be, and we don't want to hide this intent. We can expect this will take many months of consistent effort and trust building if we eventually get there. But many of us want to reach this consensus.

But remember, you are the establishment, you have infinite more resources than individual hackers to can help you. This onus is on you to be more open, and we are here to help you in that journey.

Does MOSIP have an explict framework to allow citizens who are enrolled in the system to opt out of the system at any point and how their data will be handle / anonymized. Also related to "right to privacy" and "right to forget".

Such a built in framework will nudge governments implementing this to make this freedom available to the people.

Unable to access Data Model and Data Dictionary Files through link specified on https://github.com/mosip/mosip-docs/wiki/MOSIP-Data-Model

The links to file do not working.

Virtualized IDs are a way to ensure that the national ID is not used to connect a person across systems but is extremely inconvenient for a citizen to handle a new ID for every scenario. And even in this case, a centralized system can still link the virtual IDs to a single person.

Can an option to let the system accept multiple IDs for the same person be evaluated?

It would mean that it would not be possible to "uniquely" identify a person, but it would still be used as a "proof of identity"

This would be like a person enrolling for multiple credit cards or bank accounts that are independent.

Unable to find deployment architecture of MOSIP

What is the version of "open source LDAP server" used in MOSIP ? This information is missing from technology stack

In Biometric SDK API, there is type called BiometricType in BDBInfo.
This is supposed to be SingleType right?

Hello folks,

Firstly we appreciate your opening up this code base. Its a great first step and thank you for your willingness to engage. I would like to raise a more fundamental issue that is important to the architecture of this project.

Do we need a centralized identity system?

Some of the major problems I can see are:

• The tool assumes that a government entity is aligned with the needs of its people.
• The tool assumes that partisans will not use such a system to systematically target its political opponents.
• The tool assumes that it will be used for empowerment rather than discrimination. Any tool that is used to "authenticate" a welfare service, can also be used to "deny" it.

How do the creators of this project view these ethical dilemmas? Will this result in inadvertently creating a tool for authoritarian and tyrannical regimes to oppress its opponents?

Are the alternatives effectively debated? Will the citizens of the countries implementing such systems have consent in adopting it?

Will be happy to get some answers here!

Any project like MOSIP should also have a consent framework for citizens who should have the right to choose whether to participate or not in such a system and to what extent (for example consent for taking in biometrics, consent for address information etc).

I understand MOSIP cannot guarantee its implementation but having such a framework will make governments think about the concept of explicit consent and the consequences of dealing with situations where citizens refuse to give consent.