In the eventuality that a PIS database compromised, all of the SSO credentials that have been associated with the user accounts would be usable to query any data in the corresponding APIs that the credentials are authorized to access. This would be somewhat mitigated for APIs that restrict requests to come from a given domain, but in the event that the database for a PIS is compromised, the PIS server itself could also be compromised.

Context: As users login to Opus they will make use of their Proof of Account Ownership verifiable credential (VC)- allowing them to demonstrate that it is in fact their account.

Opus will allow users to login solely with their wallet credentials, meaning that you do not need a username and password to get into the system everytime.

Issue: Currently there is no functionality to support verification of Proof of Account Ownership VCs.

Next steps: Familiarise yourself with Streetcred; this tutorial in particular illustrates the flow we expect user to undergo when signing up, and then attempting to log in to Opus: http://merged-demo.azurewebsites.net/

Implementation of the desired user flow:

1. User navigates to Opus.
2. A QR code is presented upon clicking login.
3. Scanned by the user, which triggers a verification. This verification checks the VC held in the user's wallet against the registered accounts held in Opus' database- this is currently a Postgre DB in the main server.
4. If the VC matches a registered username/email within the user database, they are logged in as that account.

Note: Create a dummy Opus organisation and a dummy credential definition to work with until this issue is solved.

For reference the starter code for the SSI branch is lifted from: https://github.com/streetcred-id/iiw-demo

In addition to being an attractive target for hackers, storing these SSO credentials presents an interesting trust problem from the perspective of more privacy-conscious users.

We are just committing to the user that we are not storing their information. We are not providing strong guarantees, cryptographic or otherwise, that we will not use this information for our own gain.

Especially for more powerful SSO integrations, such as bank accounts, it might be hard to convince folks to trust us.

Context: If a user no longer wants to use Opus and wishes to deactivate their account there needs to be a user flow to allow them to do this.

On the SSI-Streetcred side this is represented as a revokation of the Proof of Account Ownership verifiable credential (VC) held within their wallet.

Issue: Currently there is no functionality to support revokation of Proof of Account Ownership VCs.

Next steps: Familiarise yourself with Streetcred. These reference points may be useful for working with credential revokation: One and two.

Implementation of the desired user flow:

1. User selects account deactivation in the Opus front end.
2. They are removed from the User database in the Opus server.
3. This triggers the revokation of the Proof of Account Ownership VC from their personal wallet.

Currently, when you save a python file on the server that causes a syntax error, it crashes the docker container, and you have to restart it. Ideally, it would continue trying to hot-reload the application without requiring you to restart the container.

server_1  |  * Debugger PIN: 128-930-505
server_1  | 172.20.0.1 - - [17/Mar/2020 17:16:16] "GET / HTTP/1.1" 200 -
server_1  | 172.20.0.1 - - [17/Mar/2020 17:23:40] "GET / HTTP/1.1" 200 -
server_1  |  * Detected change in '/server/run.py', reloading
server_1  |  * Restarting with stat
server_1  |  * Debugger is active!
server_1  |  * Debugger PIN: 128-930-505
server_1  |  * Detected change in '/server/run.py', reloading
server_1  |  * Restarting with stat
server_1  |   File "/server/run.py", line 6
server_1  |     if __name__ == "__main__"::
server_1  |                               ^
server_1  | SyntaxError: invalid syntax
private-identity-server_server_1 exited with code 1

Based on this readme template, we should improve our readmes across all OpenMined projects.

Please consult the following document for our desired best practices.

Context: We will be using Streetcred as an easy way to get up and running with a Hyperledger Aries cloud controller and wallet. Streetcred has a number of different concepts which we will be required to implement:

• Organisations: Act as the issuers of verifiable credentials (VCs).
• Credential definitions: Define the format which VCs can take.
• Verification templates: Define what data to request from a wallet when a verification is required.

Issue: Unsure on how these entities should be managed across the development efforts, and how their credentials, e.g. the access tokens for an organisation, should be shared.

• Is it best practice that each developer will have a dummy organisation, and set of their own templates?
• We will need to create a master account which represents the true Opus account for when users begin to sign up. Who owns this account? Can we add multiple developers to this account?
• How flexible are credential definitions to modification further down the line?
• Do you want a single master credential definition for each usage pattern or can you have duplicates? Does it make a difference?

Next steps: This is a discussion point more than anything and so thoughts and feedback would be greatly appreciated.

One of the cornerstones of success in this project is to ensure that a given account is verifiable as a unique individual, as bolstered by various third-parties. However, if person A shares their OMPIS account with person B, and person B is then able to act on behalf of person A, then we reduce many of the important guarantees that are necessary for this app to function.

