Collecting data from API registration workflow

[emmambd]

We need to store the contact data collected in the form that users see when they register for an API account.

[davidgamez]

Task:

• Integrate GCP Identity platform with the registration screen.
• Launch Github and Google registration flow(Oauth).*
• Agree and set credential policy.
• Customize registration email.
• Implement redirect after successfully signing in.

[fredericsimard]

Here are my recommendations:

• Passwords should be at least 12 characters long, ideally 16, of letters and numbers. If it were only letters than it's better.
• Ideally no upper limit, I hate it when they put limits like 63 or 74 characters.
• The password being stored should be hashed and salted, as you might know.
• The hashing and salting string and algo used to hash & salt should not be stored on the same server, ideally†.
• SSO and passkeys doesn't need any of that.
• The very best would be that all personal information (first, last names, email, etc) are encrypted at rest, not only during transit. That's another effort we can show the authorities we did to protect users' info.
• Anything else you think of that can goes in the same direction, the better. And we need to document all that, especially for the Data Management Policy.
• Below the registration box, there has to be a link to the privacy policy (Law 25), or a checkbox for them to do the action of giving consent (GDPR) is even better. Under Law 25 it is assumed you agreed to the privacy policy by seeing the link ("by clicking Register, you give your consent to the privacy policy" or something along those lines), but in Europe it is not, users need to make the action of consenting to it.
• We need to store when and what a user gave consent to, and province/state + country (to know which laws apply to them, not know where they live).
• Oh, forgot: access to this data about users should be limited to only those people who have an actual need to. Even better, if 2 or 3 people are required to give their approval before the data is decrypted and shown in plain text that would be almost perfect.
• Another thing I forgot: if you send an email to confirm their email address is valid, in that email it needs to state clearly that they received it only for this purpose, that this is not a registration to a newsletter, or will receive emails other than when it's related to the service they just subscribed to.

Ideally and like I mentioned to David, one place to store all of that information on users, including subscriptions to newsletters and other services, would be great. In other words, if the supervising authorities ask for a detailed report, we should be able to do it easily without querying multiple locations that have different ways of organizing the same data.

I know it's a lot, but I believe it is required not only because of laws, but because it's the correct thing to do.

† I believe we can accomplish this with 1Password and a service account.

[davidgamez]

@fredericsimard

• Passwords are being stored on the GCP Identify Platform; there no concern about saving hashes and salts as it's already handled by the service.
• In the consent section, we are not currently asking for the users' province/state + country. I am inclined not to store this information as we don't need it for now as part of the services. Adding extra information will add "risk" that might not be justifiable just for auditing purposes.
• We can define a password policy with any requirement.
• As MVP I'm not sure if we can have a single place for all agreements, subscriptions, etc. Let's review the use cases individually and the current systems/platforms that we manage.

[fredericsimard]

Passwords are being stored on the GCP Identify Platform; there no concern about saving hashes and salts as it's already handled by the service.

Awesome!

In the consent section, we are not currently asking for the users' province/state + country. I am inclined not to store this information as we don't need it for now as part of the services. Adding extra information will add "risk" that might not be justifiable just for auditing purposes.

We might need it in cases of audits actually. In order to know which law applies to a specific user, we need to know from where they agreed to it. European authorities are as likely as any other to knock on our door, the laws applies based on where the users are located.

I was thinking of using their IP address to get a location, no need for them to provide it. No need to store the IP either.

We can define a password policy with any requirement.

I'm not sure what you mean by that?

As MVP I'm not sure if we can have a single place for all agreements, subscriptions, etc. Let's review the use cases individually and the current systems/platforms that we manage.

Could we pull that data from all these places and aggregate it into one place? This is only for ease of use of MobilityData staff, no one else.

[davidgamez]

I was thinking of using their IP address to get a location, no need for them to provide it. No need to store the IP either.

Let's review this solution and how we would like to implement it.

We can define a password policy with any requirement.

We just need to agree on the rules. Let's connect and define the policy. Here is documentation on how to do it https://cloud.google.com/identity-platform/docs/password-policy#enable_enforcement.

Could we pull that data from all these places and aggregate it into one place? This is only for ease of use of MobilityData staff, no one else.

We can do it. I'm suggesting keeping it outside of the scope of this issue as this issue is only about the feeds API registration process.

[davidgamez]

Blocked by #118