Monty API Authentication, Authorisation, T&Cs and External Data Licenses

[hamishwp]

We need:

1. UI to ask users to accept T&Cs and can be linked to the license of each database pulled into Monty
2. Add field to Users to accepted_monty_terms, including another field for RC data access authorisation (e.g. exclusive access to Field Reports)
3. GO issues JWT token for user
4. Monty API uses shared secret to validate token

For point 2, we also need to build in the ability for users to insert external database tokens and their usernames that can be used to allow the user to also extract data from non-open access database (such as EM-DAT). However, need to be careful about storing these tokens...

[batpad]

For point 2, we also need to build in the ability for users to insert external database tokens and their usernames that can be used to allow the user to also extract data from non-open access database

Can you say more? Do you mean the user needs to be able to store their access credentials for an external database, that would then be used to query that external database on the fly? We can encode some idea of access rights or permissions into the token, but encoding usernames and credentials to external databases seems a bit non-standard - would be good to understand the use-case better.

[mariam-yu]

@justinginnetti @LukeCaley @hamishwp (cc @tovari):

Here are 3 directions we can take with the terms & conditions on the GO website accounting the current UX:

Scenario 1 - “Forced acceptance of the terms”
For anyone landing on the website, there would be a popup to ask them to accept the conditions. It would then save the acceptance into cookies. We could also potentially save them to user's profile once or if they login.
This is a forced user flow, as users have to make a choice before proceeding to the website.
Cons: users are usually reluctant to accept terms online, especially without fully understanding what they are. It also may be a strange experience if they don't accept, since they will technically still be able to browse the platform, but without seeing certain datasets.

Scenario 2 - “Soft acceptance of the terms”
Not forcing the user to go through the popup, but having a cookie-style banner for users to accept or not. They can still browse the website, but until they accept they won’t see the datasets and the banner will persistently stay.
Cons: same issues as above regarding not showing datasets if they reject, while they may not fully grasp the idea. The users tend to reject things online if possible.

Scenario 3 - “Auto-acceptance of the terms”
No action is needed from the user. Just a notification that just by using the site they accept the terms. If they don’t want, they need to leave the site.
Cons: The users don't have a say in it. They are sort of forced into accepting the terms by using the tool. This may be acceptable if the terms are not so restrictive or require their personal data.

Unless we need an explicit consent, the third option is the best and least invasive. The banner will be treated like the cookie banner, meaning it will be stored in user cookies and may reappear only if the users clear they cookies or load the site for the first time.

We can, in addition, expose further terms and condition regulations to registered users, especially given that they get access to more and more sensitive data. As such, we will need a checkbox upon registration that the users must accept to register. The link to terms will lead to another page with the actual content.

We shall also have a more permanent link to that terms page in the footer of the platform.

[justinginnetti]

Okay, thanks, @mariam-yu . I also prefer Option 3, plus the "checkbox upon registration" for new users that you proposed above.

[udaynwa]

Linking JWT token integration with Montandon discussion here

IFRCGo/go-api#2029

[hamishwp]

6th Feb Meeting Summary

Initial clarification: acceptance of the T&Cs is not required unless:

1. the user wants to have a Monty API token to download the data directly, or
2. the user wants to download the data from any of the plots or data visualisations directly from GO (this functionality will be built later on)

What we need to build is the following:

• Back end - JWT token generation, including the 'inMovement' variable in the payload
• Back end - Link the JWT to the user profile, their authorisation levels and information in the payload
• Front end - build T&Cs page, based on a tabular data file that can easily be updated when new data sources are added.
• Front end - integrate into the GO user profile the ability for the user to generate an API token, which requires accepting the T&Cs of all external and internal organisations
• Front end - Create the ability for non-GO users (thus people not in the Movement) to also generate a Monty API token. This is not at all clear to me how to do this. @LukeCaley @justinginnetti let's make sure to chat about this.
• Back end - save and integrate into the users GO experience whether they have approved the T&Cs or not (this will be required later when users can actually download data from GO)
• Outreach - @justinginnetti please check with the partners of whose data we already have in GO about the future plan to allow users to directly download their data

For the 5th point, I propose the following: create a survey (inside GO if possible) that allows an external user to sign up for a Monty API key, then, once we have approved it, we send them the API key to the email address they signed up with.

Thank youuu!

@samshara @frozenhelium @udaynwa @mariam-yu @batpad @tovari @nnjemie