As identities now have multiple email accounts, the email field is no longer used in the search for identities. It should search in the related emails of an identity, not in their email attribute.

When an auditor exports an audition listing (csv, xls) a checksum must be generated, shown in screen and logged.

This is done to prevent the auditor from modifying the file afterwards and claiming it has been modified by us or something.

Provide a basic oAuth API (app keys and secrets) and try it out with curl.

Then create a set for @DemocracyOS and get them to @cristiandouce

Access tokens are not currently removed on the database, so that means an incremental grow.

A cron job should run to remove the deprecated ones.

All actions performed by users on the NetID platform should be logged in an auditable fashion.

In essence, we should log: WHO did WHAT, WHERE and AT WHAT TIME.

For each logged action, we should consider at least the following:

Who

• IP
• User agent
• NetID user

What

• Performed action (e.g.: authorized, created identity, etc.)
• Affected identities by action (if any).

Where

• GeoLoc of user agent, if avalable.
• Venue associated to user if available (i.e.: office name)

At what time

• timestamp of performed action.

Many features were added but README.md file is still the default Symfony2 text.
Update it to include new configuration and functionalities.

Add wiki pages, too.

Currently the login page is the FOSUserBundle default login page.

This issue consists in give a PdR style to this page, including the colours and logo.

Provide endpoints for client apps to know if a user is validated to perform a given action (i.e. verb).

Auditors should be able to audit activity on the NetID platform.

Specifically, auditors should be able to:

• List all activity performed on an identity
• List all activity performed by a user of NetID.
• List all activity performed on the platform.
• Download a csv of any of the previous lists.

Considerations

• Auditors should not be able to perform any kinds of editing. Unless they are also Operators or a more privileged role.
• Actions by auditors should be auditable as well (i.e.: logged). Yes: all searches, downloads, etc.

Add missing translations for spanish locale

Operators should only be able to validate registered, unvalidated identities.

In order to do this an Operator should be able to:

• 1. Find an identity by legalID name, or email. . If an identity exists for a given, complete entry, it should display. If not, a "no identity for given data" message and prompt the Operator to create a new user for a Citizen. Form should resemble the one described in 2.
• 2. A form for editing existing values on the ID and adding those required but missing (e.g.: legal address, complete names, etc.) that submits data as validated individual. This should open when clicking on a search result from 1.
• 3. Mark an identity as "suspicious". This is for cases when another user might have mistyped his legalID and the same number is registered for two different users. An Operator here should validate the proper user and mark the other one as "suspicious".

Considerations for 1.

• If a given legalID search yields more than one result, consider 3.
• If an Operator creates a new, validated identity, when search doesn't yield a result, that entity should NOT be email-validated for client apps (i.e.: DemocracyOS) as users should still validate their email even if their identity is validated.

For a user to perform an action that requires real ID validation on a client app, NetID has to know a bit about these actions. These actions are what we call verbs.

A client app should be able to have verbs associated to them so they can have validated users for those verbs.

Let's start with a vote and comment verbs for @DemocracyOS .

We need to persist users in order to manage their validation status. For that we'll need a model.

V1, users should support:

• name: complete first, second, etc. names
• lastName: complete surnames
• birthDate: date of birth (use ISO date formatting)
• legalId: legal ID the user used for registering (e.g.: DNI number in Argentina).
• discrict: legal distric where the user is registered for voting.
• apps: collection of tuples with:
  • appId: id of the app the user is registered to
  • foriegnId: id of the user in the third-party app

For instance, the JSON for a user of @DemocracyOS should look like:

{
  name: "Carlos Alberto",
  lastName: "Toma y Araujo",
  birthDate: "1997-07-16",
  legalID: {
    name: "DNI",
    number: "29455231"
  },
  district: "Ciudad Autónoma de Buenos Aires",
  apps: {
    appId: "democracy-os",
    foreignId: "#12f2931ffa91"
  }
}

When an operator searches for an identity to validate, the result must not exceed a given number on the parameters.yml file

Roles and actions are now static, defined in the security.yml file.
They should be stored in the database and the admin should be able to assign each action individually to any user.

Identity validation may require an image upload.

Perform a log each time a user logs into the application.

• User ID
• Datetime
• Current roles at login time
• IP and fingerprinting info

Amazon S3 is required to store de log and possibly in the future upload identity pictures.

Each identity has many emails which may be validated separately

Many words are still only in english.

When a user is created, how are we going to validate their email and legal id (DNI)?

Logs will be stored in a separate MongoDB and will be listed as another Admin in the backend, available to auditor role.

Operators can access a search view where they enter email, legal id, firstname and/or lastname to search for an specific Identity.

The result will be a list of the matching identities and a button to validate each one of them, though they must be few (e.g.: a result can't be more than 5 identities).

Operator can press the validate button and a warning sign will be shown to make him understand that this action will be logged and prompting wether he's sure to proceed.

On acceptance, Identity will be validated onwards.

Add a minor description and License to Readme.md

Hello,

I looking at creating a voting kiosk at a 24hr Internet cafe and I am looking to integrate a voter card that is based on this
https://github.com/MrChrisJ/World-Citizenship

And also backed by a bitcoin load for its value at time of creation added to zeronet to keep its Decentralized nature while having the transaction impeded in a picture with a key it's meta with a checksum (sha512) to reduce counterfeit votes, voting ID and a valid login card that is equipt with more than enough security also including a password that is needed which could be your fingerprint as identified on the card.

If bitcoin is used to make sure you are successfully logged in (each time you login to vote you take bitcoin out of circulation to add transparency that you were at a voting machine) and it's history avaliable on Your on personal card with a photo in the card of you at sign up so multiple cards are not made and multiple votes are not made that can't be repaired if votes are cast to sway the vote and as it not being for military usage the system would know if you are military and ask at time of setup for a peaceful way of voting while non weaponisation of votes and policy that is not weaponised by military.

Please let me know if anyone is interested as well as keeping compatible with easily setting up another with security cam and fingerprint reader required

Photo of you taken at time of vote for validity and audit / self audit if used by organisation during each session of login for votes and at home browsing would use namecoin and zeronet until ready to go a kiosk that also uses namcoin and zeronet namcoifor decentralization and security with no downtime or the voting system being able to be shutdown with backups and a growing voter network that uses a network they can help at home with maintenance and reduce cost being en

• Log Identity creation
• Log Identity update
• Log Identity deletion
• Log Identity listing
• Log Identity exporting

The function apache_request_headers() might not work on production environment.

Got to check that, because it is used to get Authorization Bearer on the request headers.

Roles can be grouped into Groups. In other words, a group is a Roles container.

Define groups for:

1. Super admin user
2. Admin user
3. Operator
4. Auditor

Every time an operator validates an Identity, this action must be logged for future auditions.

If no root user is already created a new one must be created using the parameters loaded in heroku config variables.

Endpoint receives via POST method the email of the identity and responds a 200 status code if the identity is validated or a 403 indicating the error in the json response.

kudos @bastianhell

Steps to reproduce

1- Login on NetId as root
2- Select Identity from Content dropdown
3- Click Show action on any user

Result: 500 Error.

Original: DemocracyOS/democracyos#260