One of the most important use-cases is in-person validation of data. How do we prevent person B from logging into person A's account and having person A's data validated instead of their own? Even if we do something along the lines of "locking down" the application to a single account per device, what's to prevent someone from sharing that device?

If we only rely on SSO-based API integrations, we won't be able to provide very strong guarantees of identity. Unfortunately, most of these APIs do not provide information that they verify in a meaningful way.

However, thanks to GDPR and other legislation, almost all user data has to be accessible via at least a web UI in order for applications to comply with the restrictions placed on them.

In the long run, it would be great to have a more direct way to access this information, but in the short run, we can build tools for web-scraping that will help us get much more meaningful identity verification.

There are a number of architectural decisions to make here. Let's discuss potential ways of accomplishing this here. I've reached out to a friend who has recently built a fairly sophisticated client-side web scraping system that will hopefully be able to provide further insight.

Architecture proposal

For web-based users:
We could build a Chrome/Firefox extension that hooks into our backend servers via websocket. This would allow us to "drive" the user through the necessary steps to grab information from third-party services. We'd definitely want to think through fraud prevention there, as blindly trusting client-side data is rarely a good idea. Our best bet would be to actually use the extension to effectively "sniff" on the API requests providing the information to the page (not sure how this is possible, but I have it on good authority that it is, at least with Google Chrome extensions.)

For mobile users:
This will be a poorer UX for sure, but for accessibility purposes, it's very needed. A react-native application that effectively renders a webview and then accomplishes the same goals as the above application via more "usual" web-scraping techniques (reading the HTML) will be necessary. The good news is, within a signed mobile application, it's much harder to fake the data we're retrieving, so there's less need for extensive fraud prevention measures. In addition, it might similarly be possible to sniff web requests within an iOS/Android webview, which would make our scrapers much more resilient. Either way, it would similarly need to be driven by a real-time connection to our servers.

In every online-enabled system, fake accounts run rampant. If we're using primarily SSO for verifying a user's individuality, even the strongest SSO accounts integrations for identity verification ( i.e. banks) could be fraudulently acquired.

For example, as an individual in the US, I could have bank accounts with 3 banks, each with SSO. I could sell access to two of those accounts to others, who could then use those accounts to bolster the identity of a fake account.

Make sure we account for CORS (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS).

Ideally, we should handle app-wide configurations in one place so as to simplify the various requests that will be sent to the API throughout the application.

This will require changes to both client and server.

We'll need to extend the user model to store the credentials for each new SSO provider.
We'll need to ensure we're creating a session for the user after the SSO has occurred.
We'll need to integrate this with the client application.
Ideally, we'll lay foundations that will make it easier to extend the application to include additional SSO providers.

We'll treat querying data from each SSO provider as a separate task.

Where?

Main readme

Who?

All contributors

What?

Users of this library should have a good idea of where to get support within Slack so that the general channel does not become a place for people dropping software implementation problems. Please add the following section somewhere in your readme:

## Support
For support in using this library, please join the **#lib_opus** Slack channel. If you’d like to follow along with any code changes to the library, please join the **#code_opus** Slack channel. [Click here to join our Slack community!](https://slack.openmined.org)

When finished, it should look exactly as it does here: https://github.com/OpenMined/.github/blob/master/README-TEMPLATE.md#support

Additional Context

None

If we allow for multiple, entirely decoupled deployments of the PIS system, we open up the following possibility:

Let's say we have an application that is attempting to use the PIS system to verify a positive COVID test result within the past two weeks in order to distribute aid to that person. They have a SSO with PIS feature that supports the OpenMined-hosted PIS and the Amazon-hosted PIS. User A has tested positive with COVID a few days ago.

He signs up for the OpenMined PIS and verifies his test results there. Then, he has his friend sign up for the Amazon-hosted PIS, but he then links his test results account to his friend's Amazon PIS account, and his friend signs up for receiving aid and gets it.

Context: This is the creation point for the Proof of Account Ownership verifiable credential (VC). As users sign up to Opus a VC will be issued to them from the Opus organisation.

This VC will act as Proof of Account Ownership, and can be used in either a two factor authorisation (2FA) login pattern, or by users to login without a username and password using simply a QR code or unique URL.

Issue: Currently there is no code to support creation of Proof of Account Ownership VCs.

Next steps: Familiarise yourself with Streetcred, and the tutorials/demos they have themselves. This tutorial in particular will take you through all of the concepts required: https://docs.streetcred.id/docs/tutorial

Implementation of the desired user journey:

1. User registers their account through the Opus front end.
2. Upon account creation a QR code or URL is displayed on screen.
3. QR code/URL is consumed and the new Proof of Account Ownership VC is added to the user's wallet.

Note: Create a dummy Opus organisation and a dummy credential definition to work with until this issue is solved.

For reference the starter code for the SSI branch is lifted from: https://github.com/streetcred-id/iiw-demo

In addition to integrating with a number of Single Sign On (SSO) providers within our application, we also need to be an SSO provider ourselves to allow for applications to authenticate with our system for subsequent data requests.

We have identified https://authlib.org/ as a library that will allow us to accomplish this.

Also, it would be nice to have an example of actually signing in via this newly created SSO provider in a separate application. This can be a simple client side application that handles that process.

I don't have the most experience structuring flask apps for sustainable long-term development. I would love feedback on the current structure from someone who has more flask experience.

• Add a "Hello, world" endpoint to the external API section of the application (with a parameter and JSON return value, just so it has something somewhat substantial to document)
• Set up Swagger in the project (see #6 for details on good tooling options for Flask)
• Document the aforementioned "Hello, world" endpoint
• Expose documentation to the public in some way (either served by Flask or a separate container that hosts it in the docker-compose setup would do)
• Add a section to the Readme detailing the basics of documenting endpoints

SSO Providers

I want to go ahead and start fleshing out my thoughts on which SSO providers we should look at, and examining the value they each bring for each of the primary goals of this project:
a) Identity Verification - how much value will this service provide for the purpose of verifying the validity and uniqueness of the person in question?
b) Data Verification - what data does the service provide access to, and have they taken any steps to verify this data?

As I’ve been digging into the various APIs, I’ve been realizing that there’s very little formal validation for many important attributes about a person. And even when a service does do more formal validation they don’t actually expose any of the corresponding data via their API, as it’s not terribly relevant for most of their use cases. See the Coinbase section for a great example of this. Even services that have a very robust identity verification component (i.e. √) do not allow you to access that information via their API, even when other quite sensitive information is exposed.

Given that’s the case, I believe that the most utility we can gain from the existing SSO providers will be for use-case a). If you have 10+ SSO accounts, including ones that verify your identity behind the scenes, such as banks/Coinbase, and ones that have fairly-sophisticated anti-botting mechanisms, such as Facebook, your proof of identity will be quite strong. In contrast, if you just sign up with Facebook and Twitter, you’ll not have a very strong identity. This is why making it very smooth integrating all of these SSO providers is so crucial.

So, in the interest of opening up the discussion, what SSO providers would accomplish this?

Here are some I've researched already:

Facebook

None of the fields we can get from facebook are verified, and therefor the transmission of this information is not very useful. However, the fact that they have anti-botting measures in place mean they are decently useful for verification of individuality, especially in contrast to a more botting-friendly platform, i.e. Twitter.

Twitter

At face value, and for unverified accounts, we can glean very little information from Twitter. However, accounts that are of public interest can be verified, which allows for verification that the individual in question has access to a verified account. This could be very useful as a proxy for
showing that folks have some certain access levels for certain public institutions. Probably not strong for use case a), though, as typically more than one person has access to these verified accounts, and they're tied to organizational identity as opposed to individual identity.

Coinbase

Age verification for Coinbase accounts, see https://help.coinbase.com/en/coinbase/getting-started/authentication-and-verification/identity-verification.html), In fact, they only require a phone number until you invest over a certain amount or want certain other features (such as transferring currency to another Coinbase user.)

Banks

This is about as good as it gets in the USA for b). Due to federal regulation, bank account holders are required to be above 18 and state ID. Therefore, if you SSO into your bank account, we can make a single call to verify you have an active account, and voila, we've got a pretty strong proof of identity here. As for a), while many individuals have bank accounts with more than one bank, this is still a strong proof of individual identity.

https://developer.bankofamerica.com/CPODevPortal/apidocs/public/#/get-started

There are plenty more to discuss.

One of the main goals of the project is to expose end user data via a public API. A major part of this effort will be setting up a way of documenting this API effectively.

It would be great to have a couple of options as to how we could accomplish this to choose from.

The solution we want should have:

• great UX for consumers of the API
• a way to allow for multiple versions of documentation to be hosted simultaneously
• should allow for us to document both the API endpoints as well as general system-concepts
• should be easy to host
• should be open source

Nice to haves:

• "try this endpoint out" functionality that allows you to hit the API with credentials from your own account (assuming you're signed in)

As the platform grows and scales, we will have a large influence in which applications are able to expose data through our system. Every integration we build/enable could be a fraudulent one. In the case of an application providing data, say a contact tracing application that inaccurately reports that users of the app have not been in contact with the virus, this would enable users to fraudulently claim something untrue about themselves.

In the case of applications which are consumers of data, they could ask for identifying information within their app and, through our integration, collect and store sensitive information about the individual